On Wed, 2007-06-06 at 17:31 -0400, Jeremy Katz wrote: > At the same time, I think we still need to be able to very clearly > separate out our changes from what upstream has. Just a git repo of the > kernel very quickly gets out of control and you end up with bazillions > of things that you never push back upstream because it's easier to just > keep sitting on them. So I don't think that just a VCS repo of the > source is what we want... we're going to end up wanting some integration > with something quilt-like to get patches out; so like stgit or mq or ... Like I said, I think it depends on what the package is and most importantly what the maintainer and developers want to do. I know that Dave Jones didn't want to use git to build the kernel, and that's fine He doesn't have to use it. One thing I'm trying to do here is break the maintainer model that we have today. I want developers to come and work directly in Fedora. And that means taking out that extra step if we can - going directly from a VCS to a package. Using HAL as an example - want to pull in the latest one? Just point your repo at the upstream one and catch up to that release. Then click to build. Or, even better, the developer can do it himself and push it into our release. Remember, in a lot of causes for us the maintainer _is_ the main developer! So why not draw that line as close as possible? > > This might sound crazy (SUPPORT > 1 SYSTEM, ARE YOU CRAZY?) Well, yes, > > until you realize what you need to do here. To start with you only have > > to teach the rpm build side how pull a specific tag from a specific > > repo. On the query side we need a browser for each kind, which is a bit > > of work, but something I think we need to do anyway. (i.e. "What would > > git do?") > > So if I am the owner of the rpm package which has an upstream of hg and > want to fix, test and commit a change to say (for the sake of argument) > neon which is in git, I now have to know two different systems? You're > crazy ;-) No. If you happen to be a maintainer _and_ a developer and you have _chosen_ to use hg or git or whatever, then we make it easy for you. This is about adding options to bring us closer to the upstream developers and make their lives easier. > > To add to the craziness of this path, think about actually maintaining > these packages across different distro releases... every VCS has its > own unique and specially crack-ridden way of handling branching. Yes, but you only need to teach our systems about that once. > > Or when you star to think about the "I'm a downstream of Fedora and need > to change X, Y, and Z" and you are then having them set up potentially 3 > different VCS systems to do so. Depends on what they want to do. > > Or the "it's time for a mass-rebuild; let's go and commit a version bump > to all the packages so we can rebuild. Uhhm. Uh-oh. This is actually easier for those VCS packages than it is today. Right now we have to go in and edit every single spec file, edit, and commit. If we back away from having spec files like that and instead generate that info before compile time (so a "pristine source" is just a set of metadata, rules and a source tag) doing mass rebuilds is _easy_. > > > Plus, to be honest, it completely avoids the whole "which damn system do > > we use." And I like focusing on the end user features instead of > > getting stuck in VCS dicussion hell. We're not going to get everyone > > else to agree or even use the same system. So let's build something > > that supports both. > > So instead of picking _one_ answer, we now have to make sure that we > implement all of the end user features for N systems? Seriously, this > is losing. This comment inspired me to make a very special graphic: http://www.ideasuite.com/~blizzard/images/captain_no.png So let me ask you this question: where do you want Fedora to go? Just keep adding packages? Situation as usual? We got things outside of the firewall. That's nice. We will never rest on our laurels. What's next? I have a pretty specific vision for where we should be two to three years down the road, and it involves innovating in these spaces including looking at having source repos to fix real problems with developer productivity. How can we make developers (not just maintainers) lives easier? How can we shorten the distance between them? I don't see you offering ideas, only saying others are bad. --Chris
