Future SCM Technology

[Jesse Keating]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070606/60eef034/attachment.sig>