Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc.

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Wed, 2004-07-21 at 11:29 +0900, Miles Bader wrote:
    > > Colin Walters <address@hidden> writes:
    > > > I am unconvinced that people are going to be typing "tla submit" often
    > > > enough that it is necessary to create a new configuration language.

    > > Why do you think people won't be using "tla submit"?

    > In its current form it is way too limited.  When people submit Rhythmbox
    > patches, they often want to describe the patch.  How is that going to
    > work?  Would tla become a MUA?  What if they also want to attach a
    > backtrace from a core file?  What if they want to GPG-sign the message?
    > What if we have an existing infrastructure like Bugzilla for handling
    > these kinds of things?  

Those questions (which I think have pretty easy answers but are good
questions anyway) represent an (extreme) local maximum, from my
perspective, in the utility of your contributions as Critic.

Yes, I suspect that arch will indeed become, in a very limited sense,
an MUA.   (It will be an MUA in the sense that _any_ program that ever
sends email of any form is an MUA, and not much more beyond that).

Yes, there is a limit (but not "none"!) to how useful Bugzilla can be
made in an arch context.   Bugzilla won't be any less useful with arch
than with any competing system, but BugGoo or its descendent will be
much more useful (and arguably already is) than Bugzilla could hope to
be without a major overhaul.

Things like GPG-signing: since the procedure for sending a message
will need to be configured, why do you think that this would be hard?
Similarly for attachments.

Often the log entry should be a good place for a description.   When
it isn't, a text attachment is a good place.

There are, as you note, many many details and variations to consider
when doing a submit script (or designing an arch infrastructure
generally).  What's an open question (my betting money is down,
though) is whether those variations fall into a small enough range to
consider answering with something other than "build a layer of scripts
over arch".

There's plenty of incentive to find a tighter solution than layered
scripts.   It would make an arch infrastructure a "first class object"
that programs could reflect on rather than just a set of API entry
points that programs could call.   Do you understand what I mean by
that or am I being to "jargony"?


    > For a larger project, how would they choose the
    > "component" a bug report corresponds to?

What do you mean (if it's important)?

    > What about authentication?

What about it?

Are you just playing buzzword bingo there?   Is it not worth your time
to express yourself clearly for an audience of peers?  What's the
deal?

-t