Release schedule for Plasma Next
sebas at kde.org
Sat Feb 1 15:13:35 UTC 2014
I've let the ideas in this thread sink in for a bit, and have now formed an
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  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".
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
More information about the Plasma-devel