Re: branching for future fedora releases

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

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/2010 09:15 AM, David Cantrell wrote:

master
 |- f13-branch
 |   |- f13-alpha
 |   \- f13-beta
 \- rhel6-branch
     |- rhel6-beta1
     |- rhel6-beta2
     \- rhel6-rc1


master
 \- fX-branch           -->--->---+->-+            <----<---<---+
     \- fX-alpha                  |   |  TIME                   |
         \- fX-beta     <- merge -+   | PASSES                  |
             \- fX-rc       <- merge -+             ->-merge ->-+


> This is more of an alternative idea proposal.  Rather than make each
> sub branch off of fX-branch, you make it off the previous.  That
> ensures you pick up any patches that went on to fX-alpha or fX-beta
> and did not go on fX-branch 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.

Is there any real difference between these two methods? In both the
developer commits go to master and the gatekeeper picks the ones to go
into the branch/alpha/beta/rc branches. When creating a new sub-branch
you want all the changes from fX-branch, right? So doing a merge from it
or a branch based off of it results in the same code. Or is there some
benefit with a git merge vs. a branch when creating the new one?

> The final merge in the example is intended to make fX-branch
> represent the latest anaconda in that Fedora release.

Doesn't this have the potential for removing patches in fX-branch that
aren't in the rc? Wouldn't it be better to make the final build off
fX-branch so that it includes everything for the release?

So at the end the releases would look like a loop, we release alpha,
beta, rcX, rxY, and finally back to fX-branch for the final fX release.

- -- 
Brian C. Lane <bcl@xxxxxxxxxx>
Red Hat / Port Orchard, WA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBS46hpRF+jBaO/jp/AQJxUAf/SoslPjs1v1h3S7wNPvRQwboiM5ivrV9b
k8wd9a3rmOesC6DN9ZCX7zEE2IqzGTPIaKb0SqydGNJ8cGVB03pLln4wDYy5qVTW
FdtX471wfzH24og9/HpjyNFfqs8O6iXWVHfeGdklEPubGUNlT6bOlDfgNaboKTdq
89TzIbTieMJBdzyleXekX/X6fzgsGxbLLUBQP8PWOtPevG/3pMFXp9VTu/P7fuDc
gVYyTM9AGPtT0MOJlJefCBaQkzMc8i6U5jfqYa05PEM28TcTmV/FynMlNnMnrzfG
Sl+7U+vp8oWYUxhMVfLzEIPfw0lsLGzpDHenGVXtM+NEfdFPKbep7A==
=U25Q
-----END PGP SIGNATURE-----

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux