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 switch) - the new DOAP listings location, that is like projects old, but simplified since only focused on DOAP listings and content (no code): http://svn.apache.org/viewvc/comdev/projects.apache.org/data/ 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 https://projects.apache.org/doap/ to https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/ 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. Regards, Hervé [1] https://projects-old.apache.org/guidelines.html see 2 last bullets: - PMCs can be referenced as an rdf:resource that points at http://<pmc>.apache.org/. e.g. <asfext:pmc rdf:resource="http://httpd.apache.org/"; />. In this case, the PMC descriptor file must be called <pmc>.rdf and must be stored in the directory: http://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files/ - 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 example <asfext:pmc rdf:resource="http://tlp.apache.org/pmc/tlp.rdf"; /> Le dimanche 19 juillet 2015 09:48:17 sebb a écrit : > On 15 July 2015 at 22:11, <hbout...@apache.org> wrote: > > Author: hboutemy > > Date: Wed Jul 15 21:11:32 2015 > > New Revision: 1691273 > > > > URL: http://svn.apache.org/r1691273 > > Log: > > import projects DOAP files updates > > > > Modified: > > comdev/projects.apache.org/site/doap/cxf/cxf.rdf > > comdev/projects.apache.org/site/doap/httpd/httpd.rdf > > comdev/projects.apache.org/site/json/foundation/projects.json > > comdev/projects.apache.org/site/json/projects/cxf.json > > comdev/projects.apache.org/site/json/projects/httpd.json > > 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.
