17:28:41 <jow> #startmeeting
17:28:41 <lede-bot> Meeting started Wed Jul 20 17:28:41 2016 UTC.  The chair is jow. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:28:41 <lede-bot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:28:56 <jow> #topic LEDE July meeting
17:29:21 <thess> nbd: It wouldn't hurt. We could possible archive to gmail
17:29:21 <jow> we can start if you're ready
17:29:34 <blogic> hi
17:29:38 <blogic> sorry got held up
17:29:57 <jow> np, greato have you here
17:31:11 <jow> SO the agenda proposal is here
17:31:13 <Hauke> agenda: http://piratepad.net/RVVihbFpUh
17:31:14 <lede-bot> Title: PiratePad: RVVihbFpUh (at piratepad.net)
17:31:19 <jow> #link http://piratepad.net/RVVihbFpUh
17:32:21 <jow> #topic Infrastructure
17:33:10 <thess> OK - I'll bite. Flyspray?
17:33:53 <Hauke> no problem we can start with Flyspray
17:35:02 <thess> I have been in contact with the developers (such as they) are and they mentioned the desire for help with the product.
17:35:27 <thess> Personally, I am not all that interested in doing that, but I will continue to look into bugs,
17:35:39 <thess> report them and push fixes to them on Github.
17:36:38 <thess> Also, I would like to do more triage work on reports and have a request for all of you.
17:37:09 <thess> I would assign bugs for investigation or fixing if we had a list to topics each of us was
17:37:26 <thess> interested in handling. Otherwise things just sit there until someone picks them up.
17:38:56 <jow> makes sense to me
17:39:23 <jow> at least I know that I cannot really fix ath9k or ethernet driver bugs
17:39:36 <jow> I'm happy to deal with buildroot or packaging stuff though
17:39:59 <jow> or fix things in the projects/ realm, such as ubox and things
17:40:08 <thess> Any objects to me putting out a request (email) for topics / specialities from each developer/committer.
17:40:22 <blogic> thess: sounds good
17:40:53 <thess> I'll put it up as a page on our site
17:41:07 <jow> #action inquire committer topics for better future bug triage
17:41:31 <jow> #action publish results in web.git
17:42:11 <thess> Anything else with FS?
17:42:27 <blogic> thess: i like it alot
17:42:29 <jow> at some point I like to put some effort into the design
17:42:43 <jow> the layout of comments to an issue is unlucky imho
17:43:02 <jow> like shifted to the left below the menu and way narrower than the rest
17:43:07 <jow> makes it easy to overlook
17:43:22 <jow> but all in all I like it too, especially the github auth
17:43:50 <thess> Yeah, the Github auth is awesome.
17:44:26 <thess> Layout changes are pretty straight forward as it is a themed CSS (ala Drupal/Joomla)
17:44:26 <jow> KanjiMonster asked for less redundant info in the mail notifications
17:44:41 <jow> but I didn't find the motivation to redo that part yet
17:44:54 <thess> jow: Yes, still have open task on that.
17:44:58 <jow> I was lucky that the lede-bugs and lede-commits lists work as they do for the moment
17:45:07 <KanjiMonster> I mostly care about the subject
17:45:32 <jow> that we can probably change easily
17:45:54 <jow> #action rework FS issue notification mail subjects to allow gmail threading
17:46:12 <jow> iirc it is an printf-like string available directly via the settings menu
17:46:22 <thess> Didn't we do that already?
17:46:41 <jow> I changed some thing already but did not yet remove the change/action type from the subject
17:47:31 <jow> it should basically always contain just the issue title without any "comment added" or "issue changed" suffix
17:47:33 <thess> With respect to layout - take a look at bugs.archlinux.org (Flyspray site)
17:48:33 <jow> thess: it has the same problem though, comments feel a bit "unstructured" and unrelated to the actual issue
17:48:57 <jow> but thats bikeshedding - lets move to the next item
17:49:17 <jow> Regarding the mirror situation
17:50:33 <jow> currently we have the problem that half a dozen different build slaves are rsyncing their artefacts to the download server at random intervals
17:50:53 <jow> on top of that the hetzner rsync performance is awful at best
17:51:43 <jow> the mirror team of the RWTH aachen sponsored us a machine we can use to act as primary download server
17:52:32 <jow> that machine should provide a more stable rsync performance compared to hetzner, downside is that it does not have ipv6 connectivity
17:52:52 <Hauke> are they working on ipv6?
17:53:05 <jow> it is supposed to be available "soon"
17:53:17 <jow> but as we all know this can mean next month or next decade
17:54:01 <blogic> jow: howabout having master at aachen
17:54:09 <blogic> and sync to hetzner and provide ipv6 there ?
17:54:23 <jow> furthermore we got another mirror sponsored from rwth aachen (aside from the yet-to-be used master machine)
17:54:56 <Hauke> I am for blogic's idea
17:55:01 <jow> we got asked by the people there why their mirror receives so little traffic and whether they should continue providing it
17:55:16 <thess> +1 w/john
17:55:27 <jow> they said its currently spending more bandwidth rsyncing than serving any clients
17:55:41 <jow> which brings me to the next problem giving me headaches
17:56:16 <jow> our build artefacts are extremely volatile, from the rsync pov there is little similarities between the binaries produced by two consecutive build runs
17:56:24 <jow> we should investigate why
17:57:29 <jow> example here: http://phase2.builds.lede-project.org/builders/mipsel_74kc_dsp2/builds/134/steps/packageupload/logs/stdio
17:57:58 <blogic> weird
17:58:03 <thess> date stamps, signatures ?
17:58:12 <blogic> lynxis: did we not have reproducable builds ?
17:58:22 <jow> thess: possible, it needs to be figured out
17:58:42 <jow> so what did I do so far;
17:59:06 <jow> - I lowered the TTL of downloads.lede-project.org to 5 minutes so that we can quickly switch to the new host
17:59:39 <jow> - I assigned an alternative name to the current rsync server and reconfigured the buildbots to sync there, to not interrupt things during the switch
18:00:04 <lynxis> blogic: reproducible builds: I'm working on that one. will finish it tonight.
18:00:09 <jow> - I prepared HTTP, HTTPS and RSYNC on the new machine
18:00:36 <jow> What I need to figure out yet is how to make the rsync transfers atomic
18:01:54 <jow> my plan was to investigate pre-xfer and post-xfer hooks in rsyncd
18:02:44 <jow> the basic idea is to acquire an exclusive file lock when rsyncing to the download master and let upload requests from builders stall until that master transfer is through
18:03:11 <thess> jow: just need way to cleanup lock after failures/timeouts, etc.
18:03:34 <lynxis> how is debian doing those things?
18:03:36 <jow> the current (old) download master will serve 1) as staging area to gather and consolidate the buildbot uploads
18:03:44 <jow> 2) as ipv6 mirror
18:04:00 <KanjiMonster> also ensure that other builders that wait for the lock won't get killed because of a percieved lockup as well
18:04:28 <jow> KanjiMonster: that is part of the investigations
18:04:33 <jow> lynxis: they don't
18:05:03 <jow> at least from the things I found in the internet
18:06:11 <Hauke> is it possible to upload to a tmp directory and when it is finished just change the link from the old one to the new one
18:06:25 <jow> KanjiMonster: the idea was to use some kind of best-effort flock, basically wait for something like 30s on the exclusive lock then continue anyway
18:06:59 <jow> KanjiMonster: that should already dramatically reduce the likelyhood of rsyncing partial uploads to the download master (assuming the staging<->master connection is reliable and fast)
18:07:35 <jow> Hauke: that would be my backup plan
18:07:38 <Hauke> if we upload it to a tmp directory which changes for each upload we do not have any locking issues
18:08:54 <nbd> jow: is --delay-updates not enough?
18:09:31 <jow> nbd: no, it cannot guarantee the consistency of the entire tree, e.g. if the Packages index fits to the .ipk files
18:10:26 <jow> the other point I want to discuss quickly is the traffic distribution
18:10:48 <nbd> jow: how about this: hard link the dl dir to a new one, rsync to that one, then rename it and get rid of the old one
18:10:51 <jow> as I wrote above we got complaints from the rwth that their lede mirror is underutilizied
18:11:34 <blogic> jow: just turn it into the master
18:11:41 <blogic> and point downloads.lede... there
18:11:45 <blogic> that should utilize it :-)
18:12:08 <jow> blogic: the one they complained about is not the future master machine but their main ftp
18:12:58 <jow> we've got five instances from them by now, three buildslaves and two download machines
18:13:10 <Hauke> does opkg use the mirros or only the master?
18:13:17 <jow> opkg only uses the master
18:15:13 <thess> jow: So as blogic said - make it the master
18:15:49 <jow> ok
18:15:49 <thess> I never thought I'd hear of someone complaining about not consumming bandwidth
18:16:13 <jow> #action promote RWTH machine to new download master
18:16:48 <jow> SHall we switch to the code updates?
18:17:25 <lynxis> +1
18:17:32 <jow> okay
18:17:32 <thess> OK
18:17:36 <jow> #topic Codebase updates
18:17:50 <jow> Not much from me here, a few very minor commits aside
18:18:03 <jow> I mostly merged random PRs and a few patchwork items
18:18:19 <blogic> same here
18:18:34 <lynxis> I'm working on omap to become compatible with beaglebone black cape's
18:18:39 <blogic> updated lots of image building code with mayor collateral dammge
18:18:52 <blogic> but nbd fixed most of it now
18:18:53 <thess> lynxis: Great!
18:19:00 <blogic> ipq seems stable now
18:19:29 <Hauke> is this todo list up to date: https://lede-project.org/todo.html ?
18:19:29 <KanjiMonster> apart from the mange bootargs thingy hanging on certain cmdline contents
18:19:30 <lede-bot> Title: Project ToDos (at lede-project.org)
18:19:38 <KanjiMonster> *mangle
18:20:02 <blogic> KanjiMonster: i did not follow it to be honest
18:20:03 <jow> Hauke: no, the todo needs a mjor overhaul, ideally we decide the new contents in this meeting
18:20:25 <blogic> KanjiMonster: the conversation cinfused me and i did not understand what the problem was so i am waiting for someone to send a patch
18:20:59 <Hauke> what are the bigger topics which are missing for the next release?
18:21:27 <jow> the one big topic which is affecting the actual release mechanics is the multi device image building code
18:22:04 <KanjiMonster> blogic:   it seems to choke at a root= argument that doesn't match what the code is expecting, hanging the device. I guess, the code isn't the most readable.
18:22:43 <blogic> KanjiMonster: as i said, i'll wait for a patch to fix it
18:22:54 <blogic> KanjiMonster: i only have the eval kit so i am already chuffed we got thi far
18:23:03 <blogic> jow: yes
18:23:06 <jow> from my side I'd say we could start release branches any moment as soon as we can build images containing their profile packages
18:23:10 <Hauke> jow:  is this only the target specific code or some generic code which is missing?
18:23:28 <jow> Hauke: as far as I know the entire implementation of it needs to be done
18:23:33 <jow> nbd correct me if I'm wrong
18:23:36 <blogic> jow: once that is done we should fire up the infra and push a release and use it as a testing release to get status quo and then push another release soonish
18:23:50 <jow> the image building rework in the targets is basically preparation steps to overhaul the image building
18:24:03 <Hauke> ok
18:24:50 <Hauke> is IPv6 working now? there is "
18:24:52 <Hauke> Review recent IPV6 changes
18:24:57 <Hauke> on the list
18:25:16 <jow> the idea is that we can build multiple rootfs images in one go, to let each final device image contain exactly those packages it specified in its default packages (e.g. kmod-usb in tplink units having usb ports)
18:25:38 <jeffree> sorry to be offtopic: does anyone know why wikidevi has been down for days?
18:26:19 <jow> Hauke: it was never really broken, it just has various quirks
18:26:25 <Hauke> ok
18:26:41 <jow> but all in all I'd say that it works
18:29:07 <jow> anything else here?
18:29:14 <thess> Release names?
18:29:19 <jow> ah yes
18:30:10 <jow> I'm for the pragmatic approach and would just call it LEDE 1, LEDE 2, ... LEDE N
18:30:10 <thess> I have become partial to yy.mm.minor however, it should be the actual release date and not a desire.
18:30:40 <jow> but yy.mm is fine for me too
18:30:57 <jow> I just want to not deal with the code naming anymore
18:31:32 <thess> Fine with me -- projects have names, release have version numbers
18:31:38 <jow> its tedious to find suitable names and without inside knowledge its hard to figure out which version it corresponds to
18:31:47 <jow> I never know how debian 8 is called
18:31:54 <thess> jessie
18:31:58 <lynxis> :)
18:31:59 <jow> and I never know what version "Gutsy Gibbon" is
18:32:03 <jow> ...
18:32:03 <thess> whoops - wrong
18:32:46 <thess> dates are fine - how about use the date we branch and the minor for releases (candidates and actual)
18:33:16 <jow> yeah, something like branchyear.branchmonth.buildnr or something like that
18:33:29 <thess> +1
18:33:53 <KanjiMonster> regarding version numbering, I find the libreoffice approach for rcs sensible, where xx.yy.zz rc1 is just xx.yy.zz.1, rc2 then xx.yy.zz.2 etc, which avoids the rc -> final rename issue for opkg paths
18:34:30 <jow> why not
18:35:19 <Hauke> I prefere LEDE 1, LEDE 2, ... over a date
18:35:20 <jow> what I was aiming at was simply carving out some side branches that represent a release and put aside some buildbot resources to just watch those branches
18:36:03 <jow> e.g. branch master into 16.09 or lede1, then let buildbots build that whenever something is pushed there, much like the current snapshots are done
18:36:07 <jow> this has a few upsides:
18:36:11 <Hauke> having build bot build the branches would be very nice
18:36:23 <jow> - new users always install the latest patch version
18:36:37 <thess> hauke: the problem with LEDE 1, 2 etc. is these names are more appropriate for a product name than an engineering release
18:36:42 <jow> - rolling out fixes is as easy as cherry picking or push things to the branch
18:37:11 <jow> - no dedicated release maintainer is needed anymore
18:37:40 <thess> jow: whatever the name, your strategy is good
18:37:53 <Hauke> what do we do when the kernel version or config gets changed, then a full upgrade is needed
18:38:09 <Hauke> I like the strategy
18:38:12 <jow> Hauke: in an existing release?
18:38:37 <jow> we should simply avoid it
18:38:44 <Hauke> like a minor kernel version update
18:38:49 <jow> we can still just make a new release
18:39:24 <jow> its basically zero effort, just branch, adjust default config, tell buildbot to watch releasebranch++
18:39:27 <rmilecki> i wish names were sortable
18:39:37 <rmilecki> e.g. 1 vs. 12
18:39:42 <rmilecki> so we should have... 001?
18:39:45 <rmilecki> sounds weird
18:40:06 <Hauke> rmilecki: sort -n can also sort 1 vs 12
18:40:14 <Hauke> jow: sounds good
18:40:16 <rmilecki> yes, but some tools can't
18:40:26 <rmilecki> e.g. i'm not so sure about nginx listing
18:40:27 <KanjiMonster> so back to yy.mm ? ;p
18:40:52 <jow> yeah lets do yy.mm[.buildnr]
18:41:01 <thess> agree w/jow
18:41:02 <wiulinu> +1
18:41:05 <Hauke> will be add luci by default in the stable branch builds?
18:41:11 <jow> I guess so
18:41:16 <rmilecki> ack on both
18:41:20 <rmilecki> yy.dd + luci
18:41:24 <rmilecki> yy.mm ;)
18:42:01 <jow> #topic Releases
18:42:12 <jow> #agreed use buildbots to build release branches
18:42:30 <jow> #agreed use branch year and month (yy.mm) as version designation
18:42:52 <jow> this all depends on the image building though
18:43:01 <jow> last time we had no eta for that
18:43:13 <jow> nbd: can you chime in?
18:45:16 <jow> I guess no, so lets move to the openwrt merge discussion?
18:45:35 <rmilecki> i wish to have this completed
18:45:38 <rmilecki> and then take a decision
18:45:47 <rmilecki> see who of is working on what
18:45:56 <rmilecki> and agree on some schedule
18:46:03 <jow> rmilecki: this = merge or this = release stuff?
18:46:08 <rmilecki> rootfs
18:46:10 <jow> ah
18:46:27 <jow> yeah I wish to have it completed too then carve out a release asap
18:46:33 <lynxis> +1
18:46:45 <blogic> +1
18:48:38 <jow> #agreed multi rootfs image building needs to be finished asap
18:49:10 <jow> shall we wait for nbd?
18:49:33 <jow> I need to leave soon
18:49:40 <blogic> let me call him
18:49:43 <blogic> 1 sec
18:49:46 <thess> meet again soon?
18:50:10 <nbd> re
18:50:40 <blogic> nbd: comments ?
18:50:58 <nbd> just a moment, need to read backlog
18:51:30 <nbd> image building is still a bit hard to predict, but i got most of the groundwork in place now
18:51:42 <nbd> there is now a way to deal with ubifs and its different flash settings properly
18:51:45 <nbd> using the new image format
18:51:49 <nbd> i've converted some targets to it already
18:52:08 <nbd> i should be able to make legacy images work with the new rootfs building code as well
18:52:48 <nbd> if no unexpected issues show up, i hope to be able to get a prototype of it working in maybe 2 weeks
18:52:55 <nbd> it requires more porting work though
18:53:07 <nbd> to make targets use either the new image building code or at least the LegacyDevice wrappers
18:53:38 <jow> I guess we can all volunteer in converting the target parts
18:54:04 <thess> OK
18:54:59 <blogic> jow: most is done
18:55:08 <blogic> rt305x is missing, i forgot about it
18:55:08 <nbd> got mvebu fully ported over in my staging tree
18:55:14 <nbd> kirkwood definitely needs some love
18:55:26 <thess> legacy nand devices don't produce images
18:55:46 <thess> maybe related to ubi-utils
18:56:03 <lynxis> #action Give some love to kirkwood
18:56:58 <jow> anything else on the image building topic?
18:57:34 <thess> jow: If you need another target builder, I have have one ready to go.
18:57:35 <lynxis> i would take care of reproducible-build on https://reproducible-builds.org/
18:57:36 <lede-bot> Title: reproducible-builds.org (at reproducible-builds.org)
18:58:07 <blogic> jow: only that i wish i had not had the idea :-)
18:58:51 <jow> blogic: but it is long overdue
18:58:56 <blogic> jow: i know
18:59:09 <jow> ok, remerge topic?
18:59:19 <blogic> ok
18:59:29 <jow> #topic OpenWrt merge discussion
18:59:48 <jow> must things that happened in the last weeks can be seen on the mailing list
19:00:44 <jow> prpl reiterated their wish for us to sit together and work out the issues
19:01:05 <Hauke> is there big intrest in a merge ? The discussion on the list stoped 2 weeks ago
19:01:23 <blogic> Hauke: i think yes
19:01:33 <jow> personally I'm a bit lost in the topic
19:01:42 <jow> not sure waht we're still supposed to do
19:01:43 <blogic> Hauke: i guess people are scared to be flamed at so they dont get involved
19:01:51 <rmilecki> if you ask me, I don't have too much interest, i'm unfortunately getting annyoed by remaining OpenWrt ppl from time to time :(
19:01:51 <blogic> jow: agreed
19:02:15 <KanjiMonster> kaloz being MIA doesn't help either (at least it seems that way)
19:02:31 <jow> I helped zoltan to migrate the openwrt wiki to a non-lede machine
19:02:35 <blogic> jow: i honestly would not mind, however i think we cant make it happen
19:02:37 <nbd> yeah, last i heard from him he wanted to try to put together an opportunity for a face to face meeting
19:02:41 <blogic> its up to the owrt folks i guess
19:02:51 <nbd> but i didn't hear back from him
19:03:07 <blogic> jow: the thing is we did everything thewy asked, name conditions, propose a process, enter discussions
19:04:16 <jow> KanjiMonster: what is the situation on the openwrt side? is there any more activity in irc?
19:05:00 <jow> nbd: so the paris meeting was just happy talk?
19:05:54 <KanjiMonster> jow: the public channels are still rather active
19:06:32 <jow> ok
19:06:46 <nbd> jow: mostly. i still do think that a face to face meeting would be quite important for getting closer to being able to get the remerge discussion going in a constructive direction again
19:06:59 <jow> nbd: the question is what should be in the end
19:07:19 <jow> personally I neither care about the openwrt name nor about the old openwrt codebase
19:07:43 <jow> and I know that we cannot handle wiki and forum without serious volunteer help
19:07:50 <Hauke> like I said having a F2F meeting would probably exclude some people that have problems traveling
19:08:07 <jow> well f2f could be a video conference too I think
19:08:29 <lynxis> I like f2f meeting and it gives us much more than a video conference
19:09:00 <jow> so I guess one thing we should figure out first;
19:09:07 <Hauke> someone added a meeting at the ELCE
19:09:17 <Hauke> I assume that many people will be there
19:09:46 <jow> is any active lede developer willing to support a remerge and willing to work on a reunified project or is someone having objections
19:09:54 <Hauke> I think we shold do an audio/video meeting first and then decide for F2F
19:10:00 <jow> or rather are all instead of is any
19:10:28 <Hauke> I would like to see us merge again
19:10:29 <jow> and, where do we want to end up, what is the desired outcome
19:11:19 <blogic> jow: well, we already agreed on what we think should be the way
19:11:47 <blogic> in short, have them join lede and then use the old brand in one way or another after the domain is handed over to spi
19:12:02 <blogic> i doubt we would find much support for doing it the other way around
19:12:22 <rmilecki> blogic: there is more than domain if u ask me
19:12:34 <rmilecki> mail servers, mailing lists, irc channels, servers
19:12:36 <blogic> rmilecki: yes that was the short version
19:12:37 <rmilecki> what about them?
19:12:45 <rmilecki> nto that I expect a full answer
19:12:48 <rmilecki> just many things to consider
19:12:54 <blogic> sure
19:13:05 <jow> mailing lists can be forwarded
19:13:16 <jow> irc channels live and die by their participants
19:13:28 <rmilecki> jow: they are maintained by someone at OpenWrt who does random things silently
19:13:31 <jow> servers can be repurposed
19:13:46 <rmilecki> that's why I can't figure out a good way to work with OpenWrt
19:14:39 <jow> rmilecki: but thats the exact problem, once you're outside of the openwrt core its a nebulous thing
19:15:02 <blogic> jow: i never realized how much until i was not part of the core anymore
19:15:02 <thess> Does OpenWrt represent more to us than just resources.
19:15:09 <jow> its almost impossible to get a proper handle onto it, much like on the entire remerge discussion in the first place
19:15:31 <blogic> thess: well, at least some of us have a histroy with it
19:15:49 <KanjiMonster> thess: it's also brand name / recognition. everyone knows openwrt, but lede is "new"
19:15:49 <blogic> thess: and at least some $corp had made an investment, which they are now worried about
19:16:06 <jow> thess: for me its nostalgia, a more or less strong brand name and community resources
19:16:53 <jow> but personally I do not really care about the brand
19:17:06 <wiulinu> brand name isnt as important as most people think, people who use openwrt also know about lede, most of them.
19:17:17 <jow> thats my perception as well
19:17:33 <thess> So our choices seem to be: attract the resources, or get openwrt to be organized and managed as LEDE
19:17:46 <jow> I guess it is more about aligning with the community, everything else is replacable (in my opinion)
19:18:35 <KanjiMonster> having both openwrt and lede also splits contributions; NXP chose openwrt for their initial submission of their amd64 platform
19:18:35 <blogic> it would be nice to get it resolved in one way or the other
19:18:47 <blogic> we have a long history after all
19:19:59 <jow> KanjiMonster: sure but is there someone acting upon those submissions?
19:20:05 <Hauke> as an external contributor who is not so activae in the commonity it is now hard to decide where to contribute
19:20:34 <KanjiMonster> jow: wigyori is at least merging pull requests on github
19:21:22 <jow> ok
19:21:48 <jow> so what shall we do in adition to what we already did?
19:21:58 <jow> simply ask them to join us, thne share the name?
19:22:24 <jow> we can keep telling eachother that we would like to meet and discuss but I see very little momentum
19:22:49 <thess> It would help us going forward if we had a Wiki & Forum. Who manages the openwrt ones now?
19:23:03 <jow> and more importantly I do not even see any indication of discussions similar to ours going on on the openwrt side
19:23:17 <Hauke> last week I asked in the thread to find a date for a audio meeting
19:23:55 <Hauke> but got now response so far: http://comments.gmane.org/gmane.comp.embedded.openwrt.devel/40938
19:23:56 <lede-bot> Title: OpenWrt Development List (at comments.gmane.org)
19:24:02 <jow> thess: I managed the oepnwrt wiki until recently and helped zoltan to migrate
19:24:14 <Hauke> that was the reason for my question if anybody is intrested in a merge
19:24:21 <jow> thess: the forum is administered by imre iirc
19:24:23 <KanjiMonster> since wigyori seems to run openwrt now, maybe we just need to coordinate with him
19:24:48 <KanjiMonster> (but I guess the final blocker for some things remains kaloz ...)
19:24:56 <Hauke> at least he is the most active person there
19:25:10 <jow> KanjiMonster: you mean because kaloz is mia?
19:25:44 <jow> thess: we do have a copy of the openwrt wiki data lying around on our download server
19:25:48 <Hauke> I do not want to wait for kaloz forever
19:26:04 <KanjiMonster> jow: assuming there are some adminstrative things for the domain/servers for which noone else has access/the rights
19:26:15 <jow> we could also try to talk to mikwe
19:26:17 <jow> #*mike
19:26:58 <jow> thess: but not sure if we really want to host a wiki copy with s/OpenWrt/LEDE/
19:27:17 <thess> Wasn't suggesting that!
19:27:29 <KanjiMonster> jow: I guess that would be a viable workaround
19:28:58 <jow> thess: that was partly joking; its just that any kind of wiki we'd set up would contain mostly contain redundant info
19:29:20 <jow> and I didn't want to maintain the authorative documentation in the wiki but rather in git
19:29:41 <jow> so what remains is the community wiki contents and those are already well served by the openwrt wiki
19:30:33 <jow> similar to the forum, the topics discussed there are already openwrt/lede universal, its just running under the openwrt domain
19:30:50 <jow> so it likely makes no sense to start a different competing forum with the very same topic scope
19:31:49 <thess> Any way to cross-reference without pissing people off? Are the OpenWrt forum moderators amenable to LEDE topics?
19:32:36 <blogic> thess: lede users on the owrt forum started to refer to usign "the drak side" because they get flamed ;)
19:32:38 <jow> that would be the big question
19:32:59 <jow> a cheap diplomatic solutiopn would be a LEDE subforum or something
19:33:08 <jow> and let openwrt treat us as a community build
19:33:15 <thess> The Wike has too much valuable data to loose. The dev doc could use some updates, etc.
19:33:25 <thess> s/Wike/Wiki/
19:34:10 <blogic> i am afraid i need to leave now
19:34:19 <thess> l8r
19:34:36 <blogic> thess: gn8
19:34:50 <jow> me too, shall we summarize hise point on the public list? maybe we can facilitate some more feedback there?
19:35:13 <jow> s/hise point/this points/
19:35:18 <Hauke> yes jow will you do this?
19:35:28 <jow> yes but probably not before tomorrow
19:35:35 <Hauke> mo problem
19:35:48 <thess> Yes, we could try a further public discussion.
19:36:27 <jow> #action Try to work out more details regarding the LEDE/OpenWrt coexistence on the public list
19:36:34 <thess> jow: Your points (topics) in a old mail message may be a good start
19:37:07 <jow> can I close the meeting log?
19:37:11 <thess> OK
19:37:13 <Hauke> yes
19:37:19 <jow> #endmeeting