<div dir="ltr">My idea about this concerns the way we let other people know aboout new features. I usually read our feature plan (e.g. <a href="http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan">http://techbase.kde.org/Schedules/KDE4/4.11_Feature_Plan</a>).<div style>
I think we could add one general page per project, similar to that one, listing:</div><div style>- the feature</div><div style>- the branch where it is developed</div><div style>- the developer</div><div style>- the milestone (eg: kde 4.12, october 2103) where developer thinks to merge/release.</div>
<div style><br></div><div style>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).</div>
<div style>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.</div><div style>
<br></div><div style>Just my 2 cents </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/9 Scott Kitterman <span dir="ltr"><<a href="mailto:kde@kitterman.com" target="_blank">kde@kitterman.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tuesday, July 09, 2013 02:02:48 AM Aleix Pol wrote:<br>
> On Mon, Jul 8, 2013 at 3:04 PM, Àlex Fiestas <<a href="mailto:afiestas@kde.org">afiestas@kde.org</a>> wrote:<br>
> > Now that kde-workspace and kdelibs are going to be frozen (which in theory<br>
> > means less work for everybody) I'd like to propose a new release schedule<br>
> > to<br>
> > be applied starting with 4.12.<br>
> ><br>
> > Basically the idea is to cut testing time and compensate it by keeping<br>
> > master<br>
> > always in a "releaseable" state, now that two major components are frozen<br>
> > it<br>
> > looks like it is a good time to get used to it.<br>
> ><br>
> > You can read all the proposal in:<br>
> > <a href="http://community.kde.org/KDE_Core/ReleasesProposal" target="_blank">http://community.kde.org/KDE_Core/ReleasesProposal</a><br>
> ><br>
> > Before sending this email I have checked with distro people, i18n people,<br>
> > other developers and almost all of them seemed to either like or be<br>
> > neutral<br>
> > about it (only one exception :p) so I hope that the proposal is not a<br>
> > complete<br>
> > disaster.<br>
> ><br>
> > As its name indicates, it is a proposal, so please be constructive in the<br>
> > feedback, we can change as many things as we need.<br>
> ><br>
> > Finally, I have scheduled a Bof at Akademy, would be nice to have all the<br>
> > feedback from the community that is not able to come before it happens:<br>
> ><br>
> > <a href="http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July" target="_blank">http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July</a><br>
> ><br>
> > Cheers !<br>
><br>
> Hi,<br>
> I think this can be an important step forward in KDE. I see here that we're<br>
> essentially adding flexibility to our project delivery, it's something that<br>
> we've missed for longtime and I'd say that we want to use this opportunity<br>
> to our favor.<br>
><br>
> Most of the arguments I see here are technical complaints about such a<br>
> management change. Most of us here are technologists and we can deal with<br>
> those changes. Moreover, we just adopted git and some developers are still<br>
> using it as svn.<br>
><br>
> I think that agreeing upon having a clean and usable master will be healthy<br>
> for all KDE projects, one of the biggest problems I've had as a maintainer<br>
> is lack of future versions' users. We want those, and I know many KDE<br>
> developers who don't test regularly what our users will end up suffering.<br>
> This has to stop. Either way, I hope that our project maintainers will keep<br>
> making sure no unfinished features end up in our final releases.<br>
<br>
</div></div>Getting this workflow firmly in place seems like a reasonable pre-requisite to<br>
the shorter release cycle.<br>
<br>
Scott K<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><pre style="color:rgb(0,0,0);font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;word-spacing:0px;background-color:rgb(255,255,255);font-size:medium">
Andrea Diamantini
WEB: <a href="http://www.adjam.org" target="_blank">http://www.adjam.org</a>

Sponsored by BlueSystems to work on the rekonq project
WEB: <a rel="nofollow" href="http://rekonq.kde.org/" style="color:rgb(0,0,0)" target="_blank">http://rekonq.kde.org</a>
IRC: rekonq@freenode</pre></div>
</div>