[vlc-devel] A respectful disagreement...

Shelley Horwitz shelley at sjcomm.com
Sun Jan 8 13:06:31 CET 2012


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.



________________________________
 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
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/19c53e0b/attachment.html>


More information about the vlc-devel mailing list