[Pulp-dev] Core Commit Bit Process

Fri Jun 1 20:04:11 UTC 2018

Thank you Brian! I like the brevity. It covers everything I can think of at
the moment.

On Fri, Jun 1, 2018 at 3:49 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/719d09fb/attachment.htm>