quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] Re: My current quilt 0.21 :)


From: Martin Quinson
Subject: Re: [Quilt-dev] Re: My current quilt 0.21 :)
Date: Thu, 30 Jan 2003 09:06:23 +0100
User-agent: Mutt/1.4i

Good $time_of_day,

On Thu, Jan 30, 2003 at 02:40:09AM +0000, James Rowe wrote:
> Hey
> 
> On Wed, 29 Jan 2003 10:48:14 +0100
> Martin Quinson <address@hidden> wrote:
> 
> > James, how does it looks like for you ? Could you add your thought to
> > the TODO file ?
> 
>   It would be really nice for to have named tagged to the items in TODO,
> so you see quickly that nobody else is working on that particular item. 

We could use the bug tracking system from savannah to fill wishlists, also.
No idea which system is more convinient.

>   I really need prettier support for a global out of tree quilt data
> source, so that is the highest thing on that list for me(unless of
> course 'Test if patches/ can be moved with environment variable as
> planned.' wasn't referring to that. But still... before I carry on I
> need to reiterate some points from a unanswered mail last week.

Yes, I really need that too. But since quilt was a moving target last week,
I didn't check the source to see if I can implement that.

>   I am going to continue supporting the autotools build system
> locallly, as much for portability as, for sensibility during install.
> Perl location, patch location/version(especially for systems like
> Solaris, or users who have a 2.0.x) and to a lesser extent bash(if you
> count SGI box I am exporting this sylpheed to now) are some of the
> immediate issues. Of course, these issues can be achieved with the
> current static Makefile with some effort, but personally I don't think
> it is the way to go.  
> 
>   The portability issue applies to a few other areas in quilt too,
> specifically tempfile creation(but that is an issue for a mail after I
> get my work done).

For me, you can go ahead and implement some ./configure stuff. It should be
pretty easy, and cleaner than doing autoconf's work without autoconf (even
if current solution is really enough on linux).

>   So really to sum up and finalise:
>       It seems nice and stable(although I couldn't try any rpm-based
> features)

Great.

>       Before we pounce on anything in the TODO list we should be atleast
> submitting a mail to -dev saying so.

Agreed.

>       Has anybody got any reasons for not using docbook for the manpages?  I
> plan on starting on some documentation tomorrow, and would prefer to
> use docbook for simplicity.  Could make life easier for site information
> generation if/when that time comes.  But for the meantime it makes
> little difference to me anyway, as a quick transform to man for
> inclusion is possible if there are objections.

I guess that it's only lack of time. The only other reason i can imagine is
that the README file is generated from the output of all scripts --help
stuff. Maintaining documentation in only one place is always good, IMHO.

>       And again, quilt should be outputting full --help information but I
> would like to see some agreement on this before I implement it. 
> Especially as there are other things I could be doing instead.

I don't understand here. Agreement on what ? Implementing a full help
information should be pretty consensual, I guess.


Thanks, Mt.

-- 
The "US department of defense" should be renamed the "US department of
attack". 




reply via email to

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