Re: [Gnu-arch-users] Utterly painless arch?

[Zack Brown]

On Tue, Sep 09, 2003 at 10:00:17AM -0700, Tom Lord wrote:
> 
> 
>     > From: Zack Brown <address@hidden>
> 
>     > Miles Bader said:
>     > > This is definitely true; what I wonder is, is it possible to make it 
> utterly
>     > > painless to start using arch without introducing obstacles that would 
> make it
>     > > hard for a project to grow later (for instance, the most `initially 
> painless'
>     > > tagging-method in arch might actually be `by name', but that causes 
> obvious
>     > > problems later on)?
> 
> Watching IRC and the list, I've learned three things:
> 
> a) screwing around with =tagging-method is, indeed, the number one
>    problem newbies encounter

That's why the default should be something that requires no user action,
but just works reasonably; and then if they want better behavior, they should
be able to change it later.

> c) of the huge number of new =tagging-method features planned, a
>    single feature, the `untagged-source' directive, solves these
>    problems quite well.   As a refresher, the directives:
> 
>       untagged-source junk
>       untagged-source precious
> 
>    will mean to treat files matching the source pattern but lacking
>    tags as junk or precious rather than source (in implicit and
>    tagline) or unrecognized (in explicit).
> 
>    There's an unofficial patch floating around that hard-wires the
>    effect of `untagged-source junk' for explicit inventories.
> 
> In consequence of this, I'm writing the support for that directive
> _today_ and barring unforseen problems, it should be available later
> today.   More on that later.

Does it require any user interaction at all? I think in this case, it's more
important to have a transparent default that works 'well enough', than the
best possible behavior.

> It's already a pretty small number of commands.    From the traffic
> I've seen, the biggest obstacle relates to your observation that
> people grab some source they already work with, and try to check that
> into arch.   Then they run face-first into the need for
> =tagging-method customization and can't get through that wall until
> they learn what `inventory' does fairly deeply (and, even then, it can
> be awkward for some trees).

Again, this is an argument for a tagging default that's transparent to
the user. If the inventory stuff is so complicated, then just give sane
defaults so the user doesn't have to worry about it. Let them 'upgrade'
to more powerful controls later as they get more used to the system.

> 
> Two things will help fix that, I think.   One is the `untagged-source'
> directive mentioned above.   The other is a single command that let's
> you select from a canned list of "pre-sets" for =tagging-method --
> perhaps just an option to `init-tree'.
> 
> 
>     > The second big piece of overhead is the naming conventions imposed on
>     > repositories (I know, I know, but let's avoid the flames please). Its 
> enough
>     > of a pain just understanding the category--branch--etc style, let alone
>     > remembering it later. Someone who just wants to experiment with tla 
> doesn't
>     > want to have to learn all those naming conventions. It should be 
> possible for
>     > the user to specify their own arbitrary string to be the name. tla 
> should
>     > then provide a mechanism for the user to migrate to the more featureful
>     > naming conventions later. If it's impossible for tla to provide its 
> full set
>     > of features with such a restricted name, then it should provide a 
> restricted
>     > set, and document those restrictions. Then the user can regain those 
> features
>     > when they migrate to the proper conventions later.
> 
> In all honesty, while people do sometimes complain about the
> namespace, I don't think it is a huge obstacle.  I could be wrong.

It's just an additional inconvenience. Before anyone can start to use
tla, they are forced to develop a fairly deep understanding of its
organizational infrastructure. While this organization may be good, it
becomes part of a tla boot-up barrier that can't be avoided.

By creating something like name defaults, you give the user the ability
to follow the naming conventions when they're ready, but they can also
experiment with the tool, without having to understand or be comfortable
with the naming conventions.

People I've talked to don't only find the naming conventions to be
difficult to understand, but they balk at being forced to use a system
that someone else thinks is best for them, when they themselves already
disagree on the face of it. If you give them time to get to know the
tool without imposing that control from the start, they may come to see
the value of those controls as they learn how tla is used.

I'm really suggesting not abandoning the naming conventions, but just
providing a set of defaults that will work without user intervention, so
the user will only need to know the bare minimum about those ideas before
starting to play around with tla. Once they get the hang of it, they would
then be able to start taking advantage of those naming features.

> 
> 
>     > Those two things are the big obstacles IMO. In order for a user to just
>     > sit down and use tla, there has to be first of all, a quick way to 
> start up
>     > a project; and second of all, a way to get around the complex repo 
> naming
>     > stuff, even if only temporarily.
> 
>     > The tagging method you talk about is another issue, but less important.
>     > Default tagging should just be by name, so the user doesn't have to do
>     > anything. Let the power users choose better tagging systems, and let
>     > novices have things just work reasonably.
> 
> No, the default tagging should not be by `names'.  That would
> effectively disable some of the most interesting features of arch for
> newbies.
> 
> I think a decent choice for absolute beginners, especially if they are
> a little bit familiar with CVS, is something like:
> 
>       explicit
>         untagged-source junk
> 
> with a source regexp that matches tons of stuff and a `tree-lint' that
> warns (not errors out) about things matching source but lacking tags.
> 
> Then it's "just like CVS" in the sense that the things you add are
> source, the things you don't aren't, and the mystery files give you
> the moral equivalent of "? file" output.
> 
> Dummy, me: I should have made this change weeks ago.

I admit I don't really understand the feature you're talking about. But
if it would require no user intervention, I'm all for it. As soon as you
require that they make some choice between tagging options (or that they make
modifications to files to adhere to their tagging choices), it seems to me
you are requiring them to get to know all the ideas behind those options; and
that's what I'm suggesting would be good to avoid. By having a default that
requires nothing from them, you may not get the full shining glory of tla,
but you give them more of the ability to approach that shining glory slowly,
rather than overwhelming them with it all at once.

Be well,
Zack

> 
> -t
> 

-- 
Zack Brown