11:03:45 #startmeeting Mer advisory board 20/4/2012 11:03:45 Meeting started Fri Apr 20 11:03:45 2012 UTC. The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 11:03:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 11:04:25 first off, let's check who's here: plasma active: mdfe_ , nemo: jukkaeklund (not present), technical lead: lbt, maintainer: sage, chairman/architect: stskeeps 11:04:37 present 11:04:41 o/ 11:05:09 we agree we have enough votes to make decisions stick, then 11:05:26 #info mdfe_ stepping in for Danny as representing from PA 11:05:39 #topic http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-04-05-12.00.html 11:05:48 #topic http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-04-05-12.00.html - Followup on actions and confirming minutes from last meeting 11:06:01 there was no actions from last time, any objections to the minutes from last time? 11:06:10 no 11:06:16 no objections 11:07:22 I'm not sure about 11:07:56 mdfe_: it's basically just a check that we agree this is what happened last time, to avoid tampering / there being decisions we don't agree happened 11:08:25 since it's an irc minutes it's a bit hard to fake though :) 11:08:34 We should maybe note that the url in the published agenda was typo'ed :) 11:08:39 yes 11:09:12 I was not present in the last meeting, but we can go on 11:09:15 ok 11:09:33 #info OK'ed (no objections from mdfe, lbt, sage) 11:09:40 #topic 1. Project news since last, presented by project architect 11:09:51 #info Mer PRERELEASE 0.20120419.0.2 , a number of CVE's fixed, thanks to D Wadsworth's contributions to bugzilla. Little bit delayed due to bug found in OBS/sb2 build scripts. http://www.mail-archive.com/mer-general@lists.merproject.org/msg00442.html 11:09:55 #info Mer BoF proposed for Devaamo Summit (http://summit.devaamo.fi/ ) 11:09:57 #info Device testing enablers now created, in the 'eat' package - it's easy to include ability to run tests from Mer Platform SDK to a given device 11:10:00 #info Planning nominations for E-P as QA Technical Lead, timoph as testrunner-ui/testplanner maintainer, iekku as bugzilla maintainer, both under QA area 11:10:03 #info Tizen IVI preview has been published and is MeeGo 1.2 derived (downloads.tizen.org) - A few of us are attending Tizen Conference 7-9 May 11:10:06 #info End of this advisory board term will be 17 May and we have to discuss if 3 months is still a sane length for next advisory board terms. 11:10:09 #info Qt5 base snapshot has passed review in Mer and will be admitted in next release (after 0.20120419) 11:10:12 (done) 11:10:35 i'll be sending nomination proposals for the next advisory board meeting, if there's others you feel that should be nominated in a mer role, please send there too 11:10:54 i will also put this 3 month term limit on agenda for next meeting 11:11:13 #info Infrastructure monitoring is being setup to avoid some resource issues we've had recently (ie out of disk space) 11:11:59 (done) 11:12:17 any complaints, things i forgot, or discussion topics that I, as architect should discuss here? 11:12:41 or perhaps requirements/wishes for coming releases 11:12:49 I have some questions about mer core updates 11:12:54 sure 11:13:38 I do not really understand what triggers the update of an package 11:14:12 I mean is there a kind of defined process? 11:14:28 it can be a couple of things: the wish to be current, to include security updates, or someone notices a package that they want to update needs a newer update 11:14:43 like for example, qt4.8.1 needing a newer version of libxcb 11:15:03 I'm asking because sometimes I wonder why some really inner parts will be updated 11:15:20 like glibc to eglibc update 11:15:55 I just like to understand 11:16:16 eglibc was both in terms of security fixes, the desire to have better ARM performance and to be closer to linaro toolchains 11:16:30 also, because we are asking people to work upstream, we also need to take the output of those projects 11:16:45 and we have : https://bugs.merproject.org/show_bug.cgi?id=161 "figure out how to track CVEs that apply to Mer" and https://bugs.merproject.org/show_bug.cgi?id=97 "Process to track upstream releases (cf debian)" 11:16:53 or we end up with ancient packages with a lot of patches on them 11:17:12 Ok thanks for this info 11:17:23 of course if it breaks things, we try to revert 11:17:37 mdfe_: a related issue is "how do we handle stable branch releases of Mer" 11:17:38 and in stabilization branches, which will come eventually, we will avoid version upgrades 11:17:48 :) 11:18:15 this sounds really good to me 11:18:33 Which also has issues for the SDK and systems (eg scratchbox2 will need an older OBS) 11:19:04 the SDK will need a older OBS? 11:19:08 right now we're marching to the point where we can honestly publish as a stabilization branch and keep that running 11:19:55 mdfe_: we will eventually have a version of sb2 which won't build on the OBS that's available on 20 Apr 2012 11:20:10 due to upstreaming efforts needing to sync, as an example 11:20:22 but it may be that the sb2 available today won't build on the OBS that's available in June 2012 11:20:54 that's due to sb2 support being beta at the moment and APIs may change 11:21:21 it's an issue and hence if vendors are looking to create stable branches they should raise this in Mer 11:21:23 I did not get it exactly but it sounds like big changes are planned 11:21:50 not big... but internal OBS : SB2 API changes 11:22:11 long story short, as sometimes happens, there will be 2-3 approaches to same things in open source :) 11:22:14 maybe we should talk after this meeting in detail? 11:22:18 sure 11:22:20 this happened to our SB2-OBS work in upstream OBS 11:22:59 so we got asked to work together on combined solution so we'll base on a slightly different approach than current SB2-OBS settings 11:23:14 but result will be better for long term 11:23:29 but yes, let's move on 11:23:31 #info Vendors considering stabilisation branches of Mer should raise this with Release Management people to discuss support issues. 11:23:44 I really like long term solutions 11:24:27 #info FYI: Release management every tuesday in #mer-meeting at 11:00 UTC - we plan content and directions there usually 11:25:01 I don't think that's in doubt mdfe_ - this is just being open about some change happening at the moment 11:25:24 ok 11:25:33 ok, next topic unless anyone else has anything 11:26:14 #topic 2. Core and collaboration discussion, http://www.mail-archive.com/mer-general@lists.merproject.org/msg00416.html by David Greaves / lbt 11:26:35 I would like to get it "on the record" that as a group we want to make a Community OBS happen in such a way that the Mer Project and projects around it can use it in a similar way to the MeeGo Community OBS. 11:26:40 catches up 11:26:58 As I said in the email - I think this is a no-brainer :) 11:27:09 i have one question about this - what's the practical impact of this decision? 11:27:46 I want to permit collaboration on supporting a cobs rather than having multiple ones to support 11:28:14 that will have the usual issues around 'sharing' resources 11:28:27 usernames, resource allocation etc 11:29:07 so you're asking if it's okay for mer as a project to participate in making a community OBS happen, and contribute to it? 11:29:28 yep - and essentially for us to volunteer to umbrella it 11:29:46 note, I don't mind if another solution arises 11:29:49 in terms of management, or in terms of legal entity 11:29:53 both 11:30:04 do whatever we need to do to make it happen 11:30:22 bearing in mind the risks I noted in the email too 11:31:30 so I want to go away and talk to other groups, maybe get legal advice and be confident that I know what the group wants and I'll represent us accurately 11:31:38 right, in terms of legal entity you know my opinion: i will be unhappy with a situation where we have a situation where the community obs will cause a shutdown of the mer core work/server's legal entity 11:31:53 because of legal attacks 11:32:07 yep - so I know I need an answer to that 11:32:12 in terms of management, i don't see why we couldn't participate as part of a community obs's organisation 11:32:32 giving input/'donating' obs workers 11:33:00 *nod* 11:33:31 How is this handled on a i.e. openSUSE pov? Maybe we can get an idea from there? 11:33:33 i do however believe we need to have ability to incubate projects, but it is not our responsibility to carry everyone's weight - we're a cooperative, people must pitch in 11:33:36 So this also allows PA and Nemo and Maemo to decide to delegate a c.obs to Mer project 11:33:51 so it's a balance 11:34:01 Stskeeps: agreed 11:34:33 what do y mean with 'delegate' => I read: "donate a worker" right? 11:35:06 I mainly mean not setup and manage their own OBS 11:35:37 jep. Agreed. 11:35:46 agreed 11:35:52 I'll need to report back to AB how resources are used and if PA donate "a" worker and use 10 ... we'll send the boys round :) 11:36:10 or just iekku on her own ;) 11:36:21 ;) 11:36:32 lbt: can you summarize the possibilities for solutions we can decide upon? 11:36:38 wait what :D 11:36:45 I suppose that everyone on board will have reason to make a c.obs performant 11:37:11 Stskeeps: I'm cautious about solutions still 11:37:32 the obvious one is a c.obs entity that has donations and sources HW from Hetzner 11:37:52 s/c.obs/collaboration area, mer community-ish/g ? 11:38:07 yes 11:38:26 I'd like the funds to be a bit fluid 11:38:51 my opinion is that we can probably participate with workers, but frontend and download areas must be seperate 11:39:09 I suspect that will be the case 11:39:10 this makes sense 11:39:30 we may make the collaboration area the 'main' place to send funds 11:39:42 so basically Mer project would just be yet another contributor to the c.obs 11:39:59 then allocate them to a discrete Mer-Core project 11:40:06 but what is about the umbrella? 11:40:40 mdfe_: in terms of Mer as a legal entity, when you have an organisation that is 'under' Mer, it's called to be under "Mer umbrella" 11:40:51 mdfe_: so the other issue is funding 11:41:16 I want 'us' to be able to allocate funds to cobs and mer core CI 11:41:28 and yet keep them legally discrete 11:41:31 i get it 11:41:39 lbt: i'd like to see listed what directions this decision point can take, just to summarize 11:42:00 yep - I need to talk to eV first 11:42:22 I'll also see if anyone at SF knows anything - and maybe Devaamo 11:43:00 how about giving progress reports at the AB meetings too? 11:43:17 my angle is that we can allow for mer (as entity) to contribute hardware to a community area and participate in the management of the community area, but the community area main servers are not under mer legal entity 11:43:23 is that about what i've said? 11:43:42 yes 11:43:49 any other options so we can list those? 11:43:59 it may be that we all serve on 2 ABs 11:44:22 Another option is to invert your suggestion 11:44:50 lbt: progress reports of what? 11:45:02 mer collaboration (as entity) to contribute hardware to a core area and participate in the management of the core area, but the core area main servers are not under mer collaboration legal entity 11:45:22 Sage: well, I need to go on a quest ... seek answers... 11:45:48 i think initially we could do it through a proxy person, instead of a AB that sits also in community area 11:45:49 discuss with eV for example and the other nfp umbrellas 11:46:11 because there might be companies in upcoming AB's that want to play it more safe 11:46:20 proxy=representative 11:46:22 I didn't note who said it but I have heard we may be over-engineering 11:46:37 so I want to get legal risk assesment first 11:46:46 :nod: 11:46:59 so... 11:47:43 the item is mainly to say "do we want to do this". It feels like a "yes" but I'd like any other objections/questions before a vote 11:47:56 for your proposal (inverted), what would then host the core area servers? 11:47:58 just to keep track 11:48:26 host as in 'own' 11:48:36 a small legal entity that's initially funded by collaboration but could be funded by individuals 11:48:42 ok 11:48:53 yes, discrete contract with Hetzner for example 11:49:53 i think http://wiki.merproject.org/wiki/Governance should be kept in mind here.. my gut feeling is for that it's better to keep the piggybank in mer and contribute to a community area 11:50:07 simply to reduce risk 11:50:28 as it'd be fatal to mer if collaboration would stop funding 11:50:39 ah, but then Mer is responsible for (and may be considered to own via funding) the community area 11:51:16 okay, so, one of these two forms should be investigated and analysed on what makes sense 11:51:16 I've lost track already. 11:51:19 from the constraints visible 11:51:21 yeah 11:51:44 Sage: This stuff I understand :) 11:52:00 lbt: i feel we've processed it a bit and we should look at those two options as method and get them weighed and analysed 11:52:02 If there is lets say "Mer Community" that hosts OBS server on separate domain and separate servers from mer core. 11:52:21 lbt: and perhaps make a decision that this is the general direction we're going into (two options) 11:52:22 Then if mer core project would donate some machines as workers for that there wouldn't be any risk, right? 11:52:49 lbt: as it will also matter what other participants on community area would think 11:53:07 Sage: I would be speculating too much 11:53:49 Stskeeps: the idea is that I go away being able to say "the AB wants to investigate ways to do this subject to a couple of well discussed constraints" 11:54:51 so right now I'm not asking for commitments or constraints wrt a solution 11:55:24 eV may come back and say "we'll create a cobs division and elect you to it" 11:55:38 I'll discuss and report back any such proposals 11:56:15 right, so i propose decision on this: "the AB decides that we are interested in facilitating a community area subject to the discussed constraints (legal risk to core, collaboration between multiple entities/projects), with initial proposals: mer as a entity can contribute hardware to a community area and participate in the management of this, but the community area main servers are not under mer legal entity. and 2) community ... 11:56:21 ... area (as entity) contributes hardware to core area and participates in management of it, but core area main servers are not under mer collaboration legal entity" 11:56:25 as the two first proposals to be evaluated 11:56:51 .. does that maeks sense? 11:56:58 too restrictive 11:57:07 "lbt to go find solutions" 11:57:15 :) 11:57:36 the AB decides that we are interested in facilitating a community area subject to the discussed constraints (legal risk to core, collaboration between multiple entities/projects) and allows lbt to investigate solutions to this ? 11:57:44 yep - cool 11:58:01 anyone OK with us taking a vote on this, or should we add more options? 11:58:10 er, everybodyh OK 11:58:12 that is 11:58:47 I'm happy to vote now (or answer questions) 11:59:25 can someone open the facilitating word there. What does that consist? 11:59:40 as in, making it possible to exist 11:59:47 or rather, 'making it possible' 12:00:08 Sage: you asked something specific before .... I think the point is that eV (the KDE legal entity) may solve this in a completely out-of-the-box way. 12:00:29 and we may not mind 12:01:31 #info please Vote yes/no on this decision point: the AB decides that we are interested in facilitating a community area subject to the discussed constraints (legal risk to Core, collaboration between multiple entities/projects) and allows lbt to investigate solutions to this 12:01:40 "AB decides that Mer project is interested in contributing to the community area with the discussed constraints (legal risk to core, collaboration between multiple entities/projects) and allows lbt to investigate solutions to this ?" 12:01:52 that also works i guess 12:02:04 yes 12:02:05 lbt, that ok with you? 12:02:18 The first one is a bit hard to read in my opinion but I'm fine with both :) 12:02:22 #info Please vote yes/no on this decision point: "AB decides that Mer project is interested in contributing to the community area with the discussed constraints (legal risk to core, collaboration between multiple entities/projects) and allows lbt to investigate solutions to this ?" 12:02:27 okay, voting has started :) 12:02:30 yes 12:02:31 yes 12:02:34 yes 12:02:48 #agreed "AB decides that Mer project is interested in contributing to the community area with the discussed constraints (legal risk to core, collaboration between multiple entities/projects) and allows lbt to investigate solutions to this ?" 12:02:59 #info yes votes: lbt, Sage, mdfe_ 12:03:03 OK, moving on to AOB 12:03:07 #topic Any Other Business (AOB) 12:03:17 any other business to discuss? 12:03:28 yup :) 12:04:03 that shouldn't be an entire agenda item of it's own, that is :) 12:04:05 The bank needed to relate my contact details with the project so I created: http://www.merproject.org/about.html (which is also a less technical description of Mer) 12:04:11 hehe 12:04:31 still waiting for an OK from them ... grrr 12:04:45 :nod: 12:04:53 I have some wording for a donation policy which I'll share here 12:05:05 Mer is a community project and depends on the generosity of supporters for funding. 12:05:06 Our primary expenses are related to hosting and we are in the process of setting up a bank account to allow us to handle donations in a transparent manner. 12:05:08 Mer produces software that we expect to be installed directly onto devices - we have to take security very seriously. For this reason we can't accept donations of hardware for which we don't have exclusive control and the fairest way to do this is to make no exceptions. All hardware for Mer Project services will be obtained directly by the Mer Project from Hetzner unless the Advisory Board approves another solution. For organisational 12:05:09 contributions we can organise invoicing via a UK VAT-registered limited company for a service to create and maintain Mer servers. 12:05:11 Our approach to funding hosting is to ensure that we have enough money to cover our hosting expenses for the next 12 months. ie we'll ensure that our projected bills don't exceed our balance before we commit to increasing our costs. For people who pay periodically we'll periodically re-confirm their commitment to continuing donations for the next six months and adjust our expenditure accordingly. 12:05:31 I intend to put this up on the wiki as a 'draft' but would like any immediate responses to it 12:05:52 we can confirm it next time (or this time if everyone is OK) 12:06:15 i think we need to put the 'cooperative' somewhere in first line, and propose this on next advisory board meeting as it needs discussion and is administrative 12:06:29 OK I will verify the steps with my accountant before doing anything 12:07:18 erm... before taking any money - I'll put it on the wiki though 12:07:21 as this goes a bit beyond AOB purpose 12:07:49 yeah - I got an email from stefan and wanted to respond quickly 12:08:12 since they got buried in the spam folder I felt a bit guilty 12:08:34 any other discussion points or can i close the meeting? 12:09:08 Any comments in principle on that wording 12:09:40 not from my side 12:10:41 alright, thank you all for coming 12:10:44 #endmeeting