On 05/10/2011 11:27 AM, Vincent van Ravesteijn wrote: > On Tue, May 10, 2011 at 3:21 PM, Richard Heck <rgh...@comcast.net> wrote: > >> On 05/10/2011 08:50 AM, Abdelrazak Younes wrote: >>> On 05/10/2011 02:12 PM, Richard Heck wrote: >>>> On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote: >>>>>> Third, when we switch to git, bugs will be fixed in branch first, >>>>>> then these changes get merged into master automatically. >>>>>> >>>> This is a separate issue, but surely this isn't true. Bugs will get >>>> fixed in git branches and merged into trunk, not fixed in BRANCH_2_0_X >>>> (or whatever it is then called) and merged into trunk. >>> Vincent meant that bugs should get fixed in git branches which were >>> *branched* from BRANCH_2_0_X, not from master. Those branches would >>> then get merged into BRANCH_2_0_X first and then (or at the same time) >>> into master. >>> >> I'll have to think about this. The current policy of committing first to >> trunk makes a lot of sense, as far as keeping branch stable. > If we switch to git there is no such thing as committing to trunk first. > I understand this. I meant that ...
>> There are >> plenty of cases where a bug gets fixed in trunk first, and then we wait >> to commit to branch until we see how that goes. > > In the development model I propose, we fix a bug in a topic branch. > This branch will regularly be merged into a > testing branch which is comparable to the current svn trunk. > ...what you describe here would happen, as opposed to their being committed (merged) first to something comparable to current branch. > When a feature is cooked, tested, or if we have seen how it goes, the feature > will be merged either into master (a sort of stable trunk) or it will be > merged into BRANCH_2_0_X. All fixes that are merged into > BRANCH_2_0_X will of course get merged into the stable trunk > as well when BRANCH_2_0_X get merged into master. > The only thing I would add to this is that I think the same distinctions apply to BRANCH. (I'll use caps to try to keep the different meanings of "branch" straight.) I think there should be something corresponding to BRANCH_2_0_X, which is always maximally stable and is intended to the next maintenance release, and a "BRANCH testing" branch, which contains bug fixes and potential new features that are eligible for maintenance release. This is what I would intend to use for daily work and would encourage other "guinea pigs" to use. Jurgen agreed with this suggestion elsewhere in the thread, partly on the ground that it would help us get more testing. Some really adventurous people might want to use the "trunk testing" branch, but those of us who collaborate with ordinary users probably would not want to do that, because it may contain format changes or features that may be a bit more dangerous, or touch too much code, and so aren't eligible for branch for that or some other reason. Richard
