[Gnu-arch-users] Re: [GNU-arch-dev] Re: GNU Arch status update

[Tom Lord]

   From: Anand Kumria <address@hidden>

   *sigh*; another tla slow down. Oh well.

One does what one can, when one can, with what one has.

I've created several bugs based on your report.  You can see 
the updated bug database at:

   http://www.gnuarch.org/bugs--devo--2005/

Here are some replies to your message:

   Okay, no idea how a user reports bugs using your new system.

You've discovered one way by accident.  This is it: capture the attention
of a bug czar in any civil way and present your bug report.  It's the
job of the bug czar's to record and refine your report into a format
that best suits the programmers.  You might, of course, be asked to help
do that in some cases.

My intention is to reclaim the "[BUG]" string for subject lines on
gnu-arch-users and gnu-arch-dev and to brush off and start using
the bug-gnu-arch list (for users who want to report bugs but not subscribe
to any list).   My goal is to staff the bug czar desk 5 days a week, for
a small amount of time, during which the acting czar processes new reports
and engages in any correspondence needed.

The bug czar system is not officially on-line yet.  We are still working
out if/how we can allocate commercially volunteered hours (hours of labor
donated by a for-profit enterprise) to staff our bug tracker.   However,
I will use your report here to try out the system for myself.

If the RFCV (request for commercial volunteers) fails I suppose we can
try and do something like this on the basis of ordinary (unpaid, unmanaged)
volunteerism -- but that approach (a) historically has problems;  (b) makes
me ethically quite uncomfortable for reasons too long and boring to go into
here (very briefly: it's too easy to wind up abusing well intentioned 
volunteers that way -- maybe they should go volunteer in a local old-folks
home or young-folks school or some other community-based, face-to-face, 
much-harder-to-get-sucked-into-utter-bs context).

But anyway... on with your bugs....


   So here is
   what I know that seems to continually get missed;

   tla commit:
           - generates an empty log if $EDITOR is not set
           - generates an empty log if import has not been done

Those are clear enough.  The bug is called `commit-log-errors'.

           - fails, crashes and burns horribly if signature generation fails

I've created a bug, `commit-signature-crash', for this.  I trust that
this is easy to reproduce (e.g., I could change a signing rule to "exit 1"
and see it) but, that I or another programmer will have to do so in order
to understand what you are referring to makes this bug more expensive for
us to work on.   A little bit more information about the nature of 
what you mean by "fails, crashes and burns horribly" /might/ be a big win.


   tla undo:
           - selective undo

See the bug `selective-mkpatch-wanted'.

   tla tag:
           - default the '-S' switch to on
   tla import:
           - default the '-S' switch to on

Can you think of a different request that would satisfy you instead?

Those changes would lower the barrier to allowing simple typos to 
muck up an otherwise perfectly clean archive and so I have not created
a bug report for them.


   tla make-category / make-branch / make-version / archive-setup
           - remove: they are no longer needed with the tag/import changes

I disagree.   I have no trouble imagining scenarios in which the presense
of an empty category, branch, or version is meaningful to the users of
a given archive.

(Perhaps, though, fixing the bug `help-too-long' would satisfy you?)


   tla make-archive
           - default the '-l' switch to on for all archives

Can't do that literally for robustness reasons but I've created
a bug, `transactional-archive-listings' to address the issue I think
you really mean to solve.

   tla add / delete / move / default-id
           - remove these unneeded aliases
   tla mkpatch / dopatch
           - remove these unneeded aliases

I happen to like those aliases.   I'd like more aliases, in fact.
Are you sure that fixing `help-too-long' isn't enough to answer
your concerns in this area?

   A mechanism to identify the currently checked out tree-revision (similiar
   to baz tree-id -- but if the name offends, pick another one!)

You will need to explain to me what you mean by "currently checked out 
tree-revision" because there are multiple possible meanings and I'm not
clear which one you mean.  (No bug report created yet.)

   These are the interface nits and warts that I'd hope can be fixed in a
   1.3.x or a 1.4.x.

Thank you.  Very nice report, overall.

   Cheers,
   Anand


-t