[vlc-devel] A respectful disagreement...

Sun Jan 8 13:29:45 CET 2012

2012/1/8 Shelley Horwitz <shelley at sjcomm.com>

> I respectfully disagree with Remi's point:
>
> "Feature-based versus time-based. The project history suggests that
> feature-
> based releases simply don't work because there is not enough commitment to
> finishing features, and time-based releases don't work because there is
> not
> enough commitment to stabilizing branches."
>
> I do not think there is any problem with either feature-based or
> time-based releases as long the development team agrees on what features
> will be included in each release and chooses a reasonable date for
> publishing that release. This is a planning and management issue.
> Professional developers look at requirements and priorities to define their
> workload to produce a schedule. The schedule is a target, and the target
> gives developers something to shoot at in making a commitment to finish
> on-time.
>
> A roadmap is the integration of feature-based and time-based releases. It
> is a PLAN... the studied, considered, reasonable, and organized way to
> accomplish product improvement. In fact, it eliminates all the adverse
> conditions that Remi raises. It recognizes necessary features, gives them
> appropriate priorities, assigns them to specific releases (and release
> dates), and gives developers strong motivation to produce good, working
> code in a reasonable timeframe.
>
> I cannot emphasize enough that this is what PROFESSIONAL developers do...
> this is the business of software development.
>
>
Please, don't use HTML emails in this mailing list, some people don't have
HTML enabled mail readers available 24/7.

And you are completely missing the point of volunteer vs. paid developers.
Since most people related to VLC development do this as a hobby, it isn't
feasible to make them work with any schedules or force them to do certain
features. Even current releases are stressful events because only few
people do release blocker bug fixing, and if someone would be forced to do
that, I think they would quit pretty fast.

IMHO roadmaps aren't useful if there isn't any guarantee for events in it
to happen. Bad/fake/broken promises are the cancer of software industry.

