[vlc-devel] Releasing too slow

[Sidney Doria]

Rémi,

It's completely clear to me. The 1.00 is the 1.00. The one!

It's perfectly normal that people be concerned about the stable
release 1.0 of such respected sofware.

The 1.0 must be remarkable and has a special taste which everyone in
here is waiting for.

Just relax a moment. It's going on.

Sidney Doria
VLC pt_BR localisation



2009/7/5 Rémi Denis-Courmont <remi at remlab.net>:
>        Hello,
>
> I think I already mentioned it, but I am very dissatisfied with the 1.0
> releasing timeline.
>
> First, there has been way too little informations on what was going on.
> Basically, I have almost never known what was blocking the release at a given
> point in time.
>
> Second, it has been way too slow. Most recently, there have been so few and
> minor bugfixes, that I really wonder why the release was not already done. It
> makes me think we are waiting for things that nobody wants to fix, which is
> utterly pointless. Even the 0.9.0 freeze, lasting 10 weeks, was far shorter:
> 03-19 1.0.0-pre1
> 04-17 1.0.0-pre2
> 05-09 1.0.0-rc1
> 05-27 1.0.0-rc2
> 06-05 1.0.0-rc3
> 06-17 1.0.0-rc4
> 07-?? 1.0.0??
> That is already more than 15 weeks and we're not even done yet, even though
> 1.0 has far less disruptive changes than 0.9 had...
>
> Why did we wait four weeks between each of the first four previews? It used to
> be two weeks which makes much more sense to me. Why is 1.0.0 still not out,
> even though even 1.0.0-rc1 (and definitely 1.0.0-rc2) was, as far as the
> source code is concerned, I think, release-grade?
>
> IMHO, the proper time for a freeze is a month or so after forking. The quality
> of backported fixes decreases with time, as the trunk diverges from the frozen
> branch. We do not have enough quality assurance (if any) and dedicated bug
> fixing resources that we could really afford long stabilization periods found
> in more commercially-driven projects.
> Also, the new features in trunk start getting stable, such that the earlier
> release makes no sense (c.f. the 0.8.3 unreleased branch).
>
> IMHO also, we could as well have released 1.0.0 two months ago or almost (say
> shortly after 1.0.0-rc2). It seems to me that almost none of the fixes since
> then addressed regressions, which is supposed to be the whole point! That is
> not to say we should not fix old bugs, but they should not block releases
> either. Then, we (as usual) have the contribs. Again, I do not see why that
> should block source code releases. The Linux/BSD people are suffering from
> *BOTH* the Windows releasing delay and the distribution packaging delay. This
> makes no sense. With 0.9, we had the Windows binaries later than the source
> code, which makes a PERFECT SENSE considering the never-ending contribs
> delays. There has now been evidence that I am not the only one being
> frustrated by this.
>
>
> Frankly, I am getting quite demotivated. The lack of release predictability is
> demotivating, and so are the lack of visibility and timeliness. And it appears
> to hurt our credibility in the open-source community in general. Either we get
> someone to do source code release management seriously, or we might as well
> give up.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>



-- 
Sidney Doria
Redes ad hoc móveis
Doutorado em Computação
UFCG
Brasil

"Nessa jornada, o conhecimento será o seu escudo..."
(Mestre dos Magos no episódio do grimoire de ouro)