[OpenSER-Users] Survey for new mailing list

Bogdan-Andrei Iancu bogdan at voice-system.ro
Fri Feb 8 20:36:41 CET 2008


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 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
>>
>>     
>
>
>
>   





More information about the sr-users mailing list