>
>   ------------------------------
> *From:* "vlc-devel-request at videolan.org" <vlc-devel-request at videolan.org>
> *To:* vlc-devel at videolan.org
> *Sent:* Sunday, January 8, 2012 3:00 AM
> *Subject:* vlc-devel Digest, Vol 56, Issue 35
>
> Send vlc-devel mailing list submissions to
>     vlc-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>     http://mailman.videolan.org/listinfo/vlc-devel
> or, via email, send a message with subject or body 'help' to
>     vlc-devel-request at videolan.org
>
> You can reach the person managing the list at
>     vlc-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vlc-devel digest..."
>
>
> Today's Topics:
>
>   1. [PATCH] Allow for newer a52_init(void) call. take 2.
>       (Kelly Anderson)
>   2. Re: [PATCH] Fixed a crash caused by yadif deinterlacer on
>       Windows XP (Naohiro KORIYAMA)
>   3. Re: The case for 2.0 (John Freed)
>   4. Re: The case for 2.0 ( R?mi Denis-Courmont)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat,  7 Jan 2012 21:47:27 -0700
> From: Kelly Anderson <kelly at silka.with-linux.com>
> To: vlc-devel at videolan.org
> Subject: [vlc-devel] [PATCH] Allow for newer a52_init(void) call. take
>     2.
> Message-ID:
>     <1325998047-4299-1-git-send-email-kelly at silka.with-linux.com>
>
> Fix compile with svn://svn.videolan.org/liba52/trunk.
>
> ---
> modules/audio_filter/converter/a52tofloat32.c |    4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/modules/audio_filter/converter/a52tofloat32.c
> b/modules/audio_filter/converter/a52tofloat32.c
> index 2980dd8..ec4a8f0 100644
> --- a/modules/audio_filter/converter/a52tofloat32.c
> +++ b/modules/audio_filter/converter/a52tofloat32.c
> @@ -205,7 +205,11 @@ static int Open( vlc_object_t *p_this, filter_sys_t
> *p_sys,
>     p_sys->i_flags |= A52_ADJUST_LEVEL;
>
>     /* Initialize liba52 */
> +#ifdef A52_ACCEL_DETECT
> +    p_sys->p_liba52 = a52_init();
> +#else
>     p_sys->p_liba52 = a52_init( 0 );
> +#endif
>     if( p_sys->p_liba52 == NULL )
>     {
>         msg_Err( p_this, "unable to initialize liba52" );
> --
> 1.7.8.3
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 8 Jan 2012 14:52:43 +0900
> From: Naohiro KORIYAMA <nkoriyama at gmail.com>
> To: Mailing list for VLC media player developers
>     <vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] [PATCH] Fixed a crash caused by yadif
>     deinterlacer on Windows XP
> Message-ID:
>     <CAOa_K+sQay2ruGuK2JV0xMcsQfvZrWOUPuqTdiXEs61yhHsstw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> The old patch, I sent to vlc-devel ML yesterday, didn't help the crash
> on Windows XP 32bit.
> I was wrong that I tested with the module that was compiled with a
> different patch.
>
> So I made a new patch and tested again
> (before applying old patch, after applying old patch, after applying
> new patch):
> - Windows XP 32bit using XP mode on Windows 7 (win32)
>   NG->NG->OK
> - Windows 7 64bit (win32/win64)
>   OK->OK->OK
> - Mac OS X Lion (intel64)
>   OK->OK->OK
> - Ubuntu 11.10 32bit using VirtualBox (32)
>   OK->OK->OK
> - Ubuntu 11.10 64bit using VirtualBox (64)
>   OK->OK->OK
>
> It's all OK with the new patch.
> But as jb mentioned on the ML few days ago, compiler warnings appear again
> on 32bit builds both Windows and Linux.
>
> --
> KORIYAMA, Naohiro
> nkoriyama at gmail.com
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-Fixed-a-crash-caused-by-yadif-on-Windows-XP-again-57.patch
> Type: application/octet-stream
> Size: 4741 bytes
> Desc: not available
> URL: <
> http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/f2dee75d/attachment-0001.obj
> >
>
> ------------------------------
>
> Message: 3
> Date: Sun, 8 Jan 2012 10:28:24 +0100
> From: John Freed <okvlc at johnfreed.com>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] The case for 2.0
> Message-ID:
>     <CAEVvu1PEz9PEkyx+yRVD3EojiY-L0UKw1YZzcTg6QZ_25JG3_A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Agree with Shelley's points, which go beyond the issue of 1.2 vs. 2.0. A
> roadmap with a target date for a 3.0 is definitely a marketing tool that
> provides an advantage to VLC beyond its quality and availability.
>
> >From a user perspective, a license change in and of itself would warrant a
> major version number. This affects not just how programmers interact with
> the product but also (potentially) the users themselves.
>
> I would also like to suggest adoption of a numbering system similar to the
> Linux kernel, to avoid the "pre-" and ".99" and such in the versions.
> Even-numbered minors are development branches; odd minors are released.
> Thus, the current development (Twoflowers) is 2.0, and when it's released
> it's 2.1. Rincewind would be 2.2, and the released version 2.3. (Or 3.0 and
> 3.1 if need be. On a side note, I generally associate new names, like
> Rincewind, with a major-version bump -- compare Ubuntu, Fedora, etc.) This
> has the advantage of never releasing ".0" versions, which as I have advised
> my clients in the past, should be avoided like the plague. :-)
>
>
>
> On Sun, Jan 8, 2012 at 5:27 AM, <vlc-devel-request at videolan.org> wrote:
> >
> >
> > Message: 5
> > Date: Sat, 7 Jan 2012 17:15:39 -0800 (PST)
> > From: Shelley Horwitz <shelley at sjcomm.com>
> > To: "vlc-devel at videolan.org" <vlc-devel at videolan.org>
> > Subject: Re: [vlc-devel] The case for 2.0
> > Message-ID:
> >        <1325985339.50472.YahooMailNeo at web83701.mail.sp1.yahoo.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > The reason for changing version numbers is as much a Marketing decision
> as
> > it is for features and functions. When versions do not change for a very
> > long time, users do not perceive any improvement in the product itself
> and
> > look for other "more modern" tools with better technology.
> >
> >
> > A good guideline for new versions is once every year. Some products go
> > every six months, some go every 1 1/2 years. A schedule of updates every
> > quarter, and a major release each year gives your users the idea that the
> > development team has a plan. The length of time is not as important as
> > consistency in updating and upgrading on a reasonable schedule. This is a
> > good example of a professional development environment, rather than a
> bunch
> > of hackers tinkering with a new toy.
> >
> >
> > Having such a schedule shows that you have a roadmap for developing your
> > software; it gives your users confidence that this product has a future
> > they can depend on. Continuous release of subversions only to fix
> problems
> > does exactly the reverse. It indicates that the program is going nowhere
> > and even after a long life, still has problems.
> >
> > This issue is about your customers PERCEPTION of the quality and
> longevity
> > of VLC; it is not about how much or how little changes. It is what your
> > users see about the future of VLC. It is what they believe, not about
> what
> > you change.
> >
> > It is time for VLC 2.0. It is time to start planning for all future
> > releases and updates for VLC. It is time to set goals and targets. It is
> > time to develop a ROADMAP!!! It is time to show both your users and your
> > developers that VLC has a future.
> >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/01d4fb83/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 8 Jan 2012 11:52:34 +0200
> From: " R?mi Denis-Courmont" <remi at remlab.net>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] The case for 2.0
> Message-ID: <201201081152.34814.remi at remlab.net>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> Le dimanche 8 janvier 2012 02:15:48 Pierre Ynard, vous avez ?crit :
> > So now we're not talking about just the next release, but all majors
> > releases from now on. Will all following releases bring as many features
> > as Twoflower, and be way beyond and different from the previous one, and
> > feature a license change, to warrant the same number bump?
>
> The current development process has three levels of release (major
> releases,
> bugfix releases and repackaging), yet the versioning scheme has four
> (major
> number, minor number, revision number and optional packaging letter). This
> is
> inconsistent, and that is why this is not the first time we debate whether
> to
> increment the major version or the minor one.
>
> Unless someone has a better idea on how to use the major version number, I
> think it would make sense to use it for stable branches / major release /
> whatever-you-want-to-call-them.
>
> (...)
> > Rather than trying to pin landmarks on an empty timeline, it would be
> > better to plan what big features we want in the next version. The fact
> > that this an opensource project driven by volunteers doesn't mean that
> > we can't at least try to do this.
>
> Feature-based versus time-based. The project history suggests that feature-
> based releases simply don't work because there is not enough commitment to
> finishing features, and time-based releases don't work because there is
> not
> enough commitment to stabilizing branches.
>
> So unless one of you turns into a VLCtropic billionaire, this is screwed
> either way.
>
> --
> R?mi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
>
>
> ------------------------------
>
> _______________________________________________
> vlc-devel mailing list
> vlc-devel at videolan.org
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
> End of vlc-devel Digest, Vol 56, Issue 35
> *****************************************
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/52ff0cf7/attachment.html>