On Wednesday 06 June 2007 13:16:07 Jeffrey C. Ollie wrote: > It's F7+5 and F8T1-57 (yes, less than two months until F8T1 under the > current schedule[1]). If we are going to replace CVS[2] with another > SCM for hosting the Fedora Package Repository we need to get started > now! And to get things started, we need to discuss what kinds of > workflow we want our new SCM to support. As stated on Fedora Infrastructure List I firmly believe that this is not something we can do by F8 release. This is something we need to discuss and strawman and put up proof of concepts and get more people thinking on it during the F8 cycle and try to implement during the F9 cycle if possible. > > Here's a list of things to think about (thanks to Jeremy Katz): > * How do we make it easier for a maintainer to rebase their package to a > newer upstream? Perhaps you should define a bit here what is meant by 'rebase'. Is it adjusting local patches to the new source, or is it just getting the new tarball into the mix? For the former, I think that having exploaded source tree modules may be helpful in this regard. Something that doesn't come down by default, but can be requested with a make command. Once you have the exploaded tree then you can do fun things with patch management systems such as quilt to port your patches and some such. For the latter, I'm not sure what we can do to make it easier, if we have to. Seems pretty easy to me to chuck a new tarball at the source control. Is there anybody out there that thinks that this is too hard? > * How do we make it easier for a maintainer to develop, test, and create > a patch to fix a problem that's being experienced in Fedora? This kind of goes back to the exploaded tree again, and a patch management system. Other than that we really want to be able to send test builds with these patches somewhere and get users to them. How much that is related to the SCM, probably not much, just more fun with make files and koji targets. > * How do we make it easy to send these patches to the upstream of the > project being worked on? Git has some pretty compelling tools for sending changesets around, to/from bugzilla, email, etc... It's also easy to make git repos http available so that somebody can easily cherry pick a patch set or change set off an exploaded source tree. > * How do we enable downstreams to take our bits, track them and make > changes as they need/want? I really like this one here. A distributed SCM make this pretty easy I bet, downstreams can just clone our repos, add their changes, and continue to "pull" in upstream changes to merge with their downstream changes. Eventually we upstream can cherry pick their changes into our upstream. > * How do we better enable a user who has a problem with something we > ship to be able to fix it themselves and get the fix back to us? distributed SCMs are easy to clone and have local to build stuff. Of course that would mean that the module they clone is self sufficient in that it can be used to produce a source rpm that in turn can be chucked at koji or a local mock target. -- Jesse Keating Release Engineer: Fedora
Attachment:
pgpaUE1Wq0rRF.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
