[OpenSER-Devel] [OpenSER-Users] Survey for new mailing list

Henning Westerholt henning.westerholt at 1und1.de
Fri Feb 8 17:30:37 CET 2008


On Friday 08 February 2008, Bogdan-Andrei Iancu wrote:
> [..]
> 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.

(moved to devel list)

Sure, more and understandable user information is a good thing, and i also 
agree with most of the points you've raised above.

But all this is quite a bit of work. So how do you think would be the 
procedure for such a report? Must the developer doing the fix write the 
announcement? Or will this be done from you? How is the severity of a fix 
decided? 

I think that many people, even if they use the stable branch, will not update, 
if they don't encounter a really critical bug. If you're in a production 
environment, then the things moves a little bit slower.

I don't like the idea of creating sub-releases in the stable branch, as this 
will be the result of writing regular announcements about this type of 
changes. Then we would have:

- the trunk which is moving fast and can break every time
- the stable branch, which gets a few commits a weeks and should work
- quasi-releases in the stable branch after every fix above a certain severity
- minor releases for every fix above a certain (higher) severity
- regular minor and major releases

If you want to bear the additional overhead of this new type of release, ok. 
But i think that we should use the well approved approach:

- release regular minor and major releases
- for security problems release immediately a minor release

and better bundle our time and energy for this.

To be honest, we've at the moment not the capacity (or motivation) to 
proofread our release announcements, and writing good user documentation. 
So how do you think this will be work out? ;-)

Henning



More information about the Devel mailing list