Open Stack

On Thu, 2020-03-12 at 18:09 -0400, Brian Rosmaita wrote:
> On 3/12/20 10:37 AM, Thierry Carrez wrote:
> > Thierry Carrez wrote:
> > > [...]
> > > So one solution might be:
> > > 
> > > - Define multiple roles (release liaison, event liaison, meeting 
> > > chair...) and allow them to be filled by the team as they want, for 
> > > the duration they want, replaced when they want (would just need +1 
> > > from previous and new holder of the role)
> > > 
> > > - Use the TC as a governance safety valve to resolve any conflict 
> > > (instead of PTL elections)
> > 
> > Proposed as a strawman at: https://review.opendev.org/#/c/712696/
> > Feel free to comment on how crazy that is there...
> > 
> 
> Maybe the proposal itself is crazy, maybe not, but the timing of this is 
> certainly crazy.

at least form a nova perspecitve this is an appriate time as we were in a postion where due
to changes in errics employment he would not be able to continue with his role as novas ptl.
with as you indicate later ther are many factors going on currenlty on the world at larage and
in people personal and internal commitments so we were in a postion where we might not have a candiate
to take over until the next election and we may or may not have candidates for that election.

fortunetly gibi has been able to find time to become novas interim ptl for the rest of the ussuri
cycle. i am not going to speak on behalf of nova but i suspect that if the core team had the option
of moving to a ptl less model then they might just do that as from my experince nova ptl have never or very
really been in a postion where they must be  a tie breaker between other cores out side of there normal role as
a core themeses. so for nova i dont think that aspect of the ptl role is partically relevent as the core team general
reaches consensious without requiring a ptl to step in and make a dessions.

given the lack of ptl candiages over the last few cycle i think removing hte need to have a candiate run in a election
would encurage decentralistion of the set of jobs that defualt to the ptl.

if gibi or someone decied to run as ptl for victoria have the flexablity to not require a ptl does
not perculde operationg as we do today, it just takes the pressure off contiutors as we wont have to involve
the tc if noone puts there name forward for the election. we can fall back to a ptl less model and just ensure
that each of the function are performed by someone in a timely manner.

so if this was to proceed i was hoping that it could take effect form the victoria cycle.
that said i dont dislike the ptl role, i think it has served use well and could continue too but
this is not the first time in the last few release where i fell like the requirement for there to be a ptl
has been more harmful then helpful as i think without a nominated ptl the work would still have got
done more organically with less process.
> 
> This is not a good time to be having this discussion.  We're just about 
> to start week R-8.  The final release for non-client libraries is at 
> R-6, the final release for client libraries and feature freeze is at 
> R-5.  So there is (should be) a lot of stuff happening in the projects 
> right now, that may preclude people from being as active in this 
> discussion as they might wish.  Plus, I don't know about y'all, but the 
> current pandemic is making simple day-to-day living more stressful on me 
> than it was a few weeks ago.
> 
> What I'm saying is that I'd appreciate clarification on the timeline for 
> this change.  This is the kind of thing that could use discussion at the 
> PTG.  If the point of Thierry's patch is to prepare for discussion at 
> the PTG, then that's great, I personally will revisit it at R-1, and be 
> ready to have a productive discussion.  But I think this is not a good 
> time to make the usual "silence is assent" inference to a proposal 
> floated on the mailing list.
> 
> cheers,
> brian
>