2018-11-06 heroes meeting


[20:01:50] <tampakrap> let's start?
[20:02:11] <cboltz> yes, we are already two minutes late ;-)
[20:02:58] <cboltz> welcome everybody to the heroes meeting!
[20:03:10] <tampakrap> do you have the link with the topics?
[20:03:12] <cboltz> topics are on https://progress.opensuse.org/issues/41927
[20:03:32] <bmwiedemann2> hi there
[20:03:48] <cboltz> I should probably add "hosting the Chameleon theme on static.o.o"
[20:03:57] <tampakrap> hello bmwiedemann2
[20:04:34] <tampakrap> cboltz: how about we start with this then?
[20:04:49] <cboltz> yeah, why not ;-)
[20:05:01] <cboltz> you've probably seen the request on heroes@ some weeks ago
[20:05:07] <cboltz> so the basic questions are
[20:05:15] <cboltz> - should we do that (IMHO yes)
[20:05:29] <cboltz> - does it make sense to have versioned directories?
[20:07:08] <cboltz> I know Guo requested the versioned directories, but I'm not sure if it makes sense
[20:07:11] <tampakrap> versioned dirs means?
[20:07:33] <cboltz> Guo's idea was something like   https://static.opensuse.org/chameleon/v1.0.3/dist/css/chameleon.css
[20:07:40] <bmwiedemann2> it means, caching can be more efficient, because one version will never change
[20:08:22] <cboltz> right, but it also means that for every little bugfix in the design, you'll have to adjust several sites to switch to the latest version
[20:09:42] <bmwiedemann2> a 'latest' symlink could help there?
[20:10:22] <cboltz> not really IMHO
[20:10:53] <cboltz> if a page includes current/... we can't make the cache lifetime too long
[20:11:10] <cboltz> (to the outside, "current" will look like a normal directory)
[20:11:27] <mstroeder> Isn't the idea of versioned CSS to avoid wrong caching after an update?
[20:12:04] <cboltz> yes
[20:12:37] <cboltz> I'm "just" afraid that this versioning will cause superfluous work because we'll have to change several sites whenever a new version appears
[20:14:30] <tampakrap> okay then I'm also against versioning
[20:15:44] <cboltz> I'd say we should tell Guo about our opinion about versioning - but if he still has a strong preference for the versioning, I'd accept that
[20:16:08] <tampakrap> sure, fine by me
[20:16:17] <cboltz> ok, I'll answer on heroes@ later
[20:16:50] <mstroeder> The problem is that a new layout may require a new CSS. So if you deliver new HTML referencing new styles, missing in a cached version, your site looks broken.
[20:17:33] <cboltz> I know ;-)
[20:17:45] <mstroeder> Ok, ok...
[20:18:12] <cboltz> don't get me wrong - I see good reasons for both ways
[20:18:42] <cboltz> but my experience is that if you add superfluous work somewhere, it won't be done, and several sites will be stuck with the old version
[20:19:13] <mstroeder> Full ack.
[20:19:35] <cboltz> therefore I prefer the small risk of cache issues (which IMHO is really small - I don't expect big changes to the Chameleon theme)
[20:20:52] <cboltz> so - next topic?
[20:21:13] <cboltz> questions and answers from the community
[20:21:13] <tampakrap> tickets?
[20:22:26] <tampakrap> apart from the topic we just discussed, I don't think we had any
[20:23:12] <cboltz> since nobody dared to ask a question - yes, go ahead with the tickets ;-)
[20:23:31] <tampakrap> we are down to 118 yey!!!
[20:23:53] <tampakrap> *pop* (champagne)
[20:24:01] <cboltz> thanks a lot for handling all the tickets!
[20:24:08] <tampakrap> one important is that we dropped the shuttle net address from baloo
[20:24:11] <cboltz> you flooded my inbox, but I'm happy about that ;-)
[20:24:28] <tampakrap> the preliminary work happened last week in one of the network outages we had in the nuremberg office
[20:24:41] <tampakrap> and today Per brought the interface down
[20:24:53] <tampakrap> so let's hope there won't be any issues
[20:25:13] <tampakrap> I'd say to leave it there for a couple of months, and if things are stable we can remove it completely
[20:25:54] <cboltz> agreed
[20:25:59] <tampakrap> I'm also thinking that the tickets that are actually tickets for our vendors can be closed as soon as we forward them
[20:26:11] <tampakrap> I don't see a reason of keeping them open since we can't work on them
[20:26:34] <tampakrap> I went ahead and did it with some long standing ones, would it be fine if I do it with all of them and keep it as a rule?
[20:27:10] <cboltz> I see exactly one reason to keep them open - vendor tickets are non-public, which means I will no longer see a "reminder ticket" of outstanding issues
[20:27:42] <tampakrap> we can keep a list of them somewhere
[20:27:55] <tampakrap> in a meta ticket or in an etherpad page or in a git repository
[20:28:06] <cboltz> sounds like superfluous work to me
[20:28:14] <cboltz> could we (ab)use the "feedback" status instead?
[20:28:22] <tampakrap> with a reference to the downstream and upstream tickets
[20:28:32] <tampakrap> nah I don't really like it
[20:29:35] <cboltz> I'd prefer it over an outdated meta ticket / etherpad / ... ;-)
[20:30:16] <tampakrap> well, the problem is that our tickets are most of the times outdated as well
[20:30:41] <tampakrap> we don't get enough info from our vendors eg ETA or even if the issue is fixed
[20:30:50] <cboltz> maybe that's why I don't want to add another thing that gets outdated ;-)
[20:31:13] <tampakrap> thats why I would prefer one "outdated" place instead of all of those tickets
[20:31:14] <cboltz> not even getting a notification when someone is fixed sounds interesting[tm]
[20:32:03] <tampakrap> anyway, we are not coming to an agreement so let's keep it like it is
[20:32:40] <tampakrap> another thing is that I unassigned myself from tickets that I'm not working or I'm not planning to work on soon, and that other people can work on them
[20:32:53] <tampakrap> and I think we have around 20 unassigned tickets now
[20:33:11] <tampakrap> one special case is our oldest ticket https://progress.opensuse.org/issues/2392
[20:33:28] <tampakrap> which depends on many upstreams to get fixed, and I don't think we should really keep it open
[20:34:00] <cboltz> actually - maybe not
[20:34:18] <cboltz> IIRC download.o.o serves repodata itsself (no redirect)
[20:34:41] <cboltz> if it really does so, redirecting repodata requests to https://download.o.o would be doable
[20:35:22] <cboltz> (redirecting to https for all rpm files is of course a different issue)
[20:35:38] <tampakrap> no idea
[20:37:32] <cboltz> do you know who knows mirrorbrain good enough to know that?
[20:38:26] <tampakrap> lars darix rudi adrian
[20:38:33] <tampakrap> the usual suspects :)
[20:38:59] <cboltz> can you ask them? ;-)
[20:40:35] <tampakrap> maybe, no promises
[20:41:13] <tampakrap> anything else? I need to leave in 5 mins
[20:41:35] <mstroeder> Testing Æ-DIR?
[20:42:00] <cboltz> indeed, I'm not surprised that you ask ;-)
[20:42:13] <cboltz> I have to admit that I didn't have time to test it yet :-(
[20:42:25] <mstroeder> the VMs are waiting for you...uuuh... ;-)
[20:42:45] <tampakrap> also didn't get to it yet and I don't see it happening soon unfortunately
[20:43:35] <mstroeder> The easiest thing would be if you just try to integrate a playground VM with it.
[20:44:18] <mstroeder> I can teach cboltz how to do that at GPN18,5
[20:44:49] <cboltz> sounds like a plan ;-)
[20:45:14] <cboltz> maybe I'll find an hour or two to look at Æ-DIR before, but - no promises on that
[20:46:07] <mstroeder> Send me an e-mail for your initial password reset. You need a 2nd password (e.g. via phone).
[20:46:24] <tampakrap> so I need to go
[20:46:36] <tampakrap> thanks everybody, have a nice evening
[20:46:44] <cboltz> tampakrap: enjoy whatever you'll do tonight ;-)
[20:48:18] <cboltz> mstroeder: I'll do as soon as I have some time ;-)
[20:48:32] <cboltz> anything else, or should we close the meeting?
[20:50:04] <cboltz> looks like we can close the meeting
[20:50:07] <cboltz> thanks everybody!
[20:51:18] <mstroeder> bye.