Jason, Yes. I saw that. But, quite a few times I have found the trunk unstable or broken. Its why I'm proposing the changes. To be clear, I'm not in anyway impugning the quality or expertise of the dev team. They are doing amazing work! I'm looking down the road. As the project grows and FS becomes a critical piece of any company's infrastructure a clear distinction between "stable" and "development" branches are pretty standard in project the scope of FS. Lon On Feb 18, 2010, at 5:51 PM, Jason White wrote:

Lon Baker <lon@kickasspixels.com> wrote:

...

The development branch is where feature requests and non-critical bugs reports would be filed for the next production release.

The current process leaves a gap between production ready and development code that may become greater over time.

Did you read the statements by FreeSWITCH developers indicating that the svn trunk is usually more stable than "released" versions, and that this is at least partly due to a lack of testers/testing prior to release?

A change of policy isn't going to address those underlying problems.

For the record, I don't favour the proposed change.

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

I'll drop it. You're right they don't last long. I didn't open bugs because I assumed the trunk is being worked in, so breakage is something I expect and anywhere from minutes to a few hours later they are gone. Lon On Thu, Feb 18, 2010 at 6:35 PM, Brian West <brian@freeswitch.org> wrote:

In the grand scheme trunk isn't unstable or broken for long... this is just downright false.  If it was why aren't you opening bugs?

We have had a few snafu's but again they don't stay long.

/b

On Feb 18, 2010, at 8:28 PM, Lon Baker wrote:

...

Yes. I saw that. But, quite a few times I have found the trunk unstable or broken. Its why I'm proposing the changes.

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Brian, Didn't intend to step on any toes. I do open bug reports, have submitted patches and have someone on my team who does contribute to the docs/wiki. If the team wants to maintain a stable trunk I will try to find a team member to help manage it. If there is a philosophical reason for not doing it, I'm fine the current process. Whatever helps the dev team. You guys do a great job and its a pleasure to work with freeswitch. Lon On Feb 18, 2010, at 7:36 PM, Brian West <brian@freeswitch.org> wrote:

We usually don't go to bed if its not fixed... I recall many times I was up at 2am dialing digits and testing while Anthony was coding the fix bugs... its part of what we do and shows just how dedicated we are to this project and how picky we are about the code.

/b

On Feb 18, 2010, at 8:53 PM, Lon Baker wrote:

...

I'll drop it. You're right they don't last long. I didn't open bugs because I assumed the trunk is being worked in, so breakage is something I expect and anywhere from minutes to a few hours later they are gone.

Lon

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch- users http://www.freeswitch.org

Lon Baker <lon@kickasspixels.com> wrote:

I'm looking down the road. As the project grows and FS becomes a critical piece of any company's infrastructure a clear distinction between "stable" and "development" branches are pretty standard in project the scope of FS.

I would rather that the developers spend time fixing bugs and implementing new features instead of backporting changes to a "stable" branch that may be very outdated. One way of managing this is the Linux kernel's model, with short development/release cycles, where there is only one branch. (There are short-lived "stable" branches as in 2.6.32.1, 2.6.32.2 etc., but my understanding is that bug fixes destined for those branches must already have been applied to the development branch destined for the next release; this minimizes back-porting of fixes.) I'm sure there are other models. My essential point is that, so far, the FreeSWITCH developers have not chosen to maintain long-lived "stable" branches, that there are alternatives to this approach, and that it has its downside, especially regarding the extra time/effort/work associated with maintaining it.

The one thing I'm going to stop doing is helping anyone unless they write docs. I can't count the times I have helped someone with the promise they would write docs. They get what they want and move on... its selfish and rude. The same goes for a stable branch... it seems its wanted/demanded but again nobody steps up to help with it. I have been at this for over 14 hours today and yet still have a stack of stuff to do that keeps growing. I thank each and everyone that helps out... I truly enjoy having you all involved. Thanks, Brian On Feb 18, 2010, at 8:53 PM, Jason White wrote:

I'm sure there are other models. My essential point is that, so far, the FreeSWITCH developers have not chosen to maintain long-lived "stable" branches, that there are alternatives to this approach, and that it has its downside, especially regarding the extra time/effort/work associated with maintaining it.

Lon Baker <lon@kickasspixels.com> wrote:

