On Tuesday, July 09, 2013 02:02:48 AM Aleix Pol wrote: > On Mon, Jul 8, 2013 at 3:04 PM, Àlex Fiestas <afies...@kde.org> wrote: > > Now that kde-workspace and kdelibs are going to be frozen (which in theory > > means less work for everybody) I'd like to propose a new release schedule > > to > > be applied starting with 4.12. > > > > Basically the idea is to cut testing time and compensate it by keeping > > master > > always in a "releaseable" state, now that two major components are frozen > > it > > looks like it is a good time to get used to it. > > > > You can read all the proposal in: > > http://community.kde.org/KDE_Core/ReleasesProposal > > > > Before sending this email I have checked with distro people, i18n people, > > other developers and almost all of them seemed to either like or be > > neutral > > about it (only one exception :p) so I hope that the proposal is not a > > complete > > disaster. > > > > As its name indicates, it is a proposal, so please be constructive in the > > feedback, we can change as many things as we need. > > > > Finally, I have scheduled a Bof at Akademy, would be nice to have all the > > feedback from the community that is not able to come before it happens: > > > > http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July > > > > Cheers ! > > Hi, > I think this can be an important step forward in KDE. I see here that we're > essentially adding flexibility to our project delivery, it's something that > we've missed for longtime and I'd say that we want to use this opportunity > to our favor. > > Most of the arguments I see here are technical complaints about such a > management change. Most of us here are technologists and we can deal with > those changes. Moreover, we just adopted git and some developers are still > using it as svn. > > I think that agreeing upon having a clean and usable master will be healthy > for all KDE projects, one of the biggest problems I've had as a maintainer > is lack of future versions' users. We want those, and I know many KDE > developers who don't test regularly what our users will end up suffering. > This has to stop. Either way, I hope that our project maintainers will keep > making sure no unfinished features end up in our final releases.
Getting this workflow firmly in place seems like a reasonable pre-requisite to the shorter release cycle. Scott K
