On Wed, Apr 18, 2018 at 7:03 PM Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> Le jeudi 19 avril 2018, 00:05:01 CEST Christopher a écrit : > [...] > > > > Yeah. That's great, but as I pointed out, it's useless to do so if > they > > > > aren't utilized for any other purpose. > > > > > > As I keep saying, the DOAPs *ARE* used to build the p.a.o pages. > > > > Okay, okay. Sorry, Sebb. You're right. It does seem to still be in use > for > > building some portions of p.a.o. I just didn't see any evidence of that, > > and could not find any documentation on *how* it is used to build them. > perhaps I should just add that PMC RDF data files are used to build > Committees > pages: https://projects.apache.org/committees.html (Committee is a > synonym > here for PMC) > and projects DOAP files are used to build Projects pages: > https://projects.apache.org/projects.html > > Who maintains the "PMC RDF data files" which are "used to build Committees pages", and where are those stored? > it's not so obvious since the difference between Committe and Project is > not > so obvious > > I'm happy to have some feedback on the documentation written, that I'm not > sure many people read: I'll be happy to improve it given on the feedback > > > > > You are right. I was mistaken. I had not spent enough time on the site to > > understand how it is used, and it was not obvious to me that any > > functionality was missing when the DOAP file was missing. Sorry for the > > misunderstanding on my part. > > > > After some more time spent on the site, I was able to see some portions > > which don't work if the DOAP is missing. Specifically, I can now see that > > it is used for grouping projects by language, by category, and listing > > releases (which is the information I was asking for, and which would be > > useful to add to [2], along with any other way it is used that I did not > > observe.) > > > > I do think it is preferred that p.a.o get release information from > > reporter.a.o instead... it would make maintaining DOAP simpler, and > reduce > > the burden on developers to maintain a duplicate dataset. > I confess that Branko's remark about "Semantic Web aficionados appear to > have > vanished into the space between microservices" seems relevant... > the idea behind using some universal format, and not just Apache internal > tooling, was appealing: everything that is done magically by internal > tooling > has drawbacks. > But for sure, the release part is the most hard to manually maintain part. > > The problem with this universal format is the pain to maintain. If "(whimsy|reporter|projects)[.]apache[.]org", or another tool provided a good UI to generate the universal format... I don't think maintenance would be an issue. Over the last few years, I keep encountering what I think is probably some sort of universal truth: the problems with nearly any process or workflow is lack of adequate tooling. > > Thank you for your persistence in educating me. I did eventually get > there. > > Sorry if my confusion and ignorance caused any unnecessary strife. :) > It's good to have feedback and interest, even if the interest contains > criticism: it's constructive feedback > > Indeed. Which is why I only apologize for the strife which is "unnecessary". :) > Regards, > > Hervé > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
