[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