| *** chandankumar has quit IRC | 03:05 | |
| *** dklyle has joined #openstack-tc | 04:23 | |
| *** jaosorior has joined #openstack-tc | 04:28 | |
| *** dklyle has quit IRC | 04:38 | |
| *** openstackgerrit has quit IRC | 05:18 | |
| *** ricolin has joined #openstack-tc | 05:39 | |
| *** jaosorior has quit IRC | 05:59 | |
| *** jpich has joined #openstack-tc | 07:07 | |
| *** evrardjp has joined #openstack-tc | 07:08 | |
| *** jaosorior has joined #openstack-tc | 07:46 | |
| evrardjp | I am not sure to understand the risk and problems for openstack (wide term) of having a project considered as leaderless -- can someone explain that to me? For me it's bad for the project in itself...? | 08:09 |
|---|---|---|
| *** e0ne has joined #openstack-tc | 08:20 | |
| *** jaosorior_ has joined #openstack-tc | 08:35 | |
| *** jaosorior has quit IRC | 08:40 | |
| *** dtantsur|afk is now known as dtantsur | 08:49 | |
| *** cdent has joined #openstack-tc | 09:25 | |
| *** ricolin_ has joined #openstack-tc | 09:38 | |
| *** jaosorior_ is now known as jaosorior | 09:39 | |
| *** ricolin has quit IRC | 09:40 | |
| *** ricolin_ has quit IRC | 09:58 | |
| *** tosky has joined #openstack-tc | 09:59 | |
| *** jaosorior has quit IRC | 10:09 | |
| *** jaosorior has joined #openstack-tc | 10:11 | |
| *** tosky has quit IRC | 10:19 | |
| persia | evrardjp: My read is that any project that is leaderless is ungovernable under the rules by which we have chosen to play. As we accumulate code that we cannot govern, we degrade the signal/noise ratio of what we produce. Once that gets low enough for anyone to get frustrated, there is the potential for the "openstack is ungoverned broken code" to emerge. | 10:35 |
| persia | In practice, if people use some bit of code, there is usually at least someone willing to do the 10-15 hours a cycle required to be PTL of a mature/inactive project. | 10:36 |
| evrardjp | precisely -- or code should maybe die | 10:36 |
| persia | I think a lot of fuss is made about it, and we work ourselves up too much sometimes, but my experience with projects at risk is that simply reaching out to the active folk often results in a volunteer in a couple days. | 10:36 |
| evrardjp | ok | 10:37 |
| persia | Yes, if the project is leaderless and there is nobody willing to volunteer, then it makes sense to retire that project, which is again not a huge volume of work, but needs a volunteer (either someone on the TC or an appointee). | 10:38 |
| evrardjp | I was just thinking of avoiding to repeat mistakes | 10:38 |
| persia | (so, when the election doesn't get someone, then the TC needs to either find someone to be PTL or find someone to retire the project. Fairly routine, except "leaderless" is a frightening word.) | 10:38 |
| evrardjp | yeah that's 100% true -- frightening. | 10:39 |
| evrardjp | my point was it was maybe not so frightening | 10:39 |
| evrardjp | it's maybe no such big deal -- but I understand the problem with your first answer | 10:40 |
| cdent | evrardjp: I kind of agree with you. Sometimes things just die. It's okay. | 10:40 |
| persia | What sort of mistake are you thinking might be repeated? | 10:41 |
| evrardjp | there might be a risk for projects getting a safety rope a few times in a row that is hidden -- maybe some projects don't get to die when they actually should or they don't get the proper attention to new contributors when they should | 10:43 |
| evrardjp | I don't mean that's what's happening but it could. | 10:43 |
| smcginnis | I've been concerned about that with the number of times the release team needs to "force" a release for projects that are no longer participating. | 10:44 |
| smcginnis | We at least have a flag to track that now. | 10:44 |
| *** gouthamr has quit IRC | 10:44 | |
| smcginnis | I just don't want to have a lot of those kinds of releases without much visibility that there is a large part of a release that was not actually driven by a team, but a process. | 10:44 |
| evrardjp | smcginnis: well that's how it was raised in my mind -- maybe we don't have a good view of things | 10:45 |
| evrardjp | it's good that we have a flag now | 10:45 |
| * cdent wonders if smcginnis is up early or in china | 10:45 | |
| evrardjp | haha | 10:45 |
| smcginnis | cdent: Another one of those mornings... | 10:45 |
| evrardjp | :D | 10:45 |
| * evrardjp pours a good coffee and hands it to smcginnis | 10:46 | |
| smcginnis | I do still think we need to think through how we handle projects that have gone away vs projects that are just not active. | 10:46 |
| smcginnis | It's not always clear which. | 10:46 |
| evrardjp | that's starts with a definition of "Gone away" then | 10:46 |
| smcginnis | evrardjp: Don't worry, I have a trusty espresso maker. ;) | 10:47 |
| smcginnis | I'm thinking those projects where no one is still interested in fixing the bugs and working on updates and requested features. | 10:47 |
| smcginnis | Vs projects where there might be some bugs and desired features, but for the most part are stable. | 10:48 |
| cdent | a major problem distinguishing "gone away" and "not active" is that there are plenty of projects that sometimes appear dead upstream but are actively members of distributions or products | 10:48 |
| evrardjp | ok for me the first case is "dying" not "gone away" -- "gone away" is when ppl are not really actively focusing on it, but can return to it soon for $businesspurpose | 10:48 |
| persia | Another is when projects are feature-complete, and so don't need much activity (and the incumbent PTL may not remember to do the minimum, like participate in the release). | 10:49 |
| evrardjp | not actively focusing on it is a risk to miss deadlines, forget duties | 10:49 |
| smcginnis | evrardjp: True, just trying to use less exteme phrases, but dying is probably more accurate. | 10:49 |
| evrardjp | cdent: active members of distributions should be active at making sure the deadlines and duties are met, no? | 10:50 |
| persia | evrardjp: They have no incentive to do so: their local deadlines are the important ones, and they can use "upstream" as a "them" on which to blame delays if they are having issues. | 10:50 |
| cdent | evrardjp: you would think so, but we have plenty of evidence that that is not the case | 10:50 |
| smcginnis | Many examples. | 10:51 |
| persia | (this works better if folk are actively not participating in the upstream identity, which unfortunately means that distro developers sometimes cling to "distro developer" or "just packaging" even if doing the majority of active work in a project.) | 10:51 |
| evrardjp | I think that's where the problem lies cdent / smcginnis + persia | 10:52 |
| evrardjp | oh god so many issues, so little time. | 10:53 |
| persia | I think it's just a natural side effect of having both "upstream" and "distro" releases. Either one can be a sensible model. Both leads to confusion and split identity. | 10:53 |
| persia | heh | 10:53 |
| smcginnis | On the other hand, if distros are using a project, making their own changes, and not contributing upstream - if that project dies upstream, should we even care. They've kind of brought it on themselves. | 10:53 |
| evrardjp | persia: agreed. | 10:53 |
| evrardjp | smcginnis: that was my initial point. | 10:53 |
| smcginnis | It gets into a grey area where you can almost consider those commercial versions as forks of a dead project. | 10:54 |
| evrardjp | "is that very important that... " | 10:54 |
| evrardjp | smcginnis: if it's gray for the vendor, I'd say "why do we care?" | 10:54 |
| cdent | smcginnis: our (meaning openstack "leadership") over-willingness to compensate for downstream lack of commitment is our current crisis | 10:54 |
| evrardjp | as long as it's not gray in the community | 10:54 |
| smcginnis | We do have some public perception to think about ("OpenStack is dying!!") but then again, maybe a little atrophy is a good thing. | 10:55 |
| persia | smcginnis: From a distro perspective, I think the answer is "no", although some distros have policies that require "active upstream". From an upstream perspective, I think the answer is "no", because the project is clearly not participating in the wider community (in this case, "OpenStack"). As long as we cling to the idea that "distros" fund "upstream", we end up in a funny loop where we think we must care. | 10:55 |
| evrardjp | cdent: +1 | 10:55 |
| smcginnis | cdent: I think you're right. | 10:55 |
| persia | cdent: Absolutely. | 10:55 |
| cdent | Probably because we are trying to preserve some of the gravy train... | 10:55 |
| smcginnis | persia: That's very true as well (the loop) | 10:55 |
| evrardjp | persia: well phrased that's a good summary | 10:55 |
| evrardjp | cdent: I imagine this as the eurostar. | 10:56 |
| persia | cdent: Or we're trying to milk a chicken, to use another metaphor. | 10:56 |
| evrardjp | "the gravy train" | 10:56 |
| smcginnis | I'm sensing a Denver tie in here. | 10:56 |
| evrardjp | hahaha | 10:56 |
| cdent | "funny loop" is right | 10:57 |
| persia | smcginnis: http://images.footballfanatics.com/FFImage/thumb.aspx?i=%2fproductImages%2f_82000%2fFF_82764_xl.jpg&w=400 ? | 10:57 |
| cmurphy | speaking as a distro, a lot of the reason we package some things is because it is part of openstack, not because we need it, and so if it dies or is dying there's not much urgency on our part to step up unless a customer actually needs it | 10:58 |
| smcginnis | persia: I was thinking more like this - https://memegenerator.net/img/instances/42796416/all-aboard-the-gravy-train.jpg | 10:58 |
| cdent | cmurphy: I think that's a good point. The feedback goes in both directions and we've got a situation where upstream says "openstack is X" and so all of X goes in the distro, but from the distro's customers standpoint only parts of X matter | 10:59 |
| cdent | more of the "funny loop" | 10:59 |
| smcginnis | Was just going to say that - the funny loop concept is seeming very apropos. | 11:00 |
| persia | smcginnis: heh, although mine was more about me misreading "a Denver tie in here" the first time, rather than intending to be meaningful. | 11:01 |
| evrardjp | cmurphy: that's why killing a project that's dying is not so bad IMO -- It reduces the costs along the line to the consumer | 11:01 |
| cmurphy | evrardjp: ++ | 11:01 |
| evrardjp | cmurphy: if there is a customer willing it, then there is a real evaluated cost of development and a business case | 11:02 |
| persia | Although defining "dying" is hard. If something works and has thousands of users, and nobody at the helm, is it dead? | 11:02 |
| evrardjp | where if it's "dying" there is a hidden cost that's not accounted. | 11:02 |
| evrardjp | persia: that's not "dying" with my terms above, that's "stable" :) | 11:02 |
| evrardjp | I guess that's what smcginnis was saying with "not active" | 11:02 |
| evrardjp | words are hard. | 11:03 |
| persia | As long as OpenStack measures "death" by things like fixing upstream bugs and participating in releases, but subscribes to a model where users interact with distros, there is naturally no meaningful link between most users and the governance of the project. | 11:03 |
| smcginnis | Part of this I think is the need to defined some terms with common shared meaning. The conversation gets hard when everyone has slightly different understandings of what these states of projects mean. | 11:03 |
| persia | If OpenStack never releases, but only provides software to distros to package, working with distros as intermediaries to discover user needs, it becomes clear what is used/unused, and what needs help (or should be retired). This is known to work. | 11:04 |
| evrardjp | persia: you want to move away from this model and use tags like supported-by-SUSE|supported-by-RH? | 11:04 |
| cmurphy | persia: if it has thousands of users then it is guaranteed to have bug reports, and if there is no one even looking at the bug tracker that sounds pretty dead | 11:04 |
| persia | Similarly, if OpenStack completely ignores distros (or uses trademark rules to prevent distro patching), and releases to users, it becomes clear what is used/unused, and what needs help (or should be retired). This is known to work. | 11:05 |
| persia | Somewhere fuzzy between the two is awkward and painful. | 11:05 |
| evrardjp | supported-by-<vendor/distro/something> | 11:05 |
| cdent | "fuzzy between the two" is our MO | 11:05 |
| evrardjp | persia: mmm interesting | 11:05 |
| cdent | (on all sorts of dimensions) | 11:05 |
| evrardjp | cdent: haha | 11:05 |
| persia | evrardjp: I prefer a slightly different taxonomy for support (wherein some supporting organisation publishes a claim on what they support, rather than individual projects receiving updates of all the orgs that support that project). | 11:06 |
| cdent | largely because we are unwilling to upset anyone | 11:06 |
| evrardjp | persia: trademark rules seems opposite to the goal IMO | 11:06 |
| persia | cdent: To be fair, that is often that individuals in that "we" are unwilling to upset their own employers (or the employers of their peers, upon whose support they depend for their agenda). There are lots of folk who end up being upset by OpenStack that don't fund senior members of our community. | 11:07 |
| persia | evrardjp: I was referencing how Mozilla used Firefox trademark to prevent distro patching in the past, not current OpenStack trademark rules. | 11:07 |
| evrardjp | ok | 11:08 |
| evrardjp | sorry to have restarted conversation on this can of worms. | 11:09 |
| evrardjp | I prefer understanding things :) | 11:09 |
| * smcginnis looks at the definition of debridement | 11:09 | |
| cmurphy | we definitely hate having conversations in this channel | 11:10 |
| evrardjp | cmurphy: It's not the first time I am lurking here :p | 11:12 |
| evrardjp | I should say -- I prefer starting a conversation that ends up with actionable items. | 11:13 |
| smcginnis | I think one action is we need to more clearly define what these active states are for projects, then separately decide if we want to be more active about doing something based on those states. | 11:14 |
| evrardjp | that sounds okay to me -- lay of the land first. | 11:16 |
| cdent | smcginnis: sounds like a good two agenda items at least | 11:16 |
| cdent | (although I think the way in which within 3 months of the PTG or forum we put off any conversations for in person, and then don't actually talk about them much because we don't have time is a bit of a problem) | 11:17 |
| persia | I would suggest that labeling the states things like "A", "B", "C" or "foo", "bar", "baz" or any other semantically meaningless model is a good way to separate the discussion of the state of the project from the discussion of how projects reach those states. | 11:17 |
| persia | cdent: I would be more inclined to agree if we didn't have such punctuated progress at those events. For models like Apache, where in-person activity "doesn't count", it is essential to have all the discussion between conferences (with the conferences used only as background to ongoing discussion). I think we have the other model, but it depends on us actually meeting in person every three months or so (as otherwise it takes even longer to come | 11:19 |
| persia | to consensus). | 11:19 |
| smcginnis | cdent: I agree. | 11:19 |
| cdent | I have a confused metric for "progress" that needs some recalibration | 11:20 |
| smcginnis | I hope with the passing of the PTG we don't end up having six month punctuated progress. | 11:21 |
| persia | Yes :) | 11:26 |
| * cdent tilts head forward, takes of glasses, squeezes bridge of nose with thumb and first finger | 11:30 | |
| cdent | off! | 11:30 |
| * cdent sighs | 11:30 | |
| *** rosmaita has joined #openstack-tc | 11:34 | |
| *** mriedem has joined #openstack-tc | 11:36 | |
| *** tosky has joined #openstack-tc | 11:41 | |
| *** ricolin has joined #openstack-tc | 12:13 | |
| *** jaosorior has quit IRC | 12:18 | |
| *** jaosorior has joined #openstack-tc | 12:19 | |
| jroll | persia | Although defining "dying" is hard. If something works and has thousands of users, and nobody at the helm, is it dead? <- it seems so. look at us panicking over paste being in this situation | 12:27 |
| jroll | bitrot is a thing, you need someone keeping an eye on it | 12:27 |
| *** tosky has quit IRC | 12:35 | |
| cdent | (no updates on the paste situation, btw. World stops in europe for august) | 12:44 |
| smcginnis | cdent: You're obviously not taking advantage of being in Europe then. | 12:47 |
| cdent | probably should, may be my last chance | 12:48 |
| *** jroll has quit IRC | 12:59 | |
| *** jroll has joined #openstack-tc | 13:00 | |
| cmurphy | heh | 13:02 |
| *** mriedem has quit IRC | 13:03 | |
| *** SteelyDan is now known as dansmith | 13:25 | |
| *** jaypipes has joined #openstack-tc | 13:26 | |
| *** ricolin has quit IRC | 13:38 | |
| *** ricolin has joined #openstack-tc | 13:48 | |
| dhellmann | tc-members: I have been using the formal voting rules for election results and PTL volunteers. That resulted in some delays this cycle, so I'm thinking about whether we want to shorten the waiting period on those patches. What do you all think? | 13:54 |
| dhellmann | and speaking of volunteers, we need to consider what to do with searchlight: https://review.openstack.org/#/c/590601/2 | 13:55 |
| dhellmann | and freezer: https://review.openstack.org/590071 | 13:56 |
| cdent | dhellmann: I'm not sure it matters. On the election results, the new PTLs already know, making the reviews official can be slow or fast, doesn't impact reality. On the volunteers, I think formal votes is right as we want some proper thought. | 13:56 |
| dhellmann | though I suppose for freezer at least we have a majority indicating that we should accept the volunteer | 13:56 |
| dhellmann | cdent : yeah, I was thinking it seemed silly for the election results to sit there for a week waiting for objections | 13:56 |
| dhellmann | and that it would have been convenient this time around to have them landed so the volunteers could write their patches more easily. although I guess we don't necessarily want to optimize for that case | 13:57 |
| *** openstackgerrit has joined #openstack-tc | 13:59 | |
| openstackgerrit | Merged openstack/governance master: Add Stein goal for upgrade checkers https://review.openstack.org/585491 | 13:59 |
| openstackgerrit | Merged openstack/governance master: Adding Dariusz Krol candidacy for Trove PTL https://review.openstack.org/588510 | 13:59 |
| openstackgerrit | Merged openstack/governance master: remove expired atcs https://review.openstack.org/588586 | 13:59 |
| openstackgerrit | Merged openstack/governance master: Update Chef OpenStack PTL email address https://review.openstack.org/591212 | 13:59 |
| cdent | dhellmann: did you see the somewhat related discussion about "dead/gone/stable" above? | 14:00 |
| openstackgerrit | Merged openstack/governance master: Update with results from the Stein PTL election https://review.openstack.org/589691 | 14:00 |
| dhellmann | I'm still catching up on things this morning (I had ~400 python3-first emails from gerrit to wade through) | 14:01 |
| persia | jroll: I agree that there exists a group that defines it that way and panics. I'm not sure that such a group should panic. I agree that bitrot is a thing. I'm also aware of codebases that don't release very often (and this is considered a good thing). One of my favorites is tex, which tries very hard not to release, where possible, despite being aggressively and actively maintained. | 14:03 |
| dhellmann | I'm personally more concerned with users than distros. | 14:03 |
| dhellmann | We release because we have users who do not pay vendors for packaging and support. | 14:03 |
| dhellmann | So if we have a project clearly abandoned upstream, we should communicate that. Then either users or distros can decide if they want to be involved in keeping it going. | 14:03 |
| persia | dhellmann: I think keeping to the formal rules for elections is good. On the other hand, maybe it is worth planning the voting more aggressively, with the intent of trying to land a set of changes within a week or so after the election closes. | 14:04 |
| dhellmann | That seems to be what has happened with both freezer and searchlight this cycle, where the folks from ZTE (and someone else?) said "but we're using that! we will help!" | 14:04 |
| dhellmann | persia : the delay really seems to have been due to the waiting period. I would have to look, but i think we had enough votes to approve within a couple of days. | 14:05 |
| dhellmann | Maybe the formal-vote rules need to take into account that if we have 11 +1 votes we're probably OK to approve the change. | 14:05 |
| *** annabelleB has joined #openstack-tc | 14:05 | |
| persia | On searchlight: last year, the solution was to reach out to the then PTL and remind them of the expected duties, which resulted in some actions. If that person is no longer interested, maybe they can suggest someone? If this has been tried, then I have no suggestions: my understanding is that there is no future development expected for searchlight, but many users (who are largely satisfied and would be surprised if it went away). | 14:05 |
| dhellmann | though I guess in part the waiting period is for community input, not just tc members | 14:05 |
| dhellmann | persia : we have a volunteer for searchlight now | 14:06 |
| dhellmann | so I think we have a volunteer for each team that was leaderless after the election and where we didn't already agree to disband it | 14:06 |
| persia | dhellmann: I would agree that unanimity is sufficient for approval without waiting. Even so, I think it isn't bad to wait, as long as the wait is expected. Is there a rush? Should maybe we schedule elections a couple weeks earlier to avoid the rush in the future? | 14:06 |
| dhellmann | (like refstack) | 14:06 |
| dhellmann | persia : this time it was inconvenient to have the patch sit up for a while because we had so many volunteers we had to apply. and I guess I just want us to get on with other things, so maybe I should let go of that. :-) | 14:07 |
| dhellmann | cdent : thinking about this some more, I wonder if there's a way in your proposed change to track how many times we have to appoint someone to lead a team? like make that field a list of series names instead of just a single string? | 14:07 |
| persia | Unless this blocks, I think yes, consider it done (pending timeout), and move on anyway. Parallelism for the win :) | 14:07 |
| cdent | dhellmann: that's a reasonable idea: appointed:\n- rocky\n- steind | 14:08 |
| dhellmann | yeah | 14:08 |
| dhellmann | I liked persia's suggestion of using names | 14:09 |
| dhellmann | definitely solves the "what does that date mean" problem | 14:09 |
| cdent | yes | 14:09 |
| cdent | making another version of that is on my today list | 14:09 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: Updating CloudKitty PTL information https://review.openstack.org/590180 | 14:09 |
| openstackgerrit | Merged openstack/governance master: Updating CloudKitty PTL information https://review.openstack.org/590180 | 14:30 |
| dhellmann | cdent : after you make your update, I will go through and propose follow-up patches to update the PTL volunteers we're currently tracking via patches to the election repo | 14:31 |
| cdent | ✔ | 14:31 |
| openstackgerrit | Trinh Nguyen proposed openstack/governance master: Self-nominate as Searchlight PTL https://review.openstack.org/590601 | 14:40 |
| *** annabelleB has quit IRC | 14:42 | |
| *** annabelleB has joined #openstack-tc | 14:42 | |
| *** annabelleB has quit IRC | 14:45 | |
| *** annabelleB has joined #openstack-tc | 14:52 | |
| fungi | i like the formal voting delay. remember the tc are not the only reviewers of governance changes, and it does our community a disservice to pass measures of any kind without sufficient time for input from the constituency | 14:55 |
| openstackgerrit | Trinh Nguyen proposed openstack/governance master: Adding Trinh Nguyen candidacy for Searchlight PTL https://review.openstack.org/590601 | 15:08 |
| jroll | so py3 first... some of our jobs depend on swift. do we have a way to run swift on py2 in devstack with everything else in py3? | 15:31 |
| fungi | i want to say clarkb or ianw had something proposed to put them in separate venvs? | 15:33 |
| dhellmann | jroll : devstack has a variable that controls which apps are installed with python3 | 15:34 |
| dhellmann | at least it did a year ago; that may have changed when I wasn't looking | 15:34 |
| dtroyer | DISABLED_PYTHON3_PACKAGES: swift | 15:34 |
| jroll | awesome, thanks y'all :) | 15:34 |
| dtroyer | under vars: devstack_localrc: | 15:34 |
| dhellmann | thanks dtroyer | 15:34 |
| dtroyer | nothing like a little devstack/zuul support in the TC channel :) | 15:35 |
| clarkb | there is also a method for indicated swift should be installed python2 and not python3, but I think we mostly just turn it off | 15:35 |
| dtroyer | jroll: that's actually not quite enough… I'm looking in OSC's .zuul.conf | 15:36 |
| dtroyer | the osc-functional-devstack-tips job | 15:36 |
| jroll | dtroyer: ok, I can check that out. thank you | 15:37 |
| jroll | I guess I was asking more generally "are we ready", not for support, but re-reading it does look like a support ask. my fault :) | 15:37 |
| dtroyer | ah, I'm in a make-more-things-run-in-zuul mode :) | 15:38 |
| smcginnis | The swift team has made some progress on py3 support, so hopefully in the near future there's no need for special handling. | 15:41 |
| dhellmann | jroll : before you start, please read http://lists.openstack.org/pipermail/openstack-dev/2018-August/133232.html | 15:43 |
| dhellmann | it sounds like you're just working on functional tests, which should be fine, but just in case... | 15:43 |
| jroll | dhellmann: oh you think I have enough free time to start the day the goals are announced. :) | 15:43 |
| dhellmann | jroll : if you're asking questions, you've already started, right? ;-) | 15:44 |
| jroll | heh | 15:44 |
| dhellmann | anyway, there are some patches we don't want people to write by hand | 15:44 |
| jroll | totally, appreciate the link :) | 15:45 |
| dhellmann | I was going to wait to send that until tomorrow, but since you expressed interest I wanted to stay out in front of any changes :-) | 15:45 |
| jroll | ha | 15:45 |
| *** gouthamr has joined #openstack-tc | 15:54 | |
| *** e0ne has quit IRC | 16:03 | |
| *** dklyle has joined #openstack-tc | 16:10 | |
| *** e0ne has joined #openstack-tc | 16:28 | |
| *** jpich has quit IRC | 16:31 | |
| *** masayukig has quit IRC | 16:43 | |
| *** annabelleB has quit IRC | 16:54 | |
| openstackgerrit | Chris Dent proposed openstack/governance master: Add a house rule about how to signal appointed PTLs https://review.openstack.org/590790 | 16:59 |
| *** dtantsur is now known as dtantsur|afk | 16:59 | |
| *** e0ne has quit IRC | 17:01 | |
| *** annabelleB has joined #openstack-tc | 17:02 | |
| *** annabelleB has quit IRC | 17:07 | |
| *** annabelleB has joined #openstack-tc | 17:09 | |
| *** ricolin has quit IRC | 17:16 | |
| *** openstackgerrit has quit IRC | 17:19 | |
| *** eumel8 has joined #openstack-tc | 17:20 | |
| eumel8 | Hello | 17:23 |
| eumel8 | I miss the Extra-ATC deadline in Stein Release Plan. Is there something changed or it's still not there? | 17:24 |
| smcginnis | eumel8: Do you mean you missed submitting names to be added as Extra-ATC? Or you were supposed to be added as an Extra-ATC? | 17:25 |
| dhellmann | eumel8 : https://review.openstack.org/#/c/586751/ was approved on the 6th | 17:25 |
| eumel8 | smcginnes: no, I'm done with Rocky ;) But in the Stein Plan is no date for Extra-ATC scheduled | 17:26 |
| dhellmann | or are you looking for the dates for the next cycle | 17:26 |
| dhellmann | aha | 17:26 |
| dhellmann | yes, I do not see the ATCs deadline on https://releases.openstack.org/stein/schedule.html | 17:26 |
| eumel8 | yep | 17:28 |
| eumel8 | I want to add the date in my diary and there is not date planned ;) | 17:28 |
| dhellmann | I believe that date is dictated by the election schedule | 17:28 |
| dhellmann | and I think the election folks will want to wait until after the current tc election to work that out. tonyb, fungi, persia, or diablo_rojo_phon may have more insight | 17:30 |
| dhellmann | of course, you don't have to wait for the deadline to update the list :-) | 17:31 |
| *** eandersson has quit IRC | 17:32 | |
| fungi | yeah, in the past it's mostly been gauged as however soon before elections provides sufficient time for the tc to review and approve updates | 17:32 |
| fungi | that differs a bit between ptl and tc elections now that they're not held at roughly the same time | 17:32 |
| dhellmann | and I think we need at least a week under the formal voting rules | 17:33 |
| fungi | ultimately whatever the state of the governance repo is at the time the tc chair tags it for a given election, those are the extra-atcs who get included in the electorate | 17:33 |
| dhellmann | speaking of which, I saw a comment in one of the election repo changes that mentioned needing a new tag for the TC election. Let me know when you have a name picked out and I can do that. | 17:35 |
| *** ianychoi_ has joined #openstack-tc | 17:38 | |
| eumel8 | ok, I think it's around R-7 and I will set a pointer at the end of January 2019. Hopefully I'll not too late like this year ;) | 17:38 |
| *** openstackgerrit has joined #openstack-tc | 17:38 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: appoint Omer Anson PTL for Dragonflow for Stein https://review.openstack.org/591470 | 17:38 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: mark Changcai Geng as appointed PTL for Freezer https://review.openstack.org/591472 | 17:41 |
| *** ianychoi has quit IRC | 17:41 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: appoint Sam Yaple PTL of Loci for Stein https://review.openstack.org/591474 | 17:42 |
| *** rosmaita has quit IRC | 17:43 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: mark Dirk Mueller's appointment to PTL as such https://review.openstack.org/591475 | 17:45 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: mark appointed PTLs for Stein https://review.openstack.org/591475 | 17:47 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: appoint Claudiu Belu PTL of Winstackers for Stein https://review.openstack.org/591476 | 17:49 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: mark Trinh Nguyen's appointment as an appointment https://review.openstack.org/591478 | 17:52 |
| dhellmann | cdent : I think that covers everyone ^^ | 17:53 |
| *** e0ne has joined #openstack-tc | 18:30 | |
| persia | As an election official, I'd prefer not to have a defined "extra-ATC deadline", but rather to encourage folk to add extra-ATC as soon as the person in question passes the threshold the PTL applies for that project. | 18:41 |
| persia | My experience is that we often end up asking for the tag within a couple days of setting the dates for the election and only a few days before the election actually starts. This makes it tricky to predict such an "extra-ATC" date much in advance. | 18:42 |
| persia | (yes, we could probably do better, but I'm not sure we have a plan to do so soon, and wouldn't want anyone not to be able to vote just because we hadn't improved.) | 18:43 |
| *** fdegir_ has joined #openstack-tc | 19:17 | |
| *** srwilkers_ has joined #openstack-tc | 19:17 | |
| *** lxkong_ has joined #openstack-tc | 19:17 | |
| *** mgagne_ has joined #openstack-tc | 19:24 | |
| *** tellesnobrega has quit IRC | 19:25 | |
| *** knikolla has quit IRC | 19:25 | |
| *** lxkong has quit IRC | 19:25 | |
| *** fdegir has quit IRC | 19:25 | |
| *** srwilkers has quit IRC | 19:25 | |
| *** mgagne has quit IRC | 19:25 | |
| *** annabelleB has quit IRC | 19:25 | |
| *** srwilkers_ is now known as srwilkers | 19:25 | |
| *** lxkong_ is now known as lxkong | 19:25 | |
| *** fdegir_ is now known as fdegir | 19:25 | |
| *** purplerbot has quit IRC | 19:27 | |
| *** amotoki has quit IRC | 19:27 | |
| *** knikolla has joined #openstack-tc | 19:28 | |
| *** amotoki has joined #openstack-tc | 19:30 | |
| *** e0ne has quit IRC | 19:52 | |
| *** annabelleB has joined #openstack-tc | 20:15 | |
| *** e0ne has joined #openstack-tc | 20:18 | |
| *** purplerbot has joined #openstack-tc | 20:25 | |
| *** e0ne has quit IRC | 20:33 | |
| fungi | persia: yep. the reminder on the calendar came about because we always had teams coming to us after we'd generated the rolls asking if it was too late to propose additions to governance, not considering the turn-around on getting those approved or anything | 20:38 |
| fungi | mostly i just wanted to get them in the habit of updating early and continuously, yes | 20:39 |
| *** cdent has quit IRC | 21:06 | |
| *** e0ne has joined #openstack-tc | 21:50 | |
| *** e0ne has quit IRC | 21:56 | |
| *** annabelleB has quit IRC | 21:59 | |
| *** zaneb has joined #openstack-tc | 22:55 | |
| *** zaneb has quit IRC | 23:03 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
