| *** diablo_rojooooooo is now known as diablo_rojo | 02:39 | |
| *** ykarel|away is now known as ykarel | 04:09 | |
| ricolin | tc-members, please help to review on https://review.opendev.org/c/openstack/governance/+/810037 and https://etherpad.opendev.org/p/health_check | 04:55 |
|---|---|---|
| *** ykarel is now known as ykarel|afk | 05:03 | |
| *** rpittau|afk is now known as rpittau | 07:28 | |
| *** ykarel is now known as ykarel|away | 10:25 | |
| *** diablo_rojo is now known as Guest656 | 13:10 | |
| spotz | ricolin: done on the review, ether on the todo for today | 14:12 |
| gmann | ricolin: ack, will check today | 14:13 |
| *** rpittau is now known as rpittau|afk | 15:45 | |
| *** diablo_rojo__ is now known as diablo_rojo | 16:09 | |
| *** diablo_rojo__ is now known as diablo_rojo | 16:38 | |
| gmann | ricolin: done, commented. improvement on threshold can be done in follow up but fixing the invalid project handling can be done in this commit itself. | 17:14 |
| fungi | also i strongly recommend you calibrate those thresholds against projects you already feel are operating in a "healthy" manner and those you feel are currently "unhealthy" rather than picking numbers out of thin air | 17:15 |
| fungi | and maybe use a different word than "unhealthy" since past efforts have proven that if you publish a list of "unhealthy projects" then the people working on them are quite likely to be offended by the apparent judgement of their efforts | 17:16 |
| gmann | yeah we can reword 'unhealthy' to something 'Need more activities' and threshold can be set so that no one get offended as there are really less work. like if I merge only 5 review in 180 days in tempest even i am active there I should not get offended even start doing mroe reivew | 17:25 |
| gmann | I think current threshold proposed in etherpad is good to give us 'really low activities' projects | 17:27 |
| fungi | at risk or need help or look into, whatever | 17:29 |
| gmann | +1 | 17:31 |
| fungi | but yes, any terms which imply a value based judgement are going to do more harm than good | 17:32 |
| fungi | we learned that lesson the hard way on our very first attempt at this | 17:33 |
| gmann | yeah | 17:35 |
| dansmith | gmann: is it worth trying to document why we're doing this? | 17:36 |
| dansmith | like, why do we care about patch rate, per author, authors, etc? | 17:36 |
| dansmith | for stable libraries, patch rate is inversely proportional to goodness, but that's different for some other projects | 17:37 |
| dansmith | and, if a project is deemed unhealthy or "at risk" or whatever, what are we going to do? | 17:37 |
| dansmith | we're not going to deploy hordes of idle engineers to build field hospitals in those projects | 17:37 |
| * dansmith mixes metaphors with current events to keep it interesting | 17:38 | |
| gmann | dansmith: that is good point about relating /documenting the counts | 17:38 |
| gmann | we do not want to take any hard decision based on the results but a signal to start approaching current team or preparing the plan with other way (ask for contributors if it is not possible to retire project/lib). | 17:39 |
| fungi | my non-tc-member opinion is that these metrics would (along with a bunch of other data from folks like release management, qa, vmt) help inform whether the tc should remove the project from openstack due to being, inactive+unmaintained+broken | 17:39 |
| gmann | for example if oslo going with 'at risk' stage then we have to raise it widely | 17:40 |
| gmann | well, to decide if project can be removed or not this is just a first signal but not full criteria to remove | 17:41 |
| fungi | what else is the tc going to do though aside from removing a project? | 17:41 |
| dansmith | fungi: yeah that's my point.. I think that's pretty much the only thing we'd really be able to do as a result of this | 17:41 |
| gmann | like dansmith mentioned, for libs even counts are less but if we have few maintainers to fix bug/release it is all good to keep. | 17:42 |
| dansmith | I feel like asking for help on a struggling project is rarely if ever going to actually do anything | 17:42 |
| fungi | if there are additional steps the tc would take prior to removal, then enumerate them somewhere | 17:42 |
| dansmith | point being, if that' really it, then we can/should tailor our stats to just what we would use to determine removal | 17:42 |
| gmann | for projects/service we reply mandatory like support, nova, keystone etc then we cannot remove and think on possibility to get maintainers | 17:43 |
| gmann | raise it to board or so | 17:43 |
| dansmith | and honestly, I'm not sure what else that would be other than "can't do releases as needed" or "isn't able to address CVEs" or something | 17:43 |
| fungi | but the way i see it, if the project is ignoring new changes, is merging almost nothing, isn't keeping up with mandatory release activity, has thoroughly broken ci jobs and doesn't respond to the vmt on reported vulnerabilities, then there's a clear case for removal | 17:43 |
| dansmith | fungi: yep, same sort of things I'm thinking of | 17:44 |
| dansmith | patch rate low or high isn't really that important.. lots of pending patches with no review, not keeping up with releases, CVEs, etc are | 17:44 |
| gmann | yes, I am thinking all condition (mentioned in etherpad) as AND and then say 'at risk' | 17:45 |
| gmann | with current framework of 'TC liaisons' we need to do it manually and then start the help/removal criteira checks | 17:46 |
| dansmith | well, and I'm saying it seems like maybe the etherpad is concerned with more stats than we'd really care about for any action | 17:47 |
| fungi | also in the past we've seen some what i would consider "problematic" projects where they're actually merging some changes, just ignoring any which aren't posted by the core review team (and generally it's the case that all the core reviewers work for the same company) | 17:47 |
| dansmith | just saying a project is "at risk" doesn't really mean much to me | 17:47 |
| dansmith | fungi: and what do you think we can do about that? | 17:47 |
| dansmith | admonish them? | 17:47 |
| fungi | i'm saying that focusing on whether or not changes are merging isn't a reliable metric | 17:48 |
| fungi | and not admonish, just remove | 17:48 |
| gmann | dansmith: we can reword that to 'low activities' or so as it is just count stats not all the factor to consider project 'at risk' | 17:48 |
| fungi | assuming they're also not keeping up with release activity, vulnerability reports, et cetera | 17:48 |
| gmann | that is removal criteria. which can be triggered by this tool | 17:49 |
| dansmith | I dunno, it just seems like a potentially large amount of work to collect a bunch of stats that might be interesting, but not really actionable | 17:49 |
| dansmith | so I'm just asking | 17:49 |
| gmann | dansmith: like for murano case, instead I was waiting for goal pacthes to merge there and then after 1 month i realize there is no activity there in Xena cycle. | 17:50 |
| gmann | I feel, this tool can let us know about such projects in advance | 17:51 |
| gmann | + knowing less active core (has to e present for stack/support) projects which need some solution and cannot be removed. | 17:53 |
| dansmith | yeah, I mean I'm mostly talking about collecting the stats and labeling projects as at-risk or whatever.. the clear cases are...clear | 17:55 |
| dansmith | so I'm just saying we should keep in mind what the target actions are and maybe focus on those stats and eventual labels | 17:55 |
| dansmith | which comes from documenting why we're collecting them and what we want them for I think | 17:56 |
| gmann | yeah, that make sense instead of just saying 'at risk' | 17:56 |
| fungi | i agree, it's good to approach it from the angle of what you need to know, rather than what you happen to be able to query | 17:56 |
| gmann | let's discuss in tomorrow meeting. agree on documenting the usage/action first | 17:58 |
| opendevreview | Elod Illes proposed openstack/project-team-guide master: Remove 'Unmaintained' phase https://review.opendev.org/c/openstack/project-team-guide/+/810499 | 18:13 |
| -opendevstatus- NOTICE: Zuul has been restarted in order to address a performance regression related to event processing; any changes pushed or approved between roughly 17:00 and 18:30 UTC should be rechecked if they're not already enqueued according to the Zuul status page | 18:37 | |
| *** slaweq_ is now known as slaweq | 19:26 | |
| spotz | fungi wouold the Zuul restart have anything too do with No package found for python-libvirt? | 21:16 |
| fungi | spotz: nope | 21:19 |
| fungi | would just be either zuul tested and reported a result on a change or it didn't | 21:19 |
| fungi | if jobs ran and reported a result, then zuul's doing what it should | 21:19 |
| spotz | fungi okie wasn't sure on the timing and it was dying on retries | 21:19 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!