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

Re: RFR: GIT Package VCS

On Fri, 2007-06-08 at 23:48 +0200, Nicolas Mailhot wrote:
> 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,

Which is one of the goals, yes?  As long as we agree on that, I'll
attempt to show that the other audiences you have in mind are also
served by doing this.

>  not its
> usefulness for upstream (just wants ready-to-push patches)

By having quilt-like commands in the VCS we are able t manage our
changes as a sequence of patches just like now and send them upstream
just like now.  So at the least it should be no harder to work with
upstream than now.  I argue that it will, in fact, be easier to work
with upstream because the VCS will make it easier for us to port the
patches forward to upstream's HEAD if upstream desires and take
suggestions from upstream and merge it into our patch.

>  for fedora
> users (just want to be able to do quick audits)

This would be your argument about log messages, yes?  I'll address that

>  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)
Which could be a limitation of our tools rather than a statement on the
idealness of the system.  In any case, exploded trees won't make it
harder for "a single developer per koji build" to do their job.

Also, as a packager, I do sometimes want to see the history of changes
that went into a specific patch in a previous build.  There was a
regression introduced when PackagerFoo rebased to a new upstream.  What
were the changes that went into that rebase?  Can I see the regression
in the specific set of changes made then?

> 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)
I have two points for this:

1) As previously stated, when further development of a patch does
happen, the log messages are a total mess.  Looking at a diff of a diff
is horrible for extracting meaning and overall context whereas a diff
between the prior tree with patch-v1 and the current tree with patch-v2
applied is much easier to read and audit.

2) Using exploded trees and a DRCS does not have to send the complete
logs to a mailing list.  The DRCS tracks which changes occur on which
branch.  So I would checkout/branch/clone the current package directory.
Make changes that will go into the patch locally with as many commits as
are necessary to me.  Then, when I have rpmbuilt it and tested the
change, I would merge the changes from my local branch to the Fedora
Package Branch.  At this point, if we decide that we don't want to send
out a complete log of the patches to the commits list, we can send only
the commit message from the merge so you only have to see the message
for "the final product".

For someone who wants to dig deeper, the full logs would be available by
checking out a branch of the package.

> 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?
As a packager, yes we do.  As your Fedora User who wants to quickly
audit the changes, perhaps not.  But we can address both audiences here
because the metainformation about what branch a commit is made to is


Attachment: signature.asc
Description: This is a digitally signed message part

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