[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: branching for future fedora releases

> > 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]