| *** jamesmcarthur has joined #openstack-tc | 00:12 | |
| *** jamesmcarthur has quit IRC | 00:16 | |
| *** tosky has quit IRC | 00:21 | |
| fungi | office hour is at hand, for several minutes already now | 01:03 |
|---|---|---|
| TheJulia | o/ | 01:04 |
| *** gmann_pto is now known as gmann | 01:07 | |
| fungi | and that concludes another office hour. catch our next exciting installment 2019-01-102019-01-11 at 15:00 utc | 02:05 |
| fungi | er, that should read 2019-01-11 at 15:00 utc | 02:06 |
| *** whoami-rajat has joined #openstack-tc | 02:31 | |
| *** ricolin has joined #openstack-tc | 03:12 | |
| *** jamesmcarthur has joined #openstack-tc | 04:00 | |
| *** jamesmcarthur has quit IRC | 04:05 | |
| *** diablo_rojo has quit IRC | 04:56 | |
| *** lbragstad has quit IRC | 05:12 | |
| *** Luzi has joined #openstack-tc | 07:35 | |
| *** tosky has joined #openstack-tc | 07:49 | |
| *** jpich has joined #openstack-tc | 08:56 | |
| *** logan- has quit IRC | 09:21 | |
| *** logan- has joined #openstack-tc | 09:28 | |
| *** e0ne has joined #openstack-tc | 09:33 | |
| *** ricolin has quit IRC | 09:58 | |
| *** jaosorior has quit IRC | 10:00 | |
| *** jpich has quit IRC | 10:08 | |
| *** jpich has joined #openstack-tc | 10:09 | |
| *** dtantsur|afk is now known as dtantsur | 10:13 | |
| *** e0ne has quit IRC | 10:47 | |
| *** e0ne has joined #openstack-tc | 10:50 | |
| *** ricolin has joined #openstack-tc | 10:58 | |
| *** jaosorior has joined #openstack-tc | 11:01 | |
| *** openstackgerrit has quit IRC | 11:05 | |
| *** ricolin has quit IRC | 11:30 | |
| *** cdent has joined #openstack-tc | 12:16 | |
| cdent | a non-openstack colleague asked me yesterday if we (openstack) as a community have any concerns about amazon outpost | 12:45 |
| cdent | I made the usual assertions about openness and alternatives being important | 12:45 |
| fungi | that also presumes that we as a community wouldn't have similar concerns about the aws public cloud (openstack isn't just for private clouds, after all) | 13:06 |
| fungi | tc-members: heads up, we're being asked to weigh in on http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001600.html | 13:08 |
| cdent | fungi: sure, not suggesting this is an only/unique issue, just that outpost is new-ish and this person was curious if it is presented new/more concerns | 13:09 |
| * ttx will look asap | 13:22 | |
| *** e0ne has quit IRC | 13:30 | |
| *** jamesmcarthur has joined #openstack-tc | 13:45 | |
| fungi | it strikes me as another case of something written in private and then brought to the community, so i can understand the hesitancy of the telemetry team to just adopt it as one of their deliverables | 13:55 |
| *** lbragstad has joined #openstack-tc | 13:55 | |
| *** lbragstad has quit IRC | 13:56 | |
| *** lbragstad has joined #openstack-tc | 13:58 | |
| TheJulia | Ideally, I would say it can go in and later be adopted by a project if there is such a match and people find it useful | 13:58 |
| fungi | yeah, it's an option either way. they go it unofficially and then telemetry adopts it later once it's more proven, or they make a separate official team around it and then fold it into telemetry later | 14:00 |
| fungi | my point is more that 1. i don't think somehow "forcing" the telemetry team to adopt it is wise, nor 2. that there's any guarantee they would choose to adopt it on their own eventually | 14:01 |
| cdent | is the telemetry team much alive? | 14:02 |
| fungi | not according to your health tracker update from july | 14:03 |
| cdent | that was july | 14:04 |
| fungi | ttx and zaneb might have updated info? | 14:04 |
| *** ricolin has joined #openstack-tc | 14:05 | |
| *** Luzi has quit IRC | 14:05 | |
| fungi | but yeah, while it might be nice if the existing members of the telemetry team saw this as an opportunity to get new people involved to share the load, i can understand why it looks to them like taking on more responsibility when they already don't have time for their existing responsibility | 14:06 |
| *** e0ne has joined #openstack-tc | 14:10 | |
| dims | right fungi | 14:13 |
| dims | folks seen this yet? https://techcrunch.com/2019/01/09/aws-gives-open-source-the-middle-finger/ | 14:14 |
| fungi | dims: nope, thanks! | 14:14 |
| fungi | i find the headline misleading | 14:15 |
| fungi | could just as easily say it's mongodb who gave the middle finger to open source | 14:16 |
| fungi | and amazon is now simply reacting to that choice | 14:16 |
| fungi | mongodb said "you can't charge for hosting a service based on our software" and amazon replied "good to know, i guess we won't then" | 14:17 |
| ttx | it's next on my Health tracking list... unless zaneb beats me to it | 14:22 |
| smcginnis | fungi: That's actually a good way to look at it. | 14:24 |
| ttx | On that techcrunch article... it feels a bit one sided yes. Amazon is not perfect but when you give them a chance to contribute in an open collaboration manner they usually do | 14:24 |
| ttx | It's just that MongoDB is not interested in contribution, they want money | 14:25 |
| ttx | and that's the last thing Amazon would give them | 14:25 |
| smcginnis | I could see this either deterring more projects from following that model, or driving them to extend their control to restricting who can use their APIs, if not their implementation (a la Oracle vs Google with Java) | 14:25 |
| fungi | it's certainly an opportunity for amazon to make an example of them | 14:26 |
| ttx | which is why this whole new licenses thing is so crazy | 14:26 |
| fungi | i could see amazon justifying investing an unnecessarily large sum on development work to basically crush mongodb to a fine grit | 14:26 |
| ttx | With such stable software it's so much simpler for Amazon to fork than to pay | 14:26 |
| cdent | clearly this is why we should switch to some versin of the GPL | 14:27 |
| * cdent runs away | 14:27 | |
| fungi | i'm happy to run away with you on that one, cdent | 14:27 |
| ttx | cdent: no, you just need to make it easy to contribute and be happy when they do | 14:27 |
| cdent | I don't think that's enough | 14:28 |
| fungi | i'm not personally a huge fan of the apache license, but it's doing okay by us so far and switching to a different free/libre open source license would be rather a lot of work for probably minimal gains at this stage | 14:28 |
| ttx | If GPL could save MongoDB that's what they would use | 14:29 |
| cdent | I wasn't suggesting that gpl could save mongodb, rather that gpl provides protections against people "just taking stuff" | 14:29 |
| ttx | But if they switched to GPL Amazon would do the exact same move. | 14:30 |
| fungi | the gpl wouldn't really constrain amazon significantly | 14:30 |
| cdent | and it is that latter which I think is _too_ enabled by the open source movement (as opposed to free softwar moved) | 14:30 |
| fungi | the agpl might, but that's a different ballgame entirely | 14:30 |
| ttx | it would only deter other non-Amazon potential contributors | 14:30 |
| evrardjp | I can't read that article, I cannot unclick to so many things I don't want to send my cookie data to :p | 14:30 |
| ttx | so... net loss | 14:30 |
| ttx | evrardjp: just run FF with content tracking protection | 14:31 |
| cdent | it's so hard any more to have a speculative noodling conversation about how to ideally change the world. somebody always wants to stick reality into the conversation. | 14:31 |
| fungi | i have tracking protection cranked all the way up, along with eff privacy badger and ddg privacy essentials active... privacy badger notes 9 different trackers it blocked. that's pretty terrible i agree | 14:32 |
| fungi | nope, make that 10 trackers | 14:33 |
| ttx | cdent: it's almost as if people were looking for loopholes in order to make more money than the others | 14:33 |
| cdent | and there we end on the common root of all evil: money | 14:33 |
| *** jamesmcarthur has quit IRC | 14:59 | |
| ttx | office hour topic: is money the root of all evil | 15:00 |
| cmurphy | hello | 15:01 |
| cdent | tc-members, office hours | 15:01 |
| ttx | I like money. | 15:01 |
| ttx | It can come in handy | 15:01 |
| ttx | I found some usage for it. | 15:01 |
| fungi | ohai | 15:01 |
| ttx | 5star - would use again | 15:01 |
| cdent | we could probably form a "two sides of the tc house" based on the money position | 15:01 |
| fungi | currency is a convenient shared fiction which only exists because we believe it does | 15:02 |
| fungi | emphasis on the "convenient" | 15:02 |
| lbragstad | o/ | 15:02 |
| dims | o/ (again) | 15:03 |
| cdent | fungi: have you read "sapiens" (yuval noah)? | 15:03 |
| fungi | nope, sounds like i should? | 15:03 |
| smcginnis | How many chickens does a new laptop cost? | 15:04 |
| cmurphy | I am wondering about the current health of the help wanted list; has it brought any good in the last year+ it has been around? and do we think the current list up to date or does it need to be refreshed? | 15:04 |
| evrardjp | ttx: Excellent 5/7. | 15:04 |
| smcginnis | I have not seen any direct signs that it is being used. | 15:04 |
| cdent | a) yes, it is good and interesting, but b) one of the things it touches on is the ways in which those shared fictions are oppressive (in the wrong hands) | 15:04 |
| fungi | cmurphy: the current list is mostly not yet up to date. i expect it to usually be up to 6 months behind reality since we currently look at it as a once-a-cycle touchpoint | 15:05 |
| cdent | when I've inquired about the impact, people didn't think it had had any, even where we've seen change | 15:05 |
| cdent | that is the change came from somewhere else | 15:05 |
| cmurphy | the reason I ask is that evrardjp and I are going to present about upstream involvement internally and are considering pointing to it but I want to be sure it's actually a worthwhile document to point to | 15:06 |
| evrardjp | cdent: if it has no impact, we should not keep that | 15:06 |
| evrardjp | cdent: it can send a wrong message | 15:06 |
| fungi | cmurphy: oh, whoops. i misread that as health tracker. the help wanted list yes it's probably suffering much more from stagnation | 15:06 |
| evrardjp | I believe it has impact. | 15:07 |
| evrardjp | cmurphy: even if it's not 100% accurate, I believe it's a good pointer | 15:07 |
| evrardjp | things might change, but we can indicate that in our messages | 15:07 |
| smcginnis | evrardjp: Have you seen any sign of anyone using it to decide where to put resources? | 15:07 |
| mnaser | i know clarkb would love to get help in making our gate more stable and a lot of that gives the person doing it openstack operational experience which is honestly pretty valuable. | 15:08 |
| lbragstad | i was able to update most of the projects i volunteered for in November (with the exception of 1 I believe) | 15:08 |
| evrardjp | smcginnis: If you mean a concrete corporate plan, no. But I have heard about contributors interested to contribute and that was a nice resource. | 15:08 |
| smcginnis | evrardjp: Oh, that's good. | 15:08 |
| fungi | the impetus of creating the help wanted list was that we had companies approaching openstack who wanted to know where to invest staff to be able to make a positive impact | 15:08 |
| evrardjp | smcginnis: whether this was converted into real actions, that's a different thing. | 15:09 |
| mnaser | but if you mean in a pov of someone who supports openstack, you learn an immense amount of operational knowledge through fixing gate issues imho | 15:09 |
| fungi | in subsequent discussions, it was suggested that sales pitches aimed at convincing contributors where to pitch in (which is what the current entries in the list mostly amount to) aren't relevant to the original audience who instead needs to see business cases for how helping in these ways will improve things for their customers/investors/bottom line | 15:10 |
| evrardjp | fungi: yes that's fairly true, that's what I meant behind the scenes when I said that I don'tknow if this converted into real actions, because it might not answer a business case for said contributor | 15:13 |
| dhellmann | tc-members: Last week in our meeting we talked about setting goals for ourselves for the rest of Stein. Do any of you have goals you think we should consider? | 15:13 |
| TheJulia | o/ | 15:13 |
| evrardjp | dhellmann: should we refactor health checking? It seems not scalable and more reactive than pro-active... I have yet to think of how to improve it though. | 15:14 |
| mnaser | dhellmann: while i don't have anything in particular, i think maybe if we make better use of storyboard, it would help use identify these more often | 15:14 |
| mnaser | and it can provide a way for the community to raise issues with the tc | 15:15 |
| evrardjp | That could be a goal in itself, being able to scale better the health checking of projects would allow us more time on issues while still keeping an open eye on what's going on | 15:15 |
| evrardjp | mnaser: could you extend what you mean there? | 15:16 |
| TheJulia | mnaser: you do, but that can also require a significant amount of time to identify the actual root cause in some cases :( | 15:16 |
| dhellmann | evrardjp : I'm concerned that if this group can't manage to communicate with all of our teams at least 1 time per cycle, we're not really going to be able to provide much leadership. | 15:16 |
| evrardjp | dhellmann: totally true, but I think we should do more than once a cycle :p | 15:16 |
| dhellmann | mnaser : what does "better use of storyboard" look like in this context? | 15:16 |
| dhellmann | evrardjp : yes, that would be ideal | 15:16 |
| mnaser | dhellmann: when we identify things we can do better or we should work on, things that are actionable goals, we put them into storyboard. as time goes by, we can pick out individual items and resolve them | 15:17 |
| dhellmann | do you have anything specific in mind that we haven't written down somewhere? | 15:17 |
| TheJulia | dhellmann: evrardjp: at the same time, too often could be viewed as hovering and some projects just don't have the activity to warrant greater than once in a cycle | 15:18 |
| mnaser | dhellmann: i do not, i think the wiki task tracker page has been good to do the same | 15:19 |
| dhellmann | ok | 15:19 |
| * TheJulia casually wonders if we should get projects to clean up their wikis and put it in their in-repository docs... | 15:20 | |
| mnaser | i think a cycle goal might be killing the wiki :) | 15:20 |
| TheJulia | ++ | 15:20 |
| mnaser | for a lot of projects, it contains some really bad stale information unfortuantely that can be really confusing for users | 15:20 |
| TheJulia | +1000 | 15:21 |
| mnaser | if soemone has the cycle goals etherpad handy... | 15:21 |
| cdent | I don't think where the docs live is a problem. the in repository stuff is often just as stale | 15:21 |
| cdent | we don't prioritize written communication | 15:21 |
| dhellmann | https://etherpad.openstack.org/p/community-goals | 15:21 |
| evrardjp | mnaser: ++ on the wiki kill | 15:21 |
| smcginnis | I do think the in-repo docs are at least a little more up to date than some of the things I've seen out on the wiki. | 15:22 |
| TheJulia | cdent: indeed in some cases, but part of the conundurm is the multiple sources of perceived truth | 15:22 |
| dhellmann | I wonder if dealing with the wiki is really strategically useful. I agree it would be "nice to have" but I'm not sure it's a "must have" item | 15:22 |
| smcginnis | And would have the benefit that as things change in the project, there's a chance that it could include the documentation change related to it. | 15:22 |
| mnaser | i wouldn't say it's a must have | 15:22 |
| cdent | smcginnis: yes, that's generally true, but simply moving content around isn't going to change our attitude to it | 15:22 |
| mnaser | but it could be an easy one | 15:22 |
| smcginnis | Yeah, if it's just a matter of copy/paste, check off goal, then that would be very unfortunate. | 15:22 |
| TheJulia | dhellmann: I do concur, it would be nice, but the resistance to must would be too great... and there might just not be time to get projects to transition off of it. For some things it kind of actually makes sense | 15:22 |
| evrardjp | dhellmann: depends if it really sends a confusing message to users or not. I am not able to judge, as I have my habits. | 15:22 |
| dhellmann | I'm much more interested in identifying some must have items for *the TC* to do | 15:22 |
| cdent | If we say "clean up the wiki" why won't people will say "yeah, sure" and do something else? | 15:23 |
| TheJulia | smcginnis: I suspect active projects would argue over contents | 15:23 |
| cdent | dhellmann++ | 15:23 |
| smcginnis | TheJulia: The nitpick potential would be very high at the other extreme of copy/pasting. | 15:23 |
| TheJulia | The TC could try to drive a grass roots campaign to move/cleanup the wiki | 15:23 |
| cdent | I think it would be useful for the tc to audit its docs in a consistent fashion, to make sure the references etc are fresh | 15:23 |
| ttx | I have been on the wiki kill project for a long while | 15:24 |
| cdent | it's probably a good way to review things and refresh our memories and get more clear on where we are aligned and not | 15:24 |
| ttx | mostly blocked on some other lightweight way for teams to publish documents | 15:24 |
| ttx | which we may soon have with gitea | 15:24 |
| TheJulia | So it seems like there is sufficient mass to at least consider strategic wiki activities. Perhaps something else? | 15:25 |
| TheJulia | ttx: could you elaborate a little? | 15:25 |
| TheJulia | specifically on soon have | 15:25 |
| ttx | wiki should be free from most reference information now. Except board agendas | 15:25 |
| evrardjp | yes that's interesting but also weird | 15:25 |
| * TheJulia laughs at the wiki content assertion | 15:25 | |
| fungi | the gitea poc opendev has been working on (to replace cgit) has a wiki feature, though it's more like github's wiki concept than mediawiki/wikipedia's | 15:25 |
| fungi | we're also planning to disable the wiki piece initially, for several reasons | 15:26 |
| mnaser | fwiw i think dhellmann is bringing a very solid point where we seem to be struggling to identify actionable things we should be doing | 15:26 |
| ttx | the idea being we need a lightweight way to publish information, but one that makes it clear who owns maintenance of what doc | 15:26 |
| ttx | the free-for-all aspect of mediawiki is a blessing and a curse | 15:26 |
| TheJulia | ttx: at what point would we want to consider guiding the culture regarding documentation behaviors/ativities? | 15:26 |
| mnaser | i do like what cdent suggested but i'm not sure how much time folks have. as someone involved in openstack deployment, i do this stuff way too often and it exposes you to a lot of whats working and whats not, it's very valuable | 15:26 |
| ttx | TheJulia: I worked to remove most "official" documents from the wiki so that it's seen more as a super-etherpad than as reference information | 15:27 |
| fungi | first because that means we need to solve authentication in gitea (which we don't want to slow down getting a new repository browsing interface into the community's hands), second because "wikis" in gitea (or github for that matter) need to be tied to repositories and have author permissions delegated by repository "owners" which we won't want the opendev team on the hook to manage directly | 15:27 |
| ttx | that's why we have governance.o.o or releases.o.o | 15:27 |
| TheJulia | ttx: For at least the TC that makes sense. | 15:28 |
| dhellmann | Here's one: As the opendev transition continues, we will eventually need to make a decision about what gerrit namespace(s) we want the openstack project to use, and whether to allow unofficial projects to use "openstack/". | 15:28 |
| TheJulia | That... could be interesting | 15:28 |
| dhellmann | it's still very cumbersome to rename a repo, so there's a technical driver for deciding to say "yes" | 15:29 |
| fungi | where "allow" might mean we grandfather in existing ones who don't want to rename straight away, but refuse to add any more to it | 15:29 |
| dhellmann | yes, that also | 15:29 |
| ttx | I'd take the opportunity to clarify that long-time confusion once and for all and say "no" | 15:29 |
| lbragstad | ttx ++ | 15:30 |
| TheJulia | fungi: including to refuse to add more that are likely to become part of a project or that are slated for project inclusion? | 15:30 |
| *** jamesmcarthur has joined #openstack-tc | 15:30 | |
| ttx | yes, it might mean a transition for existing unofficial projects... but they will transition to OpenDev terms anyway | 15:30 |
| cdent | Would it make sense to allow people to choose? For plenty of people, being on the infra, without the namespace, is what they will want. | 15:30 |
| TheJulia | I suspect there could be a lot of blowback from those impacted by varying "in" project considerations | 15:30 |
| dhellmann | another option would be to use a separate prefix for each team, which would tend to avoid the rename problem (nova/nova, etc.) | 15:30 |
| evrardjp | I don't personally care what the namespace of a project is. I want to spend time for the users, not sure they will see an impact. | 15:30 |
| fungi | TheJulia: possibly either? that's part of what would need to be discussed | 15:31 |
| dhellmann | cdent : yes, not everything hosted on opendev is going to be on a path to become part of openstack anyway | 15:31 |
| TheJulia | fungi: okay, agreed | 15:31 |
| fungi | half of the stuff hosted on opendev isn't officially part of openstack | 15:31 |
| cdent | I'm assuming that most _new_ projects that are not already strongly associated with an official openstack project will prefer to be seen as independent | 15:31 |
| fungi | well, by repository count anyway | 15:32 |
| cdent | the brand value is not what it once was | 15:32 |
| cdent | but the infra value remains high | 15:32 |
| dhellmann | right, the question isn't a global one about all of opendev, it's just about what to do with things in the openstack/ namespace | 15:32 |
| cdent | My choice would be: don't allow new, let existing choose, but if they don't make a choice, grandfather them in. This seems least effort. | 15:33 |
| cdent | which is valuable | 15:33 |
| evrardjp | least effort +1 | 15:33 |
| dhellmann | if we say we're not going to allow new unofficial projects to use the name, how do we handle new project teams in the future? | 15:34 |
| evrardjp | not sure what the "don't allow new" meant, but I suppose you meant follow the usual process | 15:34 |
| cdent | evrardjp: don't allow new was aligned with that ttx said: don't let new unofficial into the namespace | 15:35 |
| evrardjp | yeah, so for new projects to be in the namespace, they go through the usual governance process, which is fine for me. | 15:35 |
| TheJulia | dhellmann: and things being added on existing projects that are still working through other processes. I think we need to keep in mind that excess process is a major impact to velocity | 15:36 |
| dhellmann | our process right now calls for them to operate in the open for some period of time. which leads to them using some other prefix for a while, and then having to rename their repo. which is still work for the opendev team. | 15:36 |
| ttx | Note that there is a lot of non-openstack related projects up there | 15:36 |
| fungi | also, do we want to mandate specific namespaces for official project teams, or just let them choose whatever they want? | 15:36 |
| ttx | and a truckload of abandoned projects | 15:36 |
| ttx | I'd definitely not grandfather the ones that have nothing to do with openstack or are dead | 15:37 |
| * TheJulia wonders if re-namespacing will be rocking the boat too much | 15:37 | |
| fungi | there are rather a few abandoned git repositories listed as deliverables for official teams as well | 15:37 |
| *** jamesmcarthur has quit IRC | 15:37 | |
| ttx | Every time I look at that unofficial-but-under-openstack/ list I wonder | 15:37 |
| fungi | earlier this week i notices, for example, that the last substantive commit merged to the solum-specs repo was in 2015 | 15:37 |
| fungi | er, i noticed | 15:38 |
| ttx | sure, but that is a support repo | 15:38 |
| evrardjp | I have a question, is that energy well spent to care about that? I am fine also fine letting the doors open, keeping current state, as its even less energy on this | 15:38 |
| ttx | openstack/ailuropoda on the other hand | 15:38 |
| evrardjp | Just curious about the amount of energy required, before taking a decision | 15:38 |
| dhellmann | well, it's a question we're going to be asked soon, so I think we should have an answer ready | 15:39 |
| cdent | Is there a published timetable on the opendev migration that we can publicise a bit louder? | 15:39 |
| cdent | I would guess that many are not aware of it | 15:39 |
| dhellmann | good question; I don't know | 15:39 |
| fungi | with both opendev sysadmin and tc member hats on, i'd be in favor of letting teams/projects pick whatever namespaces they want for their repositories | 15:39 |
| fungi | cdent: there is no timetable/deadline for re-namespacing. current namespaces are being kept intact, but we'll start allowing repositories to rename into or be created into new namespaces in the not-too-distant future (no exact date yet) | 15:40 |
| dhellmann | I think I'd like to take an opportunity to introduce some consistency. So either all teams use a team-specific namespace, or none do. | 15:40 |
| cdent | fungi: i don't mean timetable on the namespacing, I mean the migration to the new domains and use of the new stuff, in general | 15:41 |
| fungi | that will be a slow effort which happens service-at-a-time | 15:41 |
| fungi | and will likely take a year or more to complete the transition | 15:42 |
| cdent | does the openstack-developer-on-the-street who is only paying mild attention know it is going to happen at all? | 15:42 |
| dhellmann | do they need to, yet? | 15:42 |
| fungi | we just successfully replaced the first. as of yesterday the old ns1/ns2.openstack.org nameservers and the adns1.openstack.org silent master were removed, now that the domains they were serving have been moved to new opendev.org nameservers | 15:43 |
| cdent | dhellman: I don't know, but that's not really the question | 15:43 |
| dhellmann | isn't it? part of change management is communicating at the appropriate points in the process. | 15:43 |
| dhellmann | if the change isn't actually scheduled, I'm not sure what we would say | 15:43 |
| cdent | I only heard about it by accident and I had a few different reactions, one of which was cool, this is good, productizing/demarking this stuff is good | 15:44 |
| cdent | the other was | 15:44 |
| dhellmann | "change is coming" isn't actionable without details we don't have | 15:44 |
| cdent | shit, openstack is dead | 15:44 |
| fungi | how do you recommend reaching the openstack-developer-on-the-street? so far there's been http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html | 15:44 |
| cdent | I know that second reaction is overly-dramatic and hyperbolic, but it happened | 15:44 |
| dhellmann | I don't understand that 2nd reaction. | 15:44 |
| cdent | nor do I, but it happened | 15:44 |
| fungi | oh, a few weeks ago we also created the first mailing list on http://lists.opendev.org/ | 15:45 |
| mnaser | i think the 2nd reaction is expected if someone doesn't see the whole picture | 15:45 |
| mnaser | but also, people seem to enjoy throwing "openstack is dead1!1!1" too so that crowd will always somewhat be there. | 15:45 |
| cdent | mnaser: right, which is why I think we have a task here of making sure that the whole picture is well publicised | 15:45 |
| mnaser | i think focus on messaging and explaining the "why" so folks can say "aaah, makes sense, great move". | 15:45 |
| dhellmann | is the plan to move everything to opendev.org? I wouldn't expect the mailing lists to move, for example | 15:45 |
| cdent | right, it _is_ a great move, and we need to be clear about that | 15:46 |
| * mnaser suggests that maybe we can setup an adhoc meeting with some of the folks involved in opendev to coordinate and sync up on direction of things | 15:46 | |
| ttx | fwiw I heard the first convincing "K8s is dead" rumors lately, by people looking at contribution curves | 15:46 |
| fungi | the plan is that mailing lists remain whitelabeled for domains that want them | 15:46 |
| mnaser | not to steer it, but just to know the direction, so we know what's headed our way :) | 15:47 |
| ttx | Downside of the commit metric: stable software means drop | 15:47 |
| dhellmann | fungi : ok, thanks, that's what I thought | 15:47 |
| fungi | but for projects who don't have a domain of their own and want a mailing list, we now have a lists.opendev.org listserv | 15:47 |
| dhellmann | clarkb's email (linked above) does a good job of laying out the plan | 15:48 |
| fungi | i think the first looming change which will be public facing and noticeable is the new git browser for opendev.org (based on gitea) | 15:48 |
| fungi | that's still in a very alpha poc phase right now, and there will be announcements once it's stabilized more | 15:49 |
| fungi | we've been working through a ton of prerequisite behind-the-scenes stuff to start out | 15:49 |
| mnaser | and i can tell you they're working very hard on them from what i've seen :> | 15:49 |
| dhellmann | right, as individual changes start happening, it makes sense to reinforce that message and add more detail | 15:50 |
| fungi | for example, just yesterday i booted a storyboard-dev01.opendev.org instance to host the existing storyboard-dev.openstack.org site. the vhost dns name will be the same as it has been for now, but the nova instance name and the hostname we use to apply configuration management to it is in the new domain | 15:50 |
| smcginnis | fungi: gitea will be great, but considering most casual folks still think repos are hosted on github, not sure how noticeable it will actually be. :) | 15:50 |
| fungi | and just getting our automation to the point where it doesn't assume openstack.org domains for the instances hosting our existing services took a fair amount of prep | 15:51 |
| dhellmann | I can imagine | 15:51 |
| fungi | the idea is that for the vast majority of the work, there should be no noticeable impact. for things which will be noticeable we'll have announcements with dates | 15:52 |
| fungi | and in most cases also opportunities for feedback/assistance from the community well in advance | 15:53 |
| fungi | i mean, ideally anyone who wants to help with any of this, even if it's just to test stuff out, is plenty welcome. but there likely will also be cases where we have to make quick decisions and so the opportunity for advance input won't be as long as we'd like | 15:54 |
| fungi | for now, opendev-related specs are reviewed at https://review.openstack.org/#/q/project:openstack-infra/infra-specs+is:open and get published to https://specs.openstack.org/openstack-infra/infra-specs/ once approved. https://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html is probably the most exciting one for people here | 15:57 |
| fungi | smcginnis: the good news is that with our new namespacing, we have the ability for projects to decide whether they want their repositories mirrored to github at all. up to now it's basically been mandatory | 15:59 |
| dhellmann | that feels like another decision the TC should be involved in | 16:00 |
| fungi | i don't see why the tc needs to be involved in that decision for non-openstack/unofficial projects | 16:00 |
| mnaser | i think fungi is talking about things hosted on infra like.. say, ara | 16:00 |
| fungi | it's certainly up to the tc, in my opinion, for official openstack projects definitely | 16:00 |
| dhellmann | well, openstack is a project, right? so we should decide what we want to do about the syncing | 16:01 |
| dhellmann | yes | 16:01 |
| dhellmann | that's all I meant | 16:01 |
| mnaser | ++ | 16:01 |
| fungi | sure. we agree | 16:01 |
| *** diablo_rojo has joined #openstack-tc | 16:02 | |
| fungi | related but not yet designed, i think we're going to want to put the terms on which repositories are mirrored to services like github into the hands of the governance bodies overseeing those projects | 16:02 |
| fungi | my current preferred solution is a zuul post pipeline job which pushes commits/branches/tags to third party mirroring services automatically and configurably | 16:03 |
| fungi | using zuul secrets for the organization credentials | 16:04 |
| fungi | that makes it an entirely self-service mechanism | 16:04 |
| dhellmann | that seems like a logical approach | 16:04 |
| fungi | and gets opendev out of the position of looking like we're endorsing proprietary git hosting services too | 16:05 |
| dhellmann | yep | 16:06 |
| fungi | it becomes just another third-party publication solution like we already have for pypi, read-the-docs, dockerhub, puppetforge... | 16:08 |
| fungi | whatever that nodejs package repository is called | 16:08 |
| fungi | (npm?) | 16:09 |
| *** jamesmcarthur has joined #openstack-tc | 16:10 | |
| evrardjp | npmjs? | 16:11 |
| evrardjp | or npm-enterprise ofc! | 16:11 |
| fungi | ahh, yeah i guess that's it | 16:12 |
| *** openstackgerrit has joined #openstack-tc | 16:14 | |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Mark never-released xstatic modules as deprecated https://review.openstack.org/629889 | 16:14 |
| *** jamesmcarthur has quit IRC | 16:14 | |
| evrardjp | fungi: just one of the many :p | 16:15 |
| fungi | tc-members: per the last sentence of http://lists.openstack.org/pipermail/foundation/2019-January/002665.html the gold member representatives approved the proposed amendments to the bylaws, so now we just need to get the word out to the community to vote in the upcoming individual member election (need 10% of osf individual members to vote, and a majority of those to vote in favor before the amendments | 16:25 |
| fungi | pass) | 16:25 |
| lbragstad | ack - thanks for the update, fungi | 16:26 |
| clarkb | smcginnis: fwiw I think the switch to gitea is more about feedback we've gotten around cgits deficiencies than a hope that people will realize there is more than github. So we can be successful with that transition even if people are st ill confused by github | 16:26 |
| smcginnis | Oh yeah, definitely. I think I was one of them that raised cgit deficiencies in the past. | 16:27 |
| clarkb | as for github, as long as they remain a dominant hosting platform I don't think you avoid confusion by mirroring to them. People will assume that is canonical beacuse it is for the other 95% of stuff they look at. And if you don't mirror you'll get confusion around why you don't use github | 16:31 |
| *** e0ne has quit IRC | 16:38 | |
| *** ricolin has quit IRC | 16:39 | |
| fungi | actually that's less of a risk, it's more that if you don't mirror to github yourself, someone else will mirror your project to github so they can fork from it | 16:47 |
| fungi | and so all the forks on github will point back to someone who has no actual connection to your project | 16:48 |
| fungi | and _that_ will of course cause tons of confusion | 16:48 |
| mnaser | gitea seems much nicer and usable, cgit is rough around the edges, search is hard to use, etc | 16:52 |
| fungi | gitea suffers from feature creep and modern browser app bloat, but it's definitely pretty | 16:53 |
| fungi | unfortunately everyone who writes a git frontend these days wants it to be a full github replacement | 16:53 |
| tosky | oh, indeed, from the screenshots gitea looks like a rip-of... ehm, heavily inspired by github | 16:54 |
| fungi | whereas all we *technically* needed was a very usable read-only git browser with good highlighting and search functionality | 16:54 |
| fungi | but everything out there with a nice ui also has a ton of "features" which in our case become liabilities, so have to be disabled | 16:55 |
| fungi | which for many of the alternatives, those features aren't even optional, so at least gitea allows us to turn them off | 16:55 |
| *** dtantsur is now known as dtantsur|afk | 17:12 | |
| openstackgerrit | Merged openstack/governance master: Mark never-released xstatic modules as deprecated https://review.openstack.org/629889 | 17:19 |
| *** jamesmcarthur has joined #openstack-tc | 17:20 | |
| *** jpich has quit IRC | 17:32 | |
| *** jamesmcarthur has quit IRC | 17:58 | |
| *** jamesmcarthur has joined #openstack-tc | 17:59 | |
| *** jamesmcarthur has quit IRC | 18:14 | |
| *** jamesmcarthur has joined #openstack-tc | 18:17 | |
| *** jamesmcarthur has quit IRC | 18:19 | |
| *** diablo_rojo has quit IRC | 18:48 | |
| *** jamesmcarthur has joined #openstack-tc | 18:49 | |
| *** jamesmcarthur has quit IRC | 18:54 | |
| *** e0ne has joined #openstack-tc | 19:00 | |
| *** jamesmcarthur has joined #openstack-tc | 19:01 | |
| *** jamesmcarthur has quit IRC | 19:13 | |
| *** jamesmcarthur has joined #openstack-tc | 19:17 | |
| *** diablo_rojo has joined #openstack-tc | 19:19 | |
| *** jamesmcarthur has quit IRC | 19:33 | |
| *** jamesmcarthur has joined #openstack-tc | 19:34 | |
| *** cdent has quit IRC | 19:38 | |
| *** jamesmcarthur has quit IRC | 20:40 | |
| *** jamesmcarthur has joined #openstack-tc | 20:41 | |
| *** openstackgerrit has quit IRC | 20:50 | |
| *** whoami-rajat has quit IRC | 21:01 | |
| *** e0ne has quit IRC | 21:13 | |
| *** bsilverman has quit IRC | 21:30 | |
| *** e0ne has joined #openstack-tc | 21:30 | |
| *** e0ne has quit IRC | 21:33 | |
| lbragstad | i've been thinking about dhellmann's ask about what we (as the TC) want to do in the immediate future - and something i've been battling with for the last month or so (from a TC) perspective, is trying to find ways to make cross-project collaboration happen easier | 21:44 |
| lbragstad | i'm not sure how much of that we could get done, or what the deliverable for the tc would be in the short-term | 21:49 |
| fungi | i love the sentiment, but similarly struggle to come up with a real solution | 22:05 |
| lbragstad | i think it would be great to have something tangible that makes it easier to close gaps across services | 22:07 |
| lbragstad | s/services/projects/ | 22:07 |
| fungi | also wonder how/whether we could measure that | 22:16 |
| clarkb | in theory isn't that sort of what the oslo libraries do? | 22:19 |
| clarkb | they are concrete deliverables that create consistency aross projects | 22:19 |
| lbragstad | kind of - yeah | 22:19 |
| lbragstad | but thinking of cases like multi-attach | 22:19 |
| lbragstad | which really only impacted nova and cinder | 22:20 |
| lbragstad | (i think?) | 22:20 |
| clarkb | ya there are certainly other cases of it | 22:20 |
| lbragstad | in my experience, and in my opinion, it's still pretty hard to get things done across projects | 22:21 |
| lbragstad | so i'm wondering if there is anything that falls within the tc's role that does something to help make that easier | 22:22 |
| lbragstad | i mean, contributing code is always a great thing to do and helps a ton, but if there are additional things we can do process-wise or guideline-wise, maybe people will find that useful, too? | 22:23 |
| fungi | hard to disagree, unfortunately i don't personally have any suggestions. i'll certainly give it a thorough thinking though | 22:31 |
| dhellmann | lbragstad : a good first step might be to look at recent examples of that work and see what made them harder/easier | 22:34 |
| lbragstad | good idea | 22:34 |
| lbragstad | i know ildikov did a bunch of work with multi-attach, as far as keeping the ball rolling | 22:35 |
| dhellmann | we've already identified the need for a person to actually "project manage" it and drive the change | 22:35 |
| dhellmann | are there other common patterns? | 22:35 |
| dhellmann | yep | 22:36 |
| dhellmann | maybe talking to some of the folks who drove those things about their experience would be enlightening | 22:36 |
| * lbragstad makes a note | 22:38 | |
| smcginnis | Yeah, short of the TC becoming a group of project managers, I've struggled with coming up with something we can do to encourage those efforts. | 22:39 |
| lbragstad | looking at the community goals etherpad - we don't have a shortage of cross-project opportunities that people clearly care about | 22:40 |
| *** jamesmcarthur has quit IRC | 22:42 | |
| *** jamesmcarthur has joined #openstack-tc | 22:43 | |
| *** jamesmcarthur has quit IRC | 22:47 | |
| *** e0ne has joined #openstack-tc | 22:55 | |
| *** e0ne has quit IRC | 22:58 | |
| *** edmondsw has quit IRC | 23:23 | |
| *** edmondsw has joined #openstack-tc | 23:39 | |
| *** ricolin has joined #openstack-tc | 23:49 | |
| *** diablo_rojo has quit IRC | 23:54 | |
| *** diablo_rojo has joined #openstack-tc | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!