[vlc-devel] Releasing too slow

[Andre-John Mas]

Hi,

I am coming from outside the development team, so the only thing I can  
do
is ask questions. While things may have gone wrong we need to be able to
stand back, without pointing fingers and ask how things can be done  
better.

The first question is how and when the timeline the feature set is  
defined
for a release and to what degree there is divergence? I have been  
involved
in projects where a feature set was defined, but because we were  
trying to
satisfy everyone ended up diverging from what we had decided on. While  
we
want to have everything perfect, it may be useful to decide in which  
release
things are going to be put off to and why. Users can be very  
demanding, but
we need to be able to communicate the milestones, so they no what to  
expect.

Were the any gotchas? Basically issues where the amount of work  
involved was
under-estimated. Also if something is proving to take more time, but  
is not
critical to the release, then it may be best to push that feature off  
to the
next release. Communication is key.

Are we wanting to release mission critical software or something that  
works
in 95% of the cases? Remember the less resources (time, money, people)  
you
have available for development and testing the more you need to reduce  
you
expectations for perfection.

Whatever the issues you might have be sure to communicate them, even if
it is privately off-line. No one is perfect and not communicating hurts
a project.

Hopefully these come off as constructive questions, that start the ball
rolling on what can be improved on.

André-John




On 5-Jul-2009, at 14:41, Rémi Denis-Courmont wrote:

> 	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