...

The development branch is where feature requests and non-critical bugs reports would be filed for the next production release.

The current process leaves a gap between production ready and development code that may become greater over time.

Going against the grain here, I agree with you. The current way of doing things is, in my opinion, not well thought through - there's no reason to tag and release versions if the answer to any issue is 'make current', and support is not available unless that's been done. Far better to either have meaningful releases with stable and devel branches, or not to have releases at all. --Dave

How many more ungrateful complaints can we get in one night.... sigh On Feb 18, 2010 10:21 PM, "Brian West" <brian@freeswitch.org> wrote: OK so I can sign you up for the stable team? ;) As per my previous email i'm 100% sure we would do a stable release if we had people tending to issues. The only problem is you would have to be on IRC tending to issues because if tony sees someone asking about a problem he'll be diving in to fix it before they can say "I have this one". This also means working in a similar manner we do already. Our process is very chaotic at times but it has served us well so far. The goal is to leave Anthony alone so he can move forward and let the stable team manage the jira's and issues on the list related to stable. /b On Feb 18, 2010, at 10:10 PM, David Knell wrote:

...

Lon Baker <lon@kickasspixels.com> wrote:

...

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

I would caution that maintaining a stable branch is going to be quite challenging. All commits against trunk will fall into 3 categories: 1) clearly bug fix 2) clearly new feature 3) a mix of the two 1 can probably be easily back ported and 2 would be not but what of 3? We don't split patches/commits based on a clear split between 1 and 2 so it would be the job of the stable maintainer to figure it out, split it up and then commit just the bug fix part. I would argue that the churn in the stable branch would be sufficient to make it a moving target just like trunk, just slower moving and one step removed from tony ensuring everything is up to his standard. I would also argue that at some point this project will clearly go from "balls to the wall" development like now (lots of bug fixes and new features all the time) to something more sane as it matures. At some point going to stable/dev might make sense. Another thought. Look at how the linux kernel is developed now. There is linus's branch which is essentially unstable. It is the vendor's (distro) job to pick a line in the sand and keep that kernel rev stable. There is help from people that have stepped up and maintain a "stable" kernel branch, but that has nothing to do with the mainline development. I can appreciate the pain that some people have with dealing with production systems where you want stability above all else. In reality you don't want stability, you don't want surprising behavioral changes. You want code that doesn't change except in those areas that fix bugs in components that you use. But your component set and mine are different. Once you are accepting bug fixes for all components, the set that changes can churn quite a bit. Anyway, just some food for thought. I know that if I had to double commit (or at least consider double committing) every piece of code I'd get frustrated quickly. On Fri, Feb 19, 2010 at 1:17 AM, Michael Jerris <mike@jerris.com> wrote:

This seems a good time to note that we are still looking for volunteers to assist in maintaining a stable branch. I can not do this without additional volunteer resources. We have asked several times recently to fairly silent response. If anyone is interested in assisting with this effort, please contact me offlist and we can discuss further.

Mike

On Feb 18, 2010, at 11:16 PM, Brian West <brian@freeswitch.org> wrote:

OK so I can sign you up for the stable team? ;) As per my previous email i'm 100% sure we would do a stable release if we had people tending to issues. The only problem is you would have to be on IRC tending to issues because if tony sees someone asking about a problem he'll be diving in to fix it before they can say "I have this one". This also means working in a similar manner we do already. Our process is very chaotic at times but it has served us well so far.

The goal is to leave Anthony alone so he can move forward and let the stable team manage the jira's and issues on the list related to stable.

/b

On Feb 18, 2010, at 10:10 PM, David Knell wrote:

Lon Baker < <lon@kickasspixels.com>lon@kickasspixels.com> wrote:

The development branch is where feature requests and non-critical bugs

reports would be filed for the next production release.

The current process leaves a gap between production ready and

development code that may become greater over time.

Going against the grain here, I agree with you. The current way of doing things is, in my opinion, not well thought through - there's no reason to tag and release versions if the answer to any issue is 'make current', and support is not available unless that's been done. Far better to either have meaningful releases with stable and devel branches, or not to have releases at all.

--Dave

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- -Rupa

