Bug 201035
| Summary: | Accept more than one maintainer for ports (and issues in bugzilla) | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | sasamotikomi |
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> |
| Status: | Closed Not Accepted | ||
| Severity: | Affects Many People | CC: | erwin, koobs, portmaster, ports-bugs |
| Priority: | --- | Keywords: | feature |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
sasamotikomi
2015-06-22 05:27:59 UTC
This is a feature request, and will require some initial and further thought and discussion about: * how it could/should be implemented * what the benefits and risks might be * potential impact on consumers (users and systems) that utilize MAINTAINER in its current form. This is definitely within the remit of the Ports Management team, thus will be re-classified/assigned accordingly. I would strongly recommend/suggest you create (along with feedback from others) a detailed proposal summary in Gist or Wiki page format, that goes over the details. A format similar to a Python Enhancement Proposal (PEP) would be a good starting point. The maintainer is the primary caretaker of a port, not the exclusive owner. That being said... What problem are you trying to solve ? I can think of a few cases I might like to declare/codify: - Shared maintainership (primary, secondary) - Primary individual + Secondary group/team (Eg: + Anyone on python@) - Primary maintainer, plus some MAINTAINER_POLICY= (values TBD, eg: "open") so that timeout or my feedback isn't required - Multiple maintainers for large/complex ports that don't warrant, need group/team aliases, etc I'm sure there are others. I think this is a bad case of over-engineering. To support declaring the notion of multiple people (many, ideally) maintaining a port/package is over-engineering? The previous comment is talking only about goals, not implementations. We talk about improving productivity of ports/packages, updates, testing, etc, and I will grant that these things are all possible whilst having a single maintainer. I also think think everyone would agree there is something very satisfying about 'being' a maintainer that is conducive to contributing in more tangible ways. It is this that is the essence of positive 'ownership' that isn't the negative kind (territoriality) that some people get stuck on. This shared notion of maintainership shouldn't be limited to one person. And again, the claim is *not* that MAINTAINER is an exclusive lock/owner, is it that there is merit to being able to describe more than just a single maintainer, for various reasons. Honestly, my first impression was; WHAT?! you've got to be kidding. So I resisted the temptation to "react". :) After having given some "objective" thought... In my personal opinion, this adds additional complexity which is ultimately counter-productive to the current ports system. That said. I *do* appreciate the OP's objective, and I think the simplest solution would be for a "team" to adopt a pseudo name, and setup a mail address "my-port-team@some-mail-exchanger". Where each of the members could gain access to the mailings, and they could subscribe their pseudo name to the relevant mailing list(s). Then there wouldn't be a "single point of failure", as the OP seems to suggest the primary problem lies. This would also give them the opportunity to communicate with each other, as a group. Just my humble thoughts on the matter. All the best. --Chris I'm going to go ahead and take the big hammer and close this. This comes up every year or so, and while it may add some more flexibility in some cases, most of them can be solves with a single maintainer address listed in the port as well. Flexibility comes at a cost of having to maintain the flexibility. Designing and implementing a working solution, that takes care of all corner cases, will be a major task that does not add enough benefit compared to the work that needs to be done. Also remember, that a lot of downstream code (freshports, portsmon, etc.) assume there to be only one maintainer, and these projects also need to be adjusted. If you can present a more concrete use-case that cannot be done with a single maintainer, and a implementation and migration plan, including downstream projects, we may reconsider. But for now, I'd say we have biggest fish to catch. |
