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

Fri Feb 19 07:32:14 PST 2010

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> 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> 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> 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 at kickasspixels.com>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
>> 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
>> 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
> 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 <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100219/67e469b1/attachment-0002.html 