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" <strub...@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 <jus...@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 >>