Hi Anthony, As I said to Mike offlist, You can count on me for some help, not full time badly, as I only have very little free time ( yep you did/freeswitch is a much too awesome piece of code ;) ),: backports/automated tests/some resources like boxes, I already said on IRC that you just have to ask... I follow carefully every commit to the project ( viva fs-trunk ML ), so helping on identifying bugfixes and backporting them ( or at least keeping track of what should be backported ) is a task I can help on... For my part, I must say that I LOVE the 'make current' way, when I need stable, I just stick to a specific svn rev I've fully tested. I understand the need for a stable release for some people in the other hand... My 2cents on this subject: As long as you and the people involved don't focus on maintaining a 'stable' branch, which would obviously slow down future improvements, and keeps working like you did for all these years, adding a 'test field branch' for instant commits is great to ensure trunk don't get broken the time you fix it. This is a great compromise, with few overhead of work. Regarding the labelling versions, it might also be quite a nightmare: When do you branch ? new features ? new behaviour in code ? That would require strict labelling rules that might add you some overhead of work again, slowing things down. Hope a team will arise for those people needing labels, that would carry this work, and let you follow your journey on trunk without bothering with theses issues, I would definitively give a hand to help on this if needed... Regards, Gled Anthony Minessale a écrit :

Here's the deal.

This is a community project and its public but it only has a small group individuals who are "all-in" committed to the project. I am the one who started the project and who had to spend a solid 2 years completely alone working towards my goals before others even showed interest.

Now we are growing very fast, we have a lot of feedback and we listen to it regardless of our position on the subject and I will decide and make any policy that I choose and feel is the best interest of this project.

It's reasonable that someone who is using the software wants to have wonderful stable stepping stones to migrate towards the future on. It's also customary that most software, even when you pay a premium price for it, does not meet those standards every time. If you do find software that has these graceful releases, they probably have a lot of people getting paid to work diligently on it. There are also many successful open source projects with shiny revision numbers and packaged up with a bow but that is because they have a dedicated team of people.

So, we don't have that long list of people. We invited people to do it and we had nobody step up. So, this is what i am planning to do:

We are going to move our development to a branch, work on it from there and push them down to trunk when we think its the best time. This might not always end up perfect but this is what we are going to do. The actual release versions are still just fancy road signs in a long journey towards perfection. We are still on 1.0 for almost 2 years with 5 micro release that contain a 12 page change log each time. We are as careful as we can be about releases and we have no time to try to back-port patches to 6 month old code with more than 2000 revisions in between them.

When we feel we are happy with 1.0 we will then branch to 1.1 and all this stuff everyone wants, *IF* we get enough volunteers by that time to dedicate their time to maintaining it. If not we will make the best of what we have........

This is the final word on this subject, feel free to quote me.

On Fri, Feb 19, 2010 at 8:21 AM, Rupa Schomaker <rupa@rupa.com <mailto:rupa@rupa.com>> wrote:

I would caution that maintaining a stable branch is going to be quite challenging. All commits against trunk will fall into 3 categories:

1) clearly bug fix 2) clearly new feature 3) a mix of the two

1 can probably be easily back ported and 2 would be not but what of 3? We don't split patches/commits based on a clear split between 1 and 2 so it would be the job of the stable maintainer to figure it out, split it up and then commit just the bug fix part.

I would argue that the churn in the stable branch would be sufficient to make it a moving target just like trunk, just slower moving and one step removed from tony ensuring everything is up to his standard.

I would also argue that at some point this project will clearly go from "balls to the wall" development like now (lots of bug fixes and new features all the time) to something more sane as it matures. At some point going to stable/dev might make sense.

Another thought. Look at how the linux kernel is developed now. There is linus's branch which is essentially unstable. It is the vendor's (distro) job to pick a line in the sand and keep that kernel rev stable. There is help from people that have stepped up and maintain a "stable" kernel branch, but that has nothing to do with the mainline development.

I can appreciate the pain that some people have with dealing with production systems where you want stability above all else. In reality you don't want stability, you don't want surprising behavioral changes. You want code that doesn't change except in those areas that fix bugs in components that you use. But your component set and mine are different. Once you are accepting bug fixes for all components, the set that changes can churn quite a bit.

Anyway, just some food for thought.

I know that if I had to double commit (or at least consider double committing) every piece of code I'd get frustrated quickly.

