Simplify the <developers> section

[ppkarwasz]

What

Replace the fixed list of five named PMC members in <developers> with two stable, role-based team entries:

• Apache Logging Services PMC (dev@logging.apache.org) for general development matters
• Apache Logging Services 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>.

Why

The previous list had the problems any hand-maintained contributor roster has:

• It is always incomplete. A fixed list inevitably omits contributors, and the choice of who appears is arbitrary. Git history (and, for the ASF, the project team page and projects.apache.org) already track this accurately and automatically.
• Contact details go stale. People change employers, time zones, and email addresses, and eventually stop working on the project. A POM published inside a release is immutable, so any individual detail is a future inaccuracy.
• Listing individuals implies a support obligation. People named in the POM are not necessarily willing or able to answer questions about the project. Stable team aliases route questions to whoever is currently active.

The <developers> section is not free to delete, though: Maven Central requires at least one developer with a name and email (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 Central publishing validation requires the section to be non-empty. Satisfied.
• maven-project-info-reports-plugin generates team-list.html from this section, but we do not use Maven Site Plugin.
• SBOM tooling (CycloneDX / SPDX) maps <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.

[FreeAndNil]

LGTM

[garydgregory]

-1 don't change my entry.

[ppkarwasz]

Hi @garydgregory,

-1 don't change my entry.

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?

[FreeAndNil]

@ppkarwasz I am sure.
It's enough to see my name on the team list.

[garydgregory]

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 developers section and that the contributors section was used for non-committers and non-PMC members, for folks that submit patches in Jira, or any other types of contributions. Then changes.xml came along and we started using that, and then, later, we had to invent our own custom changes system that no other project uses, and I have to remind myself how to use.

Enough wasting time writing about this...

[vy]

Pushed 6a38141 implementing:

• Shortened the story. Interested can check out the PR.
• Removed individuals.

[vy]

By pointing individuals in the project sources we're dismissing hundreds of people who has contributed. I completely support sharing the community communication channels in these fields.

[ppkarwasz]

@garydgregory,

Given the reasoning @vy and @FreeAndNil laid out, does that change your -1, or do you want to be mentioned in a third entry alongside the PMC and Security Team ones, i.e.:

• Apache Logging Services PMC
• Apache Logging Services Security Team
• you, individually

I have no problem keeping your entry, but since you're already covered by both the PMC and Security Team entries, having a third one just for you would look a bit inconsistent with the rest of the change.

[garydgregory]

Nothing's changed in my view but commit e9652cc makes me revert my -1. It's still a BAD idea IMO but I can't stop people from having them ;)

[FreeAndNil]

LGTM