from mobile (sorry for typos ;)
On Fri, Sep 8, 2023, 21: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. We'd > also have to go back around to every project to educate about this > change, and address 100 different objections to the change > > 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. ;-) > > If, on the other hand, we are able to extract the frequently-changing > stuff (ie, releases) Full information about releases already available at reporter.a.o :) 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. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
