[Pulp-dev] commit-bit nomination

Mon Sep 10 14:45:17 UTC 2018

+1, I agree that Milan has met the criteria. I think we should go forward
with giving him the bit and larger discussions about decision making can
happen separately.

On Mon, Sep 10, 2018 at 9:03 AM Ina Panova <ipanova at redhat.com> wrote:

> Brian,
>
> it feels like your reply is in contradiction of what we are trying to
> achieve as a community project:
>
> 1) I am concerned that this reply can be perceived very badly by the
> community, especially once we approved the pup and announced this in hope
> of community embracing this change, by encouraging new contributions and
> motivating them with one of the retributions of becoming a committer.
> 2) We cannot afford ourselves to behave like a dental clinic which will
> say: we are too full and we are not accepting new patients ATM. There are
> community projects with a larger committer base and somehow they still
> manage to develop and evolve.
> 3) Do you suggest splitting the team in 2 with the acknowledgement of the
> fact that pulp2 is near EOF which means those people will be pinned just
> for the maintenance mode? I wonder if we have such volunteers doing this
> job daily. Anyone? :)
>
> I agree with Dana, we adopted the pup, team has voted, now we need to deal
> with the decisions we as a project have made.
>
> I think Milan has met the criteria listed in the pup, and if he has
> systematically demonstrated diligence and commitment i do not really think
> once he gets the commit bit he will go right away and screw up pulp3 code
> base because he has less experience in that area than in another.
>
> I understand that in this email thread have popped up multiple problems we
> are struggling with, but I would at least try to stay focused on the
> initial email topic and create separate discussions for the other topics.
>
> +1 on the voting.
>
> I also solicit the team to be pro-active, so we can fail fast things which
> do not work out for us.
>
>
>
>
> --------
> 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 Fri, Sep 7, 2018 at 2:17 AM, Dana Walker <dawalker at redhat.com> wrote:
>
>> I respectfully disagree.
>>
>> I was hoping for more discussion before the calling of a vote.
>>>
>>
>> The process described in PUP6 specifically states that the nominating
>> email should have a vote end date, thus calling a vote.  There's nothing
>> wrong with having discussion now on this thread, as part of explaining your
>> stance or asking questions before deciding, but voting is still actively
>> taking place.  People can always change their vote based on the results of
>> discussion up to the vote end date in seven calendar days.
>>
>> With Pulp2 nearing maintenance mode, the core and plugin teams need to
>>> assess what their needs are both in code and people. I feel that with 9
>>> people on the core team, maintaining vision is hard/impossible, and the
>>> mailing list discussions have demonstrated that.
>>>
>>
>> No, what the mailing list discussions have demonstrated is that we have a
>> problem with our decision making process.  Plenty of projects have larger
>> teams, but they usually have a team lead for breaking ties and ensuring
>> that forward progress is made even with difficult decisions where a team is
>> split on what to do.  The bright side is, no matter what decisions are made
>> on any of those discussions, the project moves forward, and can always
>> pivot in future versions based on feedback or with community submitted open
>> source work.  But decisions must be made and if our lazy consensus method
>> where even a single -1 is blocking prevents work from moving forward and
>> releases from arriving on schedule, it's time we reconsider that process,
>> and that is a separate discussion for another place and time.
>>
>> Also consider that Pulp3 is an order of magnitude smaller codebase
>>> (literally) so keeping the same number of committers seems too many.
>>>
>>
>> Again, I disagree with this focus on number of committers for many
>> reasons.
>>
>> 1) @bizhang just left the team and resigned a commit bit, so there is now
>> an opening and if there had been a problem with the number of commit bits
>> before today, then that should have been brought up previously, perhaps by
>> having no grandfathered-in committers and all team members voted on by
>> majority when this decision was made last fall, or perhaps by explicitly
>> limiting the number of commit bits in the PUP.
>>
>> 2) We just had lengthy discussions in meetings a week ago about ways to
>> improve the speed with which we respond to PRs.  There were suggestions
>> ranging from email notifications of every one that is submitted, a weekly
>> PR triage, having subject matter "experts" designated to divide up the
>> work, or it being on the shoulders of the pull requesters to continually
>> poke channels/individuals for a response until they get one.  The response
>> to all of this was simply that we are all too busy.  Too busy implies that
>> there is more than enough work to go around for more people, and the only
>> people who can approve and merge PRs are those with the commit bit, ergo we
>> need more commit bits out there.
>>
>> 3) We want to grow.  I have heard over and over again how much we want to
>> grow this project, that we want more community contributors.  We shouldn't
>> be measuring by how many lines of code exist now on a growing project when
>> we're having to delay various plugins and features because we just don't
>> have time right now.  With more people joining the work, we need more
>> commit bits to review and approve that work or we rapidly hit a bottleneck
>> where someone codes, hears nothing back for months of delay, and loses
>> interest or moves on to other projects.
>>
>> 4) Most importantly to me, I am alarmed at the apparent gatekeeping right
>> off the bat.  I noted my misgivings regarding the stated drawbacks to the
>> PUP during voting for PUP6, and having seen the quality of work for months
>> had fully expected this particular nominee to gain commit bit as soon as
>> the process was finalized, but maybe my expectations were out of line.  So
>> let's take a step back and look at the purpose of limiting the commit bit.
>>
>> (Apologies to those reading, this email got long, but I think this is all
>> relevant and important to the discussion at hand, being the first
>> nomination on a new process.)
>>
>> ----
>>
>>
>> --What are the risks associated with giving someone a commit bit?
>>
>> They are:
>> A) Malicious intent.  Someone could now delete the codebase, or include
>> malware secretly into the work.
>> B) Accidents due to inexperience.  Someone not used to this set of
>> commands, working in a shared repository could accidentally force push and
>> overwrite the upstream repository instead of just their local one, etc.
>> This mistake can and has happened even with experienced developers, so it
>> is always a risk but is more pronounced with someone new and/or
>> inexperienced with the way of doing things on a specific project.
>> C) Breaking the codebase, especially production, with buggy code.  This
>> can and does still happen even with experienced developers.
>>
>>
>> --How can these risks be mitigated?
>>
>> Well, as far as A, malicious intent and accountability, you generally
>> trust your vetting process when you hire someone.  At my previous job,
>> everyone was given the commit bit, even interns, with appropriate
>> onboarding and guidance from mentors.  Pulp historically assumed this trust
>> with Red Hat employees, but being an open source project, we sought a
>> fairer process to encourage the community to be a larger part of Pulp and
>> to be as transparent as we can.  So let's focus on the open source aspect
>> of dealing with these risks.
>>
>> A & C can be reduced through good review practices.  Every PR should be
>> reviewed, ideally by more than one person if it's a sizeable change.  We
>> already require review/approval before code can be merged.
>>
>> C especially can be helped by working on a non-production codebase first
>> and allowing time for testing and review from QE before it goes live.
>> Having good tests is also a great goal for any project.
>>
>> A & B can be reduced through the passage of time.  Having community
>> members who are active and in it for the long haul, who have demonstrated
>> good practices and gained experience such that you feel they are less
>> likely to make the mistakes of B or to be the malicious actor of A.
>>
>>
>> --What does this mean for the commit bit process?
>>
>> What we can't mitigate in other ways and really are trying to control is
>> time and commitment.  We want to see people who care about the project more
>> than just today for one contribution, who are comfortable with the process,
>> and would add to the positive collaboration going on.  This is outlined in
>> our PUP, and one of the reasons we left this subjective was so that folks
>> wouldn't try to game a system if it was automated based on numbers.   For
>> some people, this process may take one month, for others one year, but
>> anyone who meets these qualifications should be given the commit bit so
>> that we can continue to grow.
>>
>> However, this subjective assessment shouldn't be a really high bar.
>> We're not seeking epic level contributions, we're not here to limit this
>> project to only principle devs.  Even someone starting out may start with
>> an open source project, and as they contribute more and more, with filing
>> bugs, submitting pull requests, engaging in discussions, and providing
>> constructive feedback, they too should be qualified to review and approve
>> code without having to make a full-time job of it, or we might as well go
>> back to having employees have the commit bit only.
>>
>> This project is too large to limit commit bits/code reviews/merging only
>> to individuals who know the workings of the entire repository inside and
>> out.  Is there a chance they could miss something in a review that has an
>> unanticipated negative impact elsewhere in the code?  Sure, as with anyone,
>> but that's also what tests, QE, teammates, and bugfixes are for.  We need
>> trust, not control beyond the basic level to mitigate risks.
>>
>> ----
>>
>>
>> Either way, this type of conversation is probably best suited for
>>> discussion amongst each plugin group as they determine what their needs are.
>>>
>>
>> Here I agree with you.  I had assumed if you were qualified to receive
>> the commit bit for Pulp, you'd be qualified to have it in other areas,
>> especially as I've seen folks from the mini teams requesting cross-team
>> help when they're overloaded, but if we really want plugins to have
>> autonomy, then this vote should really be focused on pulp then the pulp_rpm
>> team can make their own call in a separate procedure.
>>
>>
>> As for this nomination specifically, @milan has demonstrated each of the
>> points to becoming a committer listed here. [0]  Therefore, I am still +1
>> on giving him the commit bit.*
>>
>>
>>
>> [0] https://github.com/pulp/pups/blob/master/pup-0006.md
>> * I do not have the commit bit yet myself, so technically my vote does
>> not count, but I think this was a very important discussion to have given
>> the new process and the potential effects these decisions will have on the
>> health of the Pulp project community, and thus eventually on my job.
>>
>>
>> Respectfully,
>>
>> --Dana
>>
>>
>> Dana Walker
>>
>> Associate Software Engineer
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>> <https://red.ht/sig>
>>
>> On Thu, Sep 6, 2018 at 8:26 AM, Brian Bouterse <bbouters at redhat.com>
>> wrote:
>>
>>> I was hoping for more discussion before the calling of a vote. I'm a
>>> committer in both of these areas, and this nomination surprised me since
>>> we've never talked about either change. I have concerns both with
>>> increasing the sizes of these teams and also with this specific nomination
>>> at this time.
>>>
>>> With Pulp2 nearing maintenance mode, the core and plugin teams need to
>>> assess what their needs are both in code and people. I feel that with 9
>>> people on the core team, maintaining vision is hard/impossible, and the
>>> mailing list discussions have demonstrated that. Also consider that Pulp3
>>> is an order of magnitude smaller codebase (literally) so keeping the same
>>> number of committers seems too many. I also feel that any committer being
>>> added should already be very involved, contributing features and
>>> discussion, not added and then gotten involved. Milan has been very
>>> involved in Pulp2 RPM work, but Pulp2 and Pulp3 are very different.
>>> pulp_rpm for Pulp3 is nearly feature complete and Milan hasn't been
>>> involved in any of that planning or implementation. Maybe the Pulp3/2 teams
>>> should be split? Either way, this type of conversation is probably best
>>> suited for discussion amongst each plugin group as they determine what
>>> their needs are.
>>>
>>> @Milan I think one area the core team does need leadership now is on
>>> pulp2->3 migration planning. I think that would be a good way to get more
>>> involved as a non-committer to demonstrate epic-level feature planning,
>>> show more collaboration, and clearer communication. Those are the main
>>> aspects I'm looking for. I can give feedback directly too if that's helpful.
>>>
>>>
>>>
>>> On Wed, Sep 5, 2018 at 10:44 AM, Daniel Alley <dalley at redhat.com> wrote:
>>>
>>>> Now that PUP 6 has been merged, it's time to follow the process :)
>>>>
>>>> I would like to nominate Milan Kovacik (mkovacik at redhat.com) for a
>>>> commit bit on these repositories:
>>>>
>>>>
>>>>    - pulp
>>>>    - pulp_rpm
>>>>    - devel
>>>>
>>>>
>>>> Milan has demonstrated a consistent dedication to quality in his
>>>> contributions and his reviews.  I believe his work speaks for itself :).
>>>>
>>>> The vote end date is September 12th, seven days from today.
>>>>
>>>> _______________________________________________
>>>> 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/20180910/b1f2a748/attachment.htm>