Releases in 3 months

[andrea diamantini]

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 <kde at 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 <afiestas at 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 at freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130709/1e27267a/attachment.htm>