[Framework-Team] [Plone-installers] [Board] Roadmap and Release schedule for Plone 5.2 and 6.0

Fri Mar 1 10:06:46 UTC 2019

Hi all,

as for the "until a final release is made nobody tests it" I have a
solution: let's wrap up the blockers for 5.2, make it final AND CLEARLY
LABEL that:
- it is ONLY meant for new projects (i.e. migrations are still not 100%
guaranteed)
- for BRAVE souls that want to try Python 3
- fine and dandy for python 2 projects

And now the marketing twist on it: see that the release will be 5.*2* ?
When the migration/documentation/translations are on a better shape, let's
release that as 5.*3* because it will be supporting python 3 just fine (I
guess the marketing team will have plenty of better ideas, but I came up
with that while reading these mails :D).

*With my release team hat on:* in the last month 2 PLIPs have been merged
(faster navigation and redirects control panel), which I have seen quite a
few follow up pull requests these last weeks, i.e. they don't feel rock
stable. On that same vein the i18n controlpanel interface move from
CMFPlone to plone.i18n is missing an upgrade step (see
https://github.com/plone/Products.CMFPlone/pull/2769#issuecomment-466335636)

I admire and wholeheartedly support all the effort you all put in porting
the code and trying to keep up with keeping Jenkins happy, but at the same
time I can not feel comfortable making a release if we are merging PLIPs
and pull requests right and left without taking the extra time to ensure
all pieces are in place.

There are plenty of organizations that make odd releases as unstable and
even releases as stable. For quite a while we have labeled 4.3 as a LTS
release (we are already on 4.3.18!) so, as said above I would be fine
having 5.2 out as a final release but with a TP (Technology Preview) or
whatever label.

This way we have the best of both worlds:
- the release is out and integrators can start their migration projects
(even though they could have done that before anyway with a
rc/beta/alpha...)
- we clearly communicate that rough edges are still ahead

As for keeping the peace with making frequent releases, on the release team
we had a calendar to try to schedule 5.1/5.0/4.3 releases. We can try to
aim for a monthly release of 5.2 if no major surprises are ahead but mostly
bugfixes. On that front, we have a bus factor to make final releases as
only the release manager is able to push to dist.plone.org.

The sysadmin team told us that with the new infra being set up all the
release team members will be able to push to dist.plone.org, so if we can
make that happen, we will be able to increase the release frequency, and
finally wish nice vacations to the release manager while the other release
team members handle releases.

As for 6.0, in general I'm against roadmaps that are being discussed by 2,
3 people and then thrown over the wall. What's the urgency of having a 6.0
roadmap if we still haven't finished not only 5.2 but specially all the
database migration problems? I get the idea of promising a bright future
with super cool frontends, tune up backends and adapters everywhere, but
that can easily backfire (and it has already happened, hello from Plone
5.0!) specially if you are adding dates to those promises...

Sorry if it feels stop energy, I hope only this last 6.0 paragraph, I
provided a few options for 5.2, but that's my 0.2 cents on the matter :-)

Side note: as soon as/before we release 5.2, please communicate in advance
if someone jumps and creates a 6.0/5.3 branch of buildout.coredev/cmfplone
and expects that mr.roboto/jenkins and all the integrations are in place.
AFAIK this is a release manager decision. I'm not against it, just that I
(or whoever wants to help) need to adjust quite a few variables here and
there and deploy new jenkins jobs and what not.

Cheers,
Gil

Missatge de Philip Bauer <bauer at starzel.de> del dia dv., 1 de març 2019 a
les 9:17:

> Good Morning!
>
> I'm aware that is not my place to decide and that we need to agree on a
> release-date. But unsurprisingly I disagree. I've stated multiple times
> over the last year that a release-date of 5.2 early in 2019 is critical. We
> were aiming for February, so we're already is month late with the proposed
> date of 30.03.2019.
>
> The reasoning behind a early release is not new: The Plone community
> suffers from a severe case of hen-and-egg syndrome. Until a final version
> is released nobody tests that new version. And once it is released people
> complain that it was not tested properly. The only way out of that is to
> release early and follow-up with bugfix-release as soon as serious issues
> are found and fixed.
>
> I'm certain that postponing the release by two month would not lead to
> more testing. Why should people start testing migrations now when they have
> not done it between November and now? Most people will only test it when
> the release is out.
>
> But with 5.2 we have even greater urgency. There are people and
> organizations who are required to move to Python 3 by 1.1.2020. Giving them
> as much of a head-start as possible by release 5.2 by the end of march
> seems critical to me.
>
> We urged time and time again that people should start planning and testing
> their migrations to 5.2 and Python 3 asap. We tried to make it as easy as
> possible and much more accessible that ever before:
>
> * We created a nightly demo-buld of 5.2 coredev that was online since May
> 2018 (http://demo-latest-py3.plone.org and
> http://demo-latest-py2.plone.org)
> * We documented how to test 5.2 in various Python versions.
> * We documented the migration to Python 3 in detail (
> https://tinyurl.com/plonepy3).
>
> There are still many things to do as Paul mentioned:
>
> * Translations need to be updated. English and German seems ok, others
> less so.
> * The migration-guide from 5.1 to 5.2 needs some work. I'm on it.
> * The porting-guide seems in a good state already.
> * The Installers need to be updated.
> * Marketing-Material and Newsitems needs to be prepared. The document that
> Timo and I started could to help with that (
> https://docs.google.com/document/d/1u_brtRx3lmw6-RORncZDJ59p_1bHaQEUENFb91K5l24
> )
> * Parts of the documentation need to be updated.
>
> None of this is a surprise. I don't see what should stop us from finishing
> these tasks in time for March 30th. We should get our shit together and do
> it.
>
> Philip
>
>
>
> > Am 01.03.2019 um 06:31 schrieb sven <sven at so36.net>:
> >
> > Hi !
> >
> > Same here, well said !
> >
> > I am only talking here about the documentation part, the current state
> of the docs for 5.2 and 6 is far away from publishing.
> >
> > Also, since we are on it, I would like to ask where I can find docs of
> Plone 6, like the new UI, etc.
> >
> > We started to rewrite and rebuild the whole docs from scratch, so far
> this is working well and the quality, readability, etc improved a lot.
> >
> > But since we have no idea what of the current docs will stay and which
> parts will be different we just have some basic covered, yet.
> >
> > Please let us know (Open an issue) about docs of Plone 6.
> >
> > The same goes with with things like bobtemplates, will they worl with
> Plone 6, should we adjust or remove them from the 'core' docs ?
> >
> > Thanks !
> >
> > On Thu, 2019-02-28 at 22:20 +0100, Paul Roeland wrote:
> >> hi people,
> >>
> >> although it's not the role of the Board to direct the technical
> direction of Plone, I do want to signal that I have serious concerns about
> the proposed timeline for 5.2.
> >> Not only as a member of the Board, which has to keep an eye out for
> marketing, but also as member of the documentation team.
> >>
> >> I think one month between having a RC1 and a final is way too short.
> There is still a lot of polishing to be done, in (at least) the areas of
> >>      • documentation
> >>      • translations
> >>      • real-world testing of migrations to Python3
> >>      • development of installers that work for both Python2 and Python3
> >>      • ... and probably more
> >> One of the criticisms that were uttered (not always in the nicest way,
> but that's beside the point) is that we should do better at Quality
> Assurance. That is also a marketing issue.
> >>
> >> So, while I fully support the idea of an ambitious to aggressive
> timeline, and also that we should reach RC status (meaning no more new
> features), I would strongly plead for more time, and a few RC releases. And
> then do a final around, let's say, June 1.
> >>
> >> 5.2 is an important release; it has been argued that in terms of effect
> it could have been a major release. Then, by all means, let's take it
> serious enough so that we have satisfactory translations, documentation,
> marketing messages, and a reasonably battle-tested migration experience
> before we call it a Final.
> >>
> >> Paul Roeland
> >>
> >> (Note: I'm only arguing urgently for a slowdown on the 5.2 release
> schedule. I like the ambition on the 6.0 schedule, although also there I
> think we're going to need a longer polishing time to make sure that we
> release with good translations, documentation, installing instructions and
> the like. In general we just need some time between feature-freeze and a
> good Quality-Assured release, with ribbons and glitter around it)
> >>
> >> On Wed, Feb 27, 2019 at 12:39 PM Philip Bauer <bauer at starzel.de> wrote:
> >>>
> >>>
> >>> Release-Schedule:
> >>> - rc1 next week
> >>> - final: 30.03.2019
> >>>
> >>>
> >> _______________________________________________
> >> Plone-installers mailing list
> >> Plone-installers at lists.sourceforge.net
> >>
> >> https://lists.sourceforge.net/lists/listinfo/plone-installers
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20190301/1b981b91/attachment-0001.html>