Release schedule for Plasma Next

Sebastian Kügler sebas at kde.org
Sat Feb 1 15:13:35 UTC 2014


Hey,

I've let the ideas in this thread sink in for a bit, and have now formed an 
opinion.

On Friday, January 31, 2014 15:57:19 Martin Gräßlin wrote:
> On Friday 31 January 2014 14:34:59 Eike Hein wrote:
> > On Thursday 30 January 2014 18:23:41 Martin Graesslin wrote:
> > > > Is Alpha unstable code? A release that contains known critical bugs?
> > > > why
> > > > do
> > > > we release them? Are distros going to package Alphas?
> > > > Is Beta unstable code? A release that contains known critical bugs?
> > > > why
> > > > do
> > > > we release them? Are distros going to package Betas?
> > > >
> > > > I'm sure that the answer to those questions depends on the user, and
> > > > no
> > > > matter what communication effort we do people will continue having
> > > > their
> > > > definitions of betas and alphas.
> > > >
> > > > Personally I think we should do a number of pre-releases without any
> > > > special name, and the moment we think Plasma2 is stable we tag RC1.
> > >
> > > I like this idea! +1
> >
> > I don't, personally. I think that words have meanings between
> > people, and that names are an opportunity to communicate.
> >
> > "Alpha" and "Beta", while perhaps not the most strictly defined
> > words in the language, have a lot of associated meaning among
> > the members our audience. It gives them utility, e.g. for mana-
> > ging expectations and communicating the relative position of a
> > release in its release cycle.
> 
> Isn't it better to communicate the meaning through our release
> announcements  than through the implied meanings of words like "alpha" and
> "beta"? I just read the wikipedia article [1] for it and from that I assume
> that everybody in our audience has a different expectation and thus we
> cannot meat the expectation if we rely on the meaning.
> 
> I prefer that we are verbose and explain what the current development
> snapshot  means. Whether we call it "beta", "tech preview", "snapshot" or
> "goal" doesn't matter to me. If people complain that the software is
> <insertrandominsultweheardabout4.0>, we can point to the release
> announcement  and show that it holds what we promised.

This might or might not work for development, but for the release team, and 
even more so for the promo team, this sucks. Releases need preparation, and in 
the case of Plasma Next, this is no small amount of work, having no firm 
schedule doesn't help with this at all. Also, it makes it harder to reach out 
since some journalist actually keep an agenda and plan, doing an ad-hoc 
release means we'll simply get less coverage.

Lastly, I think we really need a firm schedule to keep ourselves in check. 
We're really good at finding infinite amounts of "tinkering work", something 
can always be improved, and we're never fully happy.

Having a firm release date, which we only change with very good reason and 
prior discussion prevents all these issues.

That's why I think it's necessary to nail down a clear schedule, and not go 
for "when it's ready".

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Plasma-devel mailing list