[asterisk-dev] Asterisk 1.6 Release Management Proposal

[Russell Bryant]

BJ Weschke wrote:
> 3.2.1    Small new feature
> 
> Commit directly to trunk.

>   However, with the respect to the above statement, I don't think I
> agree with this mentality. This seems to go against any concept of any
> kind of SDLC and seems to contradict other parts of the document.
> While I agree that it is what has been standard practice in the past,
> I read this document (and maybe I misread it) that we're making an
> attempt now to make trunk more of a "golden" copy of all things
> accepted vs. the "playground/sandbox/litter box <-- take your pick of
> WHAT you want to call it. :) " it is now.  If that's the case, and I
> agree with the cause there, then anything and everything I think
> should go through some sort of review/consideration before making its
> way into trunk.

I'm not sure I really agree that trunk is treated as a playground.  I think that
the development team has been very good about only merging things into trunk
once they are deemed complete.  The adoption of team branches has really helped
with this.

Also, when I say "small new feature", I'm talking about something that is
trivial.  I also have in mind that anyone with commit access to trunk knows what
is acceptable in regards to adding trivial new features.

I am also happy with how most people usually consult this mailing list before
merging things that are really large into trunk.  For now, I'd like to just
continue to encourage using this list if there is any doubt as to whether
something is a good idea, or if it needs code review before merging.

If all else fails, we can revert things.  :)  I just don't want to introduce any
more process than is really necessary ...

>    Also, that all being said, if this is how we want to treat trunk
> going forward, what migration process will be defined for moving trunk
> from what we've all accepted it to be now (pick your favorite word for
> it up above) and get it to where we want it to be?

Well, there are a couple of things that come to mind here.

First, the development team must really buy into the idea and just keep in mind
that whatever goes into trunk will be going into a real release within a month
or two.  So, we must be mindful of how many extremely invasive changes go in at
the same time, and to what areas of the code.

Second, we have to do whatever we can to improve testing of releases.  Part of
the success of 1.6.X releases will rely on the community helping out with the
testing efforts.  This also makes it easier to bring more people from the
Asterisk user community into the development community if we make it easier for
people to test out new things by getting them into releases sooner.  If we can
continue to do better testing of the new additions in smaller increments, then
Asterisk will be much more stable in the end.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.