>> What does this entail? Do I constantly have to monitor upstream? Do I, >> personally, get all the maintainer duties? And everyone else in the >> team as well? > >No. The package is a shared responsibility, which is my perception of >the point of doing team-maintained package in the first place. If you >don't want shared responsibility, then why team-maintain something? > >> That won't work. I don't want all maintainer duties for all the >> thousands of packages under the Python team, and if "everyone" is in >> charge, then noone is in charge. Instead, if noone cares enough to put >> on the "in charge" hat, the package should be dropped from the team. > >Huh? What's the point of having team-maintained packages at all with >that perspective? Maybe it helps to think about this differently, and >consider that it is possible to not have a single-maintainer strong >ownership model of package maintainance.
I think you are confusing ownership with responsibility. "Ownership" would mean that I don't want others to touch my package. That does, as you said, not make sense in team maintenance. "Responsibility", or "being in charge", means that someone pledged to take on maintainer responsibilities, like keeping the package updated regularly, ensuring it transitions to testing, etc. – i.e., regular tasks that do not arise from external communication. In other words: * a bug is opened -> anyone in the team should act * security team contacts team -> anyone should act * upstream contacts team -> anyone should act All these are reasons for team maintenance. But on top of that, there are *regular* tasks maintainers should do, like checking for new upstream versions, or in general, keeping an eye on the DDPO for anything that does not open a bug or trigger communication on its own. And *that's* where I see the relevance of the maintainer field. -nik
