headers
Alexander Limi | 2 Dec 2005 09:36
Favicon
Gravatar

Version policy PLIP

Hi,

I would like to get some feedback on my version policy proposal PLIP:

http://plone.org/products/plone/roadmap/114

Also, I know that the people I have talked to about this from the  
framework team are positive to this so far (Whit, Alec) - but I would  
appreciate a quick decision on this, since we should rename the current  
release + the next one before we start announcing the next things.

Can we do a quick +/-1 on the mailing list and say that the decision is  
official once it reaches +3 or -3?

/me has ~15 UI PLIPs going into "3.0" and is anxious to announce. :)

--

-- 
_____________________________________________________________________

      Alexander Limi · Chief Architect · Plone Solutions · Norway

  Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder · http://plone.org · Connecting Content
   Plone Foundation · http://plone.org/foundation · Protecting Plone
Permalink | Reply | 2 comments |
headers
Michel Pelletier | 2 Dec 2005 22:44
Favicon

Re: Version policy PLIP

Alexander Limi wrote:

> Hi,
>
> I would like to get some feedback on my version policy proposal PLIP:
>
> http://plone.org/products/plone/roadmap/114
>
> Also, I know that the people I have talked to about this from the  
> framework team are positive to this so far (Whit, Alec) - but I would  
> appreciate a quick decision on this, since we should rename the 
> current  release + the next one before we start announcing the next 
> things.
>
> Can we do a quick +/-1 on the mailing list and say that the decision 
> is  official once it reaches +3 or -3?
>
> /me has ~15 UI PLIPs going into "3.0" and is anxious to announce. :)
>
You mean this list or the plone-dev list, I'm far behind on that so I 
coudln't eye a particular thread you were talking about.  I'm 
reluctantly +1 on it, the arguments in the 114 plip sold me.

-Michel
Permalink | Reply | 1 comment |
headers
Alexander Limi | 3 Dec 2005 00:13
Favicon
Gravatar

Re: Version policy PLIP

On Fri, 02 Dec 2005 13:44:57 -0800, Michel Pelletier
<michel@...>  
wrote:

> You mean this list or the plone-dev list, I'm far behind on that so I  
> coudln't eye a particular thread you were talking about.  I'm  
> reluctantly +1 on it, the arguments in the 114 plip sold me.

Yeah, I meant on this list. Anyway, we have a majority, and Alan also  
wanted this, so I'll go ahead and do the grunt work, and let Alec announce  
the new policy on naming on the lists as release manager.

--

-- 
_____________________________________________________________________

      Alexander Limi · Chief Architect · Plone Solutions · Norway

  Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder · http://plone.org · Connecting Content
   Plone Foundation · http://plone.org/foundation · Protecting Plone
Permalink | Reply | 0 comments |
headers
Alec Mitchell | 10 Dec 2005 03:47
Favicon

Current PLIP status

OK framework folks, here is a summary of the current state of things as per 
our last discussion and some followup with the relevant devs.  I'd 
appreciate any additions or disagreements:

PLIP #12: Messaging channel:
	The PLIP needs to be updated to reflect what the implementation is actually 
doing ASAP.  Without some more concrete idea of the purpose and risks of 
this idea it's not at all clear if it belongs.  Currently the implementation 
provides for delayed cataloging, which is nice (especially if it can be made 
configurable).  We need an analysis of how this interacts with Five's 
monkeypatching of manage_* methods for events and the event work being 
proposed for CMF 2.0.  This PLIP involves pretty deep infrastructure and a 
strong argument could be made that, if this is to be done, it should be done 
in CMF itself.  Getting input from the CMF folks on why this is 
great/terrible would be worthwhile, even if it's no feasable to push it down 
the stack.  I've been assured that the code is functional, and it looks 
reasonable, so what remains is for it to be properly PLIP'd and documented 
(esp. a TODO).

PLIP #52: Placeful Workflow:
	CMFPlacefulWorkflow is a mature product, and integrating it into plone has 
