[MPlayer-users] Next rc or 1.0 anyone

[Heinz Wiesinger]

Nico Sabbi wrote:
> On Friday 27 June 2008 10:57:23 RC wrote:
> > On Fri, 27 Jun 2008 10:16:38 +0200
>>>>What exactly would you want a release manager to do?
>>>>I had a quick look at wikipedia, so I have a rough overview of
>>>>things a release manager could do, but I have no clear picture of
>>>>what would be appropriate for mplayer.
>>>>
>>>
>>> appropriate would be convincing people that mplayer is a
>>> work in progress with absolutely no time schedule,
>>> absolutely unpredictable and aperiodic evolutions, absolutely
>>> no long term strategy and - consequently - 
>>> absolutely no-nonsensical release plan.
>>> Just svn checkout and drop this MANIA of releases.
>>> Releases are  plain stupid, no more no less.

I comment on this at the end :)

>>
>> Grabbing an SVN snapshot is far too much of a crapshoot.  The code
>> is in an unknown state of flux, and very often will not compile for
>> days on end.
>
> very often and for days? We always pay much attention not to break
> compilation, and as fas as I can tell we succeeded

You are right. MPlayer-svn has a very good quality almost all the time.
As far as i can think of I had never problems to compile MPlayer from svn.
(though there might have been one or two issues I do not remember anymore)

>> Freezing development for a few weeks, and just making
>> sure everything works, makes a huge difference, though, obviously,
>> even that it isn't always good enough to avoid significant bugs.
>>
>> Besides that, on many systems, building from source is
>> prohibitively difficult,
>
> no more difficult for a checkout than for a release

Agreed.

>> and MPlayer has a hard enough time getting
>> binaries built for releases, let alone more frequently.
>>
>> Add to that the common routine of developers just dropping or
>> changing options without depreciating the old usage for any length
>> of time,
>
> it doesn't happen as often as you say. I remember very few options
> dropping in several years

I can't think of any options for MPlayer that have been changed in the last 
time, though I do not use very much of them. I experienced some changed 
options in Mencoder, but that is likely to have been caused by changes on the 
codec (x264) I have used.

>> and it's positively impossible for anyone to exchange
>> instructions on how to use MPlayer, without ensuring exact
>> commonality of version.
>
> if users just learned to read ... documentation

Well, yes and no. MPlayer as well as Mencoder are simple tools, as long as you 
want them to do simple tasks. There shouldn't be the need to read any 
documentation for using MPlayer and/or Mencoder to be used for those simple 
tasks, which IS currently the case from my point of view. The documentation 
for harder tasks is also there (as far as I can tell) and I know a lot of 
people do read it. The presence of people not having read it might be caused 
by plain stupidity, lack of time or it is maybe just not presented in a way 
the user can work with it. Of course the first two things can't be changed by 
the developers ;). I'm pretty sure the last thing is somehing which is 
possible to solve though, but might be hindered by a lack of manpower.

>> Eliminating official releases would just force all 3rd parties to
>> make (incompatible) ad-hoc MPlayer releases of their own.

Partially agreed. I can't tell for sure, but I haven't read anything on 
eliminating releases of MPlayer. Even IF this would happen, nobody would 
be "forced" to do anything. NO Distribution is "forced" to include MPlayer, 
nor is it "forced" to update the version currently shipping to a newer one. 
This is actually true for all software shipped with a distribution and 
updates being made are almost always just caused by packagers having time and 
interest in doing it (or users requesting it...sometimes ;) ). Of course this 
behavior will not change, and no one wants it to change. Additionally no one 
stops packagers of various distributions to actually work together 
and "define" their "points in time of mplayer-development" to base the 
packages on, for all distributions, and no, this has nothing to do with 
forking.

Now to my comment on Nico's first paragraph :)
There IS nothing wrong with the current method of MPlayer-development IMHO.
I feel comfortable with it, in fact I can understand your point of view on 
this subject. However, this does not mean releases are stupid. The definition 
of "Release" from wikipedia:

>A software release is the distribution, whether public or private, of an 
>initial or new and upgraded version of a computer software product. Each 
>time a software program or system is changed, the software engineers and 
>company doing the work decide on how to distribute the program or system, or 
>changes to that program or system. Software patches are one method of 
>distributing the changes, as are downloads and compact discs.

Taking this definition I would even think of svn being a method of 
distributing the changes, and in that context a method to "release".
For packagers one could supply compressed snapshots on a regular basis. Using 
a version string like 20080627 would make clear it actually IS a snapshot. 
Using such a numbering-scheme is not uncommon and I'm pretty sure if you part 
with the current one (1.0pre1, 1.0rc1) the number of people asking for the 
actual release of 1.0 will get smaller. You could "publish" those snapshots 
more often and would have nothing to change in the way MPlayer is developed, 
IMHO.

I hope my comments add some sort of value to this discussion :)

Grs,
Heinz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20080627/71a668c1/attachment.pgp>