Thierry Carrez <thie...@openstack.org> wrote:
Ihar Hrachyshka wrote:
[...]
I slightly disagree with enforcing another formal role to all teams. I
feel that we have enough of them (release liaison for one) to cover for
release cross-project work, and projects are free to set their teams
with more roles if needed.
You should probably re-read what I wrote, because there is no
"enforcement" at all. There is merely the added possibility for teams to
pick someone different for release liaison work per-cycle, so that the
person preparing the next cycle is not necessarily the same person who
works on completing the release. Quoting my original email: "some teams
[...] may want to use the same super-human to handle everything [...],
and some others might use two or three humans to spread the load”.
Well, unless you won’t request projects to designate someone specific for
the role, you enforce it. But that’s not my main problem with the proposal,
and I can live with another name assigned to release liaison, I am more
concerned about switching the PTL that oversights the team in the middle of
release cycle.
I somewhat disagree with attempt to document a single project team
hierarchy and impose, top to bottom, same roles on everyone irrespective
to project needs. I understand the need of some ‘liaison’ roles where
project decisions influence other projects, but I feel that now we get
into over-formalizing internal project structure. New roles in a team
should be generally driven by actual needs, from the bottom.
Define "bottom". The need for a release liaison comes from the Release
Management Team, just as the need for an Oslo liaison comes from the
Oslo team. In case this is not clear, the idea of having "release
stewards" comes from the Release Management Team. Quoting my original
email: "a sort of per-cycle release liaison on steroids”.
There is a significant difference between release liaison role defined to
handle cross project work, and release steward defined for what seems to be
purely internal project matters.
I very much disagree with the idea of switching PTL in midterm. I
believe in some cases this proposal will add unnecessary rivalry in
lives of projects.
Define "midterm". If you take into account that the work on a release
cycle starts well before the development branches are open, then it's
the current elections that happen "midterm". Whenever you choose, it's
always at the start of something and the middle of something else.
From where I came (neutron), it does not happen that way, but maybe we are
just bad at handling release cycles? We have release cut-off as an
opportunity to clean the slate and reconsider our direction for the next
release. I don’t think introducing a structure that will allow for
significant direction changes in the middle of the release cycle will be to
the benefit of the project.
But having earlier elections for more smooth power transition would.
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
