[Framework-Team] Re: Re: Release roadmap for 3.0

whit d.w.morriss at gmail.com
Thu May 11 17:04:50 UTC 2006


for some reason, about 5 hours of mail got lost yesterday...so I did not 
see opti's originally reply to me.

Alec Mitchell wrote:
> On 5/10/06, Martin Aspeli <optilude at gmx.net> wrote:
>> On Wed, 10 May 2006 21:05:04 +0100, whit
>> <d.w.morriss at gmail.com> wrote:
>>
>> > /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.
>>
>> I agree entirely.
>>
>> > 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.
>>
>> And, as I just replied to Rocky, this isn't something we can just take
>> lightly. It may not matter to you or me, but it matters a hell of a 
>> lot to
>> the guy who is debating whether to put the effort in to deliver some
>> killer feature. If the battle is lost before it's even begun, he won't
>> bother, and it'll more likely be 4.5 than 3.5 before it gets picked up
>> again (there's a reason why versioning is PLIP #8 and we have 157 PLIPs
>> spanning several years).
>>
we've had this discussion before.  we can't promise anything will be 
going in, so it is better to not prematurely raise expectations.    the 
example you use is a poor one..... pick versioning, events, blogging 
etc.  these efforts haven't come to fruition to a myriad of factor that 
rarely include release planning or PLIPs.

arguably, one reason the framework team is in existence to remove 
inclusion of a developers code into CMFPlone as a motivation because in 
the past that motivation has proven to be a bad one because it 
encourages code dumping.  

it's just a bad carrot. 


