Re: [Gnu-arch-users] Re: abrowse and rbrowse (what rbrowse has that abrowse doesn't)

[James Blackwell]

In lists.arch.users, you wrote:
> address@hidden (James Blackwell) writes:
>> > So whose particular work habits _are_ the `primary use case'?
>> > Are you sure that matches common usage?
>> 
>> Ahh, so you see my point. There isn't a common usage. :) 
>
> Well, to be fair, you don't actually _know_ that, do you?

Is there some significant point that you're trying to make, are you
trolling, or what? 

To oversimplify, developers can be lumped into three groups that form a
pyramid.

At the tip of the pyramid you find the lead developer. He's a very
important guy. His long term vision shapes what a project will
eventually turn into. With this role comes things like the assignment of
lieutenants, veto power over most aspects of the projects, so forth and
so on.

In the middle of the pyramid you find the "lieutenants" (lt). The lt's
generally have a midrange length of vision on guiding the project. (This
is because the further ahead they look, the more blurry their vision).
Usually, a lt is authoritive for one or more parts of the project. 

At the bottom of the pyramid you have the submitters. What they lack in
power they make up in volume. These guys do gobs of bugfixes, Add
features within the framework set up by the lead and the lts, and work
their asses off. 

So, what's the most common case? Should we count by the numbers, and say
the submitters? Nope, not very reasonable in the long run, because
generally speaking, submitters don't require expansive revision control
skills. To prove this particular point, look at the number of submitters
that, rather than supply arch archives, supply *diffs* for changes! 

So, shall we then turn to the guy with the most power, the lead
developer? After all, we should guard against him burning out, and ease
the guidance of the project (after all, without direction, you're really
just wandering aimlessly). But come now, we need to be more pragmatic.
He really is after all just *one* person.

So lets shoot for the middle, the lts. They do a lot of heavy lifting,
have to play moderately, merge from the submitters, and merge to the
lead. This doesn't work quite right either, because we've left out both
the tip and the base of the pyramid.

Now, in some places, figuring out the common case is trivial. For
example, look at star-merge. That is clearly a tool that is usually used
by the lts and the lead. 

With browsing, there are two ways to go about it. You tune the
command line options to make browsing local archives as easy as
possible, you tune them to make browsing remote archives as easy as
possible, or you do something thats kind-of-in-between.

Submitters generally want to browse remote branches, because they don't
get as deeply involved in development. Lts are the exact opposite. They
have to deal with a large number of branches, and want the tools tuned
to handle those cases as easily as possible. The lead developer wants
things both ways. 

By now you're probably thinking that I'm throwing up a red herring, and
you're right. It is a red herring. This is just some crappy rhetorical
essay that rebutts your rhetorical question. However, I did think pretty
hard about whether or not there's a common case, and I didn't come up
with one.

I think that the real problem is that you're [CENSORED] because your
[CENSORED] did [CENSORED]. Some day, the tool will be be better
tailored to your particular use case, and you're [CENSORED CENSORED]
will hopefully [CENSORED]. In the meantime, you are welcome to lend
a hard, wait paitently, [CENSORED] or better yet, [REALLY CENSORED].

Love,
James

-- 
James Blackwell          Please do not send me carbon copies of mailing
Smile more!              list posts. Such mail is unsolicited. Thank you!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400