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 <[EMAIL PROTECTED]> 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 >> [email protected] >> http://lists.openser.org/cgi-bin/mailman/listinfo/users >> >> > > > > _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
