Re: [Framework-Team] [Plone-installers] [Board] Roadmap and Release schedule for Plone 5.2 and 6.0
Gil Forcada Codinachs <[email protected]> Fri, 1 Mar 2019 11:06:46 +0100
| Newsgroups | gmane.comp.web.zope.plone.teams.framework,gmane.comp.web.zope.plone.installers |
|---|---|
| Message-ID | <CAKSaQ1_SF5Zi3cmuNynYBfbCRRuUm_j7s4V7S3u6DeqcAyGUXg@mail.gmail.com> |
--===============9129170744216412455== Content-Type: multipart/alternative; boundary="0000000000003c80e305830591cf" --0000000000003c80e305830591cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 <[email protected]> del dia dv., 1 de mar=C3=A7 201= 9 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 propose= d > 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 ha= ve > 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 th= em > 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 testin= g > 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 tha= t > Timo and I started could to help with that ( > https://docs.google.com/document/d/1u_brtRx3lmw6-RORncZDJ59p_1bHaQEUENFb9= 1K5l24 > ) > * Parts of the documentation need to be updated. > > None of this is a surprise. I don't see what should stop us from finishin= g > these tasks in time for March 30th. We should get our shit together and d= o > it. > > Philip > > > > > Am 01.03.2019 um 06:31 schrieb sven <[email protected]>: > > > > 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 abou= t > 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 > >> =E2=80=A2 documentation > >> =E2=80=A2 translations > >> =E2=80=A2 real-world testing of migrations to Python3 > >> =E2=80=A2 development of installers that work for both Python2 an= d Python3 > >> =E2=80=A2 ... 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. A= nd > then do a final around, let's say, June 1. > >> > >> 5.2 is an important release; it has been argued that in terms of effec= t > 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 an= d > 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 <[email protected]> wrote= : > >>> > >>> > >>> Release-Schedule: > >>> - rc1 next week > >>> - final: 30.03.2019 > >>> > >>> > >> _______________________________________________ > >> Plone-installers mailing list > >> Plone-installers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > >> > >> https://lists.sourceforge.net/lists/listinfo/plone-installers > >> > > > > --0000000000003c80e305830591cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>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:</div><div>- it is ONLY meant for new projects (i.e. migrations= are still not 100% guaranteed)</div><div>- for BRAVE souls that want to tr= y Python 3</div><div>- fine and dandy for python 2 projects</div><div><br><= /div><div>And now the marketing twist on it: see that the release will be 5= .<b>2</b> ? When the migration/documentation/translations are on a better s= hape, let's release that as 5.<b>3</b> because it will be supporting py= thon 3 just fine (I guess the marketing team will have plenty of better ide= as, but I came up with that while reading these mails :D).</div><div><br></= div><div><i>With my release team hat on:</i> 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= 9;t feel rock stable. On that same vein the i18n controlpanel interface mov= e from CMFPlone to plone.i18n is missing an upgrade step (see <a href=3D"ht= tps://github.com/plone/Products.CMFPlone/pull/2769#issuecomment-466335636">= https://github.com/plone/Products.CMFPlone/pull/2769#issuecomment-466335636= </a>)</div><div><br></div><div>I admire and wholeheartedly support all the = effort you all put in porting the code and trying to keep up with keeping J= enkins happy, but at the same time I can not feel comfortable making a rele= ase if we are merging PLIPs and pull requests right and left without taking= the extra time to ensure all pieces are in place.</div><div><br></div><div= >There are plenty of organizations that make odd releases as unstable and e= ven releases as stable. For quite a while we have labeled 4.3 as a LTS rele= ase (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 lab= el.</div><div><br></div><div>This way we have the best of both worlds:</div= ><div>- the release is out and integrators can start their migration projec= ts (even though they could have done that before anyway with a rc/beta/alph= a...)</div><div>- we clearly communicate that rough edges are still ahead</= div><div><br></div><div>As for keeping the peace with making frequent relea= ses, on the release team we had a calendar to try to schedule 5.1/5.0/4.3 r= eleases. We can try to aim for a monthly release of 5.2 if no major surpris= es are ahead but mostly bugfixes. On that front, we have a bus factor to ma= ke final releases as only the release manager is able to push to <a href=3D= "http://dist.plone.org">dist.plone.org</a>.</div><div><br></div><div>The sy= sadmin team told us that with the new infra being set up all the release te= am members will be able to push to <a href=3D"http://dist.plone.org">dist.p= lone.org</a>, so if we can make that happen, we will be able to increase th= e release frequency, and finally wish nice vacations to the release manager= while the other release team members handle releases.</div><div><br></div>= <div>As for 6.0, in general I'm against roadmaps that are being discuss= ed 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 spec= ially all the database migration problems? I get the idea of promising a br= ight future with super cool frontends, tune up backends and adapters everyw= here, but that can easily backfire (and it has already happened, hello from= Plone 5.0!) specially if you are adding dates to those promises...</div><d= iv><br></div><div>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 :-)</div><div><br></div><div>Side note: as soon as/before we re= lease 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 dec= ision. 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.<br></div><div><br></div><div>Cheers,</div><div>Gil<br></div><= /div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a= ttr">Missatge de Philip Bauer <<a href=3D"mailto:[email protected]">bauer= @starzel.de</a>> del dia dv., 1 de mar=C3=A7 2019 a les 9:17:<br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Good Morning!<br> <br> 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 time= s 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 pr= oposed date of 30.03.2019.=C2=A0 <br> <br> The reasoning behind a early release is not new: The Plone community suffer= s from a severe case of hen-and-egg syndrome. Until a final version is rele= ased 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 ea= rly and follow-up with bugfix-release as soon as serious issues are found a= nd fixed. <br> <br> 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 t= he release is out.<br> <br> But with 5.2 we have even greater urgency. There are people and organizatio= ns 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. <br> <br> 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 p= ossible and much more accessible that ever before:<br> <br> * We created a nightly demo-buld of 5.2 coredev that was online since May 2= 018 (<a href=3D"http://demo-latest-py3.plone.org" rel=3D"noreferrer" target= =3D"_blank">http://demo-latest-py3.plone.org</a> and <a href=3D"http://demo= -latest-py2.plone.org" rel=3D"noreferrer" target=3D"_blank">http://demo-lat= est-py2.plone.org</a>)<br> * We documented how to test 5.2 in various Python versions. <br> * We documented the migration to Python 3 in detail (<a href=3D"https://tin= yurl.com/plonepy3" rel=3D"noreferrer" target=3D"_blank">https://tinyurl.com= /plonepy3</a>). <br> <br> There are still many things to do as Paul mentioned:<br> <br> * Translations need to be updated. English and German seems ok, others less= so.<br> * The migration-guide from 5.1 to 5.2 needs some work. I'm on it.<br> * The porting-guide seems in a good state already.<br> * The Installers need to be updated.<br> * Marketing-Material and Newsitems needs to be prepared. The document that = Timo and I started could to help with that (<a href=3D"https://docs.google.= com/document/d/1u_brtRx3lmw6-RORncZDJ59p_1bHaQEUENFb91K5l24" rel=3D"norefer= rer" target=3D"_blank">https://docs.google.com/document/d/1u_brtRx3lmw6-ROR= ncZDJ59p_1bHaQEUENFb91K5l24</a>)<br> * Parts of the documentation need to be updated.<br> <br> None of this is a surprise. I don't see what should stop us from finish= ing these tasks in time for March 30th. We should get our shit together and= do it.<br> <br> Philip<br> <br> <br> <br> > Am 01.03.2019 um 06:31 schrieb sven <<a href=3D"mailto:[email protected]= t" target=3D"_blank">[email protected]</a>>:<br> > <br> > Hi !<br> > <br> > Same here, well said !<br> > <br> > 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.<br> > <br> > Also, since we are on it, I would like to ask where I can find docs of= Plone 6, like the new UI, etc.<br> > <br> > 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.<br> > <br> > 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.<br> > <br> > Please let us know (Open an issue) about docs of Plone 6.<br> > <br> > The same goes with with things like bobtemplates, will they worl with = Plone 6, should we adjust or remove them from the 'core' docs ?<br> > <br> > Thanks !<br> > <br> > On Thu, 2019-02-28 at 22:20 +0100, Paul Roeland wrote:<br> >> hi people, <br> >> <br> >> although it's not the role of the Board to direct the technica= l direction of Plone, I do want to signal that I have serious concerns abou= t the proposed timeline for 5.2. <br> >> Not only as a member of the Board, which has to keep an eye out fo= r marketing, but also as member of the documentation team. <br> >> <br> >> I think one month between having a RC1 and a final is way too shor= t. There is still a lot of polishing to be done, in (at least) the areas of= <br> >>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 documentation<br> >>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 translations<br> >>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 real-world testing of migrations to = Python3<br> >>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 development of installers that work = for both Python2 and Python3<br> >>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 ... and probably more<br> >> 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 Qualit= y Assurance. That is also a marketing issue. <br> >> <br> >> So, while I fully support the idea of an ambitious to aggressive t= imeline, and also that we should reach RC status (meaning no more new featu= res), I would strongly plead for more time, and a few RC releases. And then= do a final around, let's say, June 1. <br> >> <br> >> 5.2 is an important release; it has been argued that in terms of e= ffect it could have been a major release. Then, by all means, let's tak= e it serious enough so that we have satisfactory translations, documentatio= n, marketing messages, and a reasonably battle-tested migration experience = before we call it a Final.<br> >> <br> >> Paul Roeland<br> >> <br> >> (Note: I'm only arguing urgently for a slowdown on the 5.2 rel= ease 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 a= nd the like. In general we just need some time between feature-freeze and a= good Quality-Assured release, with ribbons and glitter around it)<br> >> <br> >> On Wed, Feb 27, 2019 at 12:39 PM Philip Bauer <<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> >>> <br> >>> <br> >>> Release-Schedule:<br> >>> - rc1 next week<br> >>> - final: 30.03.2019<br> >>> <br> >>> <br> >> _______________________________________________<br> >> Plone-installers mailing list<br> >> <a href=3D"mailto:Plone-installers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" target= =3D"_blank">Plone-installers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org</a><br> >> <br> >> <a href=3D"https://lists.sourceforge.net/lists/listinfo/plone-inst= allers" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/= lists/listinfo/plone-installers</a><br> >> <br> > <br> <br> </blockquote></div> --0000000000003c80e305830591cf-- --===============9129170744216412455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline