[asterisk-dev] Release schedule ?

[Russell Bryant]

Luigi Rizzo wrote:
>     [This email is addressed to whoever decides on the release process
>     for asterisk - i am unclear if this is (as i hope) a "release
>     engineering team" as in other projects i am involved in, or it is
>     a "community decision".]

It is supposed to be more of a "release engineering team".  The way it works 
right now is that Kevin gets to decide when we make a major release, such as 
1.4.  Then, I have carried the title "release branch maintainer" for a couple of 
years now, but what that means in practice has changed over time.

It used to be that all development (bug fixing and features) were focused on the 
the development branch, and then I would go through all changes manually and 
manually patch the release branch with bug fixes.  That was Asterisk 1.0.  For 
1.2, putting bug fixes into the release branch has been done by the entire 
development team, so my position was just to make decisions when it was 
debatable about what should be put in 1.2, or whether a change was only 
appropriate for the trunk.

> I would like to know what is the planned schedule for 1.4.0,
> so that developers like me could know how to focus their work within
> their available time.

For Asterisk 1.4, we attempted at setting a release schedule.  However, the 
release was supposed to be many months ago.  That failed miserably.  One one 
had, we had a schedule we wanted to meat, on the other hand, we had a large set 
of features that we wanted to finish before Asterisk 1.4 was released.  The 
decision was made to put it off until we finished the features we wanted to 
include.  That has, for the most part, been done now.

> It seems that the beta period has been going on for a very long time,
> yet not having a deadline for the release makes it very hard to
> organize work.

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.

> With the above in mind, I would suggest the following:
> 
>  - settle on a very short deadline (e.g. 1-2 weeks, really no more)
>    for getting 1.4.0 out, possibly with a notice to users on the
>    "stability" of the release.
>    This would let developers find some motivation to work on critical
>    issues for getting 1.4.0 out.

I think a short timeline is a good idea.  My vote goes for creating another beta 
tarball in the immediate future, and leave a final 2 weeks for making any 
further fixes for 1.4.0.

>  - lift the 'no new features' ban for 1.4.1, so developers could backport
>    fixes and backward-compatible features from trunk without wasting
>    the extra time to remove the 'new features' part (something that
>    could discourage even trying to backport the fixes);

I would be happy to address these on a case by case basis, but not an overall 
statement to lift the ban on new features.

>  - schedule 1.4.1 (or 1.4.2 if you like) for end of january to get
>    a more stable release in this branch.

In the past, we have generally not let much more than 6 weeks or so go without 
doing another sub-release, so I think this would be a reasonable timeline.  For 
the first few releases of 1.4, I would expect that we create new tarballs every 
3 or 4 weeks.

In the end, when we release 1.4.0 is up to Kevin.  Hopefully he can post a list 
of the goals to reach before it is released.  Then, we can set a final deadline 
for getting this stuff finished.

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.

-- 
Russell Bryant
Software Engineer
Digium, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: russell.vcf
Type: text/x-vcard
Size: 266 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20061110/13c7ff26/russell.vcf