<snip />
Personally, I never liked the separation of infrastructure/UI-focused
releases, and it was also something that was never voted on or
accepted as the way to go — it was just suggested. But if there is an
alternating schedule, 3.0 is definitely the UI release, not the
infrastructure release. ;)
I am thinking we need to be stricter about the alternating
infrastructure and UI releases in the future: currently we are still
doing both infrastructure and UI in a single release.
I don't think this will realistically ever happen if we're supposed to
have releases every 6 months. You can't add infrastructure like
versioning and ignore the UI aspect.
That being said, I haven't done my job in making the UI tasks clear to
the team, nor have I delivered what I hoped in terms of actual work.
Things have settled down now that I have finally started at Google, so
I suspect I will be more productive in the near future. I'm still a
bottleneck on the UI side, something I'm working on resolving (and the
UI sprint we have planned is a big part of that effort).
I think representing releases as binarily UI focussed or infrastructure
focused does a bit of disservice to past discussions. The idea was more
to have release that focused on new feature alternate with ones that did
the needful and cleaned up accrued engineering debt. The idea that a
release would ignore infrastructure or ui outright is ridiculous; the
suggested structure merely gave a simple guiding principle on which a
release would focus.
-w
begin:vcard
fn:D. Whitfield Morriss
n:Morriss;D. Whitfield
org:The Open Planning Project;OpenPlans
adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA
email;internet:[EMAIL PROTECTED]
title:Lead Developer
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
