[OpenSER-Users] Survey for new mailing list

[Greg Fausak]

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 at 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 at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>



-- 
Greg Fausak
greg at thursday.com