The voting ended on August 11th with a final vote count of eight +1s and no -1 votes. I've gone ahead and merged the revisions. Thank you for everyone's comments, participation, and patience throughout this process.
Now that the revisions are merged, you can see the whole document here: https://github.com/pulp/pups/blob/master/pup-0001.md Thanks, Brian On Fri, Aug 11, 2017 at 9:11 AM, Michael Hrivnak <mhriv...@redhat.com> wrote: > +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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev