RFR: GIT Package VCS

Jeffrey C. Ollie jeff at ocjtech.us
Wed Jun 6 19:32:49 UTC 2007

On Wed, 2007-06-06 at 13:50 -0400, Christopher Blizzard wrote:
> On Wed, 2007-06-06 at 10:31 -0400, Jeremy Katz wrote:
> > 
> > Right.  I really don't think we want to just take our current system,
> > switch out CVS, and end up with all of the same workflows.  The change
> > should be more about how do we improve workflows.  That means thinking
> > about things like:
> > * How do we make it easier for a maintainer to rebase their package to
> > a
> > newer upstream?
> > * 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?
> > * How do we make it easy to send these patches to the upstream of the
> > project being worked on?
> > * How do we enable downstreams to take our bits, track them and make
> > changes as they need/want?
> > * 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?
> > 
> Awesome stuff.  This is the right way to go about the conversation, for
> sure.  I would love to add some stuff to this list:
> o How do we bring developers and consumers of technology closer
> together?  In a less market-ey speak way to put it: how do we let
> software developers (not just maintainers!) get directly involved and
> let them deal directly with the people who want to use it without the
> maintainer as a mediator?
> o How do we deal with _more than just RPMs_ as a build and delivery
> mechanism.  (Trust me, this is coming.)
> o Do we want to move to a process where code is just in a repo and it's
> built automatically instead of source + patches + spec file?

When I first read these two posts, I thought "you guys are crazy", but
then I thought about it a bit more and started thinking "Whoah! This
could be really cool!"  I think what is described here could certainly
be done with Git (it'd probably work in another distributed SCM but I'm
less famililar with those so I can't say for sure).  

It also occurred to me that this would be a very big change in how we
manage packages so maybe some kind of hybrid approach would make the
transition easier.

So what about something like this:

1.  We convert the package repository to a new SCM so that we can get
off of CVS, but the process/workflow remains relatively unchanged.  This
I think that we could definitely have in place by F8.

2.  We set up a parallel package repository that enables our new
workflow.  When a package maintainer is ready to move a package to the
new workflow, building from the old-style repository is disabled and the
package is built from the new-style one.

> Also, we need to think in use cases instead of abstract questions or
> about what technology we can use.  For example:
> "A developer has made a patch that he thinks fixes a bug for one of his
> users.  He mails the user and says "here's a pointer to the patch - just
> click on this button to try a build on your system."
> One of my goals that I've had for Fedora, one that's easy to understand
> is, "one click to try any patch."
> What's required to make that happen?  Realistically we probably need to
> move to a source control system so that when the developer commits (or
> is pushed in the git sense) the tag with that commit or change is
> available to apply.  Then the build system can just pull that tag, build
> it and make it available to the user automatically.

I think that this is more of a Web UI issue rather than a SCM issue.
Koji will already build a package based upon a tag in CVS, it wouldn't
take a lot of work to extend that to GIT or some other SCM (example
patches for SVN are available in a ticket on Koji's bug tracker).

What you would need is a Web UI that would:

1. Let users browse the packages and tags that are available in the SCM.
2. Or users could be directed to a particular package/tag by posting a
link in bugzilla/mailing list post.
3. Be able to click on a button to request a build from Koji for a
particular package/tag/release/arch.  Since the build is going to take
some time, users would need to supply an email address where a
notification would be sent with a link to download the resulting
packages.  These packages would be cached for a while in case other
people wanted to try out those packages as well.  Packages built in this
fashion wouldn't become part of rawhide or an update to a released
package - that would still require action by the maintainer.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20070606/9ce63594/attachment.sig>

More information about the Fedora-infrastructure-list mailing list