+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
