[Pulp-dev] RFC process

Brian Bouterse bbouters at redhat.com
Tue Mar 21 21:15:27 UTC 2017

Thanks for the review. I fixed those issues on the PR.

Please send your votes especially any negative ones since I plan to merge
this tomorrow morning.

On Tue, Mar 21, 2017 at 11:03 AM, David Davis <daviddavis at redhat.com> wrote:

> I found some small style problems that were left over from when the
> proposal was rst. After those are fixed, +1 to merging from me.
> David
> On Thu, Mar 16, 2017 at 6:34 PM, Brian Bouterse <bbouters at redhat.com>
> wrote:
>> After more discussion on the PR, I've pushed what I think are the final
>> revisions. These include moving it to a dedicated repo in the Pulp
>> organization. As such the PR is now here:  https://github.com/pulp/pups/p
>> ull/1
>> If there are any last comments please let me know, otherwise I plan to
>> merge this tomorrow. It would be nice if someone approved this PR. Even
>> after being merged, this is still a starting point which we can use to
>> refine the process itself over time.
>> Thanks to everyone who read or gave input.
>> -Brian
>> On Mon, Feb 27, 2017 at 4:54 PM, Brian Bouterse <bbouters at redhat.com>
>> wrote:
>>> I pushed another version based on feedback. The changes came as a new
>>> commit so you can see them there. I have 2 areas that I want to discuss
>>> before merging.
>>> == proposed change 1 ==
>>> I want really want beautifully readable proposals on pulpproject.org.
>>> That being said, I think we should pull that out of this proposal and
>>> instead go with:
>>> * A dedicated repo with this proposal's text as a README at the root.
>>> This would effectively adopt @mhrivnak's comment here[0].
>>> * We can figure out how to get those onto pulpproject.org as a separate
>>> effort
>>> == proposed change 2==
>>> Also I want to have the proposals live as a pull request until they are
>>> decided on. The current proposal has them being merged regularly. This
>>> would reduce friction by having proposals be created/revised without a
>>> single core dev needing to be involved. Also collaborators can push to each
>>> other's branches with github permissions so collaboration is still very
>>> possible. In fact @daviddavis did that with this meta PR. This part is
>>> basically written here [1] as a change.
>>> [0]: https://github.com/pulp/pulpproject.org/pull/50/#discussion_
>>> r103085714
>>> [1]: https://github.com/pulp/pulpproject.org/pull/50/files#diff-6
>>> 5d93959a5eea99a63191c1a80e105b4R284
>>> Comments and ideas are welcome either via e-mail or on the PR.
>>> Thanks!
>>> Brian
>>> On Fri, Feb 24, 2017 at 6:33 PM, Dennis Kliban <dkliban at redhat.com>
>>> wrote:
>>>> The things that I like about this proposal:
>>>> - The proposals are always merged so the community can reference them
>>>> in the future even if the proposal is not adopted. I like learning from
>>>> history.
>>>> - Revisions to the proposal are additional commits stored in git.
>>>> Having a record of changes can be valuable as the proposal lives on and
>>>> evolves.
>>>> - All the proposals are available on pulpproject.org or some other
>>>> wesbsite for anyone to see - including search engines.
>>>> I am not too thrilled about the discussion living separate from the
>>>> proposal, but I am a fan of our mailing lists. I would be happy with this
>>>> proposal being merged as is so we can announce it for voting and/or further
>>>> discussion on pulp-dev list.
>>>> -Dennis
>>>> On Fri, Feb 24, 2017 at 5:34 PM, Brian Bouterse <bbouters at redhat.com>
>>>> wrote:
>>>>> I pushed a new version based on feedback on the PR. It outlines
>>>>> several alternatives that we should consider along with downsides.
>>>>> What about leaving it as a pull request for longer?
>>>>> <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R277>
>>>>> What about using Github for discussion?
>>>>> <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R292>
>>>>> We could store the PEPs in Redmine. Why aren't we using Redmine?
>>>>> <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R262>
>>>>> There are also Downsides
>>>>> <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R250>
>>>>> of this proposal.
>>>>> My opinion is a +1 to leaving it as a pull request for longer to allow
>>>>> more autonomy for creation and revision of proposals. Also, we can
>>>>> additionally use Github for feedback, but that email threaded discussion
>>>>> should also be allowed to include a broader input from users who don't live
>>>>> in Github like most of us do. Both of these not-yet-done simple rewrites
>>>>> would remove these from the list of alternatives and incorporate them into
>>>>> the proposal itself. I'm happy to make such changes with input from others.
>>>>> Also in the Unresolved Questions
>>>>> <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R309>
>>>>> section having an acronym or initialization of a name for these would be
>>>>> nice.
>>>>> It would be great to get feedback by 00:00 UTC on Tuesday the 28th
>>>>> (that's 7pm on Feb 28th). I'll try to be more responsive with the edits
>>>>> also.
>>>>> Thanks for the input so far.
>>>>> -Brian
>>>>> On Mon, Feb 13, 2017 at 5:09 PM, Elyezer Rezende <erezende at redhat.com>
>>>>> wrote:
>>>>>> I would like to comment about the C4 [1] which is "the Collective
>>>>>> Code Construction Contract (C4), [...], aimed at providing an optimal
>>>>>> collaboration model for free software projects".
>>>>>> It does not mention about creating RFCs specifically but provides
>>>>>> some guidelines that may help when implementing them.
>>>>>> [1] https://rfc.zeromq.org/spec:42/C4/
>>>>>> On Mon, Feb 13, 2017 at 5:45 PM, Brian Bouterse <bbouters at redhat.com>
>>>>>> wrote:
>>>>>>> I want to share some ideas on a possible proposal process. It's
>>>>>>> inspired by processes in the Foreman, Python, and Django communities along
>>>>>>> with several discussions I've had with core and community users. This is
>>>>>>> written as a concrete proposal, but it is 100% changeable.
>>>>>>> I'm doing the meta thing and using the process I'm proposing to
>>>>>>> propose the process. The proposal is here [0]. It's unmerged (not the
>>>>>>> process) because I suspect we'll want a dedicated repo. This proposal, if
>>>>>>> adopted, is still a living document (like Python PEP 0001) so even if its
>>>>>>> approved it would still be an evolving document.
>>>>>>> Feedback and collaboration is welcome!
>>>>>>> [0]: https://github.com/pulp/pulpproject.org/pull/50
>>>>>>> All the best,
>>>>>>> Brian
>>>>>>> On Fri, Feb 10, 2017 at 6:01 PM, David Davis <daviddavis at redhat.com>
>>>>>>> wrote:
>>>>>>>> I also like the idea of using plan.io for our RFCs. The only thing
>>>>>>>> that github or etherpad offers over plan.io is the ability to
>>>>>>>> edit/update the RFC. If the RFC is in the body of the story/task in
>>>>>>>> Redmine, then I think it can only be edited by admins. Maybe we can use the
>>>>>>>> comments or not worry about editing the RFC though.
>>>>>>>> There were also some other points brought up this past week about
>>>>>>>> RFCs—mostly around workflows. One important thing I forgot to consider is
>>>>>>>> how to accept RFCs. Should we vote on them? Or perhaps try to arrive at
>>>>>>>> some sort of consensus?
>>>>>>>> David
>>>>>>>> On Mon, Feb 6, 2017 at 12:31 PM, Ina Panova <ipanova at redhat.com>
>>>>>>>> wrote:
>>>>>>>>> I think all mentioned options could be used, but we need to have a
>>>>>>>>> starting point. Something that would track a discussion for a long time.
>>>>>>>>> And i lean towards ---> open a story/task (as a starting point).
>>>>>>>>> Having a story/task opened we can always reference it in mail
>>>>>>>>> discussion or etherpad.
>>>>>>>>> Why i prefer to have all/most of the discussion happen on the
>>>>>>>>> story/task?
>>>>>>>>> Because i cannot guarantee that i will not miss somehow the email
>>>>>>>>> or etherpad. I actually often find myself trying to dig through dozens of
>>>>>>>>> mails to find the right one. Same with the etherpads :)
>>>>>>>>> Because i receive notifications when someone adds a comment on the
>>>>>>>>> task/story, even after one month or two. This does not happen with
>>>>>>>>> etherpad, and i actually will not see the new comments/ideas until i will
>>>>>>>>> check the pad by myself.
>>>>>>>>> Periodically. From time to time. Remembering the right pad number,
>>>>>>>>> and of course i do not remember it, so i will need to dig into my mails to
>>>>>>>>> find it out.
>>>>>>>>> --------
>>>>>>>>> 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, Feb 6, 2017 at 4:59 PM, David Davis <daviddavis at redhat.com
>>>>>>>>> > wrote:
>>>>>>>>>> One of the things that came up in our retrospective is that we
>>>>>>>>>> don’t have a formal way to propose changes to our codebase and processes
>>>>>>>>>> (aka RFCs). This was motivated in part by the recent discussion on merging
>>>>>>>>>> forward commits on our pulp-dev mailing list.
>>>>>>>>>> I'd like to maybe discuss a way we can propose RFCs and then
>>>>>>>>>> document this process in our docs. It sounds like there has already been
>>>>>>>>>> some discussion about how to handle RFCs so I apologize coming into this
>>>>>>>>>> without having any background.
>>>>>>>>>> Thinking through RFCs, I see two things to address. First is the
>>>>>>>>>> actual format of the RFC. I see some RFCs in plan.io but it
>>>>>>>>>> doesn’t seem like there’s a standard way of formatting an RFC. Should there
>>>>>>>>>> be? For reference, here's the template for foreman RFCs. I think it might
>>>>>>>>>> serve as a good starting point:
>>>>>>>>>> https://github.com/theforeman/rfcs/blob/master/0000-template.md
>>>>>>>>>> Secondly, there’s the question of where to discuss and archive
>>>>>>>>>> RFCs. Some possible options:
>>>>>>>>>> 1. Open a story or task on plan.io
>>>>>>>>>> 2. Use a GitHub repo to store and discuss RFCs (e.g.
>>>>>>>>>> https://github.com/theforeman/rfcs)
>>>>>>>>>> 3. Write the RFC on an Etherpad and once accepted, open a plan.io
>>>>>>>>>> issue.
>>>>>>>>>> 4. Just send out RFCs to the mailing list
>>>>>>>>>> 5. Something else?
>>>>>>>>>> I was thinking we could also use the mailing list in addition to
>>>>>>>>>> options 1-3 by sending out an email pointing people to the actual RFC.
>>>>>>>>>> Thoughts?
>>>>>>>>>> David
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Pulp-dev mailing list
>>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>> _______________________________________________
>>>>>>>> Pulp-dev mailing list
>>>>>>>> Pulp-dev at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>> _______________________________________________
>>>>>>> Pulp-dev mailing list
>>>>>>> Pulp-dev at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>> --
>>>>>> Elyézer Rezende
>>>>>> Senior Quality Engineer
>>>>>> irc: elyezer
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170321/92553298/attachment.htm>

More information about the Pulp-dev mailing list