[PKG-Openstack-devel] Accepted python-eventlet 0.20.0-1 (source all) into unstable

[Daniel Baumann]

On 11/12/17 02:11, Thomas Goirand wrote:
> It turns out that the classification is, in my opinion, wrong in many
> ways.

great - then adjust that by *discussing* it.

> If you look at the case of Eventlet, it's used only in OpenStack. And
> not just only once, but 38 times (in 38 packages both as runtime and
> build dependency). So to me, it really doesn't fit the bill of being
> "general purpose", and OpenStack is too dependent on it. Best is if it
> can follow the OpenStack release too.

the idea of the classification is that it has no ambiguity and is
therefore simple, easy and clear.

the original "line" was drawn at "is openstack.org upstream, yes or
no?", which is a binary question, so easy to answer (no?).


you're indicating that eventlet is used only by openstack. even if so,
publically, we'll never know if someone uses it privatly as we have no
control of what software people use for their stuff.

this line has ambiguity where it's not quite clear where to put stuff,
to me it doesn't look as suitable as the original one.

also, the main intention was to move all but the openstack-is-upstream
packages to DPMT to share the load of maintenance with DPMT. so, in case
of doubt, we'd lean towards DPMT rather than to keep the package in pkg-OS.

> If we forgot to discuss what the definition of packages that needs to
> move to DPMT, then we may have this discussion now. To me, packages that
> can be moved to DPMT should be:
> 
> - Used by other packages, or at least usefull for other packages, not
> just only by OpenStack.
> - Not having OpenStack as upstream.

i'd do it in reverse (for above reasons) - pkg-OS is the
"last-resort"/fallback bucket. packages are there only if openstack.org
is upstream for - everything else goes to any team (DPMT or whatever is
otherwise fitting).

(i'm uncertain about the reverse: do all packages where openstack.org is
upstream for have to be in pkg-OS? i'd say, as much as possible, yes..
but there might be some exceptions where they still make sense to be
e.g. in DPMT)

> These are all packages from the testing-cabal group in github and other
> testing tools, and should IMO be dealt with as a whole. Currently, these
> aren't in a single team, and that needs to change. I don't mind what
> team, but the current situation where we have a single maintainer for
> some the above is very suboptimal.

DPMT or DPAT (isn't there a python app team or something, to lazy to
look it up right now.. :)?

Regards,
Daniel