> > first. Once you make the new branch, you merge in fX-branch to pick up all of > > the new stuff that was intended for the next milestone. The idea being that > > the fX-alpha, fX-beta, and fX-rc branches are not working branches for > > development, but rather branches meant for making the releases. The merges > > avoid having to do a lot of cherry picking and dual commits. > > This sounds potentially very error-prone to me. In terms of flow (of > commits and releases) it is very roundabout. It makes me nervous. Maybe > I just don't get it. Both ways sound pretty error-prone to me. It's just a matter of where we want the possible errors to occur and how much work we want to put on the release manager. I am leaning towards the cherry-pick heavy approach, incidentally. I'm hoping it'll result in more careful consideration of what commits need to go onto which branches. > > It depends on how we want to manage the workload. Force all developers to > > commit to the correct branches or have everyone commit to a working branch > > for a release and have the gatekeeper roll up changes when appropriate. And > > the merges do not have to come from fX-branch either, they could come from > > master. > > I think developers should commit to master (if applicable) and any > appropriate product branches, just like we do now. The release lead for > each product branch then decides whether the commit should be pulled > onto any active alpha/beta/rc branch. I can possibly see some argument > for having the fX release lead do all cherry-picks onto fX-branch, but I > think that part of what we do now works fairly well (having the > developers handle that part). What we'll have here is that f13-branch will be sort of like a master branch for all things F13 related but no builds will ever come from it - all builds will come from one of the alpha/beta/rc sub-branches. That means if anyone can commit anything to f13-branch, they have no guarantee that it will ever make it into a build. A commit will only make it into a build if the release manager pulls it onto the appropriate sub-branch. Is everyone okay with that lack-of-guarantee? I'm not sure how I feel about it. I guess one serious advantage to it is that the release manager has a smaller pool of candidate commits to sift through looking for things to cherry-pick. Letting people commit to f13-branch means there's a bit of a filter at the developer's level first. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
