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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 <[email protected] >>>>>>>>> > 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pulp-dev mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Elyézer Rezende >>>>>> Senior Quality Engineer >>>>>> irc: elyezer >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
