+1 On Fri, Aug 11, 2017 at 4:54 AM, Ina Panova <ipan...@redhat.com> wrote:
> +1. > Thanks Brian for all your effort and commitment. > > > > -------- > 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 Thu, Aug 10, 2017 at 9:58 PM, Daniel Alley <dal...@redhat.com> wrote: > >> +1 >> >> On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban <dkli...@redhat.com> >> wrote: >> >>> +1 >>> >>> On Thu, Aug 10, 2017 at 9:21 AM, David Davis <davidda...@redhat.com> >>> wrote: >>> >>>> +1. I think this is worth trying out. >>>> >>>> >>>> David >>>> >>>> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald <amacd...@redhat.com> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Thank you Brian! >>>>> >>>>> On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse <bbout...@redhat.com> >>>>> wrote: >>>>> >>>>>> A small language clarification was pushed based on feedback via >>>>>> comment: https://github.com/bmbouter/pu >>>>>> ps/commit/f5b7282b2d2e369b90f149e4cc25226bb093171b >>>>>> >>>>>> Voting is open for the PUP1 revisions. Normally the voting window is >>>>>> longer, but this topic has been discussed for a long time. The core team >>>>>> earlier this week decided a shorter voting window was appropriate in this >>>>>> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise >>>>>> any concerns around this process. Otherwise, please send in votes via >>>>>> this >>>>>> thread. I'll cast mine now. >>>>>> >>>>>> +1 to passing the pup1 revisions. >>>>>> >>>>>> Thanks to everyone who has contributed comments and energy into this >>>>>> topic. >>>>>> >>>>>> -Brian >>>>>> >>>>>> >>>>>> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse <bbout...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> After some in-person convo, the core team wants to open PUP1 >>>>>>> revision voting on Wednesday and close it at midnight UTC on Friday Aug >>>>>>> 11th. We will pass/not-pass according this the voting outlined in PUP1 >>>>>>> itself (a variation on self-hosting [0]). We also want to ask that any >>>>>>> comments on the PUP1 revisions by posted before midnight UTC tomorrow >>>>>>> Aug >>>>>>> 8th. >>>>>>> >>>>>>> [0]: https://en.wikipedia.org/wiki/Self-hosting >>>>>>> >>>>>>> -Brian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse <bbout...@redhat.com >>>>>>> > wrote: >>>>>>> >>>>>>>> I've pushed a new commit [3] to the PR. It includes the following >>>>>>>> changes. Please review and comment. If there are any major/blocking >>>>>>>> concerns about adopting this please raise them. Once the PUP1 >>>>>>>> revisions are >>>>>>>> resolved, PUP2 can also be accepted based on the votes it had >>>>>>>> previously. >>>>>>>> >>>>>>>> * Adjusts the +1 approvals to come from anywhere, not just core devs >>>>>>>> * Explicitly allows for votes to be recast >>>>>>>> * Explains two examples where votes are recast. One is based on >>>>>>>> many other -1 votes being cast. The other is when concerns are >>>>>>>> addressed >>>>>>>> and a -1 vote is recast. >>>>>>>> >>>>>>>> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26 >>>>>>>> e1d97ea6fe4aa570066db768 >>>>>>>> >>>>>>>> -Brian >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse < >>>>>>>> bbout...@redhat.com> wrote: >>>>>>>> >>>>>>>>> From the discussion on the call last week, I've made some >>>>>>>>> revisions [2] to explore the idea of having a lazy consensus model. >>>>>>>>> Comments, ideas, concerns are welcome either on the PR or via this >>>>>>>>> thread. >>>>>>>>> >>>>>>>>> As @mhrivnak pointed out, the adoption of a lazy consensus model >>>>>>>>> is meaningfully different than the language we have in pup1 today >>>>>>>>> which >>>>>>>>> uses "obvious consensus". I want to be up front about that change >>>>>>>>> [2]. If >>>>>>>>> anyone significantly disagrees with this direction, or has concerns, >>>>>>>>> please >>>>>>>>> raise them. >>>>>>>>> >>>>>>>>> [2]: https://github.com/pulp/pups/pull/5/ >>>>>>>>> >>>>>>>>> -Brian >>>>>>>>> >>>>>>>>> On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse < >>>>>>>>> bbout...@redhat.com> wrote: >>>>>>>>> >>>>>>>>>> After some in-person discussion, we will have a call to discuss >>>>>>>>>> ideas and options regarding the pup1 process. We will use this >>>>>>>>>> etherpad [0] >>>>>>>>>> for notes, and we will recap the information to the list also. In >>>>>>>>>> preparation, please continue to share ideas, perspectives and >>>>>>>>>> concerns via >>>>>>>>>> this list. >>>>>>>>>> >>>>>>>>>> When: June 22nd, 1pm UTC. See this in your local timezone here >>>>>>>>>> [1]. The call will last no longer than 1 hour. >>>>>>>>>> >>>>>>>>>> How to connect: >>>>>>>>>> video chat: https://bluejeans.com/697488960 >>>>>>>>>> phone only: + 800 451 8679 Enter Meeting ID: 697488960 >>>>>>>>>> >>>>>>>>>> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited >>>>>>>>>> [1]: http://bit.ly/2rJqegX >>>>>>>>>> >>>>>>>>>> -Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak < >>>>>>>>>> mhriv...@redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> Back to where we started, having digested the discussion here >>>>>>>>>>> and references cited, it seems clear that we have a system based on >>>>>>>>>>> consensus, and that there is strong desire for decisions about >>>>>>>>>>> process to >>>>>>>>>>> continue being made with consensus. In terms of "obvious >>>>>>>>>>> consensus", I'll >>>>>>>>>>> propose that if any core member thinks it has not been reached, it >>>>>>>>>>> has >>>>>>>>>>> (perhaps by definition) not been reached. >>>>>>>>>>> >>>>>>>>>>> PUP0001 simply states in that case, "If obvious consensus is not >>>>>>>>>>> reached, then the core devs decide." We don't need to >>>>>>>>>>> over-complicate this. >>>>>>>>>>> We've had reasonable success for many years at making process >>>>>>>>>>> changes and >>>>>>>>>>> agreeing on them. The PUP system should be a tool that helps us >>>>>>>>>>> define a >>>>>>>>>>> proposal as best we can, while providing a focal point for >>>>>>>>>>> discussion. It >>>>>>>>>>> should not unduly impede our ability to make decisions. >>>>>>>>>>> >>>>>>>>>>> So in a case where consensus is not obvious, can we talk it out >>>>>>>>>>> among the core devs, particularly those with reservations, and make >>>>>>>>>>> it our >>>>>>>>>>> collective responsibility to find a path forward? Do we need to >>>>>>>>>>> define it >>>>>>>>>>> in more detail than that? >>>>>>>>>>> >>>>>>>>>>> On Fri, Jun 16, 2017 at 9:22 AM, David Davis < >>>>>>>>>>> davidda...@redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I like centos model but personally I’m not a fan of the lazy >>>>>>>>>>>> consensus option (X=0). Instead, I like the idea of having X be >>>>>>>>>>>> greater >>>>>>>>>>>> than 1 (preferably 2). I feel like if there’s at least two people >>>>>>>>>>>> driving a >>>>>>>>>>>> change (i.e. X=2) then if one person leaves the project, we’ll >>>>>>>>>>>> still have >>>>>>>>>>>> someone who is able and motivated to take on the maintenance and >>>>>>>>>>>> evolution >>>>>>>>>>>> of the change. That said, I am happy to test out the model where >>>>>>>>>>>> X=0. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse < >>>>>>>>>>>> bbout...@redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I asked about some of these governance questions to a group of >>>>>>>>>>>>> community managers from several open source projects that I meet >>>>>>>>>>>>> with >>>>>>>>>>>>> weekly. They said that if you don't have a BDFL (Pulp does not) >>>>>>>>>>>>> the other >>>>>>>>>>>>> very popular model is the lazy consensus model. I think lazy >>>>>>>>>>>>> consensus is >>>>>>>>>>>>> the spirit of pup1. I asked for some examples and they pointed me >>>>>>>>>>>>> at the >>>>>>>>>>>>> CentOS governance model [0][1]. >>>>>>>>>>>>> >>>>>>>>>>>>> Also @daviddavis and I were talking and codifying the problem >>>>>>>>>>>>> as what value should X be if X are the number of +1s required to >>>>>>>>>>>>> pass a >>>>>>>>>>>>> decision with zero -1 votes (vetos)? The CentOS governance model >>>>>>>>>>>>> sets X = 0 >>>>>>>>>>>>> by stating "There is no minimum +1 vote requirement". I'm also >>>>>>>>>>>>> advocating >>>>>>>>>>>>> for X=0 for the reasons I wrote in my earlier email. Practically >>>>>>>>>>>>> speaking, >>>>>>>>>>>>> I don't think an X=1, or X=2 will prevent many proposals that >>>>>>>>>>>>> would have >>>>>>>>>>>>> also passed with X=0. >>>>>>>>>>>>> >>>>>>>>>>>>> Regardless of the X value, we should continue the discussion >>>>>>>>>>>>> so we can arrive at a decision on both pup1 and pup3. Thanks for >>>>>>>>>>>>> continuing >>>>>>>>>>>>> the convo. >>>>>>>>>>>>> >>>>>>>>>>>>> [0]: https://www.centos.org/about/g >>>>>>>>>>>>> overnance/appendix-glossary/#consensus-decision-making >>>>>>>>>>>>> [1]: https://www.centos.org/about/governance/voting/ >>>>>>>>>>>>> >>>>>>>>>>>>> -Brian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova < >>>>>>>>>>>>> ipan...@redhat.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> And if we would remove all 'shades of grey' and go back just >>>>>>>>>>>>>> to +1 and -1 where people would need to make their mind up >>>>>>>>>>>>>> *clearly* which >>>>>>>>>>>>>> would lead stronger arguments of doing or not doing this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------- >>>>>>>>>>>>>> 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 Tue, Jun 13, 2017 at 5:30 PM, David Davis < >>>>>>>>>>>>>> davidda...@redhat.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In this model of where only -1 votes stop the PUP from >>>>>>>>>>>>>>> passing, wouldn’t it mean that there needn't be any consensus >>>>>>>>>>>>>>> at all? In >>>>>>>>>>>>>>> other words we could effectively strike the language about >>>>>>>>>>>>>>> consensus from >>>>>>>>>>>>>>> PUP-1. This model makes me worried that people other than those >>>>>>>>>>>>>>> casting -1 >>>>>>>>>>>>>>> won’t bother to vote or participate since only -1 votes matter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I personally like the idea of having at least 30% that are >>>>>>>>>>>>>>> +1 or +0. This means that enough -0 votes can still block the >>>>>>>>>>>>>>> vote, and >>>>>>>>>>>>>>> also +0 votes goes towards helping the PUP pass. Thus +0 and -0 >>>>>>>>>>>>>>> would both >>>>>>>>>>>>>>> matter. I think this is a good compromise between the extremes >>>>>>>>>>>>>>> of "broad >>>>>>>>>>>>>>> buy-in" and "default to change." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse < >>>>>>>>>>>>>>> bbout...@redhat.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We should (I thought we did) adopt a process that favors >>>>>>>>>>>>>>>> change and does not have a "broad buy-in requirement". Any >>>>>>>>>>>>>>>> change that >>>>>>>>>>>>>>>> doesn't harm the project should be allowed without broad >>>>>>>>>>>>>>>> buy-in. This >>>>>>>>>>>>>>>> empowers even a single individual to enact change. This makes >>>>>>>>>>>>>>>> Pulp better >>>>>>>>>>>>>>>> because: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Everyone is empowered. A single individual can have a >>>>>>>>>>>>>>>> meaningful impact. >>>>>>>>>>>>>>>> * Anyone can stop an idea that will negatively affect the >>>>>>>>>>>>>>>> project or community via veto. >>>>>>>>>>>>>>>> * We avoid the tyranny of the majority [0] or supermajority. >>>>>>>>>>>>>>>> * It avoids politics. If we start averaging, or counting >>>>>>>>>>>>>>>> votes for/against in an offsetting way, there will be >>>>>>>>>>>>>>>> politics. Counting >>>>>>>>>>>>>>>> votes for/against will create inequality because influential >>>>>>>>>>>>>>>> project >>>>>>>>>>>>>>>> members will likely see their ideas adopted but others won't. >>>>>>>>>>>>>>>> Having a >>>>>>>>>>>>>>>> "default to change and any core dev can veto" approach creates >>>>>>>>>>>>>>>> equality. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regarding how "obvious consensus" works with the >>>>>>>>>>>>>>>> "veto-or-it-passes" model, if there are zero -1 votes cast, >>>>>>>>>>>>>>>> that means no >>>>>>>>>>>>>>>> one wanted to stop the process. If no wants to stop it, and at >>>>>>>>>>>>>>>> least one is >>>>>>>>>>>>>>>> for it, then the most sensible thing to do is to pass it. >>>>>>>>>>>>>>>> Since someone >>>>>>>>>>>>>>>> took time to write the PUP there is obviously someone giving >>>>>>>>>>>>>>>> it a +1. If >>>>>>>>>>>>>>>> one person really wants to go to place X for dinner (aka a >>>>>>>>>>>>>>>> +1), and there >>>>>>>>>>>>>>>> are no counterproposals (aka a -1 with a suggestion) or strong >>>>>>>>>>>>>>>> preferences >>>>>>>>>>>>>>>> against (aka -0 or +0) then the group will probably go to >>>>>>>>>>>>>>>> place X for >>>>>>>>>>>>>>>> dinner by way of "obvious consensus". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In summary, adopting a "default to accept or reject with >>>>>>>>>>>>>>>> even a single veto" system creates an equal system. A system >>>>>>>>>>>>>>>> where, a >>>>>>>>>>>>>>>> single individual can make a difference, and anyone can stop a >>>>>>>>>>>>>>>> bad idea >>>>>>>>>>>>>>>> from occurring. To @mhrivnak's point about a change not >>>>>>>>>>>>>>>> meeting a broad >>>>>>>>>>>>>>>> range of needs, I expect -1's to be cast in those cases, so >>>>>>>>>>>>>>>> this system is >>>>>>>>>>>>>>>> still very safe in terms of protecting the projects needs and >>>>>>>>>>>>>>>> interests. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Brian >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jun 12, 2017 at 7:53 PM, David Davis < >>>>>>>>>>>>>>>> davidda...@redhat.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Not sure this is true. I actually abstained from voting on >>>>>>>>>>>>>>>>> PUP-3 because I was somewhere between a +0 and a -0. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova < >>>>>>>>>>>>>>>>> ipan...@redhat.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Having at least one +1 is not impartial approach just >>>>>>>>>>>>>>>>>> because the developer who , as you said, found the time for >>>>>>>>>>>>>>>>>> the research >>>>>>>>>>>>>>>>>> and writing down the proposal obviously will vote as +1 :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>> 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 Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald < >>>>>>>>>>>>>>>>>> amacd...@redhat.com> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This reminds me of the concept of a "Do-ocracy". >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If developers take the time to research and write up a >>>>>>>>>>>>>>>>>>> proposal, they have "done". It seems completely reasonable >>>>>>>>>>>>>>>>>>> to default to >>>>>>>>>>>>>>>>>>> the opinion of the people that cared enough to do the work. >>>>>>>>>>>>>>>>>>> If it isn't the >>>>>>>>>>>>>>>>>>> right decision, then someone must actively block it, simple >>>>>>>>>>>>>>>>>>> as that. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think the rule should be "PUP passes if we have at >>>>>>>>>>>>>>>>>>> least one +1 and no -1s". >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Michael Hrivnak >>>>>>>>>>> >>>>>>>>>>> Principal Software Engineer, RHCE >>>>>>>>>>> >>>>>>>>>>> Red Hat >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > > -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev