--===============1895157859==
Content-Type: multipart/signed;
  boundary="nextPart3913919.UZGJ2pYlK0";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3913919.UZGJ2pYlK0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le dimanche 13 janvier 2008, Sebastian Kuegler a =C3=A9crit :
> On Wednesday 09 January 2008 00:09:30 Kevin Ottens wrote:
> > --------- Executive summary
> >
> > In this mail I'll be advocating the way I think we should make our
> > release planning from now on. Some parts will look similar to what we
> > were doing, some won't. I think doing strict time-based release would be
> > a mistake and I think we should do ourselves a favor by having something
> > more flexible.
>
> Executive summary of my reaction:
>
> KDE is too big to make its schedule dependent on single features.

That's fine if you allow yourself to push back easily. Of course I'm not=20
advocating to decide on all the features in advance and not release until a=
ll=20
the features are in. The idea is to put frequent check point when you=20
reevaluate what will get in or not. Once this regularly updated list is emp=
ty=20
you start stabilizing.

> A=20
> time-based schedule is preferable because it gives our partners (upstream
> and downstream) a solid idea of when the new KDE is there. Commitment to
> plannable release dates is very important.
>
> I like your proposal of how a release cycle should look like. This doesn't
> seem to depend on time-boxed, though.

The time boxes are on the inner cycle of development (the snapshots), in my=
=20
example it was one month time boxes. I should have made that clearer.

> > --------- Proposal: time-boxed development
>
> [...]
>
> > So in short, the benefits I see in such a scheme:
> >  - we're more predictible
>
> We're less predictable than with a commitment to a fixed date. That is a
> pretty central point for me. Commitment.

Sure, but if you commit to a fixed date you can't commit to actually making=
=20
progress in the same period. That leads to anemic releases IMO.
(Note that I'm not saying you can't make progress, you just can't be sure=20
their will be... in particular in a mainly volunteer project)

Now that's why I proposed the time boxing, you're still more predictible th=
an=20
if you're purely feature driven (and release once everything is in) and you=
=20
give yourself the opportunity to foresee the right release date enough in=20
advance to communicate it.

Of course it's less predictible than saying we'll release every X months=20
whatever happens... which has a price.

Hence why my proposal was more about a compromise.

> >  - we keep flexibility for KDE5 without having to push for a completely
> > different cycle (it's basically just a longer feature list, in particul=
ar
> > for kdelibs, and having an earlier freeze for kdelibs)
>
> Wait, let's not mix the next major in here. We should bring it down to the
> less complex 'release plan for point releases. Trying to find some general
> release strategy which fits feature updates (4.x) major version (5.0) is
> not necessary for the next years, so let's cut down complexity here.

Sorry, but IMO we've to keep it in mind nonetheless. Changing completely th=
e=20
way we work for major releases just leads us to loosing more time. We had a=
=20
period where the release management was in a state of flux, habits had to b=
e=20
changed, and now they'll be changed back again. It definitely has a price=20
too, so coming up with something that can manage both cases with minor=20
changes is an advantage IMO and must be evaluated as such.

> >  - we share the load of the release management
>
> I don't see how / why. Can you explain?

The way I structured the proposal I gave more importance to the release=20
coordinators on purpose. They'd get a much more proactive role in driving t=
he=20
release, while for now apart from cleaning up which application is in a=20
module they don't seem to be very active. In the end the decisions are take=
n=20
randomly or with a 10000 feet high view on the module.

I might be wrong here of course, but I don't recall much activity from modu=
le=20
maintainers for our last release. Note that I'm not blaming anyone, it's=20
currently hard to really know what you'd be supposed to do as a coordinator=
=20
hence why I tried to make that more explicit.

> >  - we get toward a release based on the current status of the codebase
> > and feature lists, not some external factors
>
> I think the problem is that our codebase is too complex. As Simon said,
> there's always the bigger thing, and there's always something that might =
or
> might not make it by two weeks. IMO we're just too big (or big enough) to
> move away from focusing on single features.

Not sure I understood what you meant here.

> >  - we're better at communicating what we're doing, and the status of the
> > codebase
>
> Again, I think that's much easier to do if we have a predictable,
> time-based schedule. It's just easier to understand if you can pick a
> calendar and see "ah, warmup phase right now". It also makes communication
> to our developers much easier.

Again I think it's about a compromise between what's good for the project=20
itself and the ecosystem around the project. As for communication to our=20
developers the time boxing is IMO more efficient, because you poke them mor=
e=20
frequently and regularly (not only every X months).

> > --------- Why I don't buy "time-based release"
> >
> > Mainly for two reasons.
> >
> > First as pointed out at several place (and in particular in Martin
> > Michlmayr PhD), there's real concerns regarding innovation with such
> > release planning. That means that you would have to use a radically
> > different cycle for major versions, that's somehow what we did to get K=
DE
> > 4.0 and we probably don't want that anymore. People are change resistan=
t,
> > you break habits when you change the type of release cycle. And we don't
> > want to prevent innovation, do we?
>
> I don't agree with the don't anymore.

Not sure I understood that. You want to prevent innovation? I don't think s=
o,=20
I probably misunderstood you. :-)

> As I said earlier, it makes sense to=20
> exclude major cycles from this planning. In this light, Michlmayr seems to
> propose exactly those time-based cycles.

Actually, the point of Michlmayr in favor of time based cycles is the quali=
ty=20
of the output. But, the innovation is still a raised concern with such a=20
cycle... While the quality of the output can be ensured by other means,=20
frequent snapshots which have to meet a set of criteria being one of them.

> I also don't think innovation is a=20
> problem, rationale is the 'meta-project / too big' argument above.

I don't see why being "too big" suddenly allows us to innovate more easily =
in=20
such a release cycle while others obviously are known to have issue with=20
that.

> > Ok, now it's late and I'm tired, just hoping I didn't write too much
> > bullshit in there.
>
> Hardly any. :-)

Ah pfew! Seeing the tremendous amount of interest for this thread I was ind=
eed=20
wondering. :-)

Regards.
=2D-=20
K=C3=A9vin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le ma=C3=AEtre sans disciple, Ni le disciple sans ma=C3=AEtre,
Ne font reculer l'ignorance."


--nextPart3913919.UZGJ2pYlK0
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBHj45xB0u7y43syeIRApYhAJ93J9zcOHYkFfgkeRLgmmHNbU7VUQCgmqra
03sabi7CItZil/EyIfXVkL4=
=TGfs
-----END PGP SIGNATURE-----

--nextPart3913919.UZGJ2pYlK0--

--===============1895157859==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

--===============1895157859==--