[Pulp-dev] Core Commit Bit Process

Fri Jun 1 19:49:03 UTC 2018

I've put together a draft PUP6 - Commit Bit Assignment. I've tried to
incorporate the ideas from this thread. Also you'll see a clear-and-present
notion of subsystem owners.

https://github.com/pulp/pups/pull/10/files

Please send ideas, questions, revisions, etc via the list or directly on
the PR now through June 10th. I'll try to respond and call out any
significant changes back on the list. A formal vote will be called some
time after June 10th if blocking concerns haven't been expressed by then.

Thank you,
Brian

On Tue, May 22, 2018 at 3:45 PM, Robin Chan <rchan at redhat.com> wrote:

> To simplify my request and to get the ball rolling on the process,
> perhaps we can boil this down to the an existing holder of the commit
> bit can sponsor the candidate by means of initiating the email. The
> candidate and sponsor should collaborate to list
> qualifications/justifications which can be a means of providing some
> guidance on minimum requirements until we agree on them. It would also
> ensure that we have at least one +1 before starting the vote process.
> This sponsor would also be responsible for tallying votes/ensure
> quorum vote on the deadline & granting the git permissions/settings.
>
> +1 on plugins adopting same rule unless they choose to adopt their own
> +1 on cool down re-application - 60 days would be my suggestion
>
>
> On Tue, May 22, 2018 at 11:44 AM, Ina Panova <ipanova at redhat.com> wrote:
> > Brian,
> >
> >  thanks for spending time and writing down this email.
> >
> > +1 for submitting pup for for commit bit acquisition.
> >
> > W/r to commit bit relieve/loss/removal i would make a separate pup just
> > because we'd need to deal with a lot of conditions and usecases.
> >
> > * i suggest the process we'd adopt would be default one and plugins would
> > follow those by default unless they would write their own process.
> > * i suggest we list at least some kind of criteria like X time involved
> in
> > project development, has demonstrated to provide good form and useful
> code
> > reviews, has submitted code that was accepted into main parts of the
> > project.
> > Project in this case i am referring the repository(
> > pulp/<core><devel><plugin> ) which is part of organization (Pulp)
> > * the candidate would whether apply himself for commit bit or an existing
> > core member would nominate the candidate through the email list, for
> example
> > pulp-dev
> > * voting willbe open and public via email, with majority of core-devs
> voted
> > and no -1. Some time limit on voting would be set as well.
> > * chance of re-applying for commit bit with some cooldown
> >
> >
> >
> > --------
> > Regards,
> >
> > Ina Panova
> > Software Engineer| Pulp| Red Hat Inc.
> >
> > "Do not go where the path may lead,
> >  go instead where there is no path and leave a trail."
> >
> > On Tue, May 22, 2018 at 3:27 PM, Robin Chan <rchan at redhat.com> wrote:
> >>
> >> We should also have a process to remove a commit bit from a contributor.
> >>
> >> I believe it would be helpful to come up with an initial proposal for
> >> granting the commit bit, then a proposal for removing, and then going
> >> to a vote for the grant or both. I don't want to confuse the subject,
> >> so I'll stay on the subject of granting.
> >>
> >> Any proposal on terminology for terms would be helpful so we can
> >> communicate clearly.
> >>
> >> Process
> >> - I think the contributor should request the commit bit via an email
> >> call for vote on the pulp-dev list. Reason here is that this is a lot
> >> of responsibility and they have to be willing to accept that
> >> responsibility.
> >>
> >> Criteria
> >> I am fine with the lack of hard requirements for getting the commit
> >> bit. I wonder if it would be helpful to add some minimal requirements
> >> such as length of time of involvement or # of PRs reviewed/merged to
> >> be considered or ask for a vote? Or perhaps this that guidance it
> >> listed more as expectations for responsibilities held as a commit bit
> >> holder. The gist here would be that you let the requestor know what
> >> would be expected of them and some guidance on what what our
> >> expectations are vs. other projects.
> >>
> >>
> >> On Tue, May 22, 2018 at 4:34 AM, Milan Kovacik <mkovacik at redhat.com>
> >> wrote:
> >> > Brian,
> >> >
> >> > thanks for the proposal!
> >> > I agree with the proposed process to gain the commit bit because of it
> >> > being based on the trust folks have to each other and the project and
> >> > because of its positive feedback loop effect on the trust building,
> >> > this process I believe will bring.
> >> > I'd like to suggest we adopt a process to relieve a commit bit too.
> >> >
> >> > Thanks,
> >> > milan
> >> >
> >> >
> >> > On Mon, May 21, 2018 at 11:48 PM, Brian Bouterse <bbouters at redhat.com
> >
> >> > wrote:
> >> >> For core and it's related tools, we don't have a written process to
> >> >> describe
> >> >> giving the commit bit to a contributor. We've been wanting to agree
> on
> >> >> and
> >> >> document that process for a while, so I'm facilitating thread
> gathering
> >> >> ideas to inform the writing of a PUP.
> >> >>
> >> >> This starter email gives a brief history of what we've done and
> >> >> outlines a
> >> >> simple proposal to get us started. We can throw that proposal away in
> >> >> favor
> >> >> of any other idea.
> >> >>
> >> >> # History
> >> >>
> >> >> Historically if you were hired onto the Pulp team at Red Hat you
> >> >> received
> >> >> the commit bit day 0. In Oct 2017 we decided to stop doing that and
> >> >> instead
> >> >> document an open process. Engineers hired on the pulp time since Oct
> >> >> '17
> >> >> have not received commit bit. We have not yet documented an open
> >> >> process of
> >> >> which to give it to them or any other proven contributor.
> >> >>
> >> >> # Current State
> >> >>
> >> >> The current core devs as shown on github are: asmacdo, bizhang,
> >> >> bmbouter,
> >> >> daviddavis, dkliban, dalley, ipanova, jortel, pcreech, ttereshc
> >> >>
> >> >> # Scope of this discussion
> >> >>
> >> >> pulp/pulp, pulp/devel, and any repos for the Pulp3 Ansible installer.
> >> >> It
> >> >> applies to both Pulp2 and Pulp3. Plugins will do what they want.
> >> >>
> >> >> # Process Idea
> >> >>
> >> >> One process idea is to add a new core committer upon a vote with +1's
> >> >> received from all current core developers. The thinking is that all
> >> >> current
> >> >> core devs needs to be 100% comfortable for the new person to handle
> any
> >> >> issue in place of themselves.
> >> >>
> >> >> # Criteria
> >> >>
> >> >> Overall I believe someone who has demonstrated commitment and care
> >> >> towards
> >> >> the needs of all Pulp users and not only their own interests. Also
> they
> >> >> must
> >> >> have the experience to be trusted with major aspects of Pulp
> >> >> functionality.
> >> >>
> >> >> These requirements are somewhat vague by design. Any process with
> hard
> >> >> requirements will be gamed so I believe leaving it to the judgement
> of
> >> >> the
> >> >> existing devs is a safe approach. Anyone who specifically wants to
> get
> >> >> more
> >> >> involved should approach the core devs about mentorship. I think the
> >> >> right
> >> >> time will be obvious, and if there are doubts those can be expressed
> >> >> ahead
> >> >> of time or at vote time.
> >> >>
> >> >> # Code owners
> >> >>
> >> >> This commit bit vote could be for entire core repos, or it could be
> for
> >> >> a
> >> >> subsystem of Pulp enforced using github's "code owners" feature
> >> >> (https://blog.github.com/2017-07-06-introducing-code-owners/).
> >> >>
> >> >>
> >> >> ^ is starter content, please send ideas and discussion that will be
> >> >> incorporated into a first draft PEP at some point.
> >> >>
> >> >> -Brian
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Pulp-dev mailing list
> >> >> Pulp-dev at redhat.com
> >> >> https://www.redhat.com/mailman/listinfo/pulp-dev
> >> >>
> >> >
> >> > _______________________________________________
> >> > Pulp-dev mailing list
> >> > Pulp-dev at redhat.com
> >> > https://www.redhat.com/mailman/listinfo/pulp-dev
> >>
> >> _______________________________________________
> >> Pulp-dev mailing list
> >> Pulp-dev at redhat.com
> >> https://www.redhat.com/mailman/listinfo/pulp-dev
> >
> >
> >
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
> >
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180601/f6ca4261/attachment.htm>