Re: [Quilt-dev] misc. questions

[John Vandenberg]

On 1/14/06, Josh Boyer <address@hidden> wrote:
> On Fri, 2006-01-13 at 22:18 +1100, 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.
>
> My $0.02.
>
> >
> > 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.
>
> Nah.  Like you said, it's just adds overhead.  And the person that
> submits the patch isn't necessarily the person that commits it.  I think
> the committer should add the text to quilt.changes.

Should the patch header be written so that it can be readily pushed
into quilt.changes?

> > 3. should I start a Contributions FAQ file?  if so, in doc/ or the
> > base directory?
>
> Can you elaborate on what this would be used for?  Like a "HOWTO
> contribute"?  Or more of a "these people have contributed"?

I was thinking about questions like the first two, and others I
trouble the list with, being recorded for future reference.  Does
something like that already exist?

> > 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?
>
> Need more info.  If you've used quilt to patch your local copy of quilt,
> aren't the changes in your patches directory?

The problem is knowing which workpit I have installed on the box.

> > 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.
>
> A quilt status command might be cool.  I could see myself using it at
> least.
>
> > 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?
>
> Erm, not sure if this should be in quilt itself.  Starting a shell and
> sourcing patchfns shouldn't be that hard... or maybe I'm missing
> something?

quilt knows where its patchfns and compat/* are located, and if
`shell'  is quilt command, stdin can be used to run a quilt command
sequence that can take advantage of functions in patchfns.

I was intending on adding some window dressing around it: a
customisable prompt that can contain quilt metadata, running status on
entry, setting HISTFILE and others to record an auditible history in
the workpit, and alias's to commands like help, status, refresh,
header, etc. so the user doesn't need to type quilt repeatedly.  I
haven't thought to hard about commands where a program of the same
name exists; I'm leaning towards giving preference to the quilt
commands, esp. grep and top.  Here are the list of name conflicts on a
relatively normal installs (replace /usr/bin with /bin for Solaris):

/usr/bin/diff (Ubuntu, SuSE7.2, Gentoo, FC3, Solaris8)
/usr/bin/edit (Ubuntu, SuSE7.2, Solaris8)
/usr/bin/fold (Ubuntu, SuSE7.2, Gentoo, FC3, Solaris8)
graph is /bin/graph (Solaris8)
/bin/grep (Ubuntu, SuSE7.2, Gentoo, FC3, Solaris8)
/usr/bin/import (SuSE7.2)
/usr/bin/mail (SuSE7.2, FC3, Solaris8)
/usr/bin/rename (SuSE7.2, FC3, Gentoo)
/usr/bin/setup (FC3)
/usr/bin/top (Ubuntu, SuSE7.2, FC3, Gentoo)
snapshot is /usr/openwin/bin/snapshot (Solaris8)

and some other conflicts I found.

next - MH * nmh
upgrade - a program by UNIFY Corporation

> > 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/
>
> Are you looking to do that and push the resulting stuff back into quilt?
> If so, I have no idea.  But even if you aren't, quilt is licensed under
> the GPL so I don't see anything stopping you.

my apology; I meant to ask whether anyone would object if each test
was separated into a macro that is stored in a separate file, located
in m4/ .

--
John