19:00:30 #startmeeting infra 19:00:31 Meeting started Tue May 27 19:00:30 2014 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:34 The meeting name has been set to 'infra' 19:00:39 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting 19:00:40 agenda ^ 19:00:40 #link http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-05-20-19.02.html 19:00:40 previous meeting ^ 19:00:46 #topic Actions from last meeting 19:00:46 fungi add a wait for acl file creation on gerrit project initialization 19:00:59 jeblair: lemme find the review and see if it merged 19:01:01 fungi: istr you put a patch up for that 19:01:11 o/ 19:01:12 o/ 19:01:12 but we didn't test it with the recent batch of creates 19:01:25 o/ 19:01:27 #link https://review.openstack.org/#/c/94684/ 19:01:30 i think SergeyLukjanov submitted a patch to create a specs repo 19:01:33 looks like i wuo'd it 19:01:35 wip'd 19:01:47 should we try to use it for that create? 19:01:53 yes, SergeyLukjanov has a change up for sahara-specs I have +2'd it looks good 19:02:09 jeblair, i do 19:02:09 need to rework it to jive with sdague's https://review.openstack.org/94196 error handling 19:02:25 i'll do that right after the wrap up the meeting 19:02:31 right after we 19:02:59 #topic manage-projects status (fungi) 19:03:04 i think we kind of just did that 19:03:08 yup 19:03:12 #topic A home for Devstack within Infra (anteaya) 19:03:17 o/ 19:03:27 home is where you hang your devstack 19:03:35 so right now the devstack docs aren't under the infra umbrella 19:03:42 it would be helpful if they were 19:03:49 dtroyer is amenable to that 19:03:55 two things are needed 19:04:06 anteaya: you mean the stuff on devstack.org? 19:04:12 someone at the foundation willing for anotherjesse to transfer the devstack.org name to 19:04:14 yes 19:04:21 and an ip for the stuff 19:04:27 thoughts? 19:04:33 that would probably be jbryce; i believe he has handled most of the domain transfers 19:04:34 was anyone able to get in touch with anotherjessee about it? 19:04:41 yes 19:04:45 dtroyer had that chat 19:04:50 okay, great 19:04:55 anotherjessee is willing to make the transfer 19:05:04 we just need someone to catch 19:05:05 i believe that jbryce and sparkycollier would be happy for that to happen 19:05:11 yay 19:05:37 so I will track down jbryce and see if he can coordinate with anotherjesse 19:05:38 anteaya: Jonathan Bryce , Mark Collier 19:05:42 great 19:05:45 we should be able to start publishing the docs to a new location now too 19:05:48 which leaves the ip 19:05:51 they justwon't be available at devstack.org 19:05:59 so what server do we want them to live on 19:06:18 and if we have devstack.org, we can control where folks land when they use it 19:06:36 i assume we just create another rackspace cloudsites site and use the same docs jobs we're using for docs.o.o, developer.o.o, et cetera 19:06:46 maybe docs.openstack.org/developer/devstack would be okay 19:06:55 that's where project docs usually live 19:07:01 jeblair: I like that 19:07:02 or that, and a redirect at devstack.org 19:07:05 me too 19:07:06 annegentle: ^ are you around? 19:07:18 dtroyer isn't here right now, but I would like his input on the path 19:07:47 but for now I can get the domain transfer underway 19:07:55 and hope to hear from dtroyer by next week 19:07:57 anteaya: ++ we can work out the rest later 19:08:08 probably just worth noting that we can either host content at devstack.org or have it redirect to an existing docs site and get the interested parties to weigh in 19:08:16 fungi: yep 19:08:26 ++ for docs.openstack.org/developer/devstack and redirect from devstack.org 19:08:45 anteaya: end of topic? 19:08:51 yes 19:08:52 thanks 19:08:53 well 19:08:56 thank you! 19:08:58 mordred: oh? 19:08:59 we should probably figure out the docs build 19:09:03 they're in gh-pages right now 19:09:15 shouldn't be hard - but that's not how we do other thigns 19:09:26 I'd like dtroyer here for this part 19:09:31 yeah, that's a task to add to the list... get docs building so they can be uploaded in cooked format rather than raw 19:09:36 can we continue this next week? 19:09:37 fungi: ++ 19:09:39 mordred: well 'gh-pages' isn't so much a build thing as a publish thing 19:09:55 mordred: and i think the conversation so far has been about changing how we publish it 19:10:00 jeblair: yes. except I think gh-page will auto-render md for you? 19:10:16 jeblair: sure - just saying - the thing that puts things in gh-pages may need to be investigated - it's possible it's a human 19:10:29 dtroyer has some specific things he is looking for 19:10:34 mordred: yeah, i think it's static content 19:10:35 right, presumably there are some additional transformations which will need to be applied to the current source to turn it into something we can put on a webserver 19:10:37 and it is best if I let him tell you 19:10:40 kk 19:10:50 or maybe it's just straight html in which case no need 19:10:56 mordred: once we have a publishing method for the content, then we have a known way to change the content. 19:11:06 jeblair: ++ 19:11:12 #topic Third Party CI Gerrit Account name format (anteaya) 19:11:22 okay so on the linked etherpad 19:11:26 #link https://etherpad.openstack.org/p/juno-infra-improving-3rd-party-testing 19:11:31 thanks 19:11:51 there was a request for standardization of third party ci names 19:11:55 for email filtering 19:12:08 and it has also come up on the ml for filtering for gerrit js 19:12:21 how do we decide a new format? 19:12:25 yeah, we didn't get time to discuss it at that summit session, but i stuck it on there just because i've been asked for it a few times as well (in regard to e-mail filtering) 19:12:37 then how to we get current accounts to comply with the new format? 19:12:37 That was me 19:12:45 something like "Foo CI" ? 19:12:47 yay krtaylor_ 19:12:53 jeblair: I like Foo Bot 19:13:01 krtaylor_: oh, perhaps you read my mind then ;) thanks! 19:13:03 anteaya: we're going to ask third party ci folks to make several changes; i think we should do it all at once... 19:13:04 because we may want bots to do other things 19:13:11 * anteaya nods 19:13:39 and there was a comment on the email list that there are more bots than just ci bots 19:13:40 anteaya: so that means getting the new wiki pages set up, and making sure we have each of the new reqs documented 19:13:44 clarkb: bot seems like a common suffix, so you might have foobot bot? 19:13:45 so perhaps more than one filter 19:13:46 right, the consensus so far had been that we should have a pattern which identifies clearly that the account is for an automated system and able to differentiate whether it's a third-party system or one run by infra 19:13:51 anteaya: then i think we ask them all to change once that is all in order 19:13:52 yes 19:13:57 sounds fair 19:14:01 and i think the welcome message account should probably get exempted from that 19:14:14 yes 19:14:32 so there are bots 19:14:35 there is ci 19:14:42 and there is third party 19:14:45 there is the welcome message account 19:14:55 is third party the same set as ci? 19:15:02 there's the proposal bot -- are there any other bots that are not 3rd party ci or welcome message? 19:15:18 "jenkins" 19:15:27 what is the project creator bot 19:15:38 anteaya: that one doesn't comment 19:15:47 "OpenStack Proposal Bot" ;) 19:15:49 I can't think of any others that leave comments righ tnow 19:15:52 so it sounds like we have to list all the accounts affected by this as a starting point 19:15:58 but that one does not comment 19:15:58 then decided on categories 19:16:04 we did have "trivial rebase" commenting, but that's gone with gerrit 2.8 19:16:13 then select a keyword that a regex can isolate 19:16:44 i'm just not sure that we need to design a naming system that accomodates the proposal bot... it does something very different than 3rd party ci and doesn't leave comments 19:16:47 I can start an etherpad listing everthing and then we can work on categorizeing them in a way we agree on 19:16:47 jeblair: I think you missed elastic recheck bot 19:16:49 would some api-type service that returns some json describing current bot names work? seems that could plug in easily to gerritjs 19:16:52 mgagne: thank you! 19:16:54 I think we should have this on the full name and the username - so "SmokeStack CI" and "smokestack-ci" for instance? 19:17:01 mgagne: ++ 19:17:13 I am good with anything as long as it is standardized 19:17:41 i think it's sufficient if we decide in the meeting that it should be done, what eth basic parameters are, and then leave the specifics to hash out in a spec/ml thread/code review 19:17:43 ianw: I think people also want to be able to do email filters to not see emails of comments from ci bots 19:17:49 fungi: ++ 19:17:50 fungi: ++ 19:18:03 it should be done 19:18:04 so how about "Foo CI" and "Bar Bot" depending on whether you are, well, a ci system or a bot.... 19:18:05 fungi ++ 19:18:14 jeblair: wfm 19:18:16 that seems sane enough 19:18:37 whatever we settle on should be encoded in our third-party account documentation 19:18:45 yup 19:18:48 yes 19:19:05 #topic Review Third Party wiki template (anteaya) 19:19:06 we should start composing the visible names of the accounts ourselves at account creation based on info provided by the requesters 19:19:19 oh me again 19:19:20 #link https://wiki.openstack.org/wiki/Template:ThirdPartySystemInfoSubst 19:19:29 thanks 19:19:29 yup, i'm reordering 19:19:36 there is a template 19:20:00 #link https://etherpad.openstack.org/p/third-party-wiki-templating 19:20:13 this is the etherpad I am working from for the templating 19:20:20 the template looks good to me 19:20:29 it captures informantion that would allow me to udnerstand what is going on 19:20:36 great, thanks 19:20:51 #link https://wiki.openstack.org/wiki/ThirdPartySystems 19:20:57 we do need to make sure it's fairly comprehensive before we ask the operators to start filling it out, since we don't want to have to keep going back to them all asking for new bits 19:20:57 that's also nice to see ^ 19:20:59 Ajaeger put it together for me 19:21:20 i think that's illustrating how the page structure will come together; i like it 19:21:23 great 19:21:30 teamwork with anteaya and fungi! 19:21:38 I'll work on the other template for the openstack programs template 19:21:45 thanks 19:22:03 I just needed some initial feedback to ensure we were going in the right direction 19:22:17 I have what I need from this topic 19:22:21 once we collect info on what projects the operators think they should be voting on, we can start rolling out tighter acls limiting them to that 19:22:29 yay 19:22:46 fungi: ya and/or just give tem the ability to manage them 19:22:53 anteaya: fifieldt started with this one for programs: https://wiki.openstack.org/wiki/Template:ProjectBox 19:23:00 clarkb: right 19:23:16 Ajaeger: interesting 19:23:24 anteaya: maybe it's implied in structure, but maybe not... 19:23:35 anteaya: but a description of what is being tested and how would be useful for devs 19:23:38 clarkb: we could set the neutron-tpt group owned by neutron-core for example 19:23:47 I will make it explict 19:23:59 I don't find implying anything works with this group 19:24:01 eg, "we test patches on our super-expensive network switch thingy in such and such configuration" 19:24:09 great 19:24:31 I will expand that section 19:24:57 #topic How do we want to handle patches to openstack_project and openstack tooling that fix downstream issues. 19:25:01 clarkb: i think that's you? 19:25:06 yup 19:25:30 so on the agenda are links to a couple examples of changes that update openstack_project to make it useable by downstreams 19:25:33 sdague: ping 19:25:45 I don't want to chase people away when they do those things, but I think that we are misplacing effort 19:25:51 openstack_project is well the openstack project 19:26:17 we will do domain specific things tehre and IMO allowing for every use case is a bit overboard there 19:26:24 I agree that it's the openstack project - but I think there is a bunch of stuff in it that doesn't need to be there 19:26:27 would be good to come up with a consistent way of addressing these things 19:26:33 mordred: yup agreed 19:26:39 like, I don't think openstack_project needs to be very configurable 19:26:58 but I _do_ think a bunch can get refactored out into things that are more re-usable 19:27:04 s/very// 19:27:11 personally I would like to see refactors instead like jesusaur's jenkins reorg 19:27:16 i definitely don't want to see us extracting all the variables out of o_p into the global site manifest, for example 19:27:17 ++ 19:27:25 (to both) 19:27:51 I think also AaronGr's heira-in-tree can help us to have _less_ parameters in openstack_project 19:27:58 because many of them are there for passthrough needs 19:28:04 and not because we need parameters 19:28:16 yeah, that has led to a major spaghetti effect 19:28:28 so - if the refactors actually make things cleaner and simpler, I think theyre awesome 19:28:44 and I'd love to stop having to plumb variables through 6 layers of use 19:28:52 ++ 19:29:03 clarkb we had the same battle when starting to consume config as upstream... it was natural for us to make our own _project , but we also came back with a need for an instance specific module which held more of this config integration with parameters. 19:29:14 I think that moving most of the puppet modules out into their own repos would help define the line: openstack-infra/config should be openstack_project and manifests/site.pp (which don't need to be configurable), other modules and projects should be more configurable and reusable 19:29:17 moving things to a hiera tree has been helping us alot 19:29:19 distilled, if the change makes it easier for downstreams *and* us to modify, it's worthwhile 19:29:26 fungi: ++ 19:30:21 https://review.openstack.org/#/c/87384/ is instructive 19:30:48 and yeah, like jesusaur mentions, we should continue to push for bits people want to reuse to go down into the individual modules when it can be done cleanly, rather than just accepting that everyone tried to reuse openstack_project directly 19:31:09 jeblair: yeah. that's the other aspect of this question 19:31:10 it's not pupput; it's shell code that we use to build our images 19:31:10 jeblair: ya so that is the other type of change we see 19:31:30 I think we should take those case-by-case - tbh 19:31:34 i mean, it's super easy for a downstream to replace it with their own scripts 19:31:42 but, otoh, apparently ours are 99.9% good enough 19:32:08 in this case, I think the move to dib will obviate teh need for that patch - and a class of that type of patch 19:32:23 mordred: to a degree 19:32:32 but it's still illustrative of a person who needs a feature that wants to go into ours, and it's not a feature we'll ever need 19:32:33 but the jenkins scripts fall under that category now too 19:32:39 so maybe that's a matter of just weighing the extra cost; if it's a few lines of "dead" (to us at least) code, sure. but if it's more, then we say it's better to use new scripts 19:32:44 but it facilitates them not forking a script they could otherwise consume 19:32:50 jeblair: ++ 19:32:53 mordred: well so you shouldn't have to fork right? 19:32:59 you just set the variable in your wrapper script and exec ours 19:33:15 clarkb: that's a good approach to this case 19:33:24 clarkb: yes. except the actual mechanics there are hard 19:33:38 mordred: export FOO=bar ; exec script is hard? 19:33:40 because the scripts are in openstack_project, which is not really a thing you're likely to be consuming directly 19:33:42 mordred: well, we essentially already do that ourselves 19:33:47 what i would see as a "good" compromise there would be to refactor some of our scripts to make them better building blocks which can be more easily called from downstream scripts/tooling 19:34:14 fungi: ++ 19:34:15 fungi: they already are somewhat blocky -- more specific ones call less specific ones 19:34:23 fungi: ++ - but also what jeblair said above, which is that I think we should weight the costs as those come up 19:34:41 and know that we don't want to add senseless complexity 19:34:48 yep, i agree they're mostly that way already 19:34:53 but oftentimes such refactors help us too 19:35:15 kinda like the devstack-gate hook functions 19:35:24 yup 19:35:49 clarkb: (i think you should suggest the script callout on that patch, see what the authors think) 19:35:59 jeblair: will do 19:36:28 clarkb: or, tell them to wait for the dib refactor, which already has a different way of dealing with proxies and local content injection 19:36:36 so I think we haev agreement that we should push towards proper refactoring for reconsumption 19:36:41 clarkb: ++ 19:36:44 if the change is minor then ok 19:36:50 i was hoping sdague would be around to talk about how this affects test-matrix 19:36:59 ya so test-matrix is the other thing 19:37:16 mordred: have you fermeted on that more? 19:37:27 *fermented 19:37:42 * jeblair is worried that he fomented 19:39:18 tl;dr on that is again we have instructiev code that determines how we test stuff 19:39:29 and others would like to make it instructive for not upstream openstack 19:39:49 which bothers me because it is clearly an openstack specific tool for upstream testing 19:39:49 yeah - I mean 19:39:54 and we can't test the downstream use case at all 19:40:02 I don't think it's a specific openstack tool 19:40:21 I think we've spent a lot of time telling people to re-use the tools we've written for their internal testing and they've listended 19:40:22 mordred: it is used to deploy from source openstack clouds 19:40:29 so that they can be tested 19:40:32 yes 19:40:47 I believe we have tons of people now wanting to replicate this infrastructure that we've built to do exactly that thing 19:41:06 but they don't want to replicate the development model 19:41:34 clarkb: what do you mean? 19:41:37 what I'm saying is that I don't think test-matrix is necessarily or has to necessarily be "upstream only" 19:41:55 jesusaur: openstack is very particluar in its dev flow in order to handle 1k devs 19:41:55 in fact, I think sean has done a good job of making it a thing which takes data to make decisions 19:42:02 jesusaur: other folks want to mix it up for their 1k folks 19:42:22 mordred: right so we discussed making those bits more properly config, but you didn't like that for some reason 19:42:29 (I forget what the actual concern was) 19:42:39 mordred: i don't see how we can keep putting test variations into test-matrix that we don't test; i don't think we can review them intelligently, and i think it will hurt what we're trying to do by making it more complex 19:42:52 jeblair: I do not think we shoudl do that at all, so I agree 19:43:07 mordred: i think for downstream test configs, that has to live outside of d-g and test-matrix, but we can facilitate that with plugin/hook points, etc. 19:43:16 yeah, i do worry that our current branch handling is already jenga-like to the point where we risk even impacting our own use cases (when a change ends up modifying a behavior we weren't testing well enough) 19:43:18 clarkb: a config file sounds ideal to me... 19:43:22 yah. agreed 19:43:30 I think the main concern I had ... 19:43:44 fungi: i think we should have a giant jenga thing at the next summit 19:43:54 jeblair: it should be the THEME of the next summity 19:43:57 is that we keep in mind that someone may want to wholesale consume our config for test-matrix as well, and simply to suppliment it 19:44:17 mordred: sounds reasonable 19:44:19 but, I think we keep that in mind generally, so it shoudln't be a big departure 19:44:46 clarkb: end of topic? 19:44:49 jeblair: yes Ithink so 19:44:55 cool 19:44:58 #topic About splitting Horizon repo in two parts (rdopiera) 19:44:59 basically push to refactoring and config rather than instructive code changes 19:45:01 clarkb: I believe our disagreement is that I wanted to add awareness of branch prefixing to our branch fallback algorithm 19:45:07 jeblair: just back from CSA pickup, what's up? 19:45:16 clarkb: but I think that's out of scope for now 19:45:29 ooh! splitting horizon! 19:45:32 so I came to ask for advice, because we are going to do some changes in the horizon's repos, and we want to know the best way to proceed 19:45:32 sdague: read previous topic fyi and possible further discussion, but we need to move on now i think 19:45:33 * mordred is excited 19:46:05 rdopiera: we're very excited! splitting them should make a lot of things easier! 19:46:09 basically what we plan to do is to have a separate repo for the library and the application parts of horizon, plus a bunch of packages for all the js libraries 19:46:41 rdopiera: please clarify what you mean by "packages" in that sense 19:46:41 the js libraries part I already started on, we are using xstatic to package them, and putting them on stackforge 19:46:51 got it ;) 19:46:53 This is the “use pip to package javascript things” discussion, yes? 19:47:02 xstatic is basically a minimal python package with the js libraries as data files in it 19:47:03 krotscheck: partially yes 19:47:12 and some metadata 19:47:25 so it can be installed from pypi, etc. 19:47:45 rdopiera: have you put any in stackforge yet? 19:47:50 this is as opposed to installing the js bits via npm and everything else via pip? 19:47:55 the change to add them all to stackforge is proposed 19:47:57 jeblair: there is a patch 19:48:00 fungi: correct 19:48:12 that part is the easy part 19:48:26 what I would like to ask all of you about is tackling the horizon's code itself 19:48:41 we were thinking about cloning the repo, and removing half the files in each of them 19:48:47 that does make them somewhat less consumable to the broader js community/ecosystem, though if horizon's dashboard is the only consumer right now then i don't suppose it's much of a concern 19:48:52 this way we retain the history and the patch queue on one of them 19:49:08 fungi: MoinMoin 2 also uses the same system 19:49:11 rdopiera: this might need changes to the translation jobs, please add this to your todo list. 19:49:19 let's tackle the repo split first 19:49:19 fungi: and we hope more apps will use it with time 19:49:45 rdopiera: typically the way we do this is by git filter branching the initial state of one repo 19:49:52 then in the other repo submit a change t odelete the excess 19:49:53 honestly, I'm feeling some inconsistence when see pip handling js libs 19:49:56 rdopiera: right, the git repo split can be fairly easily handled via git filter-branch *if* the files which go in each repo are fairly well separated already 19:50:11 rdopiera: which will be in the "horizon" repo? the dashboard or library? 19:50:18 fungi: they are separated 19:50:50 jeblair: the openstack_dashboard will get renamed to horizon, and the horizon (library) will get renamed to django-horizon 19:51:20 and also i'm curious to know what the release model will become for each (both still integrated releases? library switching to ad-hoc with no stable branches?) 19:51:24 jeblair: so the patch queue will stay with dashboard, which I think is good, because most changes are there 19:51:28 rdopiera: cool, that makes sense. 19:51:49 would webui work in there at all for naming 19:51:55 fungi: simultaneus release, from what I understand 19:52:00 rdopiera: so we can help with the filter branch when you're ready 19:52:01 isn't that what we are doing with storyboard and vinz? 19:52:11 anteaya: the architecture of the two is different 19:52:16 oh okay 19:52:35 rdopiera: or if you want to do it, you can just host the new repo somewhere 19:52:35 django-horizon is mostly front-end stuff, like widgets and views 19:52:46 rdopiera: and when we create the project, import it from there 19:53:07 jeblair: that sounds good, because I can test different approaches then 19:53:18 rdopiera: i think that the horizon repo will still have the history for both projects though 19:53:28 yup and I tink it should 19:53:28 yes, that's fine 19:53:31 ok 19:53:38 because we need to track that they became two at some point 19:53:43 right, most likely outcome is that the old library bits get deleted from the horizon repo in one mass commit 19:54:16 that commit will probably invalidate a lot of patches in the queue, but the sooner we do it, the better 19:54:40 rdopiera: i think what you may want to do is to "freeze" the library inside of horizon, create the new project, then get it working in devstack-gate, then rm the lib from horizon 19:55:02 jeblair: sorry, what is devstack-gate? 19:55:39 rdopiera: it's what we used to do integration testing of all the projects 19:55:51 rdopiera: it uses devstack to install everything and runs tempest 19:55:58 I will look for it, thank you 19:56:00 #link http://git.openstack.org/cgit/openstack-infra/git-review/tree/README.rst 19:56:13 er, wrong link 19:56:20 #link http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/README.rst 19:56:21 close :) 19:56:26 (silly clipboard!) 19:56:29 rdopiera: so i expect there to be some patches to devstack and devstack-gate after the new project is created 19:56:31 ok, thank you everyone 19:56:46 rdopiera: sdague, dtroyer, and i can help out with those parts 19:56:56 rdopiera: thank you! 19:57:28 rdopiera: so we don't have a lot of time, and i'm not sure this is the best forum for the discussion anyway, but the other half of this, the xstatic part, interests some of the people here 19:57:45 jeblair: sounds good 19:57:50 rdopiera: is there a mailing list thread about it? 19:58:28 jeblair: we had a design session on that https://etherpad.openstack.org/p/juno-summit-horizon-static-files 19:58:38 rdopiera: so that people can learn about it or discuss? particularly, i want to make sure that zigo weighs in on it 19:58:39 jeblair: and there is an e-mail with some summary of progress here: 19:59:21 rdopiera: because i recall from the design session that there was a lot of talk about doing this to help debian, but zigo wasn't actually there 19:59:34 jeblair: yes and red hat iirc 19:59:46 red hat was there and seemed okay with xstatic 19:59:46 yah - I also have an extreme view myself that it's not our job to make things easier on the distros 19:59:47 http://lists.openstack.org/pipermail/openstack-dev/2014-May/035370.html 19:59:48 but fedora does have npm now so I don't know 19:59:52 but rather to do the thigns that make sense for us 19:59:53 pabelanger has also expressed a desire to be able to pip-install the django lib 20:00:10 rdopiera: also, mordred had an idea about using pbr and nodeenv to build things at tarball creation time 20:00:15 yup 20:00:22 mordred: xstatic is actually designed with easy packaging for distros in mind 20:00:24 so i want to make sure zigo and mordred have an opportunity to chime in 20:00:31 rdopiera: right. I don't share that as a goal 20:00:34 mordred: you can configure it to keep the actual files in any place 20:00:41 I share participating in and with upstreams more in mind 20:01:02 and if the distros can't figure out javascript, then they'll be replaced by distros that can figure out javascript 20:01:09