[Ffmpeg-devel] Re: Advocating periodic releases

[Michael Niedermayer]

Hi

On Sun, Oct 15, 2006 at 10:18:21PM -0400, Dana Hudes wrote:
> Michael Niedermayer wrote:
> >theres no closed state in my proposal, and i also see no sense in one
> >  
> Of course you need a closed state. A bug is closed when it is fixed and 
> confirmed fixed and committed etc.  -- or confirmed that its a 
> duplicate, not a bug, etc. Closed is the final state which confirms the 
> resolution --

so you say fixed_and_confirmed == closed and 
duplicate(_and_confirmed) == closed
from that you can conclude that fixed_and_confirmed == duplicate_and_confirmed
but that is not something we want -> there can be no single closed state

about having a dupicate_and_confirmed state in addition to duplicate, i have
my doubts about the usefullness (in practice) but i certainly have no 
objections to that if at least 1-2 ffmpeg developers say that they want such
a thing

i assume that duplicate_and_confirmed here means that after a bug has been
fixed its confirmed that the duplicate has been fixed too

this is as far as i can see only usefull if we have someone who goes over
all duplicate bugs for which the "main" bug has been fixed and checkes if the
fix really fixed it too (the question here is if anyone would do that ...)


> and should not be done by assigned developer who made 
> resolution.

yes, someone else should check and confirm things, though in practice
IMO the majority of fixed bugs will never be confirmed by anyone ...


> The original requester can close a bug too.

yes that would be nice but its important that if that is supported then
the original requester (who is a random guy or girl with a internet connection)
cannot change the state of any other bugs then the ones she opened

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is