Re: Requiring DOAP instead of MAINTAINERS file

[Behdad Esfahbod <behdad behdad org>]

Hi all,

I've read the entire thread.  I didn't see my thoughts on this mentioned
already, so I add them here.

I don't care what the infra team does to keep an updated view of my
modules as long as it leaves outside of the module and doesn't need
manual updating regularly (even every year is considered regularly.
Sorry!  More on that later.)

What I do care about is that all released modules MUST have the files
AUTHORS, README, and MAINTAINERS, some also have THANKS.  Most of these
are required by GNU Coding Standards which is a really great document,
and my other reason for this is that when a user downloads and unpacks a
tarball, they don't look for a DOAP file, they look for those ol'
big-letter files.

Which brings us to the logical conclusion that either the big-letter
files should be created from DOAP file automatically, or the other way
around.  I'm sure most agree that other way around is preferred at this
time.  Right?

So, what I like to see is, MAINTAINERS and AUTHORS automatically scanned
for names/address/login-ids and central DOAP file updated and as a
result Bugzilla developers for the module updated.  Bugzilla module for
a SVN module also can be easily extracted from configure.{in,ac}.  It's
supposed to be at least.

The rest of the DOAP bits, not sure where they are supposed to be
updated from.  Direct commit to the doap repo works for me.  That's not
harder than updating GTK+ website with every Pango release at least...

To summarize, seems to me like most of the thread was in fact irrelevant
as I don't see any change being proposed to individual modules.  It's
about gathering meta-information about GNOME in a central place, and I
don't see how that can be bad, even if the format is not perfect.  We
can always write an XSL style to convert to any other one, right?
That's what's great about XML, right?

Cheers,

behdad




On Fri, 2008-01-18 at 09:49 +0100, Olav Vitters wrote:
> Hello,
> 
> Summary: I'd like replace the MAINTAINERS requirement by doap files.
> Comments welcome.
> 
> Currently project information is spread thoughout various systems. The
> maintainers are available in MAINTAINERS files, developers in AUTHORS,
> the description is possibly in either Bugzilla or some README file,
> etc. I'd like to make use of DOAP files for this.
> 
> See for example the usage of DOAP on projects.apache.org:
>  * http://svn.apache.org/repos/asf/ant/core/trunk/doap_Ant.rdf
>  * http://projects.apache.org/projects/ant.html
> 
> Examples of what is in a DOAP file:
>  * maintainers
>  * long description
>  * releases
>  * homepage / download link
>  * bugtracker link ()
>  * repository info (SVN + viewvc)
> And others:
>  * short description
>  * mailing lists
>  * various kinds of contributors
>  * programming language
>  * category
>  * etc
> 
> The intention at the moment is to just make these DOAP files
> available. I don't plan to create something like projects.apache.org
> in the near future. This for every module in svn.gnome.org. 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).
> 
> My preference is to create some new repository and include the doap
> files there ('doap'). However, to make things easier I don't plan on
> storing the full doap file there. It will have something like
> '$module.rdf.in', that will be transformed into a $module.rdf on some
> site.
> After the conversion I plan on requiring such a doap file, and
> removing the MAINTAINERS requirement. The current /trunk/MAINTAINERS
> requirement means you cannot replace /trunk with a branch by just
> using 'svn mv' (as at one moment /trunk won't exist). With having the
> doap file in another repository, the problem is only restricted to
> that repository.
> 
> Note: There is a plan for the new www.gnome.org to contain doap files
> as well. See http://live.gnome.org/GnomeWeb/GnomeProducts. SO perhaps
> at one point the doap files are used to the www.gnome.org CMS.
> 
> Things that could use doap:
>  * moap (https://thomas.apestaart.org/moap/trac)
>  * maintainer.py (http://developer.imendio.com/projects/misc/maintainer)
>  * Mango sync script (instead of /trunk/MAINTAINERS files)
>  * Bugzilla (cron job that updates e.g. homepage link)
> 
> Note:
> The doap repository will have strict pre-commit checks. Ensuring a
> valid doap file with enough information. Also I might restrict
> changing the maintainer section to the current maintainers.
> 
> The doap files can include 'foaf' stuff to provide maintainer
> information. I'm not exactly sure what to do there. If you are a
> maintainer for 10 projects I don't think you'll ever update that info.
> However, I cannot just put info from LDAP in there as that often
> contains the full name. Doap does allow using hashing for the email
> address. ATM I don't want to add anything other than the userid. Maybe
> the full name taken from the MAINTAINERS file.
> Perhaps I'll create foaf files in the doap respository (e.g. the doap
> only contains usernames and mixes it with the foaf files, allowing
> people to change their info easily). Although I really rather use LDAP
> for this, but I can always change that after Mango allows people to
> change their details.
> 
> Oh, and I'd really like to link install-module with the doap files as
> well. E.g., you release a new tarball and a while later that release
> is added to the doap file (requires the tarball name to be the same as
> the SVN module..).
> 
> Does this sound like a good plan?
> 
> Regards,
> Olav
> _______________________________________________
> Gnome-infrastructure mailing list
> Gnome-infrastructure gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759