Sent from my iPhone
> On Sep 8, 2023, at 7:11 AM, 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) 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. Every release ever is at http://archive.apache.org/dist/ if it is not there then it’s not a release. > > 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. Regards, Dave > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org >
