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? They would still be able to make changes by fixing a single file. And the contribution process would be much easier than it is with some projects. > We'd > also have to go back around to every project to educate about this > change, and address 100 different objections to the change Provided that we did the initial setup of the central DOAPs, we'd just have to say where the DOAPs are now located. > What would be cool is if Git had something equivalent to svn externals, > so that we could have the best of both worlds. Maybe some day, Git will > catch up to where svn was 10 years ago. ;-) I don't see how that would help. We already have a central register. Having Git externals would not help with maintenance, as it would still only allow project people to update the DOAP. > If, on the other hand, we are able to extract the frequently-changing > stuff (ie, releases) from this data, and reduce it just to the seldom- > changing stuff, as you suggest, this would be worth doing. It's not > clear to me how big a lift that is, though. > > 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. > > --------------------------------------------------------------------- > 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
