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

[Andreas Gruenbacher]

On Thursday 30 January 2003 03:40, James Rowe wrote:
> Hey
> [...]
>
>   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.

I'd prefer a short note on quilt-devel for nontrivial stuff; tagging the 
TODO seems more appropriate for somewhat bigger changes.

>   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.

Well, $PATCHSCRIPTS _should_ allow to move the patches/ directory 
anywhere you like; it just is untested. I think it makes no sense to 
allow moving the .pc directory around at all; it is anyways associated 
closely with the working tree all the time. If you think differently we 
might discuss this.

>   I am going to continue supporting the autotools build system
> locallly, as much for portability as, for sensibility during install.

What is autotools? Do you mean GNU Autoconf?

> 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.

I have added some more substitutions in the Makefile. You could write a 
configure.ac to find out the paths to the utilities. (Some things like 
cp are not substituted.)

>   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).

Tempfile creation could be abstracted intp patchfns for example. I don't 
know well enough what Solaris etc. provide for that, so I'd better 
leave that to you. (But note that some temp must live on the same file 
system as the files themselves to allow a rename.)

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

Good :)

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

For non-obvious things I tend to agree.

>       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.

Docbook would be fine I think. What is most painfully missing is some 
documentation on how to set up / apply and remove / deal with rejects / 
rediff / get status information / how to recover from problems, I 
think.

>       And again, quilt should be outputting full --help information but I
> would like to see some agreement on this before I implement it.

What exactly do you have in mind? I was thinking of a wrapper that gives 
one-line information on each command, but adding an option to each 
script for printing a one-line description seemed too messy for what it 
would bring.

Of course the `quilt <command> -h' texts could be improved...

--Andreas.