On Fri, Feb 19, 2010 at 1:17 AM, Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:

This seems a good time to note that we are still looking for volunteers to assist in maintaining a stable branch. I can not do this without additional volunteer resources. We have asked several times recently to fairly silent response. If anyone is interested in assisting with this effort, please contact me offlist and we can discuss further.

Mike

On Feb 18, 2010, at 11:16 PM, Brian West <brian@freeswitch.org <mailto:brian@freeswitch.org>> wrote:

...

OK so I can sign you up for the stable team? ;) As per my previous email i'm 100% sure we would do a stable release if we had people tending to issues. The only problem is you would have to be on IRC tending to issues because if tony sees someone asking about a problem he'll be diving in to fix it before they can say "I have this one". This also means working in a similar manner we do already. Our process is very chaotic at times but it has served us well so far.

The goal is to leave Anthony alone so he can move forward and let the stable team manage the jira's and issues on the list related to stable.

/b

On Feb 18, 2010, at 10:10 PM, David Knell wrote:

...

...

Lon Baker < <mailto:lon@kickasspixels.com>lon@kickasspixels.com <mailto:lon@kickasspixels.com>> wrote:

...

The development branch is where feature requests and non-critical bugs reports would be filed for the next production release.

The current process leaves a gap between production ready and development code that may become greater over time.

Going against the grain here, I agree with you. The current way of doing things is, in my opinion, not well thought through - there's no reason to tag and release versions if the answer to any issue is 'make current', and support is not available unless that's been done. Far better to either have meaningful releases with stable and devel branches, or not to have releases at all.

--Dave

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- -Rupa

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900

------------------------------------------------------------------------

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

there's no reason to tag and release versions if the answer to any issue is 'make current', and support is not available unless that's been done. Far better to either have meaningful releases with stable and devel branches, or not to have releases at all. Well, the response on a stable version about a bug report that's been already fixed would be: "apply this patch and retest, come back to us if problem persists" Isn't that exactly what make current does? This way of developing may be not broken-trunk-proof, but from your comment I think an easier way to approach Lon's suggestion would be making a more understandable way for simple users (not fs devs) to check what modules have been altered from their version to the latest, in order to check if an issue has been solved or not, as of those clients that only want "released versions", that's the hard part. ps: hmmm Anthony's message makes my post outdated but i spent a lil bit of thought on it so i post anyways ^^ -Milena 2010/2/19 Michael Giagnocavo <mgg@giagnocavo.net>

Maybe something that could work is a simple way for people to record the SVN number and config they’re using. It might encourage people to not get so stuck up on a released version number. And once they’re more comfortable with SVN, perhaps they’ll try head more often.

-Michael

*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Michael Jerris *Sent:* Friday, February 19, 2010 12:18 AM

*To:* freeswitch-users@lists.freeswitch.org *Subject:* Re: [Freeswitch-users] 1.0.4 vs. trunk vs. bugs

This seems a good time to note that we are still looking for volunteers to assist in maintaining a stable branch. I can not do this without additional volunteer resources. We have asked several times recently to fairly silent response. If anyone is interested in assisting with this effort, please contact me offlist and we can discuss further.

Mike

On Feb 18, 2010, at 11:16 PM, Brian West <brian@freeswitch.org> wrote:

OK so I can sign you up for the stable team? ;) As per my previous email i'm 100% sure we would do a stable release if we had people tending to issues. The only problem is you would have to be on IRC tending to issues because if tony sees someone asking about a problem he'll be diving in to fix it before they can say "I have this one". This also means working in a similar manner we do already. Our process is very chaotic at times but it has served us well so far.

The goal is to leave Anthony alone so he can move forward and let the stable team manage the jira's and issues on the list related to stable.

/b

On Feb 18, 2010, at 10:10 PM, David Knell wrote:

Lon Baker <lon@kickasspixels.com> wrote:

The development branch is where feature requests and non-critical bugs

reports would be filed for the next production release.

The current process leaves a gap between production ready and

development code that may become greater over time.

Going against the grain here, I agree with you. The current way of doing things is, in my opinion, not well thought through - there's no reason to tag and release versions if the answer to any issue is 'make current', and support is not available unless that's been done. Far better to either have meaningful releases with stable and devel branches, or not to have releases at all.

--Dave

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org