community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Vesse <rve...@dotnetrdf.org>
Subject Re: Understanding the commit-then-review workflow
Date Wed, 09 Jul 2014 08:37:13 GMT
A practical example of a technical veto I've seen was when we added some
new optimisations that interacted badly with a pre-existing API in some
rare corner cases.

This actually went into a release and it wasn't until a particularly vocal
community member got round to upgrading that we became aware of the issue.
 As it was central to a their product stack and that product stack is
widely used in our field both by ourselves and the wider community this
was an appropriate veto.  After some heated discussion (because at first
we didn't understand why this was a problem - this was an example of when
a minimal test case is useless without the wider context) we were able to
come up with a technical solution that preserved the new optimisations and
resolved the bad interactions.

Rob

On 09/07/2014 08:12, "Mark Struberg" <struberg@yahoo.de> wrote:

>I think the vetoing -1 from PMCs is mainly used for 'legal' reasons. If
>e.g. some new committer adds code which he took from an external project
>and it's license is not appropriate.
>I've not yet seen -1 for purely technical reasons. This might happen. But
>usually a consensus is reached after the pros and cons got discussed on
>the list.
>
>LieGrue,
>strub
>
>
>On Wednesday, 9 July 2014, 3:36, Justin Mclean <justin@classsoftware.com>
>wrote:
> 
>
>>
>>
>>Hi,
>>
>>> Ugh.  That looks garbled to me.  What exactly is a "code modification
>>>vote?"  Any committer should be allowed to -1 a commit (with reasons)
>>
>>Any committer can vote -1 it's just not normally binding (depending on
>>project guidelines), I certainly can't see it being ignored when it does
>>happen, even a -1 by a user is probably trying to tell you something is
>>up :-) There was a long discussion about this when we were drafting up
>>the Apache Flex guidelines as the default rules are not always clear.
>>The was an attempt to get this wording fixed up but not much come of it.
>>
>>Thanks,
>>
>>Justin
>>





Mime
View raw message