[Gnu-arch-users] hmm. an alternative to a new maintainer. Hire your manager.

[Thomas Lord]

First: Let me state publicly that I'm working on cranking
out a first cut at the syntax tools I've described recently.
I'm mentioning this in public so that I'll be too embarrassed
to give up on it :-)

Second: instead of a new maintainer for tla, which for all its
flaws is pretty stable, I wonder if anyone might want to help
build Arch 2.0?  And if so, I wonder if that project can be
organized in an interesting way....

Let's take the current state of chaos and crisis as opportunity --
turn it to collective advantage.  If we've learned one thing from
recent threads on this list, it's that the FOSS-community's 
distributed revision control efforts are, at the moment, very much
a mess.  Cool!  In that circumstance, there's a clear objective:
build the Right Thing that Just Works.

An Arch 2.0 needs a few things:

  1. It needs a storage manager, which we have in revc.
  2. It needs diff/merge functionality.
  3. It needs to be portable to windows and, generally,
     have only minimal dependencies.
  4.It needs to be scriptable because, let's face it,
     if it's nicely scriptable people will build lots
     and lots of nice ancillary tools and they'll turn
     away from mucking up the core.
  5. It needs to have nifty web tools, including a full
     GUI.  See (4).


Let's start with (2).

A flaw in larch and tla is that the functionality of
inventory/mkpatch/dopatch is not separate from everything
else.  Those *should* be separate "tiny tools" (librified,
sure).

In fact, inventory really has two separable functions:
naming convention rules to figure out what files in a 
tree "look like" they should be source and tagging rules
to assign logical ids to files.  Let's call those two
functions "linting" and "tagging".

Linting, tagging, mkpatch, and dopatch are universally
useful, with or without an eventual Arch 2.0.  We've
heard reports about how the git merge architecture is
"pluggable" -- well, these tools could be plugged in.
We can see that Subversion has never quite got around
to doing whole-tree merging well -- these tools could help.
You get the idea.

So my suggestion, at this juncture, is that the community
cough up, as a start, some labor and other resources to 
work on tagging.  If this approach works, we can expand the
effort to include linting, mkpatch, and dopatch.

Let's put strict upwards compatibility with tla on the
back burner.  Sure, we (hopefully) later want a painless
migration path but the priority today, given the crisis,
is to do the Right Thing that Just Works.

So the core functionality we desire here is a mapping
from files to logical ids.  We want this in library and
CLI form.  The library form should make "language bindings"
trivial.  We want the computation of this mapping to be 
fast when applied to a list of all of the controlled files
in a tree.  We anticipate programs, using the library form,
to ask for the id of a given file more than once in a given
run.  We are willing to, for speed purposes, use heuristics
on some systems -- if a file seems to have not been modified,
there is no need to reread it every time a program asks for
its id.  At the same time, we should be able to take advantage
of systems that let us monitor the filesystem -- that let
us get a message from the system if a file is modified or
renamed or added or deleted.

As a CLI, this would be a program that accepts as input a 
list of files and that produces as output a listing of
those files together with their tags.

The design space for how logical ids are established 
seems to have five branches worth considering:

  1. Store them in the file, as taglines.  This only works for
     a subset of files that can allow arbitrary text to be 
     added.

  2. Store them as per-file, same-directory meta-data files
     (in the manner of tla "explicit"-method tagging).

  3. Store them as collected-in-one-file same-directory 
     meta-data files.

  4. Store them in an identified "tree root" in a single
     file.

  5. On systems that permit it, use the application-defined
     per-file metadata offered by the underlying filesystem 
     to store ids.

A good tagging tool/library should implement some combination of
those, letting user's choose which approach to use in a given
circumstance.

Additionally, experience with `tla' has shown that for most of those
possible tagging methods, it is performance-critical to implement
caching of some sort -- such as a file at the root of a tree where
logical ids that are expensive to compute are remembered.

The code implementing the tagging system should be written in C
and should use Hackerlib rather than libc where the libraries
overlap in functionality.   At the same time, most of the code
should contain no system calls or `vu_' calls directly -- the
operating system calls needed by tagging should be clearly 
encapsulated in a thin wrapper layer that is specific to the 
tagging module.

Code should follow the conventions in the GNU coding standards as
far as formatting and identifier names are concerned.

Every exported function should be preceded by a thorough comment
of what it does.

Every exported function that can result in an error should accept
an `errname' parameter (of type `const t_uchar * const errname')
and should describe errors encountered by calling a `printfmt'-style
function that takes the `errname' parameter first and a format string
second.

To the greatest extent possible, exported functions should have 
parameter and return types limited to basic C types -- avoid 
structures, unions, and enums.

The hackerlab `alloc-limits' interfaces should be used for memory
allocation.   Every function that allocates memory should accept
and use an `alloc_limits' parameter.  Every call to an allocation
function should be error-checked for an allocation failure.

There are additional coding conventions that apply but the list is
long and it is probably easier to communicate them incrementally by
pointing out violations than to list them all in advance.

The functionality of tagging is not especially glamorous in and
of itself.  On the other hand, it is a small task that can be completed
fairly quickly and if it goes well we can immediately move on to the 
far more interesting functionality of mkpatch and dopatch.

Believing that:

  a) Through reviews and critiques, I can help to improve the C
     coding abilities of almost anyone working on this.

  b) By imposing editorial control I can establish an aesthetic
     and practical unity with revc and code later to be established.

  c) Through managing projects like this, if there is sufficient
     participation, we can swiftly make an Arch 2.0 that is the
     Right Thing and that Just Works.

  d) My efforts in this direction are valuable from multiple 
     perspectives.

I propose to supervise this work by giving follow-on review, task
refinement, follow-on tasks etc.

I propose that people interested in working on it provide these things:

   1) a statement of motivation -- why do you want to do this?
   2) a statement of qualification -- why do you believe you are
      qualified and why should I believe you?
   3) a statement of plans -- state your technical plan in 4 pages
      or less.
   4) payment -- hire your manager, rather than the other way around.
      Of course, you might find a sponsor who will hire your manager
      for you.  I demand $75/hr with a minimum of 4 hours (for this 
      task) paid up front, upon my approval of your three statements.
      Additional hours, if needed, must be settled bi-weekly.

You must be identifiable, not anonymous.   You may retain copyright
to your work but must provide it to me under standard GPL terms (current
or any later version, at my choice).  You may, depending on 
circumstance, be required to affirm these licensing terms on paper.

Hire your manager, not the other way around.
-t