Some thoughts below ....
Scott Lawrence ha scritto:
On Mon, 2009-06-15 at 20:16 -0700, Todd Hodgen wrote:
It appears that all issues in 4.01 are now cleared up when I look at
the Projects folder. Will there be a 4.01 release, or will there
instead be a 4.02 release?
Yes - the 4.0.1 release will be copied out to the server shortly.
The delay is just because we're setting up a new server for distributing
binaries (we were getting hammered by bandwidth charges on the one they
are on now, so we're moving them to a cheaper place - redirects will be
in place so no URLs need change yet).
We are waiting with too much desire ... Scott please publish it!
We have created a version in the tracker for 4.0.2, but it's mostly a
placeholder for things to be included if possible if&when we decide we
need a release to fix some big bug - it may or may not ever actually
happen.
And to clarify, are all of the fixes in 4.01 included in 4.1?
Yes (or will be).
For a non-customer system, that will be used in office, what would you
recommend – 4.1 to provide testing for the developers, or 4.0X for
testing of the release versions?
I understand there are lots of answers here, my question is focused
more on what helps developers ensure features work, while at the same
time providing a somewhat stable platform to work from?
We are going to try to improve the stability of the mainline (4.1.x)
builds so that they are more usable during development. Ideally, they
will be usable right along, but they will always be significantly higher
risk than the 4.0.x 'stable' builds.
I very much like this approach, but it's still missing what I reckon is
the key of success: fixed release dates.
More details below ...
To this end, significantly more feature work is going to be done on
branches during this release cycle, merging back to main (and thus into
the 4.1.x builds) only when the feature is believed to be reasonably
stable.
Historically, the second biggest source of instability has been
database/upgrade incompatibilities*. Upgrading between development
builds may be a rocky thing.
I spent much time on 3.11. It was quite stable for at least 6 months. I
believe in the rule: upgrade often will keep it stable. When something
arise (startup problems, db changes) will be possibly a small issue and
the one in the team that just did some changes will recognize something
done was preventing the system to upgrade. This will help to find out
details that will eventually bring to a better code. At some point in
the 3.11 development I simply gave up. I see 2 main reasons: incomplete
code introduced in main (starting with sipxsupervisor change); build
system unreliable for months after Nortel acquisition. If you want
someone to test the development branch you have to guarantee reliable
builds. I'm sorry to say this but you don't pay much attention in the
build system. Who is breaking the build should be quickly pointed as the
responsible. The build system itself should not be interrupted for more
than a couple of days, not months like happend. Then some of my past
messages in the dev list where left unheard. Do you want a prove of what
I'm saying? The build status page is still not working. I remember it's
like that since almost the 4.0.0 release. I see the message stating this
in the dev list sent from Tony on May 18th. You can see yourself how
much time passed since that day. Sometimes I feel like messages in the
list don't get the right person and get unheard.
I'd like to hear more discussion from both users and developers on this
- can we keep mainline stable enough for the braver and more skilled of
our users to actually run it all the time? I'm not suggesting that
every single build need be usable, but what update frequency do people
think we could achieve?
I lived on almost all 3.11 development cycle for a very long time for a
very good reason: test features I really wanted to be already in my
stable release but unfortunately were not there yet. I wouldn't do it
again unless some important new features for my deployment will become
again available in the development release. From what I see now I do not
plan to do the same with 4.1. The question you should answer is: "What
will bring our brave users to try our new next release in advance?". The
answer that will work for myself is: your announcement of the next
version of sipxecs being feature frozen and the development team wish me
to test it to find out bugs. It is lots better if this does not happen
with a surprise announcement but in a regular fashion allowing people to
plan their time for this and to simply don't miss the news. Does not
matter how you call it, beta or release candidate, but it should become
such at a fixed date. Same thought for the release date. What I really
see is that the very first release (like 4.0.0 in this case) is really
treated as a beta from some users. I did not take the risk to deploy it
to some productions sites, simply cause bugs I discovered in my test
environment let me feel 4.0.0 is not perfectly reliable. This probably
is you feeling as well cause you wrote in the download page to wait for
4.0.1 before attempting an upgrade. Again many bugs I found while
testing 3.11 were posted from me on the dev list only after what I felt
like the 4.0.0 surprise release. While testing 3.11 I never had the
feeling it was feature frozen, so I always thought "this is going to
change, what is the point tell the world this can be a bug?!". In 3.11
some features changed a lot. Sometimes the first appearance of a feature
was completely rewritten. It's not easy to think what the development
team is thinking if they don't tell you that the work is done and
nothing is expected to change, do you agree?
I like to see shorter release cycle but not necessarily so sort like 3
months as I read in some other discussions. The fact is any major
upgrade is quite a job! Unfortunately I did not have great successes
upgrading to the between major version in the past. This is something
that needs to be refined better. I would suggest there should be an
upgrade beta testing phase. Tell people how to snapshot their production
system in a virtual machine and attempt an upgrade while the code is in
a pre-release phase and I'm sure you will have smooth upgrade with the
stable. Currently this is done from your population of beta testers
mainly with the stable to evaluate upgrade risks, but anyone of us will
do this in it's own way, maybe not addressing issue in a way useful for
the team to point out upgrade bugs. Coordination in this might be useful.
Major release could follow a 6 months cycle. With a month of feature
freeze beta testing. Minor release, could be lot shorter. Well maybe not
as short as Firefox with a new release every couple of days, but I'll
see a 2 week release like a maximum. We are currently waiting 4.0.1 more
than 6 weeks ....!!!!
Alberto
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
