On Thu, 2007-06-07 at 22:25 +0200, Nicolas Mailhot wrote: > Le jeudi 07 juin 2007 à 13:00 -0700, Toshio Kuratomi a écrit : > > On Thu, 2007-06-07 at 20:37 +0200, Nicolas Mailhot wrote: > > > Le jeudi 07 juin 2007 à 11:06 -0700, Toshio Kuratomi a écrit : > > > > > > > Absolutely -- they have different reasons for wanting this than we do. > > > > > > Wanting what? > > > > > > If what = kill centralised cvs for modern scm exploded trees, with > > > cvs/svn/whatever gateways, while keeping the current srpm export/import > > > modes, why not > > > > > Yes. But what is the end of your proposal? > > Could you please answer this question? You seemed to have an idea but didn't finish your thought. > > > If what = get everyone to use _insert_preferred_scm_there and kill other > > > access modes → not good > > > > > To be sure I understand, what are the other access modes? > > archive + patches, srpm import/export, export gateways to other vcs > I agree with you. We must be able to take the information in our DRCS and generate srpms that contain multiple patches just like today. Not being able to do that is to make rpm emulate the build methods of debian packages. *shudder*. > > > 2) Having the ability to pull arbitrary patches out of our VCS vs > > pulling a discrete patch out of our current CVS system is a postive > > thing for working with upstream. > > You're describing heavy forking which is not Fedora's target and not > needed by the overwhelming majority of fedora packages. > Not at all. Config files -- local changes that shouldn't be merged upstream but we might change over time. They would benefit from being revision controlled. Backports -- Our backport would benefit from a DRCS's history and merging features to help update the patch when the upstream fix changes. Local changes that are submitted upstream -- We would want to track the history of changes that make up each patch just as if we were doing the changes directly in upstream's tree. If upstream asks us to modify the patch in any of the ways that I described the DRCS helps us do that. > You're assuming upstream has the same vcs as you > No. Nothing in 2) depends on upstream sharing the same DRCS. What are you visualizing that makes you think that it does? > And I'm not sure even in this case we'd want all your coding attempts > traced in a public vcs. Seems a lot of stuff you should do in local, and > then produce clean patches for the fedora vcs and upstream Having things in an exploded tree DRCS makes it easy to work locally because you can make a local feature branch of the Fedora exploded tree, work on the code for the patch and when done, push it back to the Fedora tree. But just because something is going to be submitted upstream as a patch doesn't mean that a lack of history is desirable. Work done in our tree and then merged to upstream's tree is helped just as much by having history for us to look at as upstream being able to see the changes they made in their tree. Backporting a fix from upstream's development branch to one of our stable packages is an easy example of where having history would be desirable since the changes may need to be reworked anytime upstream makes a new release to their stable branch. > > > > 2) Better able to rebase our local changes. > > > > > > We don't want to get good at local changes, we want to push changes > > > upstream, and even cvs is good enough for our basic rebasing needs today > > > > > We do want to be good at making local changes. We want to be so good at > > it that when we submit the changes to upstream, upstream has no trouble > > recognizing that they're good changes and has no issues with accepting > > them. > > And upstream will ask targeted localised patches not huge vcs feeds it > has to sift through > Right. Which is why you can't just drop everything into an exploded tree but have to construct something like the Ubuntu page describes. This allows you to easily manage logical changesets within the DRCS and send them upstream as discrete patches. -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
