Re: [Monotone-devel] Project Management

[Thomas Keller]

> On Wed, Jul 19, 2006 at 03:47:47PM +0200, Thomas Keller wrote:
>> Still, I hope that some kind of convergence is achieved here, since I 
>> strongly believe that this project *needs* some management.
> 
> "Management" is a word that means a lot of different things to
> different people -- some of them probably useful, some of them
> probably not.  To focus the discussion, do you think you could provide
> some specific examples of problems that have arisen from lack of
> management, and what form of management would prevent those problems
> occuring in the future?

I've only scratched the surface in terms of monotone development, and I
do believe that the internals are pretty sophisticated and also matured
(otherwise there would be a big bunch of open bugs in the tracker). I
think this is because there are only very few "core" developers which do
touch these things and these developers have both, very good
communication and coding skills.

However, for me as "extension" or GUI developer one of the most
important things is a clean, complete and well-thought API. This API is
supposed to be stdio for monotone, but IMHO its neither clean, nor
complete or well-thought. I think this is because there was never a real
demand to make it this way ("hey, we're adding commands to the
automation interface on request"), so different formats, error handling
and all that arised.

There is for example my rant why not everything uses basic_io in the
automation interface as output, and yes, I have read and understood the
problems of shell scripts (sed, etc.) parsing that kind of output, and
yes, I know get_file with binary files would need some trick to work out
(e.g. by base64 encoding the contents to avoid \0 in the output), so
programming a clean interface to monotone is nothing than a mess at the
moment.

Now, I know that there are efforts by some very skilled people to expand
the automation interface in the right direction, what I'm missing here
is some guidance of *you* or any other core developer which should be
able to draw a bigger picture.

Let me give you an example: If I like to get all current attributes of a
file in the workspace I have three automation commands available
(get_manifest_of, get_revision and attributes), obviously not one of
them provides the complete data which reflect the current workspace'
status. No, to get this status I need to call *all* three commands and
pick out the parts I need.

You might probably want to answer here "hey, all these commands have a
different background and were never meant to return the data you're now
demanding", and of course, this is right from a developer's perspective.
But for me as "interface user" this is just a poor excuse, since it
shows me that the interface is not really an interface but a stub to
*some* functionality of mtn.

Don't get me wrong, this is not about renaming the thing from
"automation interface" to "automation stub", no, this is about making
this stub a *real* interface. Now you might ask "why should we want a
clean 'real' interface at all, mtn cmdline works pretty well and I don't
care about anything else", well, to attract 3rd party developers to
write tools, guis and whatever else for this system it is needed and it
should be taken care of.


What I told you above is just one thing which should deserve some
"management", but this was the most imminent and obvious for me. This
kind of management should help developers which are not actively
developing on the core or are even doing 3rd party stuff like me, this
should help giving these people a top view of the project's status, like
what features are planned for which version, what is currently been
worked on, and how things are planned to be incorporated into the code,
all this. This would also give interested people a good view on where
the project is heading in the future.
I know that the Wiki has parts of this kind of information available,
but these informations are unordered and "too far" away from a website
user which checks the 20+ frontpage links on venge.net/monotone. Also,
the downside of wiki editing is here that everybody has access to edit
everything (if not otherwise configured/implemented), and there is
nobody who really "speaks the last word" in terms of how something is
done or not done.

In the end this is a software project about distributed version control,
and maybe that kind of "decentral, distributed project management" which
happens at the moment is part of the nature of this project (and
explicitly wanted), so one might forgive me if I ask for a structure in
this regard, but my inner feeling keeps telling me that its needed.

Thomas.
-- 
Registered Linux User #369861
PGP Public Key on http://thomaskeller.biz/pgp/thomas-keller.pkr
Learn to quote http://netmeister.org/news/learn2quote.html