Does it make sense for DOAPs to contain releases? These can get out of date very quickly, and will be very large for some projects,
It seems to me that DOAPs should be used for information about projects that is not sourced elsewhere. Thus would mostly eliminate maintenance. On Fri, 30 Oct 2026 at 06:36, Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Rich, > > Thanks for driving this "modernization" :) > Moving away from scraping DOAP files and centralizing around the > release catalog/ATR makes a lot of sense and should reduce friction > for PMCs. > > I have a couple of thoughts/questions: > > - Removing retired and Attiic projects might break external references > or historical visibility. Keeping a distinct "Retired / Attic" filter > or section (or at least preserving redirection to Attic) could be > valuable for provenance and historical record. > - For projects that actively updated their DOAP files recently (I know > DOAP file update in some projects release guide, like Polaris), do we > have an easy way or script to diff the current live DOAP against what > ATR holds before the cutover, just to spot obvious regression? > > Otherwise having a clean rollback target (revision) makes testing this easier. > > Thanks! > > Regards > JB > > On Thu, Oct 29, 2026 at 9:32 PM Rich Bowen <[email protected]> wrote: > > > > Hi all, > > > > Following some conversation with Dave on Slack, which reset a few of my > > understandings and expectations about where project data should come > > from, I'm planning to switch projects.apache.org over to the ASF release > > catalog (https://release-catalog.apache.org/project_releases.json), which > > Tooling (Dave) tells me is the authoritative source. Project and release > > data > > would come from there instead of from DOAP files and scraping dist. > > > > What changes in scripts/cronjobs: > > > > - New: parsecatalog.py builds projects.json, projects/<id>.json and > > releases.json from the catalog, plus active/retired status from the > > ATR project list. > > - parseprojects.py becomes a thin wrapper that runs parsecatalog.py and > > then buildchooser.py. > > - parsereleases.py becomes a no-op. > > > > I've done it that way so the existing crontab keeps working without a > > P6 change. > > > > On the site: > > > > - Each project page links to its metadata in ATR, where committers can > > edit it. > > - Retired and Attic projects are no longer listed. > > - Old project URLs redirect to the new IDs. > > - The About page is rewritten. > > - The DOAP validation report is retired. > > > > I'll be testing some more this evening, and committing in the morning if > > nothing breaks. Yell if you have strong objections. > > > > The big advantage here is that projects can edit metadata directly in ATR, > > without mucking about with icky DOAP files ever again. The possible > > disadvantage is if they edited DOAP files since ATR loaded starter data > > from existing DOAP files, there may be a few things out of sync, but that > > should be very quick to rectify now. > > > > The current revision is r1939678, so it's easy to roll back if needed. > > > > Rich > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
