openSUSE admin

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.