On Sep 20, 2011, at 8:59 AM, Chris Lalancette <clalance(a)redhat.com> wrote:
On 09/20/11 - 07:41:13AM, Martyn Taylor wrote:
> On 09/19/2011 03:58 PM, Matt Wagner wrote:
>> On Mon, Sep 19, 2011 at 10:43:54AM -0400, Christopher Alfonso wrote:
>>> Was there ever a final decision made with regard to Hugh's git flow post
to the list. The replies were sort of split for and against. As a newcomer to the team,
I'm not sure how such process change decisions are made (unanimous/majority votes vs
the benevolent dictator approach). I may have missed a post to the list the closed this
>> AFAICT, the decision seemed to hit some ambivalence and then discussion
>> just fizzled out, and I assumed it was dead. That's part of the reason
>> that I decided to pick it back up, but in a more-palatable form.
>> As for how process-change decisions are made, truthfully, I'm not sure
>> there's any hard guideline. I'd say that in general we just try to reach
>> a consensus, and are usually pretty good at eventually getting there,
>> even if it's a bit circuitous at times.
> +1 from me. Good Stuff.
> Also, since there was no final decision made on the patch process. I
> would like to propose that if we do move to github then we adopt the
> github patch process.
> For two reasons:
> 1) This is how the majority of the ruby community works and I think it
> would be in our advantage to be consistent.
> a) We are dependent on a lot of gems, if we need to get changes into
> these gems it would be beneficial if we were experienced in their process.
> b) It lowers the barrier for entry for other rubyists wanting to
> contribute to the project, (since the github patch process seems to be
> the standard across the community)
> 2) It cleans up our mailing lists. There have been several requests to
> do something about the mailing lists, patches just clog the things up,
> this solution solves the issue without having to bring in another list
> (which I know some people are dead set against).
> I understand that this would be a learning curve for a lot of people and
> it might set us back a little time, but given the benefits I think it is
> worth it.
> Unless others have a compelling reason to think otherwise?
The compelling reason is that it is a change in the process, and I don't see
a lot of benefit from it. You are basically switching from having to monitor
the mailing list to having to monitor pull requests. I just don't see it as a
Folks that like email notification can opt in for a notification when a
pull request is issued.
Given all of the churn we've had in this project, I'd much rather see us just
settle down and get into a rhythm of producing code and releases.
tooling and code rhythm should be mutually exclusive.
new process is *massively* better (and I don't see that it is), it is just more
To me, churn and development process evolution are distinct. My opinion on
using the tools integrated with github to organize and facilitate project contributions
represents progress rather than churn.
The opinion on whether it's a massive improvement is subjective, and I personally
think everyone's opinion matters and should be evaluated. There is a lot of tooling
integrated with github, which folks find appealing. ...to me it does represent significant
improvement over re-using the email list as the process tool.