Hi,
[trimmed long explanation of how things are done today]
Antonio already showed that he can handle adhoc pull requests very well. Therefore, the idea would be to remove the two month extra waiting time. Here are just two random branch names:
- next - new patches are excepted here - so it is something like net-next
for batman-adv. Antonio will gather some patches and then sent them to David. Davids reaction will come heavy and hard... but the effort for an reaction is reduced.
- master - bugfix gathering place. So it is like net for batman-adv.
Patches will end up really fast in Linus' tree.
I am a little confused here. Our "next" branch will be the new "master" and the new "master" will be what "maint" is today ?
I also don't see the implementation of the new merge policy yet. David can only receive what we merged before but how do we determine what patch to merge when and how ? Up to now there was a simple rule (spawned from your head iirc): Features into master, cleanups into master, fixes for next into next and very critical stuff into maint. How is that supposed to work in the future?
One very vocal voice keeps telling me: Just merge everything into the "new next" - the rest will fall into place. No need to worry.
However, it would be great if your suggestion could be contemplated by such a merge policy. I don't see it yet. It would be even better if those who believe to know how it all will work out stepped up and took the job of collecting & merging the patches into the "new next". I certainly would not mind.
Cheers, Marek
On Thursday 06 December 2012 01:40:48 Marek Lindner wrote:
It would be even better if those who believe to know how it all will work out stepped up and took the job of collecting & merging the patches into the "new next". I certainly would not mind.
I translate: Not with me.
Kind regards, Sven
On Thursday 06 December 2012 01:40:48 Marek Lindner wrote: [...]
I am a little confused here. Our "next" branch will be the new "master" and the new "master" will be what "maint" is today ?
Ok, lets rename then:
* new_features (previously called next; in my first explanation called next) * rc_work (previously called maint; in my previous explanation called master)
I also don't see the implementation of the new merge policy yet. David can only receive what we merged before but how do we determine what patch to merge when and how ?
Stuff which will be accepted by David Báthory in his net repo: put it into rc_work. So small bugfixes
The stuff which will be accepted by David the Impaler in his net-next repo: put it into new_features. This includes non-next related cleanups, features, ... But no bugs. Bugs will not be accepted by the relentless David.
So it is the same as before but with the master branch removed
Up to now there was a simple rule (spawned from your head iirc): Features into master, cleanups into master, fixes for next into next and very critical stuff into maint. How is that supposed to work in the future?
Nope, not entirely. The master requirement was from you.
One very vocal voice keeps telling me: Just merge everything into the "new next" - the rest will fall into place. No need to worry.
Does this "vocal voice" has a name?
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org