11:03:45 <Stskeeps> #startmeeting Mer advisory board 20/4/2012
11:03:45 <MerBot> 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 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:04:25 <Stskeeps> 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 <lbt> present
11:04:41 <Sage> o/
11:05:09 <Stskeeps> we agree we have enough votes to make decisions stick, then
11:05:26 <Stskeeps> #info mdfe_ stepping in for Danny as representing from PA
11:05:39 <Stskeeps> #topic http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-04-05-12.00.html
11:05:48 <Stskeeps> #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 <Stskeeps> there was no actions from last time, any objections to the minutes from last time?
11:06:10 <lbt> no
11:06:16 <Sage> no objections
11:07:22 <mdfe_> I'm not sure about
11:07:56 <Stskeeps> 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 <Stskeeps> since it's an irc minutes it's a bit hard to fake though :)
11:08:34 <lbt> We should maybe note that the url in the published agenda was typo'ed :)
11:08:39 <Stskeeps> yes
11:09:12 <mdfe_> I was not present in the last meeting, but we can go on
11:09:15 <Stskeeps> ok
11:09:33 <Stskeeps> #info OK'ed (no objections from mdfe, lbt, sage)
11:09:40 <Stskeeps> #topic 1. Project news since last, presented by project architect
11:09:51 <Stskeeps> #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 <Stskeeps> #info Mer BoF proposed for Devaamo Summit (http://summit.devaamo.fi/ )
11:09:57 <Stskeeps> #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 <Stskeeps> #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 <Stskeeps> #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 <Stskeeps> #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 <Stskeeps> #info Qt5 base snapshot has passed review in Mer and will be admitted in next release (after 0.20120419)
11:10:12 <Stskeeps> (done)
11:10:35 <Stskeeps> 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 <Stskeeps> i will also put this 3 month term limit on agenda for next meeting
11:11:13 <lbt> #info Infrastructure monitoring is being setup to avoid some resource issues we've had recently (ie out of disk space)
11:11:59 <lbt> (done)
11:12:17 <Stskeeps> any complaints, things i forgot, or discussion topics that I, as architect should discuss here?
11:12:41 <Stskeeps> or perhaps requirements/wishes for coming releases
11:12:49 <mdfe_> I have some questions about mer core updates
11:12:54 <Stskeeps> sure
11:13:38 <mdfe_> I do not really understand what triggers the update of an package
11:14:12 <mdfe_> I mean is there a kind of defined process?
11:14:28 <Stskeeps> 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 <Stskeeps> like for example, qt4.8.1 needing a newer version of libxcb
11:15:03 <mdfe_> I'm asking because sometimes I wonder why some really inner parts will be updated
11:15:20 <mdfe_> like glibc to eglibc update
11:15:55 <mdfe_> I just like to understand
11:16:16 <Stskeeps> 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 <Stskeeps> also, because we are asking people to work upstream, we also need to take the output of those projects
11:16:45 <lbt> 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 <Stskeeps> or we end up with ancient packages with a lot of patches on them
11:17:12 <mdfe_> Ok thanks for this info
11:17:23 <Stskeeps> of course if it breaks things, we try to revert
11:17:37 <lbt> mdfe_: a related issue is "how do we handle stable branch releases of Mer"
11:17:38 <Stskeeps> and in stabilization branches, which will come eventually, we will avoid version upgrades
11:17:48 <lbt> :)
11:18:15 <mdfe_> this sounds really good to me
11:18:33 <lbt> Which also has issues for the SDK and systems (eg scratchbox2 will need an older OBS)
11:19:04 <mdfe_> the SDK will need a older OBS?
11:19:08 <Stskeeps> right now we're marching to the point where we can honestly publish as a stabilization branch and keep that running
11:19:55 <lbt> 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 <Stskeeps> due to upstreaming efforts needing to sync, as an example
11:20:22 <lbt> but it may be that the sb2 available today won't build on the OBS that's available in June 2012
11:20:54 <lbt> that's due to sb2 support being beta at the moment and APIs may change
11:21:21 <lbt> it's an issue and hence if vendors are looking to create stable branches they should raise this in Mer
11:21:23 <mdfe_> I did not get it exactly but it sounds like big changes are planned
11:21:50 <lbt> not big... but internal OBS : SB2 API changes
11:22:11 <Stskeeps> long story short, as sometimes happens, there will be 2-3 approaches to same things in open source :)
11:22:14 <mdfe_> maybe we should talk after this meeting in detail?
11:22:18 <lbt> sure
11:22:20 <Stskeeps> this happened to our SB2-OBS work in upstream OBS
11:22:59 <Stskeeps> 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 <Stskeeps> but result will be better for long term
11:23:29 <Stskeeps> but yes, let's move on
11:23:31 <lbt> #info Vendors considering stabilisation branches of Mer should raise this with Release Management people to discuss support issues.
11:23:44 <mdfe_> I really like long term solutions
11:24:27 <Stskeeps> #info FYI: Release management every tuesday in #mer-meeting at 11:00 UTC - we plan content and directions there usually
11:25:01 <lbt> I don't think that's in doubt mdfe_ - this is just being open about some change happening at the moment
11:25:24 <mdfe_> ok
11:25:33 <Stskeeps> ok, next topic unless anyone else has anything
11:26:14 <Stskeeps> #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 <lbt> 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 <vgrade> catches up
11:26:58 <lbt> As I said in the email - I think this is a no-brainer :)
11:27:09 <Stskeeps> i have one question about this - what's the practical impact of this decision?
11:27:46 <lbt> I want to permit collaboration on supporting a cobs rather than having multiple ones to support
11:28:14 <lbt> that will have the usual issues around 'sharing' resources
11:28:27 <lbt> usernames, resource allocation etc
11:29:07 <Stskeeps> 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 <lbt> yep - and essentially for us to volunteer to umbrella it
11:29:46 <lbt> note, I don't mind if another solution arises
11:29:49 <Stskeeps> in terms of management, or in terms of legal entity
11:29:53 <lbt> both
11:30:04 <lbt> do whatever we need to do to make it happen
11:30:22 <lbt> bearing in mind the risks I noted in the email too
11:31:30 <lbt> 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 <Stskeeps> 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 <Stskeeps> because of legal attacks
11:32:07 <lbt> yep - so I know I need an answer to that
11:32:12 <Stskeeps> in terms of management, i don't see why we couldn't participate as part of a community obs's organisation
11:32:32 <Stskeeps> giving input/'donating' obs workers
11:33:00 <lbt> *nod*
11:33:31 <jbos> How is this handled on a i.e. openSUSE pov? Maybe we can get an idea from there?
11:33:33 <Stskeeps> 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 <lbt> So this also allows PA and Nemo and Maemo to decide to delegate a c.obs to Mer project
11:33:51 <Stskeeps> so it's a balance
11:34:01 <lbt> Stskeeps: agreed
11:34:33 <jbos> what do y mean with 'delegate' => I read: "donate a worker" right?
11:35:06 <lbt> I mainly mean not setup and manage their own OBS
11:35:37 <jbos> jep. Agreed.
11:35:46 <mdfe_> agreed
11:35:52 <lbt> 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 <lbt> or just iekku on her own ;)
11:36:21 <Sage> ;)
11:36:32 <Stskeeps> lbt: can you summarize the possibilities for solutions we can decide upon?
11:36:38 <iekku> wait what :D
11:36:45 <jbos> I suppose that everyone on board will have reason to make a c.obs performant
11:37:11 <lbt> Stskeeps: I'm cautious about solutions still
11:37:32 <lbt> the obvious one is a c.obs entity that has donations and sources HW from Hetzner
11:37:52 <Stskeeps> s/c.obs/collaboration area, mer community-ish/g ?
11:38:07 <lbt> yes
11:38:26 <lbt> I'd like the funds to be a bit fluid
11:38:51 <Stskeeps> my opinion is that we can probably participate with workers, but frontend and download areas must be seperate
11:39:09 <lbt> I suspect that will be the case
11:39:10 <mdfe_> this makes sense
11:39:30 <lbt> we may make the collaboration area the 'main' place to send funds
11:39:42 <Sage> so basically Mer project would just be yet another contributor to the c.obs
11:39:59 <lbt> then allocate them to a discrete Mer-Core project
11:40:06 <mdfe_> but what is about the umbrella?
11:40:40 <Stskeeps> 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 <lbt> mdfe_: so the other issue is funding
11:41:16 <lbt> I want 'us' to be able to allocate funds to cobs and mer core CI
11:41:28 <lbt> and yet keep them legally discrete
11:41:31 <mdfe_> i get it
11:41:39 <Stskeeps> lbt: i'd like to see listed what directions this decision point can take, just to summarize
11:42:00 <lbt> yep - I need to talk to eV first
11:42:22 <lbt> I'll also see if anyone at SF knows anything - and maybe Devaamo
11:43:00 <lbt> how about giving progress reports at the AB meetings too?
11:43:17 <Stskeeps> 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 <Stskeeps> is that about what i've said?
11:43:42 <lbt> yes
11:43:49 <Stskeeps> any other options so we can list those?
11:43:59 <lbt> it may be that we all serve on 2 ABs
11:44:22 <lbt> Another option is to invert your suggestion
11:44:50 <Sage> lbt: progress reports of what?
11:45:02 <lbt> 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 <lbt> Sage: well, I need to go on a quest ... seek answers...
11:45:48 <Stskeeps> i think initially we could do it through a proxy person, instead of a AB that sits also in community area
11:45:49 <lbt> discuss with eV for example and the other nfp umbrellas
11:46:11 <Stskeeps> because there might be companies in upcoming AB's that want to play it more safe
11:46:20 <Stskeeps> proxy=representative
11:46:22 <lbt> I didn't note who said it but I have heard we may be over-engineering
11:46:37 <lbt> so I want to get legal risk assesment first
11:46:46 <Stskeeps> :nod:
11:46:59 <lbt> so...
11:47:43 <lbt> 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 <Stskeeps> for your proposal (inverted), what would then host the core area servers?
11:47:58 <Stskeeps> just to keep track
11:48:26 <Stskeeps> host as in 'own'
11:48:36 <lbt> a small legal entity that's initially funded by collaboration but could be funded by individuals
11:48:42 <Stskeeps> ok
11:48:53 <lbt> yes, discrete contract with Hetzner for example
11:49:53 <Stskeeps> 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 <Stskeeps> simply to reduce risk
11:50:28 <Stskeeps> as it'd be fatal to mer if collaboration would stop funding
11:50:39 <lbt> ah, but then Mer is responsible for (and may be considered to own via funding) the community area
11:51:16 <Stskeeps> okay, so, one of these two forms should be investigated and analysed on what makes sense
11:51:16 <Sage> I've lost track already.
11:51:19 <Stskeeps> from the constraints visible
11:51:21 <Stskeeps> yeah
11:51:44 <lbt> Sage: This stuff I understand :)
11:52:00 <Stskeeps> 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 <Sage> If there is lets say "Mer Community" that hosts OBS server on separate domain and separate servers from mer core.
11:52:21 <Stskeeps> lbt: and perhaps make a decision that this is the general direction we're going into (two options)
11:52:22 <Sage> Then if mer core project would donate some machines as workers for that there wouldn't be any risk, right?
11:52:49 <Stskeeps> lbt: as it will also matter what other participants on community area would think
11:53:07 <lbt> Sage: I would be speculating too much
11:53:49 <lbt> 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 <lbt> so right now I'm not asking for commitments or constraints wrt a solution
11:55:24 <lbt> eV may come back and say "we'll create a cobs division and elect you to it"
11:55:38 <lbt> I'll discuss and report back any such proposals
11:56:15 <Stskeeps> 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 <Stskeeps> ... 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 <Stskeeps> as the two first proposals to be evaluated
11:56:51 <Stskeeps> .. does that maeks sense?
11:56:58 <lbt> too restrictive
11:57:07 <lbt> "lbt to go find solutions"
11:57:15 <Sage> :)
11:57:36 <Stskeeps> 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 <lbt> yep - cool
11:58:01 <Stskeeps> anyone OK with us taking a vote on this, or should we add more options?
11:58:10 <Stskeeps> er, everybodyh OK
11:58:12 <Stskeeps> that is
11:58:47 <lbt> I'm happy to vote now (or answer questions)
11:59:25 <Sage> can someone open the facilitating word there. What does that consist?
11:59:40 <Stskeeps> as in, making it possible to exist
11:59:47 <Stskeeps> or rather, 'making it possible'
12:00:08 <lbt> 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 <lbt> and we may not mind
12:01:31 <Stskeeps> #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 <Sage> "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 <Stskeeps> that also works i guess
12:02:04 <lbt> yes
12:02:05 <Stskeeps> lbt, that ok with you?
12:02:18 <Sage> The first one is a bit hard to read in my opinion but I'm fine with both :)
12:02:22 <Stskeeps> #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 <Stskeeps> okay, voting has started :)
12:02:30 <lbt> yes
12:02:31 <Sage> yes
12:02:34 <mdfe_> yes
12:02:48 <Stskeeps> #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 <Stskeeps> #info yes votes: lbt, Sage, mdfe_
12:03:03 <Stskeeps> OK, moving on to AOB
12:03:07 <Stskeeps> #topic Any Other Business (AOB)
12:03:17 <Stskeeps> any other business to discuss?
12:03:28 <lbt> yup :)
12:04:03 <Stskeeps> that shouldn't be an entire agenda item of it's own, that is :)
12:04:05 <lbt> 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 <lbt> hehe
12:04:31 <lbt> still waiting for an OK from them ... grrr
12:04:45 <Stskeeps> :nod:
12:04:53 <lbt> I have some wording for a donation policy which I'll share here
12:05:05 <lbt> Mer is a community project and depends on the generosity of supporters for funding.
12:05:06 <lbt> 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 <lbt> 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 <lbt> contributions we can organise invoicing via a UK VAT-registered limited company for a service to create and maintain Mer servers.
12:05:11 <lbt> 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 <lbt> I intend to put this up on the wiki as a 'draft' but would like any immediate responses to it
12:05:52 <lbt> we can confirm it next time (or this time if everyone is OK)
12:06:15 <Stskeeps> 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 <lbt> OK I will verify the steps with my accountant before doing anything
12:07:18 <lbt> erm... before taking any money - I'll put it on the wiki though
12:07:21 <Stskeeps> as this goes a bit beyond AOB purpose
12:07:49 <lbt> yeah - I got an email from stefan and wanted to respond quickly
12:08:12 <lbt> since they got buried in the spam folder I felt a bit guilty
12:08:34 <Stskeeps> any other discussion points or can i close the meeting?
12:09:08 <lbt> Any comments in principle on that wording
12:09:40 <mdfe_> not from my side
12:10:41 <Stskeeps> alright, thank you all for coming
12:10:44 <Stskeeps> #endmeeting