<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>-1 <br></div><div><br></div><div>Milan has been a great contributor to the Pulp 2 RPM effort. I am looking forward to all the future contributions in both Pulp 2 and Pulp 3. However, after collaborating with Milan on issue 2619[0], I decided that he needs more mentorship. I can provide more feedback directly to you Milan.<br></div></div><div dir="ltr"><br></div><div>The last sentence in the "Becoming a committer" section of PUP 6 states "Anyone who specifically wants to get more involved should
approach the existing commit bit holders about mentorship." This step was omitted during this nomination process. <br></div><div dir="ltr"><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/2619" target="_blank">https://pulp.plan.io/issues/<wbr>2619</a><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 10, 2018 at 10:47 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1. I agree with @asmacdo. I do think we need a larger discussion around team sizes, etc though.<span class="HOEnZb"><font color="#888888"><br clear="all"><div><div dir="ltr" class="m_4216527952080036705gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></font></span></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 10, 2018 at 10:45 AM Austin Macdonald <<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>+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.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 10, 2018 at 9:03 AM Ina Panova <<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Brian,<div><div class="m_4216527952080036705m_1811032057953713698m_5591432377054498188gmail_signature"><div><br></div><div>it feels like your reply is in contradiction of what we are trying to achieve as a community project:<br></div><div><br></div><div>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.<br></div><div>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.<br></div><div>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? :)<br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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. <br></div><div><br></div><div>+1 on the voting.</div><div><br></div><div>I also solicit the team to be pro-active, so we can fail fast things which do not work out for us.</div></div></div><br><div class="gmail_extra"><br clear="all"><div><div class="m_4216527952080036705m_1811032057953713698m_5591432377054498188gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote">On Fri, Sep 7, 2018 at 2:17 AM, Dana Walker <span dir="ltr"><<a href="mailto:dawalker@redhat.com" target="_blank">dawalker@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>I respectfully disagree.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I was hoping for more discussion before the calling of a vote.<br></div></blockquote><div><br></div></span><div>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.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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.<br></div></blockquote><div><br></div></span><div>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.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Also consider that Pulp3 is an order of magnitude smaller codebase
(literally) so keeping the same number of committers seems too many.<br></div></blockquote><div><br></div></span><div>Again, I disagree with this focus on number of committers for many reasons.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>(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.)</div><div><br></div><div>----</div><div><br></div><div><br></div><div>--What are the risks associated with giving someone a commit bit?</div><div><br></div><div>They are:<br></div><div>A) Malicious intent. Someone could now delete the codebase, or include malware secretly into the work.</div><div>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.</div><div>C) Breaking the codebase, especially production, with buggy code. This can and does still happen even with experienced developers.</div><div><br></div><div><br></div><div>--How can these risks be mitigated?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>--What does this mean for the commit bit process?</div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>----<br></div><span><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Either way, this type of conversation is probably best suited for
discussion amongst each plugin group as they determine what their needs
are.<br></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div><br></div><div>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.*</div><div><br></div><div><br></div><div><br></div><div>[0] <a href="https://github.com/pulp/pups/blob/master/pup-0006.md" target="_blank">https://github.com/pulp/pups/<wbr>blob/master/pup-0006.md</a><br></div><div>* 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.</div><div><br></div><div><br></div><div>Respectfully,</div><div><br></div><div>--Dana<br></div><div><br></div><div><div class="gmail_extra"><span><br clear="all"><div><div class="m_4216527952080036705m_1811032057953713698m_5591432377054498188m_-2108710129248927571gmail_signature"><div dir="ltr"><div>
<p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>Dana</span> <span>Walker</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Associate Software Engineer</span><span style="font-weight:normal;color:rgb(170,170,170);margin:0px"></span></p>
<p style="font-weight:normal;margin:0px;font-size:10px;color:rgb(153,153,153)"><a style="color:rgb(0,136,206);font-size:10px;margin:0px;text-decoration:none;font-family:"overpass",sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span><br><br></span></a></p>
<table border="0"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/files/brand/email/sig-redhat.png" width="90" height="auto"></a> </td>
</tr></tbody></table>
</div></div></div></div>
<br></span><div><div class="m_4216527952080036705m_1811032057953713698m_5591432377054498188h5"><div class="gmail_quote">On Thu, Sep 6, 2018 at 8:26 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>@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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_4216527952080036705m_1811032057953713698m_5591432377054498188m_-2108710129248927571gmail-">On Wed, Sep 5, 2018 at 10:44 AM, Daniel Alley <span dir="ltr"><<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_4216527952080036705m_1811032057953713698m_5591432377054498188m_-2108710129248927571gmail-h5"><div dir="ltr"><div dir="ltr"><div>Now that PUP 6 has been merged, it's time to follow the process :)<br><br></div>I would like to nominate Milan Kovacik (<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@redhat.com</a>) for a commit bit on these repositories:</div><div dir="ltr"><br></div><div dir="ltr"><ul><li>pulp</li><li>pulp_rpm</li><li>devel</li></ul></div><div dir="ltr"><br></div><div>Milan has demonstrated a consistent dedication to quality in his contributions and his reviews. I believe his work speaks for itself :).<br></div><div><br></div><div>The vote end date is September 12th, seven days from today.<br></div></div>
<br></div></div><span class="m_4216527952080036705m_1811032057953713698m_5591432377054498188m_-2108710129248927571gmail-">______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>