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" <ase...@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