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.
Jeff