Simplify the <developers> section#490
Conversation
Replace the fixed list of named PMC members with two role-based team entries: the PMC (`dev@logging.apache.org`) for development matters and the Security Team (`security@logging.apache.org`) as the security contact. Both carry the ASF organization, a team/security page URL, and a free-form role. A hand-maintained roster is always incomplete, its contact details go stale in immutable releases, and naming individuals implies a support obligation they have not signed up for. Git history and the project team page already track contributors accurately. The section cannot be dropped entirely: Maven Central requires at least one developer with a name and email. The two meta-entries satisfy that while pointing at durable, monitored channels. `<developers>` is inherited by child projects, so a comment documents that these entries should not be overridden downstream. Assisted-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
-1 don't change my entry. |
|
Hi @garydgregory,
Fixed in 6fa6bf4. May I ask why you wish to keep your entry? @FreeAndNil: are you sure you don't want to add your entry for you contributions? |
|
@ppkarwasz I am sure. |
|
There is no need shuffle this around IMO, this feels like some kind of solution in search of a problem, change for the sake of change, for what feels like some overbearing administrative system. We are people writing code after all, that's what should be reflected, not committees. My recollection of the general history is that developers (committers, PMC members) are in the Enough wasting time writing about this... |
What
Replace the fixed list of five named PMC members in
<developers>with two stable, role-based team entries:dev@logging.apache.org) for general development matterssecurity@logging.apache.org) as the security contactBoth carry the ASF
<organization>, a team/security page URL, and a free-form<role>.Why
The previous list had the problems any hand-maintained contributor roster has:
projects.apache.org) already track this accurately and automatically.The
<developers>section is not free to delete, though: Maven Central requires at least one developer with anameandemail(see the Central requirements). The two meta-entries satisfy that requirement while pointing at durable, monitored channels instead of individuals.Who actually consumes this data?
Very little tooling reads
<developers>programmatically, which is itself an argument against maintaining a detailed list. The consumers that do matter are served better by this change:maven-project-info-reports-plugingeneratesteam-list.htmlfrom this section, but we do not use Maven Site Plugin.<developers>to SBOM authors and<organization>to manufacturer/supplier, so adding<organization>improves provenance metadata.Inheritance / downstream impact
<developers>is inherited by child projects. These entries therefore apply to the whole Apache Logging Services family, and child POMs should not override them. A comment in the POM documents this intent.