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
Attachment:
signature.asc
Description: This is a digitally signed message part
