Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

Jesse Keating jkeating at redhat.com
Thu Oct 7 22:33:58 UTC 2010


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

On 10/6/10 1:44 AM, Tim Waugh wrote:
> On Tue, 2010-10-05 at 15:27 -0700, Jesse Keating wrote:
>> PPS  I did not modify my bump script yet to attempt a commit to master
>> and merge to the f14 branch.  In the interest of time, I took the easy
>> route and just did commits to the f14 branch.  Maintainers can do a
>> merge and fixup after the builds have been done if they wish to have
>> their branches in sync with master once more.
> 
> For this sort of thing I would have thought that separate commits on
> whichever branches need changing would be fine.  Git's merging (if/when
> each maintainer decides to merge branches) ought to be able to handle
> that.
> 
> I don't think that merging "backwards" from master to f14 would be a
> good idea.  Wouldn't that bring "rawhide"-y changes into f14?  For
> example, ghostscript's master branch uses ghostscript-9.00 -- merging
> master into f14 would cause havoc.
> 
> Or have I misunderstood what you are saying?
> 
> Tim.
> */
> 
> 

For a large number of packages, master and f14/master are identical, as
they have been merged together.  These packages are kept in "sync"
across the releases, usually when upstream is only putting out bugfix
updates and the like.  My script did not do anything to detect this kind
of scenario and play accordingly, which in this case would have been to
make the rebuild bump on master, then merge it back to f14/master.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyuStMACgkQ4v2HLvE71NWrawCfSbZYph918mttaEINTYPbycQe
DoEAn1Grs5kcWtb5vbZYy5DBPEIFDTdD
=koVt
-----END PGP SIGNATURE-----


More information about the devel mailing list