12:59:43 #startmeeting 12:59:43 Meeting started Tue Apr 5 12:59:43 2016 UTC. The chair is jow_laptop. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:59:43 Useful Commands: #action #agreed #help #info #idea #link #topic. 12:59:54 #topic Meeting agenda 13:00:12 Hi all 13:00:33 Todays agenda has these items 13:00:39 * Infrastructure 13:00:44 *Repository 13:00:51 * Release Signing 13:00:57 * Engeagements 13:01:00 * Roadmap 13:01:02 * Votes 13:01:17 We can postpone items we cannot / do not want to discuss today 13:01:34 I'll start with the first agenda item 13:01:39 #topic Infrastrucutre 13:02:14 #info I am in the progress of syncing downloads.openwrt.org to our buildserver so that we have a complete mirror copy, just in case 13:02:41 #info John contacted dwvm about the mailinglists, the setup is pending 13:03:00 #info I did a little bit of work on the website but otherwise not much yet 13:03:22 So much for the progress part on my side. 13:04:01 #action I plan to document our current server infrastrucutre and the responsible people in the next days 13:05:16 hi 13:06:09 funny how I constantly misspeel infrastructure... oh well 13:07:10 so we will have a complete mirror of downloads.openwrt.org and can provide it in our own infrastructure then 13:07:19 re 13:07:20 Hi all 13:07:20 or let it be mirrored by others 13:07:27 I'd like to find a people volunteering to be the backup admins of the git and web servers as well as the system running this bot 13:07:46 Hauke_1: yes, we'll have a complete copy, will provide an rsync server and call for public mirrors asap 13:08:36 do we have to trust the mirrors? how do we prevent them from changing the files and adding bad content? 13:08:59 is the signature check by opkg enoght 13:09:18 for the legacy resources (whiterussian, kamikaze, ...) I plan to provide pgp signatures 13:09:34 ok, but I do not care much about them ;-) 13:09:38 for our new upcoming stuff we'll do pgp signing from the get-go most likely 13:09:53 get-go? 13:10:00 from the beginning 13:10:40 hi 13:10:44 sorry i forgot 13:11:08 when using detached pgp signatures, multiple people can sign the same stuff so ideally a few developers sign releases and people can verify the integrity later on 13:11:36 #action I'll write a proposol for this to the list 13:12:06 thanks 13:12:38 What I'd also like to have with the future mirrors is some DNS indirection, even if it is just an downloads.lede-project.org cname -> mirror1.lede-project.org in the beginning so that we'll have rthe ability for round-robin distribution in the future 13:13:44 So much for the mirroring, the freenode organization registration is still pending 13:13:59 got no feedback on that front yet 13:14:29 Any question so far? 13:14:41 nope 13:14:52 nope 13:14:58 nope 13:15:02 Ok, lets proceed to the repository topic 13:15:07 #topic Repository 13:15:33 It has been asked whether we will utilize github for repository hosting 13:15:58 personally I'd like to just provide an offical mirror there but do not want to host the main operations on github 13:16:02 complicated 13:16:48 me too, we could self host gerrit 13:17:01 #info Hauke suggested Gerrit as possible alternative 13:17:05 but relying ona free cloud provider is dangerous 13:17:21 for those who didn't follow the topic here, gerrit is a sort of augmented pull request review platform 13:17:23 what does gerrit do aside from code review and some repo management? 13:17:36 people can vote on merge requests with different weights 13:17:43 ordinary users can +1 stuff, admins can +2 it 13:17:51 in general, i'm not a big fan of these web based review things 13:17:59 me neither 13:18:02 and i'm not a big fan of voting on pull requests either 13:18:08 we can only use it if it interacts with email 13:18:34 I do not know if gerrit can interact with email 13:18:43 we need to find out in that case 13:18:50 I can check 13:19:12 #action Hauke will find out if gerrit can interact with email threads 13:19:12 so how should our process look like? 13:19:25 Has a self-hosted Gitlab instance been considered already? 13:19:36 with or without some system in place we need to decide on how to deal with invasive pull requests, those that can be considered architectural changes 13:19:59 patchwork handles PRs 13:20:07 I have not hosted one myself so far, but as I understand it, it has a lot of the advantages of Github (and even allows cross-instance pull requests, if I understand correctly) 13:20:12 should it be the same as how with people sending mails go a mailng list and patchwork and them manually appliing them? 13:20:22 Hauke_1: likely yes 13:20:40 neoraider: I briefly thought about it but form collegues I learned that hosting it is nontrivial 13:20:55 especially if you anticipate huge amounts of traffic 13:20:59 jow_laptop, I see. Meh. 13:21:47 basically we are runnng into the trac trap again where we will spend again hostiong the platform and making it stable rather than using it 13:22:04 we dont want to build or design a process or tool, but use an existing one 13:22:16 yes, trac has been a huge drag in oepnwrt and until today we've not been able to make it stable or performant 13:22:33 personally i dont see what is wrong with using patchwork 13:22:38 probably also due to the fact that we're no professional admins :) 13:23:05 o'rly 13:23:40 I'm not fundamentally opposed to patchwork either 13:23:56 is there a demo page that shows how patchwork handles PRs? 13:24:10 i didn't know it could even do PRs 13:24:11 they are listed just like patches 13:24:22 if you send a PR to a mailinglist patchwork will show it 13:24:36 i have seen them in linux-mips patchwork 13:25:10 https://patchwork.linux-mips.org/patch/12771/ 13:25:11 Title: MIPS: Pull request - Patchwork (at patchwork.linux-mips.org) 13:25:17 note the extra link on the top 13:25:36 ah 13:26:11 and the rest will be listed just like any other thread, just this one never had a reply 13:26:30 ok 13:26:50 fine with me 13:27:40 so we go forward with selfhosted git via http and ssh plus patchwork for pr/patch visualization and mailing lists for communication? 13:27:54 ack 13:27:55 i am not opposed to having a github'is type thing but it needs to be selfhostable with little effort and interact with mails 13:28:10 i think the biggest issue is how do we handle bug reporting? 13:28:18 until we have that we should stick to what how just described 13:28:48 we didn't make much progress on the bug reporting front yet. My personal redical suggestion is mailing list only 13:29:52 we need a bugworks really 13:29:58 yeah 13:30:09 otherwise it's just too hard to keep track of information 13:30:14 yep 13:30:26 maybe we can patch patchwork 13:30:30 especially with ath9k, i tend to monitor several long running tickets with lots of user comments 13:30:34 but again, then we would be building tools 13:30:51 i don't think patchwork can easily be made to handle that 13:31:00 exactly 13:31:21 afaik the cerowrt guys have used redmine 13:31:28 not sure how well that worked for them 13:31:29 Gitlab provides neat ticketing as well 13:31:42 including line comments, code links, hash links etc. 13:31:55 In my experience, Redmine is as inperformant as Trac (I've been hosting both on my private server for some time) 13:32:13 I agree with neoraider here. Redmine is slow. very slow 13:32:17 what if we disable lots of stuff like wiki, repository browser, etc 13:32:23 and use it *only* for issue tracking 13:32:27 to bring down the load 13:32:50 nbd: of what ? 13:32:52 trac ? 13:33:03 to be frank its a graveyard of crap 13:33:03 redmine, trac, whatever 13:33:24 if it doesn't even see repository updates, the database will be much smaller 13:33:37 and it will see only a fraction of the requests 13:33:48 hmmm 13:33:49 since people can't use it to browse random crap anymore 13:34:00 and look at the timeline 13:34:02 in this case we could also pure standalone trackers like mantis 13:34:13 +use 13:34:15 is the UI of mantis any good? 13:34:35 https://www.mantisbt.org/demo.php 13:34:36 Title: Mantis Bug Tracker | Demo (at www.mantisbt.org) 13:35:36 hm, to me it looks very confusing 13:35:46 you have to search the actual contents 13:36:50 on the other hand it provides better filter capabilities and it likely has better integration capabilities compared to trac 13:36:59 like ticket autoclosing and stuff 13:36:59 if it's not too hard to set up, i guess we could give it a try 13:37:19 okay, so do we all agree with self git + patchwork + mailinglist + mantis here? 13:37:35 plus the ability to maybe have an auxilliary gitlab later on 13:37:44 ack 13:37:46 How does Mantis integrate with mail? 13:38:50 https://www.mantisbt.org/wiki/doku.php/mantisbt:emailreporting 13:38:51 Title: EmailReporting Plugin [Mantis Bug Tracker Wiki] (at www.mantisbt.org) 13:39:37 ah lol ... mantis .. i get the joke only now ... 13:40:19 it seems you can post mantis issues by mail 13:40:48 and add notes to it 13:41:06 if we can also get it to push new bugs to a mailinglist then we have the perfect bridge between the 2 13:41:19 that would be like bugwords in that case 13:41:23 that should be no problem 13:41:49 i will ask davif for a lede-bugs mailinglist aswell and we should give it a shot 13:42:23 next topic? 13:43:27 #agreed For now, rely on self hosted Git + Patchwork + mailing lists and try Mantis for bug tracking 13:43:43 #topic Release signing 13:43:59 This topic intersects a bit with the mirror debate we had before 13:44:10 problem with release signing is a principal one 13:44:27 we do not want to have a group of only a few selected people who are the only ones to hold the secret key to sign releases 13:44:55 plus we'll need keys suitable for semi-automatic operation, e.g. when building updated binaries for security updates 13:45:20 pgp allows signing by multiple, independant people - that would cover the firmware image integrity bit 13:45:36 but for opkg we rely on usign which has a way more limited key "architecture" 13:45:56 usign doesn't really limit us much 13:46:10 there's not much in the way of adding some multi signature verification around it 13:46:19 similar to how we'd use pgp 13:46:45 I propose something like that: 13:46:57 - each developer generates his own secret usign keypair 13:47:16 - we'll setup a keyring.git where each developer puts his public usign and pgp keys 13:47:29 - we'll package that as a keyring.ipk which is part of the base system 13:48:17 Makes sense 13:48:17 whenever any developer does a release or incremental package / feed rebuilds he'll simply sign with his private key 13:48:33 whenever a leak occurs we'll udpate keyring.ipk and issue an advisory 13:49:04 or when a new developer joins or another one leaves we update keyring.ipk as well 13:49:11 when i'm back in germany, i can also work on multi-signature support 13:49:19 makes sense to me to 13:49:32 Yes, multi-signature support would be great 13:49:33 and add a command line parameter to define a number-of-signatures threshold 13:49:45 which the user can also configure based on personal paranoia 13:50:05 regarding multiple signatures; 13:50:09 We also have that in Gluon's autoupdater infrastructure 13:50:20 there's about one incremental rebuild per week to issue security updates 13:50:40 this means multiple developer need to sign the patched package index files at least once per week 13:50:54 obviously we cannot mail the plaintext file around anytime and ask anyone to add his .sig 13:51:52 i guesss this is stuff we'll figure out later as we go along 13:52:00 we start with the simple case of trusting all developer keys 13:52:07 in keyring.git 13:52:20 fine with me 13:52:21 Regarding images, we'd also need to decide what exactly will be signed 13:52:44 neoraider: I plan to sign md5sums and sha256sums with usign and pgp 13:53:02 that should provide a long enough chain of trust 13:53:07 and in the future we will have sysupgrade integration for usign 13:53:12 s/long/strong/ :D 13:53:13 jow_laptop, okay. These files should also contain some meta information (version number etc.) in the signed data 13:53:56 Signatures should always cover all relevant context of the signature 13:53:57 nbd: ? 13:54:01 how so ? 13:54:05 neoraider: maybe it is better to introduce a manifest file for that 13:54:27 neoraider: but it can be sha256sums with a comment section as well 13:54:33 jow_laptop, I agree. For Gluon, this manifest looks like this: http://luebeck.freifunk.net/firmware/0.7.1/sysupgrade/stable.manifest 13:54:47 yep exactly, something like this 13:55:01 as long as it can be processed by any traditional verification tool 13:55:10 blogic: well, i'd like firmware images to be signed directly as well at some point in the future 13:55:32 and have those checked by sysupgrade with an option to bypass the check 13:56:16 ok, to summarize 13:56:26 1) we begin with establishing keyring.git 13:56:59 2) we'll let opkg accept any key from keyring.git in the beginning to have a simple, yet secure start 13:57:19 3) we'll gradually refine this system until eventually we have multi signature support, thresholds etc. in opkg 13:57:48 ack 13:58:13 4) we'll introduce manifest files / checksum files with metadata which verify and describe a set of release images and which in turn are signed by multiple developers 13:58:21 anyone agrees so far? 13:58:30 ack 13:58:31 ack 13:58:34 ack 13:58:34 ack 13:58:35 ok 13:59:29 #agreed We'll pool pubkeys in a keyring.git, let opkg trust any of those pubkeys. System will be refined in the future and signed manifests introduced for images 13:59:48 next topic? 14:00:03 next 14:00:05 #topic Engagements 14:00:50 so blogic and me already invited neoraider and Noltari 14:01:14 next candidates on our list are stintel, hnyman and thess 14:02:08 we also approached dangole as he's doing good work in maintaining the oxnas target 14:02:34 I am fine with tem 14:02:38 them 14:02:40 ack 14:02:59 ack 14:03:14 We didn't yet work out any list of communities to approach 14:04:04 I propose to setup another etherpad we can use to pool suggestions 14:04:15 lynxsis 14:04:18 then we'll approach those candidates top down 14:04:20 and yousong 14:04:47 we have a chat with stintel tonight 14:05:00 and thess next couple of days, need to reply to his mail 14:05:55 What is your idea of "approaching a community"? I think many communities don't have a private way to contact them, so you would contact leading developers in these communities? 14:06:10 neoraider: yes 14:06:22 that plus asking for an endorsement maybe 14:06:52 neoraider: yes, about a week or two before launch and then we paln to send an email to the mailing lists 14:07:44 or maybe just leaving a message on a mailinglist, like "Hi, this is the lede project, we're doing this and that and welcome you to join collaborating with us ... link to mission statement etc.pp." 14:08:24 I expect the new to become viral anyway 14:08:28 *the news 14:08:55 in so far as that the people working with openwrt will also hear about lede sooner or later 14:09:53 I will happily announce it to the spanish "community"/forum if that helps :) 14:10:02 blogic also epxressed interest in reaching out to the asian openwrt communities 14:10:12 yes 14:10:36 i would like to ask yousing to help us setup some communities in asia that we would endorse 14:10:48 like a "offifical project server" type thing 14:10:59 we horribly failed at this over the last decade 14:11:29 oops *yousong, i have a bad typo day today 14:11:29 I can obviously play herald for the Gluon community - and also inform the other 3 Gluon maintainers beforehand if we think this makes sense 14:11:55 (2 of the 3 are also based in Lübeck, so I can just talk to them in person) 14:12:05 neoraider: this makes sense 14:12:10 sure 14:12:15 its not a big secret 14:12:36 the only reason we are not public yet is that we want to have it all setup and nice and polished and do it organized 14:12:56 there is no secret really the aim is to be public and transparent hence all the IRC logs and mailinglist logs 14:13:05 ok, so we're already over an hour now - to protect nbd from sleep deprivation we should hurry up :) 14:13:12 the whole process leading up to the reboot will be published 14:13:50 any further thoughts on the company approachment aspect? 14:14:08 personally I can't think of any company at this stage that I would approach directly 14:14:27 We should make a press release when this goes official with the names of the developers supporting this, so we get some media conervage 14:14:39 for the people not so active in the communities 14:14:41 we're still working out rules who to deal with them in thefirst place, Hauke made some suggestions on the list already 14:14:50 and to avoid any wrong information 14:15:03 yeah, let's leave out companies at this stage 14:15:09 yes, agreeing with hauke here - we should put up some official press release which we consider to be the authoartive media statement 14:15:23 maybe with a numbero f endorsements of both communities and develoeprs 14:15:46 companies can endorse the project as well if they want to, but they shouldn't get advance information 14:15:54 they can do so when the announcement is out already 14:15:59 ok, so to recap: 14:16:35 #action Anyone will reach out to his respective communities when we start the project 14:17:09 #action We'll prepare a template message we can use to send it to the various lists of relevant projects, asking for endorsements and inviting them to collaborate 14:17:27 #action We'll prepare a press release 14:17:46 #action We'll setup another etherpad where we pool community and develoepr suggestions 14:18:01 right so far? 14:18:08 yes 14:18:10 ack 14:18:12 ack 14:18:25 ok 14:18:55 ack 14:19:04 okay, lets quickly move on to the Roadmap 14:19:20 I think there's not much to discuss here yet 14:19:32 feature freeze 14:19:36 stabalize 14:19:41 release 14:20:02 and auomatisation 14:20:10 http://lede:g3h3im@www.lede-project.org/todo.html 14:20:12 we are automatic already 14:20:18 95% 14:20:25 at least on the release front 14:21:43 #topic Roadmap 14:22:14 #info blogic wrote down a number of todos in semirandom order 14:22:23 #link http://www.lede-project.org/todo.html 14:23:02 I suggest setting up a pad here again where we can maybe start to shape a timeline 14:23:16 especially for the near term things up to date we're going public 14:23:28 ok 14:24:16 more thoughts on this? 14:24:38 #action jow_laptop will setup an etherpad where we can work on a roadmap/timeline draft 14:25:23 focus is on stabilizing and not having amazing new ideas for new stuff 14:25:51 btw. can we move future discussions like the one we had today to a pad or something? i have no idea when i'm going to be available for another meeting 14:25:56 and once we stabilized we shoul reach out to the userbase and find out what the need 14:26:02 to put it bluntly; make existing stuff actually work, then start building new stuff :) 14:26:12 travelling all over the place and i'm not sure when/where i will have internet access and time 14:26:18 ok 14:26:27 nbd: well complicated 14:26:34 discussion needs interaction 14:26:41 and if you wont be near inet anyhow 14:26:55 i will be near inet, i just don't know ahead of time when 14:27:06 it will just kill the conversation 14:27:17 i would prefer to crunch the discussion into the weekly meetings 14:27:22 we agreed on day 1 to have them 14:27:23 but we can try to prepare some stuff upfront 14:27:29 it was key part of the whole idea 14:27:36 sure 14:27:40 liek we did this time 14:27:47 like setting up pads with most sutff already mention which we can then briefly skim over in the meetings 14:27:57 anyone was free to put stuff int he pad or actively push conversations on the ML 14:28:02 if i find some times where i know i will be available, i'll let you guys know 14:28:10 cool ! 14:28:11 allright, lets wrap this up guys 14:28:14 we're almost through 14:28:18 yay 14:28:27 small offtopic 14:28:37 final topic, some simple decisions 14:28:43 #topic Votes 14:28:47 i built a huge regex monster to convert wiki 2 asciidoc and am currently pulling the uci docs into web.git ;) 14:28:50 looks good 14:28:58 cool 14:29:05 nice! 14:29:22 I reworked our project rule draft a little bit to kill a number of typos 14:29:40 looks good to me 14:29:44 to make the woring a little more eloquent and to better convey the idea or reason behind those rules 14:29:56 yes 14:30:22 I kept the original spirit and added one thing, the requirement to publically dedocument responsibilities 14:30:29 *document 14:30:30 damn 14:30:35 too much coffee 14:30:52 what does that mean ? 14:31:31 it means that we'll have a page somewhere that states: git server is oprerated by jow, john and noltari, irc bot is operated by nbd, neoraider and rafal etc. 14:31:48 just so that people know whom to contact when stuff is broken 14:31:57 ok 14:32:02 lets vote on that one then 14:32:11 can be irc nicks, mail adresses etc. 14:32:25 ok 14:32:26 + 14:32:28 + 14:32:35 + 14:32:37 + 14:32:42 + 14:32:58 nice 14:33:05 + 14:33:22 #agreed 6/6 attendees accept the new rule draft 14:33:30 #action jow_laptop will commit it asap 14:33:41 Final decision, 14:34:08 CC BY-SA 4.0 unported for logo, documentation, website resources etc. 14:34:12 + 14:34:20 wait 14:34:34 do we understand if this is a good one ? 14:34:49 i know jow and me concluded it is good but we were not sure 14:35:23 I specifically wanted to allow commercial use (think of e.g. printing documentation or using the logo for a product description) 14:35:30 also the docs are partially based on those from the owrt wiki 14:35:33 attribution is desirable 14:35:38 ok 14:35:38 share alike as well 14:35:45 if you are confident then 14:35:46 + 14:35:46 in case someone extends the docu 14:35:54 so from me, + 14:35:57 + 14:35:57 + 14:36:16 i'll check the wiki license and see if we need to mark those pages separatly 14:37:13 Hauke_1: any thoughts on it? 14:39:17 anything else? 14:39:32 nbd: nope, you're free to go 14:39:36 ok, thx 14:39:37 bbl 14:39:40 bye 14:40:08 will wait for a feedback from Hauke_1 before closing this 14:42:59 + 14:43:10 #agreed 6/6 attendees agree on putting the logo and website resources under the CC BY-SA 4.0 unported license 14:43:18 thats it! 14:43:25 thanks ! 14:43:31 thank you very much for your time guys 14:43:31 :) 14:43:40 cc by-sa-4.0 is also compatible with gpl and so on, so I can integarte it into such software 14:43:49 ? 14:43:56 that was a question ;-) 14:44:12 https://www.fsf.org/blogs/licensing/creative-commons-by-sa-4-0-declared-one-way-compatible-with-gnu-gpl-version-3 14:44:14 Title: Creative Commons BY-SA 4.0 declared one-way compatible with GNU GPL version 3 Free Software Foundation working together for free software (at www.fsf.org) 14:45:23 and version 2? 14:48:14 not officially endorsed by the FSF 14:48:19 but they want to kill v2 anyway 14:49:18 ah SA conflicts with GPLv2 14:50:33 Hauke_1: do you foresee any practical problems? 14:50:56 can I integarte this logo then into a GPLv2 gui? 14:52:31 and can we license all code snipets in the wiki under bsd license 14:52:39 I will bring this up next time 14:52:50 yes, lets simply formulate a license exception then 14:53:27 like "artwork maybe used in gplv2 programs" and "code snippets in documentation are considered to be public domain / bsd" 14:53:33 I hate legal stuff 14:53:41 any other final remarks? 14:53:51 yes that would be nice 14:54:38