[FFmpeg-devel] [VOTE] drop support for using libav* compiled with mingw/cygwin in msvc

[Michael Niedermayer]

On Wed, Feb 27, 2008 at 01:35:18PM +0100, Diego Biurrun wrote:
> On Wed, Feb 27, 2008 at 12:45:19PM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 27, 2008 at 10:28:48AM +0100, Diego Biurrun wrote:
> > > On Wed, Feb 27, 2008 at 01:27:42AM +0100, Michael Niedermayer wrote:
> > > > On Tue, Feb 26, 2008 at 11:29:15PM +0000, M?ns Rullg?rd wrote:
> > > > > Diego Biurrun <diego at biurrun.de> writes:
> > > > > 
> > > > > > On Mon, Feb 25, 2008 at 01:59:45PM +0100, Michael Niedermayer wrote:
> > > > > >> [...]
> > > > > >
> > > > > > Can we please have a bit more discussion before resorting to votes the
> > > > > > next time around?
> > > > 
> > > > Yes, sorry. This is the kind of thing that happens without a formal voting
> > > > procedure ...
> > > 
> > > No.  You simply called for a vote without allowing for previous
> > > discussion. 
> > 
> > A proper formal "voting procedure" would require some discussion period
> > before people write proposed solutions about which people then can vote
> > using some condorcet method ...
> 
> I very much fear even more formal procedures around here...

I meant something like:
* Any ffmpeg developer can start a vote by posting a mail to ffmpeg-dev with
  [VOTE] in the subject. After such a mail the discussion period starts.
* During the discussion period ffmpeg developers can discuss the subject and
  propose solutions. The discussion period ends when no new solutions are
  proposed for 7 days. After it ends the actual vote starts
* During the actual vote ffmpeg developers can vote by replying to the
  mail on ffmpeg-dev and ranking the proposed solutions. Anyone can change
  their vote during the vote period. The Vote period ends after no new votes
  are received fo 7 days.
* If there is a condorcet winner (a solution which wins against all others in
  pairwise comparission), it is the winner of the vote. If there is no
  condorcet winner then no consensus has been reached and the vote is invalid.

Above would avoid the problem you pointed at.


> 
> > > Note that the discussion brought force a workable
> > > alternative solution.
> > 
> > Yes, we voted, we discussed, mans commited something based on the discussion.
> > Before the vote your and mans position was that you didnt care at all
> > about MSVC breakage, the vote demonstrated that this is not what people
> > want. In such the vote was usefull ...
> 
> All of this would have been possible without a vote.  

maybe, maybe not ...


> On the other hand
> the vote almost cut off the better alternative that we have now.

I strongly disagree


> 
> > > Voting should be the very last resort, always.
> > 
> > Especially if the result differs from what you wanted. ;)
> > No IMHO voting is very usefull to find out what peoples positions are.
> > The only reason not to vote is that one preferrs to not know what the
> > majority wants.
> 
> No.  Once there has been a vote it becomes hard to reach an alternative
> consensus.

I strongly disagree
We did have a vote and it seems we did end with an alternative, so what you
say is hypothetical, it didnt happen like that ...


> 
> > And please dont misunderstand me but i think you are more pissed about the
> > result than the fact that there was a vote.
> 
> I'm not at all "pissed" about the result.

So you are happy about it? :)


> 
> > Also speaking about votes with no proper discussion, the warning vote you
> > started also had _zero_ discussion prior. People just added discussion while
> > voting ...
> 
> We had been discussing this for years, on the ml, on IRC, wherever.

Discussing that warnings are bad and should be removed yes. But the
details absolutely no.
Where was the discussion about which warnings should be enabled and which
disabled? I did enable what i personally felt was a good idea, noone complained
but a discussion didnt happen.
And the text which was added to the policy also shows that there was no real
agreement, discussion or anything else. If there would have been the first
try would have been closer to the final one ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080227/345ddf4f/attachment.pgp>