river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: build mechanisms
Date Fri, 14 Jan 2011 11:25:37 GMT
As a community we have gotten into the habit of making changes in the
trunk, which is probably a mistake.  Given that we're (hopefully)
graduating soon we should probably be making more of an effort to
attaching patches to Jira items and branching.

As to the "Why should I contribute?  Who will see my changes?" point.
Documenting why your patch is good and useful in the Jira and/or on
the mailing list should be good enough.  If there's no discussion on
your patch then it's likely that it just scratches your own itch and
no-one elses.  This isn't a problem, start a vote thread (see below).

Alternatively, it will generate discussion of the "this patch is good,
it should be included" or "this patch is not good, because..."
varieties.  Either of which would hopefully lead to a better patch
being submitted and a vote thread (see below).

Starting a "[VOTE] Include patch Abc which fixes Xyz onto the trunk"
thread would be a really good way to go.

Simple and/or trivial bug fixes should still be okay to do on the
trunk.  (For some unknown values of 'simple' and 'trivial').

On Fri, Jan 14, 2011 at 11:13 AM, Dan Creswell <dan.creswell@gmail.com> wrote:
> Mmm, and the Linux approach to that would be "if you believe in something
> enough you'll garner support and convince people of its merits" etc etc.
>
> And no merit system is perfect.
>
> I think where we end up is needing guidance for how people should approach
> contributing work and what they can or cannot expect which should be made
> visible up front so they know what they're getting into. That in turn will
> allow people to choose or not to account for some other contribution that is
> as yet, un-merged.
>
> On 14 January 2011 11:08, Sim IJskes - QCG <sim@qcg.nl> wrote:
>
>> On 14-01-11 11:49, Dan Creswell wrote:
>>
>>> So the question is, when do we need consensus on such things?
>>>
>>
>> On the practical side, for replacing the build system. yes.
>>
>> If we have consensus in replacing it, i will instantly stop thinking about
>> the current system. I won't even dare to refactor a bit. But now, with the
>> replacement coming or not, it's in a vacuum, thinking/not thinking,
>> forking/not forking, thinking but not coding? And to be honest, i can't
>> imagine i'm the only one. I'm sure somebody out there will think: "What are
>> they going to do with my contribution if i make any? Accept it in trunk? Let
>> it rot in skunk? Delete it all together? Should i better start collecting
>> stamps or doing the groceries?".
>>
>>
>> Gr. Sim
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>
>

Mime
View raw message