[Framework-Team] Re: 3.0 bundle broken?

Hanno Schlichting plone at hannosch.info
Wed Nov 22 11:00:24 UTC 2006


Hi.

/me is back from ten days of vacation in the southern parts of Spain
without an Internet connection :)

Martin Aspeli wrote:
>> Same happend to me last night and I was too tired to debug this :-(

I circumvented the problem for now, by pointing GenericSetup to an
explicit older revision. The problem resulted from the merge of my
GSLocalAddons product into GenericSetup by Jens Vagelpohl.

The exact problem is that we have an exportimport handler registered in
GenericSetup itself for zope.component.interfaces.IComponentRegistry now
and a second one in plone.app.portlets.

This means we have two adapters registered for the exact same interface
combination which isn't possible and results in a
ConfigurationConflictError.

I'm not sure what the best way is to fix this problem properly :(

>> Also, be it for this or any other reason, I couldn't get the wicked
>> nor the iterate bundle to start up which I had planed to take a closer
>> look at.
>>
>> It seems to me that there might be something wrong with our process
>> leading to a substancial waste of time due to the fact that we usually
>> link to moving targets (aka trunk) in our review bundles.
>> Maybe we should recommend to specify at least a revision number when
>> linking to trunk versions of dependencies or anything else that
>> would lead to a better defined and more stable state?
> 
> I think linking to trunk of our own bundles (i.e. anything in
> svn.plone.org/svn/plone) makes sense. Bundle maintainers will need to
> ensure their bundles remain working until they're merged - checking in
> code that breaks your bundle is just stupid. :)
> 
> Linking to a branch or tag of other software may make sense, I think
> it should be done on a case-by-case basis. On the one hand, we lose
> productivity when something changes under us (and I have no idea what
> happened in this case, and it annoys me greatly...), but we also risk
> getting out of sync with our dependencies if we fall too far behind
> them and no-one bothers to regularly update to the latest revision or
> whatever.

The main problems with the 3.0 bundle I have seen so far resulted either
from changes in the CMF or PAS. It might actually make sense to point
these externals to specific revisions as there is quite some work going
on at least in the CMF. This is the prize we have to pay for catching up
with the latest version ;)

For review bundles it might actually make sense to point to specific
revisions of all but your own products/branches. This way you could
guarantee that your bundle actually works without having to recheck
everyday if some changes in some other code broke anything.

The only problem I can see with this is that the task of merging a
review bundle into the main development line becomes a bigger task as
quite some new problems might occur. But I think this is a good
trade-off if we get reliable review bundles this way.

Hanno





More information about the Framework-Team mailing list