Re: [Framework-Team] Now what do we do?
Our team wishes to highlight PLIP 154 as we think it is nearly implemented by FileSystemStorage + AttachmentField (still SVN). There is no bundle for this, correct? We are now past the bundle deadline, I'm not quite sure what sort of process we have for deciding whether we want to take on more at this point. I guess it would have to be up to Wiggy, as release manager, and whomever would be willing to co-ordinate such a bundle if one appears. I think we'd also need to have a debate about whether we wanted something Archetypes-specific or something a bit more general. Pragmatically, AT is of course what matters today. It may not be forever, in which case a solution would have to be seen as at least not getting in the way of any future efforts to generalise. Not having seen the FSS code, I can't comment on whether it has layers that are generalisable outside AT or not. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Now what do we do?
Previously Martin Aspeli wrote: +1 I'm happy to take a couple, at least. I suggest we have one person in charge of each bundle, who does some initial review, posts back to the list to tell people good points and bad points and explains where to look to understand what's going on, and then we can discuss, argue, fight and vote. +1 Would you mind getting started on the list (I'm at work atm...)? I think starting with plone.org/roadmap and then matching to bundles in /review (note - the easycommenting bundle is in the collective, see the link on the PLIP). Here is the list: PLIP 8 - Versioning PLIP 48 - Use session instead of cookie plugin to store PAS authentication PLIP 112 - XML Import / Export PLIp 118 - Porlets engine basd on PlonePortlets and Viewlets PLIP 119 - Contextual help portlet PLIP 121 - Asynchronous loading of content views PLIP 122 - Edit-in-place mode for all basic field types PLIP 125 - Ensuring link/reference integrity (removing 404 links) PLIP 127 - Move properties to Edit screen using pre-loaded fieldsets PLIP 142 - Componentise the global content menu PLIP 144 - Generalized Next / Previous navigation PLIP 145 - Locking PLIP 148 - Move to CMF 2.1 PLIP 157 - Content rules engine PLIP 171 - KSS / Azax to Plone PLIP 172 - Wiki syntax support for all content PLIP 173 - OpenID support PLIP 174 - More configurable and reusable i18n features PLIP 168 - integrate iterate for checkin/checkout/staging PLIP 179 - Improved commenting infrastructure There are three plips (120, 124 and 149) which have a CMFPlone but no bundle so I'm ignoring those. 121, 121 (both Bling) and 171 should be probably reviewed by the same person and will warrant a lot of discussions - that's the bling vs azax/kss decision. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Now what do we do?
Previously Martin Aspeli wrote: PLIP 173 - OpenID support This one is mine. The current status shows the design nicely but there are a couple of essential bits (like session authentication) still missing (they are listed in the docs in the bundle). I expect it to be fully stable in abou two weeks. A reviewer will need to be be reasonably familiar with PAS plugins to be able to review this I'm afraid. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Now what do we do?
Previously Martin Aspeli wrote: So - I'm proposing to take: PLIP 119 - Contextual help portlet PLIP 125 - Ensuring link/reference integrity (removing 404 links) PLIP 144 - Generalized Next / Previous navigation (all of which I'm familiar with already to a certain extent) and then try to keep the KSS vs. Bling debate going in constructive direction. People happy with that? +1 Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Now what do we do?
Our process could be improved. we reviewed a few bundles a week over the course of a few weeks. Basically, I or Alan would announce what bundles we were looking at and when the next phone call would be by email. Since the process for each bundles was not specifically owned by anyone, the coverage of attention was a bit scattered imho and alot of time was wasted in rambling conference calls. cie la vie. Since you have more bundles and more people, dividing the bundles among general areas of expertise might be a good idea. If everyone owns the review of 2 or 3 bundles you should be well covered and then you have a point of contact for the bundle authors. Not unlike SoC. Key to the process is to draft as many people from outside the voting FWT to look at bundles and get their input. Good job wiggy with the announcement. This could be a good time to rouse up some enthusiasm about actually cranking out P3. I recommend using a file in the svn bundle root as a comment trail: it is automatically web published, everyone should check out every bundle, all plone devs have write access to it, and conflict are merged(rather than blotted out or lost as in a plone doc or email thread). We used an email for each bundle that the group appended to by replying(post vote). The worst part was getting people to make opinions in a timely fashion; I would recommend getting all opinions before the vote if possible. Having collected as many comments as possible before the vote makes voting faster and reporting the outcome easier. We voted on the phone(sort of a waste of time imho); you might choose to use svn or email. Afterwards, someone (Marten in this case) compiles the votes and the various suggestions for next step and opinions into a usable report for that set of bundles and posts the report to plone-dev. In the case of a rejection, someone should compile an explanation for the author of the package including what would need to be do for inclusion and a timeline for getting those things done. lather, rinse, repeat. Once you have completed this process for all the bundles, write wiggy a final report filled with guiding wisdom, make an announcement that you are disbanding as the voting board of the FWT, have a beer, scotch or coffee and at your leisure choose your successors for the next release. -w Martin Aspeli wrote: So, the bundle deadline passed, and I almost got some sleep. I'm guessing a few bundles will trickle in still (Vincenzo is on holiday, for example, but promised to look at workflow) Members from last year - how did you go about actually undertakign the reviews? We have bundles at http://svn.plone.org/svn/plone/review/ (and one at svn.plone.org/svn/collective/easycommenting/bundles/2.5/ http://svn.plone.org/svn/collective/easycommenting/bundles/2.5/ since Kai doesn't have commit privs yet). This matches up pretty well to what we see in http://plone.org/roadmap, with a few exceptions. Most of these are excusable (AJAX dependencies that make no sense until we've sorted out that can of worms, trivial things that probably don't need much review - we'll have to take it on a case-by-case basis). I know Wichert is away for 5 days, and Vincenzo is on holiday (until the middle/end of the week?). I'd be nice if we could come up with a process, though. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
