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