Horst, I'm not going to quote your email but I'm going to reply in summary to the points you raise: 1. Fedora isn't just a downstream, we're an upstream too - RHEL, OLPC, and several other projects take Fedora and make changes on top of our changes to suit their particular needs. 2. Patches stored as binary blobs in CVS are very ugly to deal with if you need to update that patch as conditions change. 3. Patches stored as binary blobs in CVS loose the history that went into developing those patches. Sure, some patches are trivial, but there are some patches in our packages that are HUGE and have had a complex history. Having the history that went into developing those patches is immensely useful. 4. There are some patches in our packages that will never be sent upstream because they represent Fedora-specific policy (e.g. changes to default values in configuration files). The history of these files certainly. 5. You won't be maintainer of a package forever, and you likely won't be the maintainer of packages in downstream products either. Putting the history of how you developed your patches in a central, public location is make the job of the next person that has to touch your packages much much easier. 6. Regarding slow (or non-existent) network connections in much of the world: unfortunately, the reality is that the people in these areas probably aren't contributors to Fedora anyway. Just keeping up with mailing list traffic that you at least need to skim over to be an effective Fedora contributor is going to give a dial-up connection some serious trouble. Jeff
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
