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
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...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Fedora-infrastructure-list