On Wed, 2008-07-23 at 16:51 +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 23 July 2008 at 09:43, Hans de Goede wrote:
> > Doug Ledford wrote:
> > >I've been working on getting this set up and functional.
> >
> > <lots of complicated hacks and workarounds deleted>
> >
> > So Far I've been quiet on this, sort of hoping it would go away by itself,
> > but as a contributor with quite a few packages let me say that I'm deeply
> > worried about this whole distributed VCS / exploded source idea floating
> > around.
> >
> > It seems there are a few people who are a big fan of this, and about as
> > much active opponents. I have no problems with adding the possibility to
> > use a distributed VCS with exploded trees to the mix of ways to maintain
> > and build packages, but this should not replace the current nice and simple
> > setup we have.
>
> Seconded. I'm pretty happy with our current workflow and the only things
> I'm missing are "svn cp" and "svn mv".
>
> [...]
> > Also I even fail to see the claimed advantages in using a distributed VCS
> > at all, isn't our mantra upstream upstream upstream, well if this mantra is
> > properly followed and upstream is undergoing active development then most
> > of the time the pristine sources should be fine without any patches at all,
> > since all patches are integrated upstream in a timely manner. Also if
> > someone wants to do so much work on the upstrewam sources, then he/she
> > should just become an upstream developer. Really getting upstream
> > cvs/svn/whatever access isn't that hard, then one can directly commit one's
> > changes in to upstreams VCS.
>
> Apparently a couple of packages (grub, kernel, few others?) maintain a massive
> patch set over their respective upstream tarballs, so while this change might
> make life easier for them, it is not necessarily so for the rest of us.
Actually, no. A massive patch set is no easier to maintain in a dvcs
than it is with patches. The problem is that with a massive patchset,
you get conflicts on update. This happens whether the patches are
applied in an rpm, or by the dvcs as part of an update process.
> Make it an option, yes, but do not disturb the workflow of the majority
> for the benefit of the few.
I won't force anyone to anything. Of course, a number of the benefits I
laid out in the rpm thread have nothing to do with packaging and have
everything to do with things like look aside cache growth, source
storage size, and limitations of Fedora's infrastructure. Those items,
obviously, are of benefit to *all* packages, not just ones those with
active developers handling the package. And in order for Fedora to even
consider the idea of hosting source for spin makers, something like this
would be a requirement. But, obviously, that would be disturbing the
majority for the benefit of the few.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