clear benefits (locally configurable workflow mappings have broad utility).  
Some ui work needs to be done (this is true of workflow ui generally), and a 
discussion needs to be opened with the CMF folks, as this is an 
infrastructural piece that perhaps belongs lower in the stack.  The main 
impediment to polishing and merging this right now is that the primary 
developers (mroeder and encolpe) and still don't have svn access (!).  They 
have both submitted their contributor agreements, so some pressure needs to 
be put on the relevant persons to expedite this.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Sidnei da Silva | 10 Dec 2005 04:07
Favicon

Re: Current PLIP status

Alec,

Thanks for the great review. I would like to make a couple points
about stuff where I'm directly/indirectly involved.

For PLIP 106, the 'RootNavigation' thing is for making it easy to root
the navigation items to a different place than the 'Plone Site' by
setting a marker interface. It needs tests, I should be able to
provide those on time. The rest of the stuff is in good shape. I think
it makes sense to use the Physical variant of the breadcrumbs code.

PLIP 112 is somewhat related to Marshall, because Kapil has been
developing the 'pluggable xmlns stuff' as a branch of
Marshall. However, Marshall is also a important part of fixing the
problems with WebDAV in Plone in my opinion. I've chatted with Kapil
and he has agreed to split the xml marshaller stuff out of the
Marshall product.

The idea is that instead of hardcoding to a single marshaller on all
AT schemas, we would have a default marshaller, and some policy to
delegating to different marshallers depending on the incoming content
type, etc. It is lacking a simplified predicate that matches on the
incoming request content-type + portal_type and a Plone UI. In a
perfect world, I would be able to land this in time for Plone 2.1.2 to
fix the last 3 issues related to WebDAV, but I would be happy enough
to land it into 2.5.

--

-- 
Sidnei da Silva
Enfold Systems, LLC.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Miller | 10 Dec 2005 08:04
Favicon

Re: Current PLIP status

On Dec 9, 2005, at 6:47 PM, Alec Mitchell wrote:

> OK framework folks, here is a summary of the current state of  
> things as per
> our last discussion and some followup with the relevant devs.  I'd
> appreciate any additions or disagreements:
>
> PLIP #102: PlonePAS:
> 	Another mature third product that is in production use, and for  
> which the
> integration work is mostly done.  Enfold is standing behind the  
> product and
> it is apparently (nearly?) ready to merge.  The TODO list indicates  
> a few
> items that seem pretty important (role mapping, caching,  
> listMemberIds), and
> migration needs to be tested on a few reasonable sites.  A big  
> lingering
> question, what does this mean for CMFMember?

CMFMember will not work w/ PlonePAS, at all.  chances are that it  
never will.  my current thought is to write a new product, based on  
Membrane, that will replace CMFMember, providing a (hopefully  
ContentSetup-based) migration path forward.  i'm hoping to start  
working on this at the snow sprint.

> Does it matter?

i think it does.  there are quite a few folks out there using  
CMFMember, and this is going to be a show-stopper for all of them.  i
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rob Miller | 10 Dec 2005 08:40
Favicon

Re: Current PLIP status

On Dec 9, 2005, at 11:04 PM, Rob Miller wrote:

> On Dec 9, 2005, at 6:47 PM, Alec Mitchell wrote:
>
>> PLIP #113: GenericSetup
>> 	This appears to be in good shape, and while it's only a gradual  
>> step towards
>> a more reasonable migration and setup infrastructure, it is a very  
>> important
>> one.  The way that portal setup is performed on the branch  
>> currently creates
>> some undesirable dependencies (making it so that AT and ATCT tests  
>> can't
>> run).
>
> i'm working on this now.

okay, these tests are running now on the goldegg bundle (https:// 
svn.plone.org/svn/plone/bundles/goldegg).  it's true that there are  
some undesireable dependencies.  the problem is that PloneTestCase  
used to override parts of PortalGenerator to take shortcuts when  
constructing the site in a test environment.  we have not yet  
implemented a similar setup w/ the GenericSetup based installation,  
so test construction is a bit slower, and relatively extraneous  
products like kupu and ExternalEditor need to be installed before the  
tests will run.

now that i've made the changes to PloneTestCase (which Archetypes  
uses) and the ATContentTypes test setup, the tests are at least  
running.  Archetypes has 10 failures, 92 errors out of 329 tests.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Mitchell | 10 Dec 2005 09:45
Favicon

Re: Current PLIP status

