[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFR: GIT Package VCS



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]