>> > Also, 3.0 really should be just one louder than
>> > 2.5, regardless of the number.
>>
>> I don't agree with this - and I don't think this was the intention with
>> the UI release/framework release split. As I recall it explained to me,
>> the plan was that .0 releases would be the big bang - once a year, we
>> release a new version of Plone with impressive new features, where we
>> progress and make some hard decisions about what we may need to break or
>> strongly deprecate to move Plone-the-product forward.
>
> I don't think the sentiment that whit was expressing is really one
> that you can disagree with.  It's a simple fact that we only have six
> months for 3.0, and as a result there is a real limit on the amount of
> stuff we can reasonably expect to include.  If we want if Five louder,
> then we will need a lot more time.  However, because it is ui focused
> the changes will be user visible, and therefore from a marketing
> perspective it will be much "louder".  Nonetheless, there are real
> limits on how much can be done, primarily determined by the number of
> developers actively participating in the release and the time they are
> capable of committing.  Fortunately, the Norway sprint and the SoC
> project have potentially given us a fair amount more available
> man-power than we had for 2.5.
>
see previous post.  I think we need to be carefully about inflating the 
impressiveness in the wrong quarters.  this is not our concern(granted, 
having some organized effective marketing leadership might help us not 
feel like we need to do something here. and maybe the framework team 
should consult with marketing and the foundation in a more official 
capacity). 
> ...
>
>> I'd argue that Plone-the-product, as far as end users is concerned, 
>> hasn't
>> really progressed very much since Plone 2.0. We still don't have
>> versioning, locking, staging, taxonomy/categorisation in anything more
>> sophisticated than a folder, we still have a very static UI, with many
>> slow page reloads, we have a fairly inflexible portlets infrastructure
>> that makes it awkward to make the CMS personalisable. And some of the 
>> cool
>> things we've talked about for years that real users really love, such as
>> contextualised help and actions, or UI improvements to selection widgets
>> and folder navigation, are still unrealised.
>>
>> Meanwhile, there *is* competition. The big name right now is 
>> Alfresco, and
>> they are *killing* us on many aspects. We still have a stronger 
>> community,
>> we still have a better business model, we still have a better UI (though
>> their's ain't that bad). The other big one is (slightly awkardly) Rails,
>> where all the innovation in web UI seems to be happening. If Plone is to
>> survive, it needs to stay ahead of the curve, to be sexy and 
>> intuitive. It
>> also needs to avoid having too many red crosses in the feature matrices.
>
> We all agree that there are a lot of great thing we should do, and
> need to do in the long and short term.  But your job as the framework
> team is to make a realistic assessment of what we can actually get
> done in a 6 month time frame given the available resources.  What
> Alfresco is doing and what customers are looking for in a CMS is at
> most a peripheral consideration for you guys, and should rarely be a
> factor in any FT decision (the only cases where it would be are when
> there are two proposals of equal viability that are competing for the
> same developer resources).
>
>> But 2.5 is a whisper to our end users, to the people who review Plone in
>> magazines and online journals. About the only innovations I can think of
>> off-hand are drag-and-drop folder re-ordering, placeful workflow 
>> (which I
>> fear most people won't need), and maybe the history tab making a
>> re-appearance for a poor-mans audit trail. PAS? Views? Users don't care
>> (developers do of course). If 3.0 is no louder than that, we'll get 
>> maybe
>> two or three of the Archipelago PLIPs in place, and Plone will make 
>> what I
>> fear is another release that goes the world quietly by, and then 
>> community
>> gets tired of the release frenzy, settles down to do other things, and
>> very little happens.
you could market the entire release on PAS if you wanted to, merely 
because it is integration technology.  Likewhise, CMFPlacefulWorkflow is 
also a compelling story for integrators as is GenericSetup.  or the pile 
of fine un/poorly-marketted features from 2.1.

if any release is a whisper, it's because we as a community are not 
making and telling the story.  FWT is about making sure the technology 
behind that story become increasingly more predictable and dependable.  

>>
>> Take a look at http://plone.org/products/plone/releases/3.0
>>
>> How great would it be if Plone could have even the majority of those
>> features? Let's not give up before we've begun.
>
> Nobody is talking about giving up, but as the Framework team, all you
> can do is encourage the people working on those PLIPs to get them into
> a viable state and create a review bundles before the deadline.  You
> job is not marketing or cheerleading, nor should your job be
> influenced by marketing once the review process starts.
>
>> > I would argue that the proposal freeze *is* the feature freeze *is* 
>> the
>> > last date that the framework team accepts bundles for review.
>>
>>  From that point of view, sure, though there is a much greater informal
>> period before that (which has arguably already begun) where we work out
>> what we would like people to work on and what to push for. The 
>> process of
>> even starting on a bundle isn't random, we have a pretty strong list of
>> features we really want Plone to have at 3.0, that have something to do
>> with how we want to market Plone and how we want to ensure it's not 
>> being
>> left in the dust by the competition.
>
> I think there's no argument that this informal period has already
> begun, if it hasn't, then 3.0 will either be very late or even less
> exciting than 2.5.  But in the end it doesn't matter what you really
> want to see in plone, except insofar as you can encourage development
> of those features during this informal period (which you do outside
> your job as a framework team member).  All that matters to the team is
> what gets done.  I think Hanno's proposal to model the dates around
> the SoC dates makes a good deal of sense, though I think the mid-term
> date is a bit optimistic to expect the SoC coders to have a reviewable
> product ready.  Some of the SoC projects stand a good chance of making
> it into 3.0 (especially those that are part of larger endeavors
> involving multiple core developers), so it would be a poor decision to
> use dates that might marginalize their contributions.
>
I would agree with this. 

frankly, I care less about the dates than I do about the fever-pitch of 
some of the discourse (it's natural. I got slapped by rightly by stefan 
last time for my aggressive release schedule proposal for 2.1). 

It is good to be excited, it's good to push people to adopt new 
standards, processes and technologies, but this team is the gatekeeper 
for making sure releases stay sane.   Currently, there are 25 plips 
scheduled for 3.0.    That's alot of potential work for a release 
manager especially considering there is a CMF jump in the mix.  If I was 
on the FWT, I would be trying to figure out things to trim if the 
eventuality that things get hairy rather than figuring ways to cram more in.

-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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: whit.vcf
Type: text/x-vcard
Size: 181 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20060511/86b6c4f0/attachment.vcf>


More information about the Framework-Team mailing list