[Freeswitch-users] 1.0.4 vs. trunk vs. bugs

Tristan Mahé t.mahe at telemaque.fr
Fri Feb 19 08:19:37 PST 2010


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 at rupa.com
> <mailto:rupa at 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 at jerris.com
>     <mailto:mike at 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 at freeswitch.org
>         <mailto:brian at 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 at kickasspixels.com>lon at kickasspixels.com
>>>>         <mailto:lon at 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 at lists.freeswitch.org
>>         <mailto:FreeSWITCH-users at 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 at lists.freeswitch.org
>         <mailto:FreeSWITCH-users at 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 at lists.freeswitch.org
>     <mailto:FreeSWITCH-users at 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 at hotmail.com
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
> 
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> <http://iax:guest@conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org




More information about the FreeSWITCH-users mailing list