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