[Framework-Team] Re: Release roadmap for 3.0
On Thu, 11 May 2006 03:03:17 +0100, Hanno Schlichting [EMAIL PROTECTED] wrote: Hi again. From what I have read so far, we tend into the direction of giving this release a bit more time. So here is an updated roadmap proposal. The one thing it tries to be is realistic about the dates if we allow more time for development of new features and therefore bugs as well and get the busy x-mas time in our way. Plone 3.0 - June 26, plip freeze (no more plip's are accepted) Do we have such a thing? I mean ... people can write PLIPs whenever they want :) August 21, proposal freeze (review bundles must be ready) September 25, feature freeze (all features have been merged) October 22, first beta release December 18, first release candidate January 24, expected release Do we have any understanding of how long it took us to jump through those hoops for 2.5 (at least from alpha to beta, etc. and what our projections are))? Or for 2.1? I think the interim time steps look reasonable, but it's hard to judge how long it actually takes to get enough testing and coding time. Martin -- You can just adapt yourself out of it... // Archipelago sprint 26/04/2006 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Release roadmap for 3.0
Hanno Schlichting wrote: [..] Plone 3.0 - June 26, plip freeze (no more plip's are accepted) August 21, proposal freeze (review bundles must be ready) September 25, feature freeze (all features have been merged) October 22, first beta release December 18, first release candidate January 24, expected release First of all to Hanno's proposal: This looks like a reasonble time line to me. Now to the discussion this question has triggered: First, I think we should really encourage the SoC projects by defining a time line and process that offers the **possibility** of getting results from SoC projects into the 3.0 release. WRT the role of the framework team: It is my understanding that our role/duty as FWT members is code review and decisions or recommendations for ONE release: not more and not less; no cheerleading or whatever else. Of course things are involved as all FWT members are also (more or less) active members of the community but let us not forget: we are an open source community which cannot be organized like some corporate body (you have to do this until then) and we should be very careful not to diminish other peoples enthusiasm for Plone; rather the contrary. digression I'd like to compare our situation here with the process of scientific publishing which is where I am coming from: traditionally, scientific results get written up as a manuscript which is then send to the 'editor' of some 'journal'. The 'editor' asks one or several individuals that *s/he* thinks are competent enough to juge on the matter for their opinion on whether this should be published or not. These 'reviewer(s)' read the manuscript and write a report providing two things: 1. feedback to the author(s) for improving the manuscript if needed and 2. a suggestion to the editor about whether to publish or not (and why) The decision whether the manuscript gets published or not is done by the editor. In addition to this, a journal's editor (or editorial board) is free to issue so-called calls for papers (e.g., on a certain subject matter) which hopefully encourages potential authors to submit a manuscript on that matter to this journal. Futhermore, review is typically done anonymously (meaning, neither the author nor the community will ever know who reviewed what). This is what's called a peer-to-peer review, or peer-review for short. Now, how does that compare to our situation: If we equate the 'journal' with 'Plone', the 'editor' could be the 'release manager' (???), the 'reviewers' are the 'FWT' and anyone from the community could be an 'author'. A 'call for papers' could then be compared to asking for the contribution of, e.g., a certain feature. Of course journal editors and the reviewers are typically also members of the community (often respected ones) and as such act as authors themselves. Obviously, an editor would never ask the author for a review, so here, the 'reviewer' role at least is given on a case-to-case basis (something that currently has no real equivalent in our community). For scientific communities, this pattern has evolved over centuries (Isaac Newton started the 'Proceedings of the Royal Society London' which some people consider the first modern scientific journal) and it (still) makes sense in principle (even though we see some crazy deformations in this field today). Maybe moving to a pattern like this (peer-review) would also make sense for us??? /digression Just my 0.02 Euro Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Release roadmap for 3.0
Raphael Ritz wrote: First, I think we should really encourage the SoC projects by defining a time line and process that offers the **possibility** of getting results from SoC projects into the 3.0 release. My intention here was to give all the SoC projects a clear statement that their code should really be ready by the end of the SoC project and not some weeks or month after it. They should not try to code something they won't be able to finish in that time, or otherwise I fear those things will end up in a half-finished form and students will loose interest. WRT the role of the framework team: It is my understanding that our role/duty as FWT members is code review and decisions or recommendations for ONE release: not more and not less; no cheerleading or whatever else. Personally I have to add that I don't do cheerleading of any kind because I have just no idea about how the CMS market looks like, what people expect from a CMS nowadays or any real world use-cases apart from my one company intranet that still runs on Plone 1.0.5 because people did not demand more than that (which just changed a couple of days ago, so I have to finally do the painful migration to 2.1 ;) If it were the job of the framework team to give this kind of feature recommendations I'm not the right person for it. Judging about the technical merit and the likelihood of something being maintained is something I can do. Btw. I tried to document our development process on http://plone.org/documentation/manual/plone-developer-reference/overview/release-process. There I tried to distinguish between the two things of voting about PLIP's (that is ideas/features) which is done informally by all developers (we currently have no real structure to this discussions on plone-dev) and judging technical implementations and architectural implications which is done in a formal way by the framework team. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Release roadmap for 3.0
I think those are good points, and I certainly agree with the merits of having that separation be clear. I just wonder whether we truly *can* have such a separation, and whether there then is a vacuum in leadership and policy guidance that we need to fill, because I think people are expecting more than what we're expecting to give at the moment. well, hopefully, by keeping the role of this team limited, all of you should be free to do the needful outside of the team in filling that vacuum. and if people listen more because you are on the FWT, that doesn't hurt either as long as there is a clear separation. one thing you guys(and all of us non-voters) can do is throw some rocks in the direction of marketing. getting some people on the stick to fill that void *now* would make all the difference. In proprietary software dev, marketting/product management drives the feature choices and therefore has a 6-12month drop on the release. so...send a letter to your local board member. rocky has requested an end to philosophizing on this subject so I will respectfully end any comment hitherto. -w -- | david whit morriss | | contact :: http://public.xdi.org/=whit If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 I like to write code like other ppl like to tune their cars or 10kW hifi equipment... Christian Heimes, 2004 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield email;internet:[EMAIL PROTECTED] tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Release roadmap for 3.0
Maybe moving to a pattern like this (peer-review) would also make sense for us??? /digression Just my 0.02 Euro Raphael i think that is essentially what we have. in the end, the release manager decides. the FWT is just a gatekeeper to make those decisions manageable. -w -- | david whit morriss | | contact :: http://public.xdi.org/=whit If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 I like to write code like other ppl like to tune their cars or 10kW hifi equipment... Christian Heimes, 2004 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield email;internet:[EMAIL PROTECTED] tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Release roadmap for 3.0
/me dons grumpy old former FWT member hat remember, all that SoC stuff has to have bundles and be approved by you guys. No implementing proposals after the fact. That's about the only standing rule for this team. So if you are looking at this sort of schedule, likely almost none of the SoC stuff will go in until until a later 3.x release. Also, 3.0 really should be just one louder than 2.5, regardless of the number. I would argue that the proposal freeze *is* the feature freeze *is* the last date that the framework team accepts bundles for review. remember also, release manager makes all the dates and decisions except for the due date for bundle submission. -w Rocky Burt wrote: On Wed, 2006-10-05 at 20:58 +0200, Hanno Schlichting wrote: Plone 2.5 - May 2006, announced release June 2006, expected release CMF --- April 2006, 2.0 July 2006, 2.1 (planned) Zope May 2006, 2.9.3 June 2006, 2.10 November 2006, 2.11 May 2007, 2.12 Plone 3.0 - June 26, proposal freeze August 21, feature freeze October 22, announced release The good thing about this is that we should get all the great work done as SoC projects into the release, the negative thing is that we are again quite behind the schedule in regard to our stack, as both the releases of Zope and CMF we will build on are already due in June/July. But I don't see how we could get the good things from SoC into the release with some reasonable feedback and testing if we would aim for an earlier release. Hmm... I'll let the date proposals stew in my mind for a little bit... but just a comment on the SoC projects. My feeling is that we shouldn't assume *any* SoC project should make it into plone core for 3.0. The reality is that as Alec pointed out on irc today none of that stuff will really have any chance to get battle-tested in the wild. I'm more concerned with staying within reasonable dates with the rest of our stack. It frustrates me to no end we keep lagging behind our stack releases so much (I know 2.5 and 3.0 will fix some of that). - Rocky ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- | david whit morriss | | contact :: http://public.xdi.org/=whit If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 I like to write code like other ppl like to tune their cars or 10kW hifi equipment... Christian Heimes, 2004 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield email;internet:[EMAIL PROTECTED] tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
