On Fri, 2023-09-08 at 15:30 +0100, sebb wrote: > On Fri, 8 Sept 2023 at 15:10, <rbo...@rcbowen.com> wrote: > > > > On Thu, 2023-09-07 at 23:26 +0100, sebb wrote: > > > I think it would be worth considering setting up a central store > > > for > > > DOAPs. > > > This was suggested in the past, but was rejected, I think mainly > > > because PMCs were expecting to have to make regular updates to > > > DOAPs, > > > e.g. when releases are made, so wanted to keep them with the > > > code. > > > > > > It's a pain keeping the releases section of DOAPs up to date > > > (even if > > > they are local to code). > > > Now that there is an automated releases listing, I wonder whether > > > there is any point keeping the info in the DOAP as well? > > > > > > The rest of the fields in a DOAP rarely change, so it matters > > > less if > > > the DOAP is stored in a different repo from the code to which it > > > relates. > > > > > > If DOAPs were moved to a shared GitHub repo, I think it would be > > > much > > > easier for maintenance purposes. Some issues such as fixing an > > > incorrect repo URL or download page link could be dealt with by > > > anyone > > > with suitable karma. > > > > > > Just a thought. > > > > I'm a little torn on this one. It would certainly make it a lot > > easier > > for *me*, but at the expense of making it harder for the projects. > > How so?
Just in that they'd have to go somewhere else to maintain this one piece of data, separate from the rest of their project. I agree it's not a *big* inconvenience. And also, most projects would do it once, and then never again. I may be persuaded. :) > > I would certainly like to have the ability to address some of the > > awful > > phrasing, grammar, and just bad project descriptions, without > > having to > > navigate every project's different contribution process. > > And without needing to involve the project unnecessarily. Yeah, I think I'm persuaded. Particularly if we drop the 'releases' section of projects.a.o and simply point to the projects' download pages rather than trying to duplicate data that's already maintained elsewhere. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
