On Sat, 2008-07-12 at 10:36 -0400, Doug Ledford wrote: > > > > 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. Most of the Fedora contributors do that. > 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." As a side bar, we need to figure out a way to do a better recap of FUDCon. People's blogs and personal recaps are great, but this seems like a pretty important topic and I don't recall it being discussed or recapped anywhere. (Please someone correct me if I'm wrong and I missed it.) > 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. This is the first time I've heard that benefit. It seems like a fairly good one. > > 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. In many cases upstream and Fedora are synonymous (anaconda, pungi, yum, etc). In many cases they aren't. And we _do_ have upstream maintainers packaging for Fedora. The CVS package repo we have is not that large of a burden. Your argument about that is about as effective as saying RPM is the reason upstream doesn't package for Fedora because they mostly use Debian or Ubuntu, which are apt based. There is truth in it, but it is not an "OMG the sky is falling" situation. > 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. This is very simple. Nobody is blocking anything. All you have to do is actually start doing something instead of telling everyone that you are going to do something and you'll make progress. Jesse had a git repo at one time of Fedora. You might be able to leverage that work as a starting point. > > Again, scratch your own itch if it's bothering you that badly. > > Isn't that what I've been saying I want to do? Yes. So do it, and stop saying it? Places to start: 1) Koji 2) Bodhi 3) The Makefiles in the SCM 4) Jesse's git import of Fedora josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
