My idea about this concerns the way we let other people know aboout new features. I usually read our feature plan (e.g. http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan). I think we could add one general page per project, similar to that one, listing: - the feature - the branch where it is developed - the developer - the milestone (eg: kde 4.12, october 2103) where developer thinks to merge/release.
Having such a central place to know about others' work could help a lot getting informed (i.e. testing the features you'd like to test and not having master broken cause of feature X development while you are working on feature Y merge) and eventually plan a new KDE SC release (you'll know more or less when people thinks to release new features). If you have interesting new things, people will love a "two months release". On the other hand, releasing every six months just because the scheduler says so grabs out some attention. Just my 2 cents 2013/7/9 Scott Kitterman <k...@kitterman.com> > 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 > -- Andrea Diamantini WEB: http://www.adjam.org Sponsored by BlueSystems to work on the rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
