[Pulp-dev] commit-bit nomination

Mon Sep 10 14:47:33 UTC 2018

+1. I agree with @asmacdo. I do think we need a larger discussion around
team sizes, etc though.

David

On Mon, Sep 10, 2018 at 10:45 AM Austin Macdonald <amacdona at redhat.com>
wrote:

> +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
>>
> _______________________________________________
> 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/8ab48a81/attachment.htm>