-1 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.
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. [0] https://pulp.plan.io/issues/2619 On Mon, Sep 10, 2018 at 10:47 AM, David Davis <davidda...@redhat.com> wrote: > +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 <amacd...@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 <ipan...@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 <dawal...@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 <bbout...@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 <dal...@redhat.com> >>>>> wrote: >>>>> >>>>>> Now that PUP 6 has been merged, it's time to follow the process :) >>>>>> >>>>>> I would like to nominate Milan Kovacik (mkova...@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@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
