[OpenSER-Users] Survey for new mailing list

[Bogdan-Andrei Iancu]

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