Releases in 3 months

[Jaime Torres Amate]

How would the release schedule ( http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule) be in a 3 or 4 mounths release? 1 month for new features, 2 or 3 for bugfixing, translating, language bindings? Or like linux kernel, allways develop new features in other branches, and 1 month to merge them and then fixing?

"Aaron J. Seigo" <aseigo at kde.org> escribió:
>On Friday, July 12, 2013 10:12:41 Andras Mantia wrote:
>> On Thursday, July 11, 2013 06:53:51 PM andrea diamantini wrote:
>> > What about a single official development branch?
>> > Just use two branches:
>> > - master branch (stable)
>> > - kdevel branch (devel)
>> 
>> The natural question to come is: why isn't master the devel branch?
>:)
>
>because when there is no stable branch that tracks pre-release
>development, 
>the # of people testing goes down.
>
>which means there is no branch for people who would othewise like to
>follow 
>development for testing purposes but who need something that is at
>least beta 
>quality all of the time. that means no half-baked features or “this
>currently 
>breaks X, Y and Z” commits.
>
>there is a reason we don’t have more people running master. even many
>KDE 
>application developers do NOT use self-built libs, workspace or other 
>application. with kdesrc-build, time and effort are not the problems. 
>
>one reason for not self-building the libraries is to make sure their 
>application works properly with the current stable libs.
>
>however, i know for a fact (because it’s been said to me many times by 
>developers) that many do not use master because it is too much of a
>stability 
>gamble.
>
>what it comes down to is how much we care about people who would test, 
>document or translate our software being able to track development
>closer.
>
>if we don’t care much about that, then we can continue doing what we’re
>doing. 
>if we do care, we ought to think of ways to make master more stable.
>
>we’ve been able to move a lot more people to testing devel for  Plasma
>Active, 
>for instance, since we adopted such an approach.
>
>
>i also think that you’ll find, if you let yourself, that with git
>working in 
>branches is not only pain free but it often saves a lot of effort. many
>times 
>times i’ve quickly switched to master to fix a bug without first
>finishing the 
>feature set i’m working on; many times i’ve switched to someone else’s
>feature 
>branch to check on progress and try things out before they are fully
>ready, 
>only to then switch back to master or to my own feature branch(es) to
>continue 
>my work.
>
>it’s a small change in how one works, and i know that change is hard :)
>.. but 
>this one is sooooo worth it.
>
>> Ok, let me reformulate again: did we had many breakage in master the
>past
>> time that affected the official releases? Like we realized at
>branching
>> time that master is (heavily) broken and we cannot start a new
>release?
>
>no, we just released with breakage. or freaked out at the last moment
>with 
>people predicting the sky will fall while others work their ass off to
>fix 
>things. 

-- 
Enviado desde mi teléfono Android con K-9 Mail. Disculpa mi brevedad