On 04/19/2016 03:05 PM, Georg Baum wrote: > Richard Heck wrote: > >> The other two 2.2.x-staging branches are entirely for book-keeping >> purposes. It is just easier for me to have the various fixes that are >> intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep >> track of them via milestones or keywords or whatever in trac. It's also >> easier for people to backport these fixes around the same time they did >> them than to do it weeks or months later. > Really? For me it does not make any difference whether I run the cherry-pick > command now or in two months. Testing has to be done in two months anyway, > it does not make sense to test something now that might be different from > what will be released. For me it does make a difference if I look at trac > and cannot relate a bug status to the different branches. It does also make > a difference whether I have to switch branches all the time locally (or > keeping five separate working trees to avoid switching) or not. I either > have to waste disk space (if I keep separate working copies) or time (for > recompiling after each switch if I do not keep separate working copies). > >> We're not really "think[ing] about four stable releases in parallel", >> and certainly I do not expect that the staging branches are going to get >> any kind of testing. Once 2.2.x is created, it will get testing, and at >> that point 2.2.1-staging will be merged into it, and then will politely >> disappear. Same, eventually, for 2.2.2-staging. > Well, the questions on the list (e.g. "May I ask why this (and other) commit > goes to 2.2.2-staging? When will it make into 2.3-staging?") show that we > are thinking about these releases now. > > I understand that these branches make it easier for you, but I believe that > they do also come at a cost (at least for me they do). If I could ignore > anything related to these branches I would be happy, but as it looks now > this is not possible (or I had to stop reading the mailing list, > investigating bugs, and fixing bugs, which I do not want).
As far as I can see, there is only one extra question that anyone needs to worry about, namely: Should a fix be committed that is committed to 2.3-staging also be committed to one of the two 2.2.x-staging branches? The 2.3-staging branch is just playing the role of master now. The rules for 2.1.x are as usual. So the only things that are really new are the 2.2.x-staging branches. I agree that it would be better if there were only one of these, but the plans for 2.2.1 make it useful to have two. But nothing is ever committed to both. It seems to me worth remembering how things were before these branches: No one commits anything except to 2.1.x until 2.2.0 is released. I understand that just having 2.3-staging would have been an option. Maybe I could have figured out some way to keep track of what needs to go where. But 2.3-staging is already a messy mix of stuff for 2.3.x and bug fixes, and it will only get harder to keep track of things. Mmaybe I should just have created private 2.2.x branches for my own purposes. But it seemed like a lot of work to cherry pick stuff. Richard
