+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