RFR: GIT Package VCS

[Nicolas Mailhot]

Le vendredi 08 juin 2007 à 11:50 -0700, Toshio Kuratomi a écrit :
> On Fri, 2007-06-08 at 14:05 +0200, Nicolas Mailhot wrote:

> > It's definitely not
> > - "are Fedora patches are correct or useful fonctionnality-wise"
> > - "why did the Packager did this thing"
> > 
> Disagree wholeheartedly.  I don't just take upstream releases and
> package them.  I also code bugfixes, backport fixes, and make changes to
> the default configs.  When applicable, I submit these changes to
> upstream.  Seeing as this is code developed against the source tree, I
> want to be able to track the changes I make in a VCS.  Simply adding and
> removing patches in CVS is not very good for this.  Working with those
> patches against the exploded tree is much better.

But that's the VCS usefulness for you as individual packager, not its
usefulness for upstream (just wants ready-to-push patches) for fedora
users (just want to be able to do quick audits) or other fedora
packagers (as far as I know we never have more than one people working
on changes on the same package between two koji builds)

Therefore, what would tracking all those changes in a public VCS instead
of a private branch would accomplish? It would only flood the Fedora
commit list & VCS with all your private code attempts, and make harder
to identify shipped patches among all the other noise/activity (bad for
everyone but you)

If you actually look at the information you want published (not your
local developer undo/redo queue), is it so much different from what
we're already publishing today ? Exploded view may make the changes
easier to grasp, but do we *actually* need any datapoint apart from each
package build state published?

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070608/4b71b655/attachment.sig>