quilt-dev
[Top][All Lists]
Advanced

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

[Quilt-dev] Re: patch-scripts on savannah


From: Martin Quinson
Subject: [Quilt-dev] Re: patch-scripts on savannah
Date: Wed, 22 Jan 2003 09:48:21 +0100
User-agent: Mutt/1.4i

Again, the list is CCed. Are you all members ? ;)
I ask it so that we can cut the CC.

On Wed, Jan 22, 2003 at 07:16:24AM +0000, James Rowe wrote:
> Hey,
> 
>   Having not checked my mail for a few days because I have been on a
> business trip I didn't notice any of this turning up :/
> 
>   Anyway, I guess I should explain some of my reasoning.  And I am going
> to cut out some large sections of a mail I sent Martin(before noticing
> these mails)

I'll answer this other mail after this one, if I need to say something more.

> On Tue, 21 Jan 2003 15:45:02 +0100
> Andreas Gruenbacher <address@hidden> wrote:
> 
> > > * [JR] Single script to cut down the forking.
> > 
> > I consider this harmful (more difficult to maintain), and not
> > necessary at all. The bottlenecks are not with forking; the scripts
> > are quite fast.
> 
>   I think either somebody misread, or more likely I failed to get my
> point across there.  The single script idea was nothing to do with
> forking at all.  It is purely because I detest the idea of flooding my
> $PATH with more commands.  I already seem to have the need to use
> atleast 3 characters before I can tab complete, and it annoys the hell
> out of me to think more and more things are going to be put in there ;)

My bad here. Sorry again.

> > 
> > > * [JR] Change all occurence of sed/dirname/basename to cut where
> > > possible
> 
>   This is related to the above forking.  On the systems I use
> quilt(hehe, I will try to use this name now.  but no doubt patchscripts
> will sneak in when I am tired) performs considerably faster using the
> Bash variable cutting options then forking sed just to do a simple
> removal.  Then again the machine I am using right now suffers badly
> when anything is spawning.  I do believe that even though sed is useful
> in some parts(and I have left it in) that it is overkill to use it for
> small cuts.
> 
> > > * [JR] Keep it simple, and let CVS- and kernel-related scripts live
> > > in another directory, so that they may be considered optional
> > 
> > I don't understand.
> 
>   Yeah, I don't use the kernel related sections at all now.  And the CVS
> options need serious work before *I* would use them.  The way I see it
> is quilt is useful in other projects too, so including the kernel
> specific options as standard is a little ~weird~.  But this all depends
> on where you see quilt going I suppose, or atleast where you use it.

Agreed.

> > > * [JR] Compression support for patches
> > 
> > Good.
> 
> [cut from mail to Martin]
> Compression support for $P data(my $PSROOT is about 40mb at
> the moment).  I am not quit sure on the method at the moment, as I have
> very little interest in waiting for bzip2(or even gzip) to cat or
> compress a patch every time I wish to use it.  It is much more likely
> that a package lock will be made to enable/disable bzip2 during usage.
> [ end cut]
> 
> > 
> > > * [JR] Improve error checking
> > > I guess that Andreas's changes already improve it.
> > 
> > Yes, hopefully. Even SIGINT shouldn't cause havoc anymore.
> 
>   Well like I mentioned at the top I hadn't noticed much of this going
> on at all.  I am going to have a look over lunch

I guess you'll have to wait that Andreas send me his very last version and
that I merge it with the actual code base before it can happend.
 
> > > James, I'm sorry I did not find the time to check your version until
> > > now. I plan to do that soon, to try to merge your changes to the
> > > version I use.
> 
>   http://www.jnrowe.uklinux.net/files/quit-0.1.0.tar.bz2 is a newer
> snapshot, but of course it has been following my thoughts stated here 
> Right now kernel commands have been removed, I hadn't got around to
> putting them in a util/ dir like I had planned yet.

The problem is that we have 3 versions of the scripts here. Andreas's head,
yours, and the one in the savannah CVS (not counting my own, which isn't
very developped, and Andrew's which contains hopefully no new stuff since
the CVS).

My plan is to fix this situation VERY SOON. We all use quilt (or
patch-scripts) for other projects, and consider this piece of code as a
critical component of our devel framework. The temptation of fixing bugs in
our local copy in a hurry is very high, but it will lead with no possible
doubt to a fork of the code, and the dislocation of the project, even before
its birth.

I here the way I intend to fix that mess:
- Get Andreas and other suse guys moving their developpements to the
  savannah CVS
- release 0.12 from that
- Merge your developpement (or at least the parts which are not already done
  in Andreas version)
- Merge my work (mainly a wrapper over the scripts to fight against
  namespace polution)
- release 0.13 from that
- think about further developpements.

> 
> [ mostly cut from mail to Martin ]  
> TODO:
> 
>       * Add uuencoded support to the import-patch routine. Most likely with
> bzip2/gzip uuencoding support.  And generated patches will choose a
> compressor too, based on whether bzip2 exists and falling back on
> gzip(decision from configure).
> 
>       * Probably add some remote patch-get option, most likely using
> bash's/dev/tcp interface(surely there is no need for the/dev/udp... but
> who knows).  This is because just a couple of days ago I needed to
> import a stack of patches and ended up piping them.  a simple cat from
> </dev/tcp/ would be quite useful in my opinion.  But then i use quilt as
> within my development team at work.  So the collaborative aspects are
> quite important to me.
> 
>       * Probably(and this is quite high on the list) add some NLS support.
> The main reason for this is I work with 5 French people and 2 German
> people who although probably speak better English than me agree it would
> be nice to see 'native' output for the more complex information.

I can do that. I'm much better in i18n and l10n issues than in patch
handling. 
 
>       * Next on the list and half way there already is auto
> generation of a tar -X file, because I mailed someone a tarball by
> accident the other day with 'push' backup files(this is a stupidity
> option for me though ;)       
>       [ which I guess already covered anyway if the file~patchname files are
> being moved out of the src tree ]
> [ end cut ]


Jay, what's your account name on savannah, so that I can give you the right
to commit stuff?

Thanks to all of you, Mt.

-- 
Und auch jetzt ist ein Mensch mehr Affe als irgend ein Affe.
          --- F. Nietzsche




reply via email to

[Prev in Thread] Current Thread [Next in Thread]