Monday, 2018-08-13

*** chandankumar has quit IRC03:05
*** dklyle has joined #openstack-tc04:23
*** jaosorior has joined #openstack-tc04:28
*** dklyle has quit IRC04:38
*** openstackgerrit has quit IRC05:18
*** ricolin has joined #openstack-tc05:39
*** jaosorior has quit IRC05:59
*** jpich has joined #openstack-tc07:07
*** evrardjp has joined #openstack-tc07:08
*** jaosorior has joined #openstack-tc07:46
evrardjpI 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-tc08:20
*** jaosorior_ has joined #openstack-tc08:35
*** jaosorior has quit IRC08:40
*** dtantsur|afk is now known as dtantsur08:49
*** cdent has joined #openstack-tc09:25
*** ricolin_ has joined #openstack-tc09:38
*** jaosorior_ is now known as jaosorior09:39
*** ricolin has quit IRC09:40
*** ricolin_ has quit IRC09:58
*** tosky has joined #openstack-tc09:59
*** jaosorior has quit IRC10:09
*** jaosorior has joined #openstack-tc10:11
*** tosky has quit IRC10:19
persiaevrardjp: 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
persiaIn 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
evrardjpprecisely -- or code should maybe die10:36
persiaI 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
evrardjpok10:37
persiaYes, 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
evrardjpI was just thinking of avoiding to repeat mistakes10: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
evrardjpyeah that's 100% true -- frightening.10:39
evrardjpmy point was it was maybe not so frightening10:39
evrardjpit's maybe no such big deal -- but I understand the problem with your first answer10:40
cdentevrardjp: I kind of agree with you. Sometimes things just die. It's okay.10:40
persiaWhat sort of mistake are you thinking might be repeated?10:41
evrardjpthere 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 should10:43
evrardjpI don't mean that's what's happening but it could.10:43
smcginnisI'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
smcginnisWe at least have a flag to track that now.10:44
*** gouthamr has quit IRC10:44
smcginnisI 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
evrardjpsmcginnis: well that's how it was raised in my mind -- maybe we don't have a good view of things10:45
evrardjpit's good that we have a flag now10:45
* cdent wonders if smcginnis is up early or in china10:45
evrardjphaha10:45
smcginniscdent: Another one of those mornings...10:45
evrardjp:D10:45
* evrardjp pours a good coffee and hands it to smcginnis10:46
smcginnisI 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
smcginnisIt's not always clear which.10:46
evrardjpthat's starts with a definition of "Gone away" then10:46
smcginnisevrardjp: Don't worry, I have a trusty espresso maker. ;)10:47
smcginnisI'm thinking those projects where no one is still interested in fixing the bugs and working on updates and requested features.10:47
smcginnisVs projects where there might be some bugs and desired features, but for the most part are stable.10:48
cdenta 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 products10:48
evrardjpok 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 $businesspurpose10:48
persiaAnother 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
evrardjpnot actively focusing on it is a risk to miss deadlines, forget duties10:49
smcginnisevrardjp: True, just trying to use less exteme phrases, but dying is probably more accurate.10:49
evrardjpcdent: active members of distributions should be active at making sure the deadlines and duties are met, no?10:50
persiaevrardjp: 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
cdentevrardjp: you would think so, but we have plenty of evidence that that is not the case10:50
smcginnisMany 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
evrardjpI think that's where the problem lies cdent / smcginnis + persia10:52
evrardjpoh god so many issues, so little time.10:53
persiaI 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
persiaheh10:53
smcginnisOn 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
evrardjppersia: agreed.10:53
evrardjpsmcginnis: that was my initial point.10:53
smcginnisIt 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
evrardjpsmcginnis: if it's gray for the vendor, I'd say "why do we care?"10:54
cdentsmcginnis: our (meaning openstack "leadership") over-willingness to compensate for downstream lack of commitment is our current crisis10:54
evrardjpas long as it's not gray in the community10:54
smcginnisWe do have some public perception to think about ("OpenStack is dying!!") but then again, maybe a little atrophy is a good thing.10:55
persiasmcginnis: 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
evrardjpcdent: +110:55
smcginniscdent: I think you're right.10:55
persiacdent: Absolutely.10:55
cdentProbably because we are trying to preserve some of the gravy train...10:55
smcginnispersia: That's very true as well (the loop)10:55
evrardjppersia: well phrased that's a good summary10:55
evrardjpcdent: I imagine this as the eurostar.10:56
persiacdent: Or we're trying to milk a chicken, to use another metaphor.10:56
evrardjp"the gravy train"10:56
smcginnisI'm sensing a Denver tie in here.10:56
evrardjphahaha10:56
cdent"funny loop" is right10:57
persiasmcginnis: http://images.footballfanatics.com/FFImage/thumb.aspx?i=%2fproductImages%2f_82000%2fFF_82764_xl.jpg&w=400 ?10:57
cmurphyspeaking 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 it10:58
smcginnispersia: I was thinking more like this - https://memegenerator.net/img/instances/42796416/all-aboard-the-gravy-train.jpg10:58
cdentcmurphy: 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 matter10:59
cdentmore of the "funny loop"10:59
smcginnisWas just going to say that - the funny loop concept is seeming very apropos.11:00
persiasmcginnis: heh, although mine was more about me misreading "a Denver tie in here" the first time, rather than intending to be meaningful.11:01
evrardjpcmurphy: that's why killing a project that's dying is not so bad IMO -- It reduces the costs along the line to the consumer11:01
cmurphyevrardjp: ++11:01
evrardjpcmurphy: if there is a customer willing it, then there is a real evaluated cost of development and a business case11:02
persiaAlthough defining "dying" is hard.  If something works and has thousands of users, and nobody at the helm, is it dead?11:02
evrardjpwhere if it's "dying" there is a hidden cost that's not accounted.11:02
evrardjppersia: that's not "dying" with my terms above, that's "stable" :)11:02
evrardjpI guess that's what smcginnis was saying with "not active"11:02
evrardjpwords are hard.11:03
persiaAs 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
smcginnisPart 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
persiaIf 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
evrardjppersia: you want to move away from this model and use tags like supported-by-SUSE|supported-by-RH?11:04
cmurphypersia: 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 dead11:04
persiaSimilarly, 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
persiaSomewhere fuzzy between the two is awkward and painful.11:05
evrardjpsupported-by-<vendor/distro/something>11:05
cdent"fuzzy between the two" is our MO11:05
evrardjppersia: mmm interesting11:05
cdent(on all sorts of dimensions)11:05
evrardjpcdent: haha11:05
persiaevrardjp: 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
cdentlargely because we are unwilling to upset anyone11:06
evrardjppersia: trademark rules seems opposite to the goal IMO11:06
persiacdent: 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
persiaevrardjp: I was referencing how Mozilla used Firefox trademark to prevent distro patching in the past, not current OpenStack trademark rules.11:07
evrardjpok11:08
evrardjpsorry to have restarted conversation on this can of worms.11:09
evrardjpI prefer understanding things :)11:09
* smcginnis looks at the definition of debridement11:09
cmurphywe definitely hate having conversations in this channel11:10
evrardjpcmurphy: It's not the first time I am lurking here :p11:12
evrardjpI should say -- I prefer starting a conversation that ends up with actionable items.11:13
smcginnisI 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
evrardjpthat sounds okay to me -- lay of the land first.11:16
cdentsmcginnis: sounds like a good two agenda items at least11: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
persiaI 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
persiacdent:  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 come11:19
persia to consensus).11:19
smcginniscdent: I agree.11:19
cdentI have a confused metric for "progress" that needs some recalibration11:20
smcginnisI hope with the passing of the PTG we don't end up having six month punctuated progress.11:21
persiaYes :)11:26
* cdent tilts head forward, takes of glasses, squeezes bridge of nose with thumb and first finger11:30
cdentoff!11:30
* cdent sighs11:30
*** rosmaita has joined #openstack-tc11:34
*** mriedem has joined #openstack-tc11:36
*** tosky has joined #openstack-tc11:41
*** ricolin has joined #openstack-tc12:13
*** jaosorior has quit IRC12:18
*** jaosorior has joined #openstack-tc12:19
jrollpersia | 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 situation12:27
jrollbitrot is a thing, you need someone keeping an eye on it12:27
*** tosky has quit IRC12:35
cdent(no updates on the paste situation, btw. World stops in europe for august)12:44
smcginniscdent: You're obviously not taking advantage of being in Europe then.12:47
cdentprobably should, may be my last chance12:48
*** jroll has quit IRC12:59
*** jroll has joined #openstack-tc13:00
cmurphyheh13:02
*** mriedem has quit IRC13:03
*** SteelyDan is now known as dansmith13:25
*** jaypipes has joined #openstack-tc13:26
*** ricolin has quit IRC13:38
*** ricolin has joined #openstack-tc13:48
dhellmanntc-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
dhellmannand speaking of volunteers, we need to consider what to do with searchlight: https://review.openstack.org/#/c/590601/213:55
dhellmannand freezer: https://review.openstack.org/59007113:56
cdentdhellmann: 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
dhellmannthough I suppose for freezer at least we have a majority indicating that we should accept the volunteer13:56
dhellmanncdent : yeah, I was thinking it seemed silly for the election results to sit there for a week waiting for objections13:56
dhellmannand 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 case13:57
*** openstackgerrit has joined #openstack-tc13:59
openstackgerritMerged openstack/governance master: Add Stein goal for upgrade checkers  https://review.openstack.org/58549113:59
openstackgerritMerged openstack/governance master: Adding Dariusz Krol candidacy for Trove PTL  https://review.openstack.org/58851013:59
openstackgerritMerged openstack/governance master: remove expired atcs  https://review.openstack.org/58858613:59
openstackgerritMerged openstack/governance master: Update Chef OpenStack PTL email address  https://review.openstack.org/59121213:59
cdentdhellmann: did you see the somewhat related discussion about "dead/gone/stable" above?14:00
openstackgerritMerged openstack/governance master: Update with results from the Stein PTL election  https://review.openstack.org/58969114:00
dhellmannI'm still catching up on things this morning (I had ~400 python3-first emails from gerrit to wade through)14:01
persiajroll: 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
dhellmannI'm personally more concerned with users than distros.14:03
dhellmannWe release because we have users who do not pay vendors for packaging and support.14:03
dhellmannSo 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
persiadhellmann: 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
dhellmannThat 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
dhellmannpersia : 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
dhellmannMaybe 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-tc14:05
persiaOn 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
dhellmannthough I guess in part the waiting period is for community input, not just tc members14:05
dhellmannpersia : we have a volunteer for searchlight now14:06
dhellmannso I think we have a volunteer for each team that was leaderless after the election and where we didn't already agree to disband it14:06
persiadhellmann: 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
dhellmannpersia : 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
dhellmanncdent : 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
persiaUnless this blocks, I think yes, consider it done (pending timeout), and move on anyway.  Parallelism for the win :)14:07
cdentdhellmann: that's a reasonable idea: appointed:\n- rocky\n- steind14:08
dhellmannyeah14:08
dhellmannI liked persia's suggestion of using names14:09
dhellmanndefinitely solves the "what does that date mean" problem14:09
cdentyes14:09
cdentmaking another version of that is on my today list14:09
openstackgerritDoug Hellmann proposed openstack/governance master: Updating CloudKitty PTL information  https://review.openstack.org/59018014:09
openstackgerritMerged openstack/governance master: Updating CloudKitty PTL information  https://review.openstack.org/59018014:30
dhellmanncdent : 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 repo14:31
cdent14:31
openstackgerritTrinh Nguyen proposed openstack/governance master: Self-nominate as Searchlight PTL  https://review.openstack.org/59060114:40
*** annabelleB has quit IRC14:42
*** annabelleB has joined #openstack-tc14:42
*** annabelleB has quit IRC14:45
*** annabelleB has joined #openstack-tc14:52
fungii 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 constituency14:55
openstackgerritTrinh Nguyen proposed openstack/governance master: Adding Trinh Nguyen candidacy for Searchlight PTL  https://review.openstack.org/59060115:08
jrollso 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
fungii want to say clarkb or ianw had something proposed to put them in separate venvs?15:33
dhellmannjroll : devstack has a variable that controls which apps are installed with python315:34
dhellmannat least it did a year ago; that may have changed when I wasn't looking15:34
dtroyer        DISABLED_PYTHON3_PACKAGES: swift15:34
jrollawesome, thanks y'all :)15:34
dtroyerunder vars: devstack_localrc:15:34
dhellmannthanks dtroyer15:34
dtroyernothing like a little devstack/zuul support in the TC channel :)15:35
clarkbthere is also a method for indicated swift should be installed python2 and not python3, but I think we mostly just turn it off15:35
dtroyerjroll: that's actually not quite enough… I'm looking in OSC's .zuul.conf15:36
dtroyerthe osc-functional-devstack-tips job15:36
jrolldtroyer: ok, I can check that out. thank you15:37
jrollI 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
dtroyerah, I'm in a make-more-things-run-in-zuul mode :)15:38
smcginnisThe swift team has made some progress on py3 support, so hopefully in the near future there's no need for special handling.15:41
dhellmannjroll : before you start, please read http://lists.openstack.org/pipermail/openstack-dev/2018-August/133232.html15:43
dhellmannit sounds like you're just working on functional tests, which should be fine, but just in case...15:43
jrolldhellmann: oh you think I have enough free time to start the day the goals are announced. :)15:43
dhellmannjroll : if you're asking questions, you've already started, right? ;-)15:44
jrollheh15:44
dhellmannanyway, there are some patches we don't want people to write by hand15:44
jrolltotally, appreciate the link :)15:45
dhellmannI 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
jrollha15:45
*** gouthamr has joined #openstack-tc15:54
*** e0ne has quit IRC16:03
*** dklyle has joined #openstack-tc16:10
*** e0ne has joined #openstack-tc16:28
*** jpich has quit IRC16:31
*** masayukig has quit IRC16:43
*** annabelleB has quit IRC16:54
openstackgerritChris Dent proposed openstack/governance master: Add a house rule about how to signal appointed PTLs  https://review.openstack.org/59079016:59
*** dtantsur is now known as dtantsur|afk16:59
*** e0ne has quit IRC17:01
*** annabelleB has joined #openstack-tc17:02
*** annabelleB has quit IRC17:07
*** annabelleB has joined #openstack-tc17:09
*** ricolin has quit IRC17:16
*** openstackgerrit has quit IRC17:19
*** eumel8 has joined #openstack-tc17:20
eumel8Hello17:23
eumel8I miss the Extra-ATC deadline in Stein Release Plan. Is there something changed or it's still not there?17:24
smcginniseumel8: 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
dhellmanneumel8 : https://review.openstack.org/#/c/586751/ was approved on the 6th17:25
eumel8smcginnes: no, I'm done with Rocky ;)  But in the Stein Plan is no date for Extra-ATC scheduled17:26
dhellmannor are you looking for the dates for the next cycle17:26
dhellmannaha17:26
dhellmannyes, I do not see the ATCs deadline on https://releases.openstack.org/stein/schedule.html17:26
eumel8yep17:28
eumel8I want to add the date in my diary and there is not date planned ;)17:28
dhellmannI believe that date is dictated by the election schedule17:28
dhellmannand 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 insight17:30
dhellmannof course, you don't have to wait for the deadline to update the list :-)17:31
*** eandersson has quit IRC17:32
fungiyeah, in the past it's mostly been gauged as however soon before elections provides sufficient time for the tc to review and approve updates17:32
fungithat differs a bit between ptl and tc elections now that they're not held at roughly the same time17:32
dhellmannand I think we need at least a week under the formal voting rules17:33
fungiultimately 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 electorate17:33
dhellmannspeaking 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-tc17:38
eumel8ok, 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-tc17:38
openstackgerritDoug Hellmann proposed openstack/governance master: appoint Omer Anson PTL for Dragonflow for Stein  https://review.openstack.org/59147017:38
openstackgerritDoug Hellmann proposed openstack/governance master: mark Changcai Geng as appointed PTL for Freezer  https://review.openstack.org/59147217:41
*** ianychoi has quit IRC17:41
openstackgerritDoug Hellmann proposed openstack/governance master: appoint Sam Yaple PTL of Loci for Stein  https://review.openstack.org/59147417:42
*** rosmaita has quit IRC17:43
openstackgerritDoug Hellmann proposed openstack/governance master: mark Dirk Mueller's appointment to PTL as such  https://review.openstack.org/59147517:45
openstackgerritDoug Hellmann proposed openstack/governance master: mark appointed PTLs for Stein  https://review.openstack.org/59147517:47
openstackgerritDoug Hellmann proposed openstack/governance master: appoint Claudiu Belu PTL of Winstackers for Stein  https://review.openstack.org/59147617:49
openstackgerritDoug Hellmann proposed openstack/governance master: mark Trinh Nguyen's appointment as an appointment  https://review.openstack.org/59147817:52
dhellmanncdent : I think that covers everyone ^^17:53
*** e0ne has joined #openstack-tc18:30
persiaAs 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
persiaMy 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-tc19:17
*** srwilkers_ has joined #openstack-tc19:17
*** lxkong_ has joined #openstack-tc19:17
*** mgagne_ has joined #openstack-tc19:24
*** tellesnobrega has quit IRC19:25
*** knikolla has quit IRC19:25
*** lxkong has quit IRC19:25
*** fdegir has quit IRC19:25
*** srwilkers has quit IRC19:25
*** mgagne has quit IRC19:25
*** annabelleB has quit IRC19:25
*** srwilkers_ is now known as srwilkers19:25
*** lxkong_ is now known as lxkong19:25
*** fdegir_ is now known as fdegir19:25
*** purplerbot has quit IRC19:27
*** amotoki has quit IRC19:27
*** knikolla has joined #openstack-tc19:28
*** amotoki has joined #openstack-tc19:30
*** e0ne has quit IRC19:52
*** annabelleB has joined #openstack-tc20:15
*** e0ne has joined #openstack-tc20:18
*** purplerbot has joined #openstack-tc20:25
*** e0ne has quit IRC20:33
fungipersia: 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 anything20:38
fungimostly i just wanted to get them in the habit of updating early and continuously, yes20:39
*** cdent has quit IRC21:06
*** e0ne has joined #openstack-tc21:50
*** e0ne has quit IRC21:56
*** annabelleB has quit IRC21:59
*** zaneb has joined #openstack-tc22:55
*** zaneb has quit IRC23:03

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!