Re: This proposal doesn't imply extra work (was: Requiring DOAP instead of MAINTAINERS file)

["Olav Vitters" <ovitters gmail com>]

[forgot the reply-all, sorry]

On Jan 21, 2008 12:54 PM, Mathias Hasselmann <mathias hasselmann gmx de> wrote:
> Am Montag, den 21.01.2008, 12:16 +0100 schrieb Olav Vitters:
> > On Jan 18, 2008 9:49 AM, Olav Vitters <ovitters gmail com> wrote:
> > > Summary: I'd like replace the MAINTAINERS requirement by doap files.
> >
> >
> > > I have a partial script that I want to expand to include as much info
> > > as I can possibly can add automatically (everything until the 'and others'
> > > above).
> >
> > Just highlighting the parts that have been missed. I'd appreciate, but
> > it is *not at all required* to do any work after the script changes
> > the format from MAINTAINERS to doap. The field that I *require* is the
> > maintainer part (again: will be converted). All the other fields are
> > extra's. Nice to have, really appreciated if provided, but not
> > required.
>
> So I understand even less, why you want us to use a file format which as
> several technical problems:
>
>  - hard to read and write

Is this technical? It isn't the perfect format. However, it is doable.
Further, you already suggested the .ini like format, which still is
not an ideal solution (as maintainers had problems with MAINTAINERS).
I understand it is more difficult than MAINTAINERS. However, coupled
with there will be a conversion and that it mostly is a one-off thing,
I don't think it matters.

>  - redundant with AUTHORS file

AUTHORS is not always there, not readable by machines, not always in a
standard location and the layout often differs. Further, I don't care
if someone puts AUTHORS in doap. If someone does, people could
generate AUTHORS from DOAP. Initially I don't care to have AUTHORS in
DOAP, maintainers are free to either include it or not (quoted above:
"All the other fields [aside from maintainers] are extra's").

>  - redundant with Changelog, NEWS and FTP

I don't see any relation to that.

>  - no support for git or bzr

It is for GNOME SVN. Why should I care ATM for git/bzr? I'd like some
*existing* format that includes that. However, couldn't find anything
and I hate making a new format and then having to recreate whatever
exists for some existing format.

> You want additional information for svn-commits-list, web-sites?

I have more ideas, which I'll keep to myself to limit the amount of
stop energy per week.

> You want to provide the service of hosting DOAP files? So keep
> MAINTAINERS (and AUTHORS, and whatever DOAP related information we
> already have), add some PROJECT-INFO file that lists the missing pieces
> of information, and generate the DOAP file.

No. MAINTAINERS can go (again, no enforcement). AUTHORS: maintainers
will be free to add such info to DOAP, don't care. It would be great
if that is in DOAP and e.g. autogen.sh generates such a file. I don't
care if it happens or not.

Not sure what you mean with FTP. I could remove ftp.gnome.org, but
DOAP will not provide tarballs and I think not everyone wants to
create tarballs from SVN.

> > The script will fill in a lot of fields, as explained in my initial
> > email. Any info that could be fetched from somewhere will be included
> > / updated automatically. In practice I don't think you'll notice on
> > the short term.
>
> What about new modules? First of all they have to copy boilerplate code,
> to get a valid DOAP file - very bad engineering. Second they have to lie
> at many fields, as new modules usually do not have a Website or Bugzilla
> and such yet...

You seem to think I dismissed your suggestion while I haven't
commented on it yet. You suggestion would output DOAP anyway. I'm
strictly discussing the possibilities of 1) having such info in one
place 2) amount of work required from maintainers while not discussing
if the inital input is doap or something else.

DOAP has an special method for people wanting to fill in bad
information. It is done by not including the field if you either don't
know it, or whenever you want to fill in bad information. I really
hope your .ini-like suggestion follows the same logic.

> > I know changing this part of the infrastructure (maintainers vs doap)
> > for the second time is not ideal. However, some things are just needed
> > to have a better infrastructure. E.g. Mango would not work without
> > knowing the maintainers in some machine parseable way.
>
> Mango rocks, and MAINTAINERS indeed was a good idea.

It doesn't work in practice, as already explained (details in other
emails). I could add more strict pre-commit checks, but I rather move
to a better format.

Regards,
Olav