On Sat, 2008-07-12 at 07:42 -0400, Josh Boyer wrote:
> On Fri, 2008-07-11 at 21:11 -0400, Doug Ledford wrote:
> > On Fri, 2008-07-11 at 18:58 -0400, Jesse Keating wrote:
> > > On Fri, 2008-07-11 at 17:14 -0400, Doug Ledford wrote:
> > > > Gee, I looked at Fedora's rpm CVS...wasn't a single bit of indication of
> > > > *any* activity of any sort there...makes a nice example of just how
> > > > broken and disconnected from modern SCM management our system currently
> > > > is.
> > >
> > > That's right, we wouldn't want to see inflight development in the HEAD
> > > of our package source control. That rapidly gets in the way of doing
> > > mass rebuilds, scripted code compliance tests, targeted fixes strikes,
> > > etc, etc...
> > >
> > > Our package SCM is not a software development SCM.
> >
> > Because you are not being in the least bit imaginative with branches
> > does not in the least justify the statement you are making.
>
> OK, how about this:
>
> Nobody has the time
I'm *making* the time...around my day job.
> nor has anyone shown overwhelming benefits
Well, I've made noises about it. Hell, so long ago that it was me, Tim
Powers, and Christian Gafton sitting around drinking beers over the
topic we knew that our CVS repo was a total steaming POS.
But more recently, I spent 20 or 30 minutes listening to Mark Webbink
talk legal issues at the Raleigh FUDCon, and during that talk someone
asked a question (someone who was kinda upset at the time). The
question/accusation kinda went something like this: "Fedora introduced
this new thing, fedora spins, and they helped me easily make my own
spin, but now they expect me to carry both it and all the sources
myself. What kind of loyalty does this show to the community that
*makes* Fedora that you won't support them on this sort of stuff and you
leave them hanging out to dry."
Now, Mark rightly answered that question with this basic response: "Yes,
we don't distribute that for you, because that would then put us on the
hook for keeping your sources around long enough to satisfy the GPL. We
make it easy for you to create your own spins, but we don't have the
resources or the administrative capacity to guarantee that your legal
requirements in terms of the GPL are met, so we force you to distribute
your spins yourself."
After the talk was over I spent some time talking to Jesse where I
pointed out to him that if you did away with the look aside cache for
tarballs, and instead used exploded source in a repo, that you could in
fact add new branches onto a repo for essentially zero cost and those
branches could be what's used by people to make spins. That in this way
we could, for next to no additional burden, carry their sources for them
to satisfy the GPL and to allow them to more readily create and
distribute spins. Obviously, this hasn't gone anywhere since then.
> to rework
> our entire infrastructure to deal with a new SCM for _packages_ so that
> people can do code _development_ on them when that should all be done
> _upstream_.
The distinction between upstream development and Fedora development is
artificial. And it's a nice way to keep upstream developers from having
any interest in managing their own packages. Congratulations on that.
But more importantly, I'm doing this because I want Red Hat to use the
same tools that are used in Fedora (after all, Koji grew from brew, a
Red Hat internal tool, and likewise the Fedora CVS is a cheap knock-off
of the Red Hat internal CVS system), and in Red Hat Enterprise Linux, we
most *definitely* have a need to be able to do real development on
package branches versus upstream. So, as long as Red Hat and Fedora
intend to share technology in this area, then I would suggest that Red
Hat not block Fedora's needs, and likewise Fedora shouldn't actively
block Red Hat's needs, especially on the basis of artificial maxims that
aren't even true.
> Again, scratch your own itch if it's bothering you that badly.
Isn't that what I've been saying I want to do?
--
Doug Ledford <dledford redhat com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband

Attachment:
signature.ascDescription: This is a digitally signed message part