Hi Greg,
each time I prepare the release I forget to enable the -DNO_BUG flag ;)....my short memory :)....
Regards, Bogdan
Greg Fausak wrote:
Hey Bogdan,
Can we just get a release that doesn't have any bugs?
Just kidding :-)
I think a new list is a good idea.
-g
On Feb 8, 2008 9:39 AM, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Henning,
Henning Westerholt wrote:
On Friday 08 February 2008, Bogdan-Andrei Iancu wrote:
[..] Many project have lists where you can subscribe in order to get notification for critical bug or security fixes. Currently, for openser, if you are not subscribed on devel list and if you are not "good" enough in "decrypting" the commit logs, you may miss important fixes you may want to update.
I think is our duty as project to inform the users about the discovered flows in the stable versions. My suggestion is to create a new mailing list where, who is interested, will receive notifications when something critical was fixed in the stable versions of openser. [..]
Hi Bogdan,
good points. Such a list would be surely a good thing. But i don't think this is exactly what we need. If somebody choose to run a openser version from the stable branch, he must monitor the devel list for importantant changes in this branch. This could be easily achieved with some filtering. If there are understanding problems with svn commit messages, we should improve them. Remaining questions could be easily be resolved on the devel list.
But distributions and many users don't use the stable branch as base for their usage, the rely on stable releases.
So if a really critical fix is merged into the stable branch, e.g. a security fix, then we should immediately release a new minor release that includes this fix. Otherwise the user which don't have the knowledge or the time to run from the stable branch will be left in the cold.
So, my suggestions are:
- implement a regular release schedule for minor releases, e.g. every 2 months
- release immediately for _really_ critical fixes
- add a new list, called "announce" for announcements for new releases
This policy is implemented from many successful other projects. This way people running stable or from the branch know that there was a cricital fix, and that they should update.
I see some issues in this approach.
But firstly, I agree that more often minor releases will be good.
Now, the issues I mentioned:
I see no advantage of pushing the fixes via minor release. A minor release is just a TAG and a source tarball - none of this help, as you still have to go compile stuff locally (sources from tarballs or from SVN, it's the same).
We cannot do minor release for each fix - there may be highly critical, critical, medium or low as severity and we will end up with a release at each day :)
I thing people are using branches and not tags from SVN - the branch simply gives you the latest version from a major release, and as there are only fixes, there are no reason not to update (1.2.0 -> 1.2.1 -> 1.2.2 -> 1.2.3). So, a simple SVN update solves the problem in most of the cases. Also we need to take into consideration the fact that there are people using "blended" openser, so they can update only via patches ;)
Whatever we do, we need to accept that developers will never put very explanatory logs into commits (developers speaks their own language when comes to code, language which is not understandable by users) - like for cars - technicians use their language which is not supposed to be understood by driver/client ;)
Going back to my original idea - what I wanted to provide is: - a fast way to provide detailed, handy, end-user (human) readable, reports on the latest fixes, as soon as possible. - provide notes for all fixes (not only the one we really decide are important enough to trigger a minor release) - interface between the developer logs and understandable report for the users - indication about the possible ways to update (rev number, patches, etc) - this doesn't exclude your idea of minor releases for major fixes.
Regards, Bogdan
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users