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

Re: New Packager question again: can you point me to a not flawed package?



On Sun, 1 Jun 2008 07:11:03 +0300, George Danchev <danchev@spnet.net> said: 

> On Sunday 01 June 2008, Russ Allbery wrote:
>> "Paul Johnson" <pauljohn32@gmail.com> writes:
> --cut--
>> > If there were 50 patches, some of which others contribute, there
>> > might be a chance to figure which one blows something up.  As long
>> > as the patches are separate, there's a chance I could back-track
>> > and find the problem.  But it seems like you are saying that you
>> > apply those 50 patches, and then make one jumbo diff including all
>> > changes.
>> 
>> Only in the final build of the source package after everything has
>> already been merged.  The working object is 50 separate feature
>> branches, each of which contain only one change, and which I can
>> merge and update indepedently.  The only difference is when one does
>> the merge and what artifact of the merge one puts into the source
>> package.
>> 
>> Right now, the Git method is less than ideal for anyone working only
>> on the source package, since they get the merge artifact without any
>> of the underlying structure.  3.0 package formats will fix that; in
>> the meantime, if they have Git, debcheckout will get the actual
>> repository and let them work on the same thing that I'm working on.

> True. This is cool and helpful for the DD point of view while working
> with their $VCS, but might leave users of diff.gz with one single
> jumbo diff which modifies several upstream files. Please note that
> these users (which might happen to be the upstream developers of your
> package) might not even have your $VCS of choice installed or


        Upstream developers of my packages get hand crafted submit
 branch patch sets sent to their preferred mode of incorporation; their
 BTS or their mailing lists.

        Anything less is not good practice; we should be sending our
 divergence upstream.

> devscripts package to use debcheckout, they might be pure $UNIX users
> relying on patch, diff and a simple text editor.  So, will you
> generate at some point a series logically separeted quilt patches and
> store them in debian/patches/ in the final diff.gz which is the
> canonical way of Debian to distibute changes.

        This can only work if the topic branches are non-overlapping;
 and that might cover a lot of cases, but not all.

        I am not so sure it is indeed a canonical way of doing things in
 Debian.  If it is, which canon do you follow?

        manoj
-- 
An economist is a man who would marry Farrah Fawcett-Majors for her
money.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: