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. _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
