[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [GNU-arch-dev] Re: GNU Arch status update
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] Re: [GNU-arch-dev] Re: GNU Arch status update |
Date: |
Mon, 7 Feb 2005 08:35:45 -0800 (PST) |
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
- [Gnu-arch-users] Re: [GNU-arch-dev] Re: GNU Arch status update,
Tom Lord <=
- [Gnu-arch-users] Re: [GNU-arch-dev] Re: GNU Arch status update, Cameron Patrick, 2005/02/07
- [Gnu-arch-users] Re: [GNU-arch-dev] Re: GNU Arch status update, Tom Lord, 2005/02/07
- [Gnu-arch-users] Making --setup default in tag and import, Mikhael Goikhman, 2005/02/07
- [Gnu-arch-users] Re: Making --setup default in tag and import, Tom Lord, 2005/02/07
- [Gnu-arch-users] Re: Making --setup default in tag and import, Mikhael Goikhman, 2005/02/07
- [Gnu-arch-users] Re: Making --setup default in tag and import, Stefan Monnier, 2005/02/08
- Re: [Gnu-arch-users] Re: Making --setup default in tag and import, Aaron Bentley, 2005/02/08
- Re: [Gnu-arch-users] Re: Making --setup default in tag and import, Mikhael Goikhman, 2005/02/08
- Re: [Gnu-arch-users] Re: Making --setup default in tag and import, Ben Finney, 2005/02/08
- Re: [Gnu-arch-users] Re: Making --setup default in tag and import, Mikhael Goikhman, 2005/02/08