[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Quilt-dev] misc. questions
From: |
Andreas Gruenbacher |
Subject: |
Re: [Quilt-dev] misc. questions |
Date: |
Sat, 14 Jan 2006 13:14:01 +0100 |
User-agent: |
KMail/1.8.2 |
On Friday 13 January 2006 12:18, John Vandenberg wrote:
> Hi,
>
> I have a number of questions and suggestions for 0.44 that I have
> throw together; feel free to answer a few at a time and come back to
> others.
>
> 1. should patches for review contain quilt.changes updates? My
> initial impression is that this would be a good idea, as the contents
> of this file are part of the published package; but, it would hinder
> re-ordering patches. perhaps this can be avoided by adding a script
> that generates a quilt.changes update from the patch header, to be
> used prior to commit.
I'm usually creating the changes entry by hand.
> 2. should the patch header be used for the cvs commit message?
Sometimes, yes.
> 3. should I start a Contributions FAQ file? if so, in doc/ or the
> base directory?
What would that file contain?
> 4. I often add features to quilt because I need to use them then and
> there, and then months later on forget what additional patches I have
> installed on that box. Timestamps and version numbers are useless;
> the only way I can deduce what it can do is to know the list of
> patches that were applied. does this sound like a reasonable addition
> to development versions of quilt?
I don't understand what you mean here.
> 5. I also forget where I was up to with a workpit, and come back to it
> wondering whether if I need to do a fork/refresh and diff the two
> patches. I would like to add a status.in to tell me what the current
> state of play is. My thoughts were that it should display:
>
> Patch: $(quilt top)
> Status: (up-to-date|stale|missing)
>
> $(quilt header)
>
> The missing option would appear whenever there are changes against
> .pc, but no saved patch.
>
> It may also be useful for the status command to list each file in the
> patch with its own status.
>
> (btw, as you may have gathered, I have a brain like a sieve and a
> tendency to leave half finished work lying around, so if anyone has
> any other enhancement requests that assist the hypothetical user
> coming back to an old workpit, I will happily implement it knowing
> it's gonna save my arse one day)
I'm not sure which information such a status command should print.
> 6. I would like to add a shell.in, that opens a shell with patchfns
> loaded, so I can trial certain operations that doesn't warrant
> cracking open the source and adding a feature. However, this command
> could produce dire consequences in the wrong hands; is it ok to
> install this? should it issue a strong warning to the user?
I'm not sure this would be a good idea. What's wrong with simply sourcing
patchfns?
> 7. Is it ok if I start moving the autoconf tests to separate files
> into m4, and submit them to the ac-macro archive.
>
> http://autoconf-archive.cryp.to/
I don't see which pieces would make sense upstream. It's all pretty quilt
specific.
> 8. In the TODO file is an entry "Add command to extract a header."
> Could someone comment on what is desired?
The header command. This is a stale entry; I'm removing it.
Thanks,
Andreas