Re: [Board] Roadmap and Release schedule for Plone 5.2 and 6.0
Gil Forcada Codinachs <[email protected]> Mon, 4 Mar 2019 22:49:49 +0100
| Newsgroups | gmane.comp.web.zope.plone.installers,gmane.comp.web.zope.plone.teams.framework |
|---|---|
| Message-ID | <CAKSaQ1_tocEk8DNT6dW=Eb25fQ8HTaaz=fOaa3S0vsKX3FCNOg@mail.gmail.com> |
--===============5344796947759474325== Content-Type: multipart/alternative; boundary="00000000000011610905834bbd0f" --00000000000011610905834bbd0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When this rc1 is out, if we want to make more people test it, it might be a good idea to state clearly, in bold, uppercase and whatnot, that it is indeed rc, so no breaking features, no PLIP, etc will be added later. We have a good track of doing so, which also might have helped on creating this scenario. From a community/marketing/board point of view, it might be a good idea to promote this final stage testing by making a sort of sane competition, on who reports/fixes more issues etc and win some dummy prizes to be awarded at the Conference in Ferrara to help push the final release, or if a company is heavily involved, to get a spotlight somewhere/reduce fees etc etc. Which, also retrofitting, if we want the community to get more involved, we should involve them from the very beginning not as an after though when all decisions are made. One thing is doing marketing and for that you need some strategy, ideas and a focused group of people to do the job, but if we want to get the community involved in testing and ensuring that we can get 5.2 is out, we have to be open and vocal on that. At least, by doing so, if we are open from the very beginning, we can at least point to all the community.plone.org messages and call for actions, that no one should complain about the final 5.2 status because we gave them enough time. Which, IMHO, should be with the roadmap. But then again, that's my 0.2 cents. Cheers, Gil Missatge de Philip Bauer <[email protected]> del dia dl., 4 de mar=C3=A7 201= 9 a les 15:54: > Hi Teams! > > We discussed the whole thing in a hangout and reached a consensus. > > Here's what we decided: > > - We will release Plone 5.2rc1 this week > - We will publish the roadmap ( > https://docs.google.com/document/d/1u_brtRx3lmw6-RORncZDJ59p_1bHaQEUENFb9= 1K5l24) > after some polishing this week. It is as usual not a law but a condensed > version of the ongoing discussion in the Plone community. > - We will invite all developers to a remote sprint on March 14 to test an= d > improve the Database-Migration documented in > https://github.com/plone/documentation/blob/5.2/manage/upgrading/version_= specific_migration/upgrade_to_python3.rst#database-migration > - We will release Plone 5.2 final on March 30. The release-notes for 5.2 > may state (depending on the outcome of the above sprint) that the > Database-Migration von Python 2 to 3 may be not as stable as we'd like th= em > to be and that consecutive bugfix releases will address possible issues. > - We will form a group from all teams to plan the release. It will have a > weekly hangout to coordinate and track progress. That will also give us a > forum to postpone the release if a real blocker may come up. > > I'll personally try my best to test the Migration, work on the > Upgrade-Guide (already started this morning) and update the Mastering Plo= ne > Training. If anyone has any issues either with missing docs, broken > features or such please create a ticket of contact me. > > Cheers, > Philip > > -- > Starzel.de > Philip Bauer > Dilsberger Stra=C3=9Fe 9 > 81245 M=C3=BCnchen > Tel: 089 - 189 29 533 > [email protected] > www.starzel.de > > > Am 01.03.2019 um 11:06 schrieb Gil Forcada Codinachs < > [email protected]>: > > > > 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-4663356= 36 > ) > > > > 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 mergi= ng > 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 an= d > 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 tr= y > 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 releas= es > 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 releas= e > 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 t= he > 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 qui= te > 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= 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 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 > 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_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 > 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 <[email protected]>: > > > > > > Hi ! > > > > > > Same here, well said ! > > > > > > I am only talking here about the documentation part, the current stat= e > 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 o= f > 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 whic= h > 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 = and > 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 > effect it could have been a major release. Then, by all means, let's take > 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. > > >> > > >> 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 > > >> > > > > > > > --00000000000011610905834bbd0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>When this rc1 is out, if we want to make more people = test it, it might be a good idea to state clearly, in bold, uppercase and w= hatnot, that it is indeed rc, so no breaking features, no PLIP, etc will be= added later. We have a good track of doing so, which also might have helpe= d on creating this scenario.</div><div><br></div><div>From a community/mark= eting/board point of view, it might be a good idea to promote this final st= age testing by making a sort of sane competition, on who reports/fixes more= issues etc and win some dummy prizes to be awarded at the Conference in Fe= rrara to help push the final release, or if a company is heavily involved, = to get a spotlight somewhere/reduce fees etc etc.</div><div><br></div><div>= Which, also retrofitting, if we want the community to get more involved, we= should involve them from the very beginning not as an after though when al= l decisions are made. One thing is doing marketing and for that you need so= me strategy, ideas and a focused group of people to do the job, but if we w= ant to get the community involved in testing and ensuring that we can get 5= .2 is out, we have to be open and vocal on that.</div><div><br></div><div>A= t least, by doing so, if we are open from the very beginning, we can at lea= st point to all the <a href=3D"http://community.plone.org">community.plone.= org</a> messages and call for actions, that no one should complain about th= e final 5.2 status because we gave them enough time.</div><div><br></div><d= iv>Which, IMHO, should be with the roadmap.</div><div><br></div><div>But th= en again, that's my 0.2 cents.</div><div><br></div><div>Cheers,</div><d= iv>Gil<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= =3D"gmail_attr">Missatge de Philip Bauer <<a href=3D"mailto:bauer@starze= l.de">[email protected]</a>> del dia dl., 4 de mar=C3=A7 2019 a les 15:54= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Teams!<br> <br> We discussed the whole thing in a hangout and reached a consensus.<br> <br> Here's what we decided:<br> <br> - We will release Plone 5.2rc1 this week<br> - We will publish the roadmap (<a href=3D"https://docs.google.com/document/= d/1u_brtRx3lmw6-RORncZDJ59p_1bHaQEUENFb91K5l24" rel=3D"noreferrer" target= =3D"_blank">https://docs.google.com/document/d/1u_brtRx3lmw6-RORncZDJ59p_1b= HaQEUENFb91K5l24</a>) after some polishing this week. It is as usual not a = law but a condensed version of the ongoing discussion in the Plone communit= y.<br> - We will invite all developers to a remote sprint on March 14 to test and = improve the Database-Migration documented in <a href=3D"https://github.com/= plone/documentation/blob/5.2/manage/upgrading/version_specific_migration/up= grade_to_python3.rst#database-migration" rel=3D"noreferrer" target=3D"_blan= k">https://github.com/plone/documentation/blob/5.2/manage/upgrading/version= _specific_migration/upgrade_to_python3.rst#database-migration</a><br> - We will release Plone 5.2 final on March 30. The release-notes for 5.2 ma= y state (depending on the outcome of the above sprint) that the Database-Mi= gration von Python 2 to 3 may be not as stable as we'd like them to be = and that consecutive bugfix releases will address possible issues.<br> - We will form a group from all teams to plan the release. It will have a w= eekly hangout to coordinate and track progress. That will also give us a fo= rum to postpone the release if a real blocker may come up.<br> <br> I'll personally try my best to test the Migration, work on the Upgrade-= Guide (already started this morning) and update the Mastering Plone Trainin= g. If anyone has any issues either with missing docs, broken features or su= ch please create a ticket of contact me.<br> <br> Cheers,<br> Philip<br> <br> --<br> Starzel.de<br> Philip Bauer<br> Dilsberger Stra=C3=9Fe 9<br> 81245 M=C3=BCnchen<br> Tel: 089 - 189 29 533<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><= br> <a href=3D"http://www.starzel.de" rel=3D"noreferrer" target=3D"_blank">www.= starzel.de</a><br> <br> > Am 01.03.2019 um 11:06 schrieb Gil Forcada Codinachs <<a href=3D"ma= ilto:[email protected]" target=3D"_blank">[email protected]</a>>:<br= > > <br> > Hi all,<br> > <br> > 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:<br> > - it is ONLY meant for new projects (i.e. migrations are still not 100= % guaranteed)<br> > - for BRAVE souls that want to try Python 3<br> > - fine and dandy for python 2 projects<br> > <br> > 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= 9;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 w= ith that while reading these mails :D).<br> > <br> > With my release team hat on: in the last month 2 PLIPs have been merge= d (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 ro= ck stable. On that same vein the i18n controlpanel interface move from CMFP= lone to plone.i18n is missing an upgrade step (see <a href=3D"https://githu= b.com/plone/Products.CMFPlone/pull/2769#issuecomment-466335636" rel=3D"nore= ferrer" target=3D"_blank">https://github.com/plone/Products.CMFPlone/pull/2= 769#issuecomment-466335636</a>)<br> > <br> > I admire and wholeheartedly support all the effort you all put in port= ing the code and trying to keep up with keeping Jenkins happy, but at the s= ame time I can not feel comfortable making a release if we are merging PLIP= s and pull requests right and left without taking the extra time to ensure = all pieces are in place.<br> > <br> > There are plenty of organizations that make odd releases as unstable a= nd 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 havin= g 5.2 out as a final release but with a TP (Technology Preview) or whatever= label.<br> > <br> > This way we have the best of both worlds:<br> > - the release is out and integrators can start their migration project= s (even though they could have done that before anyway with a rc/beta/alpha= ...)<br> > - we clearly communicate that rough edges are still ahead<br> > <br> > 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 mo= stly bugfixes. On that front, we have a bus factor to make final releases a= s only the release manager is able to push to <a href=3D"http://dist.plone.= org" rel=3D"noreferrer" target=3D"_blank">dist.plone.org</a>.<br> > <br> > The sysadmin team told us that with the new infra being set up all the= release team members will be able to push to <a href=3D"http://dist.plone.= org" rel=3D"noreferrer" target=3D"_blank">dist.plone.org</a>, so if we can = make that happen, we will be able to increase the release frequency, and fi= nally wish nice vacations to the release manager while the other release te= am members handle releases.<br> > <br> > 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...<br> > <br> > 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 := -)<br> > <br> > Side note: as soon as/before we release 5.2, please communicate in adv= ance if someone jumps and creates a 6.0/5.3 branch of buildout.coredev/cmfp= lone and expects that mr.roboto/jenkins and all the integrations are in pla= ce. 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.<br> > <br> > Cheers,<br> > Gil<br> > <br> > Missatge de Philip Bauer <<a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a>> del dia dv., 1 de mar=C3=A7 2019 a le= s 9:17:<br> > 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= times over the last year that a release-date of 5.2 early in 2019 is criti= cal. We were aiming for February, so we're already is month late with t= he proposed date of 30.03.2019.<br> > <br> > The reasoning behind a early release is not new: The Plone community s= uffers 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 com= plain that it was not tested properly. The only way out of that is to relea= se early and follow-up with bugfix-release as soon as serious issues are fo= und and fixed.<br> > <br> > I'm certain that postponing the release by two month would not lea= d 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 w= hen the release is out.<br> > <br> > But with 5.2 we have even greater urgency. There are people and organi= zations who are required to move to Python 3 by 1.1.2020. Giving them as mu= ch of a head-start as possible by release 5.2 by the end of march seems cri= tical to me.<br> > <br> > We urged time and time again that people should start planning and tes= ting 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:<br> > <br> > * We created a nightly demo-buld of 5.2 coredev that was online since = May 2018 (<a href=3D"http://demo-latest-py3.plone.org" rel=3D"noreferrer" t= arget=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://dem= o-latest-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:= //tinyurl.com/plonepy3" rel=3D"noreferrer" target=3D"_blank">https://tinyur= l.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.go= ogle.com/document/d/1u_brtRx3lmw6-RORncZDJ59p_1bHaQEUENFb91K5l24" rel=3D"no= referrer" target=3D"_blank">https://docs.google.com/document/d/1u_brtRx3lmw= 6-RORncZDJ59p_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 f= inishing these tasks in time for March 30th. We should get our shit togethe= r and do it.<br> > <br> > Philip<br> > <br> > <br> > <br> > > Am 01.03.2019 um 06:31 schrieb sven <<a href=3D"mailto:sven@so= 36.net" 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 do= cs 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 tec= hnical direction of Plone, I do want to signal that I have serious concerns= about the proposed timeline for 5.2.<br> > >> Not only as a member of the Board, which has to keep an eye o= ut for 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= short. There is still a lot of polishing to be done, in (at least) the are= as 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 migration= s 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 ni= cest way, but that's beside the point) is that we should do better at Q= uality Assurance. That is also a marketing issue.<br> > >><br> > >> So, while I fully support the idea of an ambitious to aggress= ive 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.<br> > >><br> > >> 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, documen= tation, marketing messages, and a reasonably battle-tested migration experi= ence 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 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 instructi= ons 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)<br> > >><br> > >> On Wed, Feb 27, 2019 at 12:39 PM Philip Bauer <<a href=3D"= mailto:[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" tar= get=3D"_blank">Plone-installers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org</a><br> > >><br> > >> <a href=3D"https://lists.sourceforge.net/lists/listinfo/plone= -installers" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge= .net/lists/listinfo/plone-installers</a><br> > >><br> > ><br> > <br> <br> </blockquote></div> --00000000000011610905834bbd0f-- --===============5344796947759474325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============5344796947759474325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plone-installers mailing list Plone-installers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/plone-installers --===============5344796947759474325==--