[asterisk-dev] Release schedule ?

[Kevin P. Fleming]

Russell Bryant wrote:
> I agree.  I think Kevin has a list of things he wants completed before
> 1.4.0 is released.  Hopefully, he'll post that list to this thread.

Right now that is re-working the SLA code (which I will be spending
nearly all my time on tomorrow and Thursday), and fixing whatever bugs
can be fixed. We have a report of an app_voicemail bug found by our BE
team that needs to be addressed, and the fix is rather complex so there
are only a few people who have the skills to do it quickly.

Unfortunately I have absolutely no idea what the state of the 'known'
bugs in the bug tracker is; I'm afraid if I spend any time looking there
I'll find plenty of reasons not to make a release.

> After 1.4.0 is finally over with, I think it is worth continuing
> discussion about our release process.  The way we did it this go around
> hasn't been so great.  The part that hurt the most, in my opinion, is
> that we stuck with the original schedule in terms of "architecture
> freezes" and "feature freezes", but not in making the actual release. 
> That means that our development branch spent probably half of 2006 in
> some degree of freeze.  That really stalled development.  Also, I think
> this painfully drawn out process has hurt morale in the development
> community a bit, as well.  Asterisk is my only experience in a large
> open source project.  I would be interested in learning about the
> processes used within other projects to see how we can improve the way
> we do things for the next development cycle.

I think the biggest problem we had is that we committed to too many
features going into this release, before they were actually ready to be
merged. If you look at the presentations done at Astricon regarding new
functionality in 1.4 (which were not even complete), the list was quite
long, probably much more than should have been attempted.

In other words, either we continue adding this much new functionality
between major releases and live with the fact that it will take 9-12
months to make releases, or we bite the bullet and make the decision to
start the release process even without functionality we wish to have in
place. Coupled with more people spending time doing code reviews
(especially architectural reviews) and moving new feature patches along
the merge track, we should be able to do a better job than we have done.