On Friday 09 December 2005 11:04 pm, Rob Miller wrote:
> On Dec 9, 2005, at 6:47 PM, Alec Mitchell wrote:
> > OK framework folks, here is a summary of the current state of
> > things as per
> > our last discussion and some followup with the relevant devs.  I'd
> > appreciate any additions or disagreements:
> >
> > PLIP #102: PlonePAS:
> > 	Another mature third product that is in production use, and for
> > which the
> > integration work is mostly done.  Enfold is standing behind the
> > product and
> > it is apparently (nearly?) ready to merge.  The TODO list indicates
> > a few
> > items that seem pretty important (role mapping, caching,
> > listMemberIds), and
> > migration needs to be tested on a few reasonable sites.  A big
> > lingering
> > question, what does this mean for CMFMember?
>
> CMFMember will not work w/ PlonePAS, at all.  chances are that it
> never will.  my current thought is to write a new product, based on
> Membrane, that will replace CMFMember, providing a (hopefully
> ContentSetup-based) migration path forward.  i'm hoping to start
> working on this at the snow sprint.
>
> > Does it matter?
>
> i think it does.  there are quite a few folks out there using
> CMFMember, and this is going to be a show-stopper for all of them.  i
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Kowalczyk | 10 Dec 2005 09:42
Picon
Favicon

Re: Current PLIP status

On Fri, 09 Dec 2005 23:04:48 -0800, Rob Miller wrote:
>> question, what does (PLIP #102: PlonePAS) mean for CMFMember?
>
> CMFMember will not work w/ PlonePAS, at all.  chances are that it never
> will.  my current thought is to write a new product, based on Membrane,
> that will replace CMFMember, providing a (hopefully ContentSetup-based)
> migration path forward.  i'm hoping to start working on this at the snow
> sprint.
> I think it does (matter).  there are quite a few folks out there using
> CMFMember, and this is going to be a show-stopper for all of them.  i
> think scrapping it and building a new product is the way to go, and i
> don't expect it to be terribly hard, but i'm not going to be able to do
> it alone.  RockyBurt and SashaV have already said they want to help,
> it'd be great if we could get a few more hands.

Would it help to create a fundable.org project to facilitate time or
travel for the people with the skill to solve this problem?

I have an interest in seeing a CMFMember workalike built on top of
Membrane/Memblets ASAP, hopefully ready for testing near the time
Plone-2.5 moves to beta. I don't personally have any CMFMember
deployments, but I agree that migration will be an imperative for many.

I also favor cooperation between two intriguing PlonePAS type-membership
projects. Hopefully Helge and Jens et al. would be willing to converge to
a single product supporting both facets of PlonePAS integration, perhaps
PLIP-tracked for Plone-3.0.

  http://svn.bluedynamics.net/svn/public/Memblets/trunk
  http://svn.plone.org/svn/collective/Membrane/trunk
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rob Miller | 10 Dec 2005 10:01
Favicon

Re: Re: Current PLIP status

On Dec 10, 2005, at 12:42 AM, Jeff Kowalczyk wrote:

> On Fri, 09 Dec 2005 23:04:48 -0800, Rob Miller wrote:
>>> question, what does (PLIP #102: PlonePAS) mean for CMFMember?
>>
>> CMFMember will not work w/ PlonePAS, at all.  chances are that it  
>> never
>> will.  my current thought is to write a new product, based on  
>> Membrane,
>> that will replace CMFMember, providing a (hopefully ContentSetup- 
>> based)
>> migration path forward.  i'm hoping to start working on this at  
>> the snow
>> sprint.
>> I think it does (matter).  there are quite a few folks out there  
>> using
>> CMFMember, and this is going to be a show-stopper for all of them.  i
>> think scrapping it and building a new product is the way to go, and i
>> don't expect it to be terribly hard, but i'm not going to be able  
>> to do
>> it alone.  RockyBurt and SashaV have already said they want to help,
>> it'd be great if we could get a few more hands.
>
> Would it help to create a fundable.org project to facilitate time or
> travel for the people with the skill to solve this problem?

certainly sponsorship helps, although at this point it's more an  
issue of time than money, for me.

> I have an interest in seeing a CMFMember workalike built on top of
(Continue reading)

Permalink | Reply | 0 comments |

Gmane