[FFmpeg-devel] Getting the FFmpeg 0.6 ball rolling

[Michael Niedermayer]

On Wed, Feb 03, 2010 at 02:51:43PM +0100, Robert Swain wrote:
> On 03/02/10 14:33, Michael Niedermayer wrote:
>>> The last release was supposed to receive only backporting of security 
>>> fixes
>>> and no bug fixes. We originally intended to have a second release after
>>> about 6 months but this didn't happen.
>>>
>>> It is suggested that policy for this release be outlined at the 
>>> beginning.
>>> I think we should maybe limit the discussion to a couple of weeks at most
>>> after which we hit release process hard. I don't think we should talk
>>> endlessly to create the 'perfect' release, but rather act on a few
>>> pertinent issues and try it again to see how it goes and what works best.
>>>
>>> Initial proposals for the next release:
>>>
>> [...]
>>
>>> I know the two-week-freeze on trunk was a cause for concern last year but
>>> it seems to be the most effective way to make a release.
>>
>> 1. "We should try X this time we will later evaluate it, no discussions 
>> now"
>> 2. "We did X and it worked so we will do it again its the best way because 
>> i
>>      say it is so wo wont try and evaluate an alernative"
>> 3. "We always did X and everyone does X so its best"
>>
>> I was against a freeze last time, and iam against a freeze this time.
>> Last time the argument of "try it once" was used to silence all logic,
>> we did try it once. Now its time to try alternatives
>
> I did think of the branch + freeze branch aside from release manager-OKed 
> bug fixes approach. We can try that if that is what is desired.
>
>>> It should focus
>>> everyone's attention on fixing bugs for just two weeks. That benefits 
>>> trunk
>>> as well as people wanting to make a release.
>>
>> quickly fixing bugs is the best way at introducing new bugs, the new ones
>> might be easy to fix but you wont even know they are there for bugs
>> fixed in the last few days. And as we never accept bug reports againt
>> non head we can easyl brush that under the carpet
>
> Maybe we don't accept bug reports against non-head now, but maybe someone 
> stepping up to be a release maintainer would be happy to receive bug 
> reports against the release version and verify against head to backport 
> fixes or issue a bug report upstream to us on roundup.

if someone seriously wants to deal with bugs on 0.6 we might need to
adapt roundup a little to make this more comfortable
the least would be a "0.6" tag and a "head" tag, the idea here would be
neither -> bug in head, 0.6 not tested
"0.6"   -> bug in 0.6 not in head
"head"  -> bug in head not in 0.6
"0.6,head"-> bug in both
the problem with this approuch is that its not flexible enough
strictly each branch would need its own status/substatus/priority
a bug can  be fixed in one and open in another or wontfix in one and
not reproduceable in another. Also it might be high priority in 0.6
but normal in head
I think roundup could hanlde 2 status & 2 substatus and 2 priority
easily for head and the latest release but it would mean a bit more
clutter and more work. Its search function also would alraedy naturally
support displaying a subset of this ...
this also brings us to the roundup needs a less busy maintainer
issue. Any volunteers to help him this year?

>
> I think you have a point about quickly fixing bugs though.

yes just look at what mess i created in the last days :)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/20100203/f8b2f3ec/attachment.pgp>