Hi all,
I the last year there was a good progress on the project policy regarding releases (major and minor). Still, from my experience as booth developer and user of openser, I feel the need for way to promptly and focused inform the users of openser about the fixes, especially critical fixes, that require immediate update.
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.
Maybe a new list (like "alerts@lists.openser.org") where a developer, after making the fix, can issue (if considered important) an update alert for the interested people : Severity: Affected services/modules: Description: Rev number where the fix is available: How to update: ?
I come to this as right now I'm working at two major fixes in the stable versions affecting two important serviced - user location and accounting. And I bet a lot of people will be interested in this in order to update their installations.
Please let me know your thoughts on this.
Best regards, Bogdan
On Friday 08 February 2008 11:17:23 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.
IMHO it's a good idea. As you say for now is very difficult to know important bug fixes since reading all the commit in dev mailist is a terrible pain for a non avtice developer.
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.
Cheers,
Henning
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
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@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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu writes:
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).
i agree with this. i have never used TAGed releases for generating binaries (debian packages), but always the latest stable branch.
-- juha
IMO a good idea. I think other projects name such lists announce@....
regards klaus
Bogdan-Andrei Iancu schrieb:
Hi all,
I the last year there was a good progress on the project policy regarding releases (major and minor). Still, from my experience as booth developer and user of openser, I feel the need for way to promptly and focused inform the users of openser about the fixes, especially critical fixes, that require immediate update.
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.
Maybe a new list (like "alerts@lists.openser.org") where a developer, after making the fix, can issue (if considered important) an update alert for the interested people : Severity: Affected services/modules: Description: Rev number where the fix is available: How to update: ?
I come to this as right now I'm working at two major fixes in the stable versions affecting two important serviced - user location and accounting. And I bet a lot of people will be interested in this in order to update their installations.
Please let me know your thoughts on this.
Best regards, Bogdan
Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
Bogdan-Andrei Iancu writes:
Maybe a new list (like "alerts@lists.openser.org") where a developer, after making the fix, can issue (if considered important) an update alert for the interested people : Severity: Affected services/modules: Description: Rev number where the fix is available: How to update: ?
good idea, but perhaps Severity and How to update can omitted, since all messages ending to this list should fix a severe problem and update instructions can be found elsewhere.
-- juha
Hi all,
First of all, thanks to everybody who took part to this survey.
Based on the feedback I received from the lists, here is a short resume of the survey: - such a mailing list is a useful tool (exclusively for stable branches) - the implementation of the list must go hand-in-hand with a more often minor releasing : minor releases will be for major bugs and will happen once per months maybe; the list will advertise all fixes!
Still to work on: - should be one way mailing list (standard subscriber will only received without being able to post) ??? - who should push the update emails ?? - what is the lowest severity to be pushed on the list - I guess docs /typos might not be considered fixes ;).
I will start investigating the technical means of putting this list into practice.
Best regards, Bogdan
Bogdan-Andrei Iancu wrote:
Hi all,
I the last year there was a good progress on the project policy regarding releases (major and minor). Still, from my experience as booth developer and user of openser, I feel the need for way to promptly and focused inform the users of openser about the fixes, especially critical fixes, that require immediate update.
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.
Maybe a new list (like "alerts@lists.openser.org") where a developer, after making the fix, can issue (if considered important) an update alert for the interested people : Severity: Affected services/modules: Description: Rev number where the fix is available: How to update: ?
I come to this as right now I'm working at two major fixes in the stable versions affecting two important serviced - user location and accounting. And I bet a lot of people will be interested in this in order to update their installations.
Please let me know your thoughts on this.
Best regards, Bogdan
Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
On Tuesday 12 February 2008, Bogdan-Andrei Iancu wrote:
[..] Still to work on: - should be one way mailing list (standard subscriber will only received without being able to post) ??? - who should push the update emails ?? - what is the lowest severity to be pushed on the list - I guess docs /typos might not be considered fixes ;).
Hi Bogdan,
i think there exists some kind of standard for such a list that is expected from users and followed from many other projects:
- list name "announce" - low volume, a few posts a month, only really important content - must be moderated to prevent spam and abuse
So, going into more detail, i suggest that we use this list to:
- announce minor releases - announce critical fixes for branches (e.g. crashes for important modules) - announce important other events (e.g. a major change in project focus, fundrasing efforts) - the post will be written from the person who has done the fix - the author can post the message first to the devel list, if he wants review or another opinions - if some (non author) developer think that a certain thing should be announced, he needs to start a discussion about this on the devel list
Cheers,
Henning
-
Bogdan-Andrei Iancu -
Greg Fausak -
Henning Westerholt -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Victor Gamov