Hi,
in terms of getting changes for package configurations applied the current committer policy seems to have worked in the past. Most "last minute" discussions I remember were around the inclusion of special builds that didn't make it into the release train build which is a challenge that can't be solved with a different committer policy. Overall it seems that changes to packages are rare anyways so the privilege to be able to write to the repository is probably less relevant on EPP than on other projects. Particularly package testing which is an important part of maintaining a package doesn't require commit rights.
The biggest advantage I see in having a single committer per package is that it makes responsibility very clear. As David points out the maintainer can always delegate to someone else who doesn't have to be an EPP committer even though it should be someone with a track record in the Eclipse community.
For the rare package configuration change that is contributed by someone who is not a committer I would think that we can handle that through Bugzilla/Gerrit since we have a number of active people on the project.
That said, I'm not against having multiple committers per package per se but there is benefit in the current policy and from point of view it has worked reasonably well in the past.
Steffen
This probably deserves some discussion.
I do not particularly disagree with the policy of "having one maintainer
per package", but don't remember talking about it too much, before.
I think the reason at the time was that
we wanted "one voice" to say what went into a package, and "one
voice" responsible for voting go/no go for a release (or milestone,
etc).
I'm just wondering if we could, somehow,
allow more than one committer (to help share work, serve as backup) but
still only one of those be the designated "maintainer" that would
still have final say? And be the one expected to "vote" unless
explicitly delegated? I like this idea, but could also see it "getting
out of hand" if someone started to want to have 3 or 4 or 5 committers
per package ... where's the limit, if there is one?
But, I also don't think it's that much
effort for someone to "share the work" by submitting patches,
etc., and then allowing one person to apply them. Similar for testing.
There is no reason someone can not help with testing, and then "report
to" that one maintainer. If that one designated person is "too
busy" to do that ... then perhaps "transfer" of ownership
is in order?
I don't know the right answer ... I
just wanted to be sure we (as EPP committers) had a discussion about it.
Thanks,
From:
portal-noreply@xxxxxxxxxxx
(portal on behalf of )
To:
epp-dev@xxxxxxxxxxx,
Date:
07/11/2013 03:01 PM
Subject:
[epp-dev] -1
for Marvin Mueller on technology.packaging by Wayne
Beaton
Sent by:
epp-dev-bounces@xxxxxxxxxxx
Wayne Beaton voted:
-1
Frankly, I think that Markus would be fantastic in this role, so this veto
is most certainly not a reflection of his abilities.
In EPP we follow our Committer and Maintainer policy [1] which is similar
to the Orbit project. In essence we only allow one committer for each
package.
[1] http://wiki.eclipse.org/EPP/EPP_Committer_and_Maintainer_Policy
Voting summary: http://portal.eclipse.org/
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
