Re: [Pulp-dev] RFC process

On 03/21/2017 05:15 PM, Brian Bouterse wrote: > 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. +alltheplusses merge signature.asc Description: OpenPGP digital signature _

Re: [Pulp-dev] RFC process

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 wrote: > I found some small style problems that were left over from when the > proposal was rst.

Re: [Pulp-dev] RFC process

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 wrote: > After more discussion on the PR, I've pushed what I think are the final > revisions. These include

Re: [Pulp-dev] RFC process

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/pull/1 If there are any last comments please let me know, otherwise I plan to merge this

Re: [Pulp-dev] RFC process

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 o

Re: [Pulp-dev] RFC process

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 val

Re: [Pulp-dev] RFC process

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? What about using

Re: [Pulp-dev] RFC process

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

Re: [Pulp-dev] RFC process

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 an

Re: [Pulp-dev] RFC process

> 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 :) I have trouble finding etherpads even for regular meetings.

Re: [Pulp-dev] RFC process

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 abou

Re: [Pulp-dev] RFC process

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 pr

[Pulp-dev] RFC process

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 pr