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? 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 would like to compare this to the current work flow we have. Right now you report a bug, the developer looks at the bug, generates a patch. That patch is usually uploaded to bugzilla. Then a very advanced user might be able to take that patch, figure out how to apply it to a spec file, rebuild the rpm and then install and test it. Then that test information might be returned, it might not, but it's hard for you to share that build with other people that might want to test. Our current system creates artificial barriers between developers and users and requires a huge amount of cognitive load to get involved and to get things done. It's slowing things down and creating a bad experience. And worse, everyone doing Linux is doing the same thing. So I think we need to take the next step. Think about how to build simple, easy to understand systems and connect people closer together. So does using git for the package VCS actually help solve this? Not really. But does it mean that it's a step down the right path? Sure. But we need to make sure that we're thinking about the problems correctly instead of just trying to apply a technology to a problem without understanding which problem we're trying to solve. And I don't think our biggest problem is CVS. Our biggest problems are scale and how hard it is for people to be able to share information and be more effective. --Chris
