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 below. > 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 available. -Toshio
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
