As anyone knows, I am in favour of frequent releases to let packagers make good packagers and allow end-users with no compilation skills (which are becoming a majority in GNU/Linux world) upgrade and benefit from bug fixes. JB was thinking of a release every two months. In my opinion, given the large number of bug fixes, this could well be one release every month during several months. One month to wait for a bug fix is a long time.

Also, whenever a targer release date is passed, I propose to postpone all new feature to a subsequent release and make a Kdenlive release. My opinion...

Kind regards,

Jean-Michel

I think one every month is too frequently. Sometimes the dev needs to breathe a bit :-)

I partly agree in the thing about not letting outstanding issues block a release. However, this only counts for non-critical stuff. Sometimes we may have had a regression, which causes crashes, or something, and we should respect those as blockers for a release.

Regards and Merry Christmas/Happy Holidays all.

>Sometimes the dev needs to breathe a bit :-)

This is a packaging issue. If you release every two months, packagers will not take care for packages and will not publish good packagers. To maintain quality, you need frequent releases.

Also, without packages, no bug fixes. If you like being stuck on IRC supporting users liker yesterday, then stick to your point of view and you will stay on IRC trying to understand what is going on.



The rules of Free Software are:

* The packagers wron't move until there is a release.

* The users wron't install from source, they use packages.

* Users will contact you immediately on IRC or on the forum when there is a problem, without lookin at Mantis.

Realeasing software is not hard for main hackers. You just make a tarbal and that's it. One month later you publish another tarbal. So what the hell are you referencing to? Who needs to breethe? You or the 20.000 users waiting for upgrades and loosing thousands of hours on their laptop.



I don't quite understand Mads...

Whoa there tiger, don't get carried away :-)

In my opinion, releases is slightly more than just tagging the SVN and rolling a tar ball. Some sort of quality assurance needs to go into to it too. Obviously we are not talking about a bug free release, but for example, take the spacer tool in current svn: http://www.kdenlive.org/mantis/view.php?id=271 . I *think* it would be a mistake to make a release *right now* with the spacer tool in the condition it has. Obviously its a huge improvement from 0.7.0, but the issue with not "snapping" would mean that we would get frustrated users, that keeps missing frames from clips they thought was aligned.

Thats my opinion, anyway. You can turn it around and ask: "Can all new features be implemented to a state where its tolerable to release them to users, within a month?". If the answer is no, I think a month is too short, *OR* new features needs to be implemented seperate from the branch from where releases are made; features need must be merged to the release branch before releases, with all the tedious work related to that.

Re breathing: Is was just thinking that every scheduled release puts a pressure on the devs (this is jb I think of) to add something of value to the release. After a release crunch, jb just might need to rebound before a new release looms in the horizon.

Also, for any changes to MLT, you need to have Dan do an MLT release too.

But, you do not need to argue this with me - jb and dan really should decide this.

Regards

Mads

From my perspective (recently into video editing, but been using linux for a few years as a user, not developer), releases should not be put out so frequently.  What I think works well for me and what might help get more testers engaged is:

-I want the newest features, but prize stability and dependability more highly. I think most users would want to have this rather than the latest 1 month old feature.  Unstable releases will do more harm than good to the reputation of the project.

-I don't mind doing updates, but I'm not into updating every month.  I only do one short project per month as I accumulate footage of my kid running around.  I don't really want to update the software for every new project.

-Clearly notify us intermediate users when the svn is in good shape and approaching RC status. I would be glad to test and report bugs or wishes.  I don't really want to be involved with anything lower than late beta or RC testing. It's hard to know the stability at this point.

-Make it easy to build, with clearly communicated dependencies and other issues.  Mads has done a great job on the builder wizard and help on the forums.

-Provide time for bug testing and fixing. 

-I would think that a goal of releasing a tarball every 3 months or so would be more useful.

I think digikam project is a good example of a well run project.  They for the most part stick to their schedule and clearly notify when things are beta, RC or stable.  There is always a few weeks of RC status to get the release ready.  I have been a tester and bug reporter for digikam for a year or more now mainly because I like their attitude, progress and attention to detail. 

Please take this email as being constructive.  I think kdenlive 0.7 was very good and want to see and help with any improvements.

Geoff

To make is short:

• No seperate branch. FFMpeg and MLT have no branches and are always usable.


• I am running Kdenlive, MLT and FFmpeg trunk and it is much more stable than versions from 3 months old. @Mads: you are running trunk too. So you are not complaining. Maybe some users would like to benefit from frequent release, no?


• Packages on some platform are of unknown state because packagers are not motivated. Frequent releases oblige packages to make a good job.


• When I mean a relase, I could be kdenlive 2008-12-24. And that's it. Packagers make packages for FFmpeg, MLT and Kdenlive at a precise date. There is no work rolling out tar.gz. This is only a simple message on a web site.

This being said, I have to review packages and I say bye-bye.

@geoffrey: MLT svn allows to make static builds including FFmpeg a static library. This allows for unstable releases at a precise date or SVN revision.

In a near future, we will only need to package MLT and Kdenlive. I prefer DEB and RPMs to wizards. 

So this opens the door to more frequent releases.

If a release is defined as software that is maintained via the forum and mantis bug reporting, then the frequency of release as of today is ok.



However, as a user affected by bugs, I would want to try the latest kdenlive software without having to know anything about building it from source via wizards or otherwise. I think most users feel the same.



You could make the latest builds available in binary form ready to use in the same or similar way as for formal versions, e.g. via deb http://ppa.launchpad.net/baudm/ubuntu intrepid main. Totally unsupported of course. Make many available, for example one month's worth, and let user choose by build number or clicking in a listbox in the GUI of a webpage.

 

maybe you could do it like inkscape, have an "official" release totally stable, and then have from time to time snapshots release when some new feature is available for testing untill next stable release. the stable release could be every 2 or 3 months, the snapshot release could be once or twice a month, and the for those who want to work every day with the bleeding edge they still have the wizzard solution.