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). Georg
