[Framework-Team] package syndication: practical problems + possible solution

[Timo Stollenwerk]

Am 07.04.2014 23:15, schrieb Johannes Raggam:
> Hey FWT,
> 
> I want to share a problematic experience with the Python-package
> syndication effort, the https://dev.plone.org/ticket/13283 PLIP.
> 
> At wine/beer sprint we moved plone.app.event's timezone vocabs to
> plone.app.vocabulary, because we found that generally useful and worth
> to be used elsewhere.
> Then we moved plone.app.event's controlpanel to P.CMFPlone,  because it
> just does datetime related settings, not necessarily specific to the
> calendaring framework plone.app.event.
> 
> Now, the current refactored plone.app.event 2.0 branch, which somehow
> depends on newest p.a.vocabularies and P.CMFPlone, cannot easily be used
> in Plone < 5, just because of the dependency on CMFPlone.
> 
> With the package syndication effort, we might give up some inter-version
> compatibility of selected packages like plone.app.event, and others,
> just because other dependencies like p.a.controlpanels cannot be
> released independently from CMFPlone anymore.

I fully agree with the notion that we have too many packages and that
it does not make any sense to spread functionality across packages
that are so tightly integrated that they can't be released separately.
This not only leads to more work during the release process but also
to problems with testing and CI. On the other hand I like it a lot
that during my projects I can checkout single Plone core packages, fix
bugs without the need to use the latest Plone release or make an
internal full Plone release. The bottom line is, we have to carefully
discuss and decide which packages should be merged and which packages
should not.

In my opinion p.a.event is not a good candidate for the merge. At
least not in its current form. Like p.a.discussion or even
plone.app.contenttypes it should not be part of the core package and
remain independent. Those packages provide very important
functionality in Plone core, though, they are in general replaceable
and should stay that way, to make it easier to replace that
functionality in the future and also to keep it testable.

During the move from ATContentTypes to p.a.contenttypes we saw how
many packages and tests were relying on ATContentTypes internals
making it really hard to replace that functionality. If we move more
packages into the core, just because it is easier now (and not because
those packages are so tightly related that it does not make sense to
ship them separately) we will end up with a big mess of packages. In
addition, moving functionality into the core will make all our tests
slower because the test runner has not only to set up a small part of
Plone core but also maybe p.a.event, p.a.contenttypes. I like it a lot
that we were able to remove ATContentTypes/p.a.contenttypes from the
Plone core testing layer during that refactoring.

Coming back to p.a.event. If the "event" controlpanel is independent
from p.a.event, it can be moved to the core. Though, this only makes
sense if other implementations use those settings or if core
functionality reads/writes those settings. Otherwise the control panel
could remain in p.a.event I guess.

I said that before. My feeling is that for Plone 5 the Dexterity part
of p.a.event should be moved into p.a.contenttypes, keeping
plone.event for the event calculation stuff and maybe even move some
parts into the core. We have to discuss this in detail but I wouldn't
want neither p.a.contenttypes nor p.a.event in a big core package.
This would mean that whenever you want to change something in
p.a.event or use a fix in your own projects you need a full plone.app
or CMFPlone release. What if you want to add an enhancement and use it
with an older Plone version? That will be a lot harder with a big
plone.app package that contains lots of other functionality.

The bottom line is: If we can keep packages independent we should do
that (and not move everything into a big core package because it
currently seems easier). If a package is so tightly interrelated with
core though, it does not make any sense to ship it separately (this is
what the PLIP is about), we should move it into core. plone.app.event
clearly belongs to the first category in my opinion.

Cheers,
Timo