community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: Unnecessary SVN commits [was: svn commit: r1691273 - in /comdev/ doap/cxf/cxf.rdf doap/httpd/httpd.rdf json/foundation/projects.json json/projects/cxf.json json/projects/httpd.json]
Date Sun, 19 Jul 2015 13:18:39 GMT
time to explain what I have in mind, because I understand the reactions about 
these svn content questions: but I need to explain why I think that it's not a 
bug, it's a feature :)

1. generated json files in svn

even if they are generated, these ones are IMHO useful to ease people just 
wanting to work on information rendering, ie the site's html+javascript
Experience with releases.json not being in svn in the first place told me that 
not having whole json content in svn was just increasing barrier to commits 
from whole ASF committers to projects directory visualization

2. doap files in svn (copies of parsed content or generated ones)

>From the beginning of my work on projects-new, I had a question in mind: is 
DOAP itself a problem (since not easy, not well understood), or are there just 
problems about the way DOAP is used and explained to ASF committers (= not 
DOAP experts, if DOAP experts exist)?

Any discussion on this list about that question lead to some people wanting to 
simply drop DOAP, because for them, implicitely, the format itself/only was 
the problem, without answering previous question (and without providing a 
better alternative = the show stopper for me: no, simply telling "json" is not 
a sufficient answer, there has at least to be a schema)

Then my first steps were:
- improve projects new site and switch from projects old, as each project page 
on projects-new more clearly shows information that comes from the project's 
DOAP file (IMHO, projects old was failing at this, no pun intended): we'll see 
if ASF committers can improve their DOAP files (as some already did since the 
- the new DOAP listings location, that is like projects old, but simplified 
since only focused on DOAP listings and content (no code):

These are only the first steps IMHO before deciding if we should continue with 
DOAP or find a better alternative (yet to be found/proposed).

I see 2 other steps:
- clarify what committee DOAP files (also called "PMC descriptors") are 
supposed to contain, and how projects (maintained by the committees) are 
supposed to link to the committee. As discussed previously, current convention 
[1] is really strange. And PMC members list are easier updated automatically 
from committee-info.txt than manually.

- prefer to
IMHO, /doap/ in projects site, with every ASF committer commit access, and its 
per-committee directory containing both PMC descriptor and projects DOAP 
descriptors would be easier to understand and maintain than an XML listing in 
svn then descriptors in a lot of different places
And this would give a good canonical url for each DOAP file (easing work on 
previous item)

I know this is a long post: sorry, could not make it shorter.

Switching from projects old to projects new without changing much things to 
DOAP sources was only the beginning of a story: we need to define next steps.



[1] see 2 last bullets:
- PMCs can be referenced as an rdf:resource that points at 
http://<pmc> e.g. 
<asfext:pmc rdf:resource="" />. 
In this case, the PMC descriptor file must be called <pmc>.rdf and must be 
stored in the directory:
- PMCs descriptors can also be stored anywhere else (e.g. on the TLP website 
or in SVN), in which case they must be referenced using the full URL, for 
<asfext:pmc rdf:resource="" />

Le dimanche 19 juillet 2015 09:48:17 sebb a écrit :
> On 15 July 2015 at 22:11,  <> wrote:
> > Author: hboutemy
> > Date: Wed Jul 15 21:11:32 2015
> > New Revision: 1691273
> > 
> > URL:
> > Log:
> > import projects DOAP files updates
> > 
> > Modified:
> >     comdev/
> >     comdev/
> >     comdev/
> >     comdev/
> >     comdev/
> Why are these copies being committed to SVN?
> Projects-old makes do with a local copy of the files which it keeps in
> sync with the ones listed in files.xml
> It seems wasteful and unnecessary to create new backup copies in SVN.
> AFAICT they are bound to be out of date as they are committed manually.
> Furthermore there is also a  danger that the wrong copy may be updated
> by someone.

View raw message