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

Re: Centralized darcs

On Thursday 03 August 2006 03:32, Matthew Palmer wrote:
> > > > This is fine, but (again) you forget about your 'apt-get source'
> > > > users, which are not supposed to be aware of your SCM, where your
> > > > repo is,
> >
> > please, find 'SCM' in the above row, thanks.
> I did.  Using an SCM and shipping a monolithic diff.gz makes it *easier*
> for the 'apt-get source' user to work with the package, because there isn't
> a randomly-chosen "debian patch manager" in the way to confuse and
> confound.

The very same "debian patch manager" clearly identifies patches you've 
produced against a certain upstream version and if I want to see the text of 
your diffs altering src/file.c|h|whatever, not just a mere changelog entry, I 
must track your SCM repo and its logs (learning a debian patch manager is 
certainly easier as compared to any SCM and there are certainly more SCM out 
there than debian patch managers). Why do I need to track your changes to the 
upstream code ? Probably because I want to be sure that you haven't added any 
offending changes or any other defects to the upstream source code when 
upstream claims that their branch is working properly. Now you want to kill 
that important information from the debian source package itself and make 
like of people even harded to find out your SCM, learn to use it and track 
down the changes made to the upstream branch. I don't find that very 
impresive, and I think Security Team will not be impressed too.

> > > source and why they have been applied."
> > >
> > > Which is it?  Clearly identified patches, or "not supposed to be
> > > aware"?
> >
> > Obviously 'SCM' is what you missed above, which led you to such a
> > confusion. Yes, people might be able to apt-get source and have patches
> > which are to be (un)applied to the upstream source clearly identified
> > without having to bother with any SCM to do the _patching_ work. (SCM ==
> > VCS)
> They don't have to know anything about the SCM to manipulate a monolithic
> diff.gz package.  This is in contrast to a "patch-managed" package, where
> you *MUST* learn the patch management system to make a minimal, useful NMU
> patch.

Seems like you don't consider clearly identified patches prepared against a 
given upstream version important, and (as you said in a previous message) a 
mere changelog entries should be enough for you. This is just a very 
interesting way of tracking changes ;-)

> > > > I.e. if you have patches, do them debian way (using a debian patch
> > > > system)
> > >
> > > Please identify "the debian way", so I may start using it.
> > >
> > > Oh wait.  There isn't any single Debian way.  Never has been, almost
> > > certainly never will be.
> >
> > There is no signle SCM you can do packaging either.
> No, there isn't, but the difference is that the SCM doesn't get in your
> way.

'Tracking patches against the upstream branch without using your SCM, but the 
debian source package instead, grabbed by apt-get source' is name of the 
game, that's why debian patch managers exist.

pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 

Reply to: