metadata for project releases is discoverable from the dist in svn. It is already done for podlings in the Incubator in the clutch analysis.
It is python. I can provide some help late next week. Sent from my iPhone > On Mar 27, 2020, at 1:20 PM, sebb <seb...@gmail.com> wrote: > > On Fri, 27 Mar 2020 at 20:01, Hervé BOUTEMY <herve.bout...@free.fr> wrote: >> >> Le vendredi 27 mars 2020 20:29:14 CET, vous avez écrit : >>>> On 3/27/20 3:07 PM, Hervé BOUTEMY wrote: >>>>> It's good to see some interest back on DOAP files content ad organisation, >>>>> now that the projects.apache.org rendering makes them really useful: a >>>>> few years ago, trying to open any discussion on that was deemed to >>>>> failure. But any change is hard, since every PMC will have to be >>>>> involved. >>> >>> What if we - and I'm perfectly prepared to be told "You can't do that >>> because ..." - fetched remote (ie, project-hosted) doap files, a few at >>> a time, and move them to the central repo, and as we do that, we go talk >>> to projects individually, telling them that we're doing it, and why, and >>> what the new process is for updating. Yes, I'm volunteering to do that >>> outreach. >> you can, but I don't see the benefit of this hard work >> >>> >>> That way, over time, we'd eventually have all of those files in one >>> place, making them easier to find and update. >> find = 2 files (1 for committees, 1 for projects) > > May be more than one for projects. > e.g. Commons. > >>> >>> I'm leaving the file format question for someone else entirely. I am far >>> less concerned about that, than about ensuring that the files are easily >>> found and updated. >> my point about "PMC RDF files" vs "projects DOAP files" is not a question of >> format, but a question of amount of data and who would have real knowledge >> to update content: >> - PMC RDF files are very light, rarely updated, and contain data that are >> really foundation-centric >> - projects DOAP files contain a lot more data, can/should be often updated, >> with data that are really to be delegated to PMCs given they are more >> technical details on code >> >> That's why I really think keeping centralised PMC RDF files and >> decentralised projects DOAP files is a good idea. >> >> IMHO, centralising project DOAP files would be a hard task with low benefit, >> and even counter productive effect on having every PMC responsible for the >> content, that is technical. >> >> On letting PMC RDF files go outside the centralised approach, I'd be curious >> to check if the 4 PMCs that chose to host outside of projects.a.o did that >> to fill more data, or if they just felt that they'd host this file the same >> way they did with project DOAP file. > > I suggest dropping them entirely. > >> Regards, >> >> Hervé >> >>> >>> --Rich >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
