History

PSC Meeting 16th / 26th January 2015

Proposed meeting time:

Friday 16th January, 1500 UTC, ?? AKDT, 1700 SAST, ?? AEST, 1600 CEST

Monday 26th January, 1430 UTC, 5:30 AKDT, 1630 SAST, 00:30(27th) AEST, 1530 CEST

http://www.worldtimebuddy.com/?qm=1&lid=2759794,2174003,5879400,3369157&h=2759794&date=2015-1-26&sln=15.5-18

previous meeting

next meeting

IRC: #qgis_meeting_150116 and #qgis_meeting_150126

Members Present:

16th of january:

  • Richard Duivenvoorde
  • Marco Hugentobler
  • Anita Graser
  • Otto Dassau
  • Gary Sherman
  • Tim Sutton
  • Jurgen Fisher
  • Paolo Cavalini

25th of january:

  • Marco Hugentobler
  • Anita Graser
  • Otto Dassau
  • Tim Sutton
  • Jurgen Fisher
  • Gary Sherman
  • Paolo Cavalini
  • Richard Duivenvoorde
  • Alex Bruy (guest)
  • Andreas Neumann (guest)
  • Matthias Kuhn (guest)

Agenda:

normal to high priority - quick answer

  • vote for QGIS 2.8 release name (Anita): candidates are a) Nodebo, b) Wien, c) Halberstadt, and d) Essen. Wien and Essen haven been dev meeting venues, Nodebo will be soon. Otto is still sourcing better Splash material for Essen, so I would suggest Wien for 2.8.

high priority

normal priority

low priority

  • QGIS 3.0 design (Anita, from last month)
    • Should 3.0 come with different icons for desktop, browser, and project files? And are we willing to invest financial resources to get these icons?

Log 16th of january

15:15 -!- jef changed the topic of #qgis_meeting_150116 to: http://hub.qgis.org/wiki/quantum-gis/PSC_Meeting_16_January_2015 | 1500 UTC/1600 CET
15:23 -!- pcav [[email protected]] has joined #qgis_meeting_150116
15:29 -!- dassau [[email protected]] has joined #qgis_meeting_150116
15:41 -!- alexbruy [~alexbruy@2a02:228:300:1::119] has joined #qgis_meeting_150116
15:42 -!- strk [~strk@unaffiliated/strk] has joined #qgis_meeting_150116
15:42 < strk> a-ha! found you!
15:43 < strk> it says #qgis_meeting_150109 on https://hub.qgis.org/wiki/17/PSC_Meeting_16_January_2015?version=6
15:45 -!- mhugent [[email protected]] has joined #qgis_meeting_150116
15:46 < duiv> shoot, strk found us -)
15:46 < duiv> hi strk, welcome
15:46 < duiv> why are you looking at old versions of wiki pages?
15:47 < duiv> we postponed this one, so at first is was planned last week....
15:48 < strk> ah, that's what "?version=6" is about, now I see :)
15:52 -!- anitagraser [[email protected]] has joined #qgis_meeting_150116
15:52 < anitagraser> hi
15:55 -!- nhv [~chatzilla@2601:6:5980:5ae:c5ab:a83a:40df:1b30] has joined #qgis_meeting_150116
15:56 -!- nhv [~chatzilla@2601:6:5980:5ae:c5ab:a83a:40df:1b30] has left #qgis_meeting_150116 []
16:00 <@jef> wien: +1
16:00 < duiv> wien +1
16:01 < pcav> wien +1
16:01 < mhugent> no strong opinion. Wien sounds good.
16:01 < anitagraser> wien 
16:01 < anitagraser> +1
16:01 < pcav> anita: why Pisa is not on the list?
16:01 < duiv> will we call it 'Wien' then or 'Vienna', do we always the local one?
16:02 < pcav> I think it should come before Nodebro
16:02 < duiv> nobody sent a splash for pisa?
16:02 < anitagraser> pcav: no submission 
16:02 < pcav> I did
16:02 < anitagraser> when?
16:02 < pcav> looking for it
16:02 < duiv> with a banner?
16:03 < pcav> I suggested a WMS, one can choose whatever cut he wants
16:03 -!- nhv [~chatzilla@2601:6:5980:5ae:c5ab:a83a:40df:1b30] has joined #qgis_meeting_150116
16:03 < pcav> graphics is not really my speciality
16:03 < duiv> pcav: that is too easy :-)
16:03 <@jef> *g*
16:03 < anitagraser> pcav: i remember but the call specified that I want images
16:03 < anitagraser> sorry, lazy
16:04 -!- timlinux [[email protected]] has joined #qgis_meeting_150116
16:04 < timlinux> Hi all
16:04 < mhugent> hi timlinux
16:04 < anitagraser> hi timlinux, we're voting release names
16:04 < pcav> I can send an image then
16:04 < duiv> hi timlinux we were voting for wien
16:04 < strk> wien =4 so far
16:04 < timlinux> +1 for anything :-)
16:05 < timlinux> As long as it has a nice name I am happy
16:05 <@jef> anything is not on the list - like pisa
16:05 < anitagraser> ok, shall we move on to the next point then?
16:05 < anitagraser> just submit more ideas and i'll collect them
16:05 < anitagraser> via mail
16:05 <@jef> dassau: did you vote?
16:06 < dassau> +1 for wien - sorry :)
16:06 -!- nhv [~chatzilla@2601:6:5980:5ae:c5ab:a83a:40df:1b30] has left #qgis_meeting_150116 []
16:06 < timlinux> I think we should just vote on whether we can delegate the choice authority to anitagraser and let her work it out each release
16:06 < anitagraser> duiv: yes, local names have been used so far
16:07 <@jef> anitagraser: you are free to choose wien then ;)
16:07 < duiv> ok, fine, Wien is such a short word...
16:07 < strk> wien=6 ; 7 voters ; 8 psc members
16:07  * anitagraser chooses Wien 
16:08 < anitagraser> next point, duiv?
16:08 < duiv> ok rotation work
16:08 -!- strk is now known as krts
16:09 -!- krts is now known as strk
16:09 < duiv> I put this on the list in dec when there was a discussion on the list about inclusion or not
16:09 < duiv> I think we now already decided it will. Just not enabled by default
16:09 < anitagraser> looks like all blockers are fixed by now, right?
16:09 < duiv> strk?
16:09 < strk> only issues left I've sent on the lits
16:09 < timlinux> I was trying to figure out how to enable it last night
16:10 < strk> none of them has been "marked" as blocker
16:10 < duiv> then there was the question from Andreas about sponsoring it and the amount
16:10 < duiv> timlinux: Settings/General
16:11 < strk> issues left: composer_support, plugin_layers (?), overview_map_display
16:11 < duiv> 'Experimental canvas rotation support'
16:11 < strk> the PAL labeling refactor doesn't seem to be needed (thus strictly related to rotation) anymore
16:11 < alexbruy> strk: so all decorations now work with rotation?
16:11 < duiv> checkbox in Application section
16:11 < strk> alexbruy: north arrow and grid work
16:11 < timlinux> ok goddit thanks
16:11 < strk> one unfiled issue is the lack of testcases securing the support of rotation
16:12 < anitagraser> @sponsoring: i agree with http://lists.osgeo.org/pipermail/qgis-psc/2015-January/002607.html "paying bugfixes for third party sponsored new feature out of QGIS pocket will cause moral damages" 
16:12 < pcav> anita, could you remind me which size for the image?
16:12  * strk also agrees on the moral damage, to be honest
16:12 < anitagraser> pcav: minimum resolution of 3000x2000 px 
16:12 <@jef> that also was my point.
16:13 < pcav> anita: thanks
16:13 -!- gsherman [~gsherman@qgis/developer/gsherman] has joined #qgis_meeting_150116
16:13 < timlinux> Yeah it seems like a generally agreed point
16:13 < strk> aside from the fact that bugfixes are being currently funded already... 
16:13 < duiv> pcav: https://github.com/qgis/QGIS/tree/release-2_6/images/splash
16:14 < mhugent> hi gsherman
16:14 < duiv> hi gsherman, it still is early isn't it ;-)
16:14 < strk> but yes, this is special in that it is a new (and externally sponsored) feature
16:14 < anitagraser> hi gsherman! do you want to cast your vote on release name? wien=6 ; 7 voters 
16:15 < gsherman> i'm behind, but name works for me
16:15 < duiv> ok then can we draw a conclusion then that it will be incorporated as it is now (as an experimental feature), and no QGIS funding will be doen?
16:15 < duiv> or is this too short
16:15 < anitagraser> duiv: works for me
16:16 < mhugent> +1
16:16 < duiv> strk: still friends?
16:16 < dassau> +1
16:16 < strk> should "enabled by default" be reconsidered with latest fixes ?
16:16 < strk> duiv: still friends :)
16:16 < duiv> for me the UI is still 'experimental'
16:16 < timlinux> the status bar widget needs some ui love
16:17 < duiv> that is what I mean
16:17 < anitagraser> i haven't tried it yet
16:17 < timlinux> and also it seems to slow down rendering a lot
16:17 < timlinux> (just subjective take on 5 minutes usage)
16:17 < duiv> http://imgur.com/oTh2Zpi
16:17 < strk> that's surprising
16:18 < pcav> timlinux: you mean the rotation is slowing down the rendering?
16:18 < timlinux> http://i.imgur.com/4woGUIv.png
16:18 < timlinux> it seems like it to me
16:18 < strk> duiv (and everyone) : please file tickets with the "rotation" tag for all these issues you find
16:18 < timlinux> Im seeing bouncing progress bar on a map that normally updates instantly
16:18 < duiv> will do it NOW
16:19 < mhugent> timlinux: for me, it was fast. Maybe you can provide test project and data to strk
16:19 < pcav> timlinux: I tested it with a very slow machine and was surprised of the contrary
16:19 < strk> in a ticket, better
16:19 < duiv> timlinux: for me it was also ok, even with a 1gb raster
16:19 < timlinux> ok never mind I just tried it with it turned off and a restart
16:19 < timlinux> seems rendering speed is not much different
16:20 < gsherman> it's because timlinux deserted unbuntu...
16:20 < timlinux> hah
16:20 < pcav> :)
16:21  * anitagraser added link to qep#4 to the agenda https://github.com/timlinux/QGIS-Enhancement-Proposals/blob/master/QEP-4-QGIS_Long_Term_Releases.rst 
16:23 < timlinux> ok so duiv whats the resolution? I would prefer to remove the experimental checkbox - if we have something added to the code tree is should be good enough to use by default
16:23 < pcav> timlinux: +1
16:24 < anitagraser> timlinux: +1
16:24 < duiv> I would prefer some more work on plugin layers (and openlayers plugin) to work 
16:24 < duiv> with rotation
16:24 <@jef> 0
16:24 < duiv> I think a lot of (starting) users will complain about such problems
16:24 < timlinux> duiv, in final release?
16:24 < timlinux> or in nightlies
16:25 < mhugent> but maybe the openlayers plugin users don't need rotation
16:25 < duiv> or we should give clear messages like: "with this type of layer, you cannot use rotation, going back to 0 degrees" or so
16:25 < anitagraser> mhugent: try explaining to them that they dont need it ;)
16:25 < pcav> duiv: couldn't we sugget the plugin writers to just switch rotation off on activation of the plugin?
16:25 < timlinux> to clarify above - if it is not good enough to use in final release, we should disable it and completely hide it from the UI
16:25 < strk> really ? with no way to turn it on ?
16:26 < duiv> we had this discussion before...
16:26 < timlinux> sorry :-P
16:27 < duiv> I'm in favour of current situation, where people who need/want it can use it, and hope that there will be fixes for future versions
16:27 < mhugent> anitagraser: we are not sure here if the google license allows it.
16:27 < duiv> -1 for me
16:27 < anitagraser> mhugent: ok, then the error message should state so. otherwise there will be lots of threads asking why
16:27 < duiv> (that is make it default ON in 2.8)
16:27 < mhugent> but I haven't read the most current ones
16:27 <@jef> duiv: you are voting -1 to make it default on?
16:28 < pcav> sorry, I think votation is a bit complex here
16:28 < duiv> jef: yes
16:28 < pcav> are we voting about the same thing?
16:28 < pcav> I think the choices are:
16:28 < pcav> * remove it
16:28 < timlinux> So that means you want it default off?
16:28 < pcav> * switch it off by default
16:28  * strk also understood timlinux wanted it completely removed
16:28 < pcav> * switch it on by default
16:29 < pcav> can we re-vote on this?
16:29 < alexbruy> if I'm not wrong timlinux only want to hide it from gui
16:29 < anitagraser> is remove it = hide it from gui?
16:29 < strk> but still funcional trough the API ?
16:30 < timlinux> yes not remove it from the code
16:30 < timlinux> just hide it from the gui
16:30 < duiv> timlinux: plz explain: did you mean to also remove the experimental checkbox?
16:30 <@jef> and you need a plugin to change the rotation?
16:30 < timlinux> until we feel it is ready for general use
16:30 < timlinux> I mean if we ship something that we know doesnt work in all situations isnt it better to wait another release and ship it when it does?
16:31 <@jef> .oO(but qgis has bugs)
16:31 < strk> Ther eare 1290 bug reports in hub right now (for some context)
16:32 < timlinux> yeah so the logical extension of that is that its ok to knowingly add to them?
16:32 < pcav> I do not see the remaining bugs as serious enough
16:32 <@jef> no, we ship something that we know doesn't work in all situations anyway
16:33 < duiv> yes, if it means you can hide it from the general public, but can make it available for people who want it
16:33 < pcav> I understand it does not work on printing and with a few plugins, right?
16:34 < strk> http://hub.qgis.org/issues/11900
16:35 < strk> wonder_sk reported it failing with "Crayfish" -- he guesses it might also fail with OpenLayers (but not confirmed)
16:35 <@jef> I suppose there's more - if we make it default on, we'll learn what other issues it produces.
16:35 < strk> +1
16:36 < timlinux> yeah switch it on by default, remove the ui checkbox, if come time of shipping there are lots of unresolved problems, make it off by default in what we ship
16:37 < strk> the checkbox is not just about the ui
16:37 < strk> the current one
16:37 < strk> disables both ui and core support for rotation
16:37 < pcav> I think the checkbox should stay, if we turn it off by default
16:37 < pcav> otherwise nobody will use it anyway
16:37 < duiv> +1
16:38 <@jef> ok, not 0.  I'd like to keep it like it is.  make it optionally available.  I don't have a problem with giving people enough rope - but they shouldn't be force to hang themselves ;)
16:38 < anitagraser> +1 for off by default if too many unresolved problems when it's time to ship
16:39 < strk> anitagraser: that implies on by default till then ?
16:39 < pcav> +1 as anita
16:39 < anitagraser> strk: yes
16:39 < anitagraser> in nightly that's fine for me
16:40 < mhugent> +1
16:40 < strk> +1 (jef, btw... the env variable could have been used to set the initial state, as someone wondered :)
16:40 < dassau> +1 for anitas proposal
16:40 <@jef> we ship what is master when we release.
16:41 < duiv> jef: then I would make it disabled just before release...
16:41 < duiv> and enabled it one week later :-)
16:41 < duiv> in master I mean
16:41 <@jef> -12
16:41 < duiv> lol
16:41 <@jef> oh, where did't the 2 come from :)
16:42 < duiv> let's draw a conclusion from this.... who dares?
16:42 < timlinux> dumb question: I though openlayers 3 has rotation support - for openlayers plugin we could upgrade to OL3 and set the rotation to match the map?
16:42 < timlinux> duiv, since you volunteered :-)
16:42 < anitagraser> timlinux: seems to be more legal than tech issue
16:43 < strk> timlinux: I can't tell if it'd be enough
16:43 < strk> (not having used that plugin anyway)
16:43 < timlinux> yeah I saw mhugent's comment above but I dont understand how rotating the google map in OL plugins creates a legal issue?
16:43 < mhugent> timlinux: asking Mathias about it, 1 sec...
16:44 < timlinux> ok thanks
16:44 < mhugent> timlinux: OL3 does not have a google layer type anymore
16:44 < duiv> my conclusion then: keep the experimental checkbox. Put it OFF by default in master (and for next release)
16:44 < duiv> (but correct me if I'm wrong)
16:44 < timlinux> for printing it reverts to upright - strk could set the default layer rotation for the composer map to match the canvas?
16:45 < timlinux> mhugent, ah
16:45 < strk> ? ON by default got more votes
16:45 < duiv> strk: ok you got me... ON then
16:45 < duiv> and we put it OFF when there are too many problems around the release
16:45 < strk> right, that's what I saw getting more votes :)
16:46 < mhugent> timlinux: you need to use the google api directly and synchronize with OL3
16:46 < strk> not sure about jef's -12 though
16:46 < timlinux> ah ok
16:46 < timlinux> so basically its not easy to upgrade the OL plugin to use ol3?
16:46 < timlinux> and hence not easy to add ol rotation support
16:46 < mhugent> timlinux: at least not for the google part...
16:46 <@jef> strk: that was about release behaving different from master
16:46 < timlinux> life is always complicated :-(
16:47 < strk> timlinux: for raster, I've been just rotating the QPainter, so if we can't control plugins, we can always rotate the finally rendered stuff
16:47 < strk> but surely rotation-aware provider could do better things (like OL renderer, or WMS for that matter...)
16:49 < mhugent> it will be good to do it with QPainter for plugin layers
16:50 < anitagraser> ready for the next point? long agenda still
16:50 < pcav> so, what's the final decision?
16:51 < timlinux> strk, what is your final proposal since you are the rotation champion?
16:52 < duiv> pcav: I think: "keep checkbox, default ON, on release we can decide to make it OFF" 
16:52 < strk> what duiv said is my proposal
16:52 < pcav> fine, thanks
16:53 < strk> thank you, leaving for another meeting (in case you poke me and I don't answer)
16:53 < anitagraser> strk: bye
16:53 < timlinux> cya strk !
16:54 < timlinux> LTR?
16:54 < duiv> next point: LTS or not, if if so, make 2.8 LTS or not
16:54 < duiv> sorry LTR
16:54 < pcav> BTW: why I do not see anita and marco in the list of participants?
16:54 < duiv> on the wiki you mean?
16:54 < mhugent> which list?
16:54 < timlinux> participants of?
16:54 [Users #qgis_meeting_150116]
16:54 [@jef     ] [ anitagraser] [ duiv    ] [ mhugent] [ strk    ] 
16:54 [ alexbruy] [ dassau     ] [ gsherman] [ pcav   ] [ timlinux] 
16:54 -!- Irssi: #qgis_meeting_150116: Total of 10 nicks [1 ops, 0 halfops, 0 voices, 9 normal]
16:54 < timlinux> personally I prefer that we do 2.10 as LTR
16:55 < mhugent> why not 2.8?
16:55 < timlinux> the idea was that we should have a longer stabilisation period before release
16:55 < duiv> I thought that it was good because of the planning for educational institutions to make the january release LTR...
16:56 < alexbruy> duiv: same here. there was even discussion about this
16:56 < duiv> but maybe first: do we do LTR or not
16:57 < alexbruy> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/6#issuecomment-59546776
16:57 < timlinux> but I dont mind if we do it from 2.8 already
16:57 < duiv> and do we do it in the way Tim proposed in QEP?
16:57 < anitagraser> +1 for tim's qep. i think it's worth trying
16:58 < timlinux> duiv, btw not all universities work from mid year - mid year (in SA for example university years follow calendar years)
16:58 < pcav> IMHO having a LTR without funding for backports is not very positive
16:58 < timlinux> pcav, its one of the reasons I wanted to wait for 2.10 - I have been applying for WB funding
16:59 < timlinux> and part of it was going to be a budget to support LTR
16:59 < pcav> ok, then it makes sense
16:59 < alexbruy> if we will have LTR, we can try to adapt GRASS policy when developer that fixed bug should also backport it
16:59 < timlinux> but its uncertain if we will win it so that is why I said I am also ok to start on 2.8
17:00 < pcav> timlinux: another option is to call for LTR crowdfunding
17:00 < timlinux> or even how much funding we can ask for 
17:00 < duiv> jef: as our release manager, what do you think?
17:00 < timlinux> yeah we could do crowd funding too
17:00 < pcav> when we rach it we go, until then we wait
17:00 < pcav> reac
17:00 <@jef> that is essentially what I had planned anyway.
17:01 < timlinux> actually the funding is not so much about backporting but about supporting jef who has to do a lot more work (5 binaries for windows in the new regieme)
17:01 -!- anitagraser [[email protected]] has quit [Read error: Connection reset by peer]
17:01 < timlinux> but also about bug fixing yes
17:01 -!- anitagraser [[email protected]] has joined #qgis_meeting_150116
17:02 < timlinux> pcav, hmm not sure about waiting for specific funds to be in place before we actually release it
17:02 < timlinux> I also wanted to as mhugent / sourcepole what their attitude is since they have their own LTS programme
17:02 < mhugent> we don't have a specific opinion about it. Either 2.8 or 2.10 will be fine
17:03 < anitagraser> I think it could help to secure funding if we can show that we already have everything for LTR in place, organization-wise
17:04 < timlinux> another issue is about API
17:04 < timlinux> for example Nyall has been planning big API changes for composer
17:05 < timlinux> and it would be good to have the timing right that LTR isnt a massive delta from 4monthly release so that no plugin will work in both
17:05 < timlinux> well its something to ponder anyway
17:05 < pcav> sure
17:06 < anitagraser> timlinux: meaning between 2.8LTR and 3.0? 
17:06 < timlinux> yes
17:07 < timlinux> I mean it might make more sense to base LTR off a post 3.x release
17:07 < timlinux> so that the API is more or less the same
17:07 < anitagraser> timlinux: meaning 3.0 could be LTR?
17:08 < timlinux> yeah
17:08 < duiv> timlinux: from a university/educator user standpoint I think they are conservative
17:08 < gsherman> I would like to see an LTR in the 2.x series
17:08 < alexbruy> BTW, are there any plans about 3.0?  It is not in roadmap as far as I can see
17:08 < duiv> so they would prefer a stable 2.8 and wait until 3.2 before basing there courses on it
17:08 < gsherman> (because i'm working on a long term project and massive api changes will complicate my life :)
17:09 < timlinux> heh - me too
17:09 < duiv> alexbruy: it's our latest agenda point to discuss about this 
17:09  * gsherman is selfish
17:09 < timlinux> but to be honest even release to release changes are complicating my life
17:09 < gsherman> me too
17:10 < timlinux> my thinking is if we do LTR on 2.8 you will almost certainly need to rework your code in a year
17:10 < timlinux> when old LTR expires and new one comes out based on 3.x
17:10 < anitagraser> timlinux: but that will always be the case, right?
17:10 < timlinux> but if we base it on 3.x you almost certainly wont have to rework it
17:10 < timlinux> since I am assuming 3.x will have a shelf life of longer than 1 year
17:10 <@jef> by then we probably have enough funds to keep supporting 2.8 forever
17:11 < timlinux> and should maintain backwards compatibility
17:11 < anitagraser> timlinux:  but you have 2.8(non-LTR) stuff which you have to rework
17:11 < gsherman> some "paying clients" are not happy with funding rewrites with every release
17:11 < timlinux> anitagraser, how do you mean?
17:11 < anitagraser> is everyone assuming 3.0 will be after 2.8?
17:12 < timlinux> well I am making that assumption but better to ask jef
17:12  * duiv is getting this feeling too, but that is because tim talks about api changes, major code overhauls and anita is adding a agenda point about it
17:13 < duiv> is getting a self fullfilling prophecy 
17:14 < duiv> but I'm fine with that
17:14 < duiv> though still think that academia prefer to have a stable 2.x version as LTR first
17:14 < anitagraser> timlinux: well, under this assumtion your arguments make sense, but not if there are no plans for 3.0 yet
17:14 < timlinux> I think 2.8 should have actually been 3 because we brok api with legend stuff
17:14 < timlinux> :-P
17:14 <@jef> version numbers.  as if I care.  the just have to increase.
17:14 <@jef> +y
17:14 < anitagraser> timlinux: do you suggest to advance to 3.0 then?
17:14 < anitagraser> no more 2.8
17:14 < timlinux> yes - with nyalls composer re-org and with *v2 stuff gone. mhugent had some api breaking stuff he wanted to merge too
17:14 < mhugent> timlinux: I think the legend interface still works (so no api break)
17:14 < mhugent> timlinux: the new geometry classes will not break API
17:14 < timlinux> it didnt still work for us
17:15 < mhugent> oh
17:15 < timlinux> mhugent, wont new geom classes replace old ones?
17:15 < mhugent> there is a compatibility layer that works like the old geometry class
17:15 < mhugent> and redirects the calls to the new class
17:16 < mhugent> classes
17:16 < timlinux> ok
17:16 < mhugent> but Nyalls composer changes will break the api
17:16 < timlinux> anyway I am not trying to hard sell anything - I am happy to have 2.8 be first LTR just to get the show on the road
17:17 < timlinux> its just good to at least weight up the implications a little
17:17 < mhugent> although not many plugins are using the composer classes. So what about a 'soft api break' with only changes in the composer classes?
17:17 < timlinux> and gsherman will be happy to do a plugin update once a year than 3x a year
17:18 < timlinux> mhugent, for 2.8?
17:18 < mhugent> I don't know. Probably better after
17:19 < mhugent> Since feature freeze is next week, it has to be after
17:19 < anitagraser> timlinux: maybe the api break you encountered should be considered a bug since the change was introduced between minor releases
17:19 < mhugent> btw. there have been other api breakages on 2.x releases
17:19 < mhugent> (but unintended ones, so bugs)
17:20 < anitagraser> i would prefer to avoid soft api breaks - it's confusing
17:20 < anitagraser> let's schedule 3.0 with planned api break soon instead
17:21 < mhugent> ok
17:21 < timlinux> Ok maybe we should just cast two votes: 1) Are you in favour of us commencing with LTR releases?
17:21 < timlinux> and 2) We should make 2.8 the first LTR release
17:22 < pcav> 1) yes
17:22 < pcav> 2) yes, provided funding is set aside for this
17:22 < duiv> 1) yes
17:22 < duiv> 2) yes
17:22 < anitagraser> 1) +1; 2) 0
17:22 <@jef> +1 +1
17:23 < dassau>  +1 0
17:23 < mhugent> +1 +0
17:23 < gsherman> +1 +1
17:23 < timlinux> +1 +0
17:24 < timlinux> So seems unanimous for LTR to commence
17:24 < timlinux> and which specific release to start with is a bit more ambiguous
17:25 < duiv> yep, and 4 +1 and 4 0 for that
17:25  * timlinux looks around the room for someone who knows how to convert that into a decision :-P
17:25 < duiv> as there is no -1, and the release manager is +1 should we decide +1?
17:25 < anitagraser> +1
17:25 < timlinux> ya I am ok with it
17:26 < duiv> cool, we are doing great people
17:26 < duiv> next point? Anita
17:26 < anitagraser> i just wanted to suggest that we enforce mandatory documentation for porting to changed 3.0 api
17:27 < duiv> you mean the cookbook is not always up to date?
17:27 < anitagraser> not like 2.0 where - i think Nathan - wrote up a guide for most points 
17:27 < anitagraser> duiv: i mean that the dev introducing the change should have to update the cookbook
17:27 < anitagraser> because: insider knowledge
17:28 < anitagraser> add examples: old code - new code
17:28 < duiv> +1 but it is hard to enforce this
17:28 < duiv> same with new docs for new features...
17:28 < anitagraser> i know, but we can send out regular mails to remind people
17:28 < anitagraser> keep it on their radar
17:28 < timlinux> we should use python playbook or whatever it is called so the cookbook can actually be run and validated for a release
17:28 < gsherman> api changes really need to be documented, if nothing else an api changelog
17:29 < anitagraser> ideally, not just what has changed, but also how to use the new version
17:29 < gsherman> anitagraser: agreed
17:30 < anitagraser> remember, python plugin devs might not be wizards
17:30 < gsherman> even wizards need help sometimes :)
17:30 < duiv> people can we opt for another half hour now? then we had a meeting of 2 hours
17:30 < timlinux> mhugent, FYI this is the kind of stuff we had to do for 2.4 -> 2.6 migration https://github.com/AIFDR/inasafe/blob/master/safe_qgis/report/map.py#L341
17:31 < gsherman> when a python dev has to resort to reading C++ code to figure out how to use the api, something is wrong...
17:31 < anitagraser> can we vote setting up a pyqgis coobook page to collect information about api breaks between 2.x and 3.0 and send out an email about it?
17:32 < anitagraser> duiv: I'm fine however long it takes
17:32 < duiv> anitagraser: +1 and if you write the email I'm happy to test code and put it in the cookbook
17:32 < mhugent> I have to leave in 5 minutes
17:32 < timlinux> +1 - though shouldnt the entries be annotated with .. note:: This changed in 2.6 to blah blah blah 
17:32 < anitagraser> duiv: ok
17:32 < mhugent> +1 for pyqgis cookbook page
17:33 < timlinux> I mean at the point of the actual examples?
17:33 < anitagraser> timlinux: sure, if there are breaks between minor versions - though i still think they should be considered bugs
17:33 < duiv> timlinux: not sure, we have a cookbook for every version of QGIS
17:33 < anitagraser> but mostly the page will be to migrate to 3.0
17:34 < duiv> so for 3.0 all code should be updated in the cookbook, AND we should have a page where you can look up the most obvious changes
17:34 < duiv> (ideally)
17:34 < anitagraser> right
17:34 < gsherman> a summary of api changes is needed 
17:34 < gsherman> rather than embedded thorughout the cookbook
17:34 < timlinux> agreed
17:35 < timlinux> I was googling for just that today
17:35 < anitagraser> gsherman: not throughout: i'm thinking one central page
17:35 < gsherman> anitagraser: good
17:35 < timlinux> though I think adding notes in examples where you know it is different can't harm
17:35 < anitagraser> timlinux: sure
17:36 < timlinux> I mean when you update the example to work with 2.6 you can just underneath put a little note saying the eg was updated because of api changes 
17:36 < timlinux> django and other projects do it like that
17:36 < anitagraser> would the remaining psc members vote please?
17:36 < timlinux> and it makes it very easy to recognise when you are going off the reservation into new API terrirotry
17:37 < gsherman> +1
17:38 < anitagraser> pcav: ? jef ?
17:38 < mhugent> +1
17:38 < timlinux> I think the remaining members fell asleep at their keyboards :-)
17:38 < anitagraser> well, pcav is next on the agenda :P
17:38 <@jef> I don't know what we're voting about.
17:39 < pcav> jef: me too
17:39 < timlinux> For anita to send out and initiate a API changes document
17:39 < mhugent> I have to go. Bye all
17:39 < duiv> can we vote setting up a pyqgis coobook page to collect information about api breaks between  2.x and 3.0 and send out an email about it?
17:39 < timlinux> cya
17:39 -!- mhugent [[email protected]] has quit [Remote host closed the connection]
17:39 < pcav> bye mhugent 
17:39 -!- anitagraser [[email protected]] has quit [Read error: Connection reset by peer]
17:39 < duiv> ^^ that is what anitagraser asked to vote for
17:39 < pcav> +1
17:39 <@jef> keeping the sip bindings up to date?  running prepare-commit.sh?   tests for everything?  documententing api changes?
17:40 -!- anitagraser [[email protected]] has joined #qgis_meeting_150116
17:40 < dassau> +1 for a page about api breaks
17:40 < duiv> anitagraser: jef is asking:  keeping the sip bindings up to date?  running prepare-commit.sh?   tests for everything?  
17:40 < duiv>              documententing api changes?
17:41 < duiv> jef: you mean incorporate that into the email too?
17:41 < timlinux> duiv, I think he was being cynical
17:41  * anitagraser is confused
17:41 < duiv> ow... sorry
17:41 < timlinux> Ie its nice to have rules but we probably cant enforce them
17:41 <@jef> how is going to update that page?
17:41 <@jef> s/how/who/
17:42 < timlinux> the sinner who breaks the API
17:42 < anitagraser> jef: the idea is to remind and encourage the devs breaking the api to update the page
17:42 <@jef> timlinux: who might not even notice.
17:42 < timlinux> although if he breaks the API he probably doesnt care about the cookbook :-)
17:42 < anitagraser> and I'm aware that it cannot be enforced, but it would be good to try 
17:42 < duiv> jef: that is where you pop in
17:43 < duiv> YOU see, and send an angry mail to the sinner :-)
17:43 <@jef> duiv: fine so I have to do that page - thank you very much ;)
17:43 < duiv> no, I will do the page, but based on the input of the api breakers
17:43 < duiv> you will be the guy with the stick
17:43 < timlinux> well lets just start with a friendly email announcing the page for API breaks and asking people to maintain it - it will be better than doing nothing
17:43 < duiv> hitting them untill they give me the text
17:43 < duiv> ok....
17:43 < anitagraser> duiv: +1
17:44 < anitagraser> pcav: any thoughts or next point?
17:44 < timlinux> sorry folks I am going to be disconnected in about 10min
17:44 < timlinux> so maybe we can move things along?
17:44 < pcav> too bad timlinux 
17:44 < pcav> we needed you here
17:44 < pcav> :)
17:45 < pcav> May I suggest to have another meeting soon?
17:45 < duiv> I think 2 hours for a meeting should be the max. We should try as efficient as possible in this meetings
17:45 < anitagraser> pcav: +1
17:45 < timlinux> agreed
17:45 < pcav> yes duiv 
17:45 < anitagraser> duiv: +1
17:45 < timlinux> I am happy to have another meeting next week to keep on
17:45 < pcav> better having 2 meetings per month, 2 h max
17:45 < timlinux> I'm fine with that
17:46 < timlinux> can we just do them mid week
17:46 < duiv> next official one will be in 3 weeks anyway
17:46 < timlinux> so that we dont lose people going off on weekends etc
17:46 < pcav> next week I cannot,
17:46 < pcav> the one after is ok
17:46 < pcav> timlinux: ok for me
17:46 <@jef> didn't we talk about doing this by email last time?
17:46  * anitagraser can't connect to irc from office, so would have to be late if during the week
17:46 < timlinux> y
17:47 < duiv> anitagraser: not even with a web client?
17:47 < timlinux> can we meet on something else that you can connect on?
17:47 < anitagraser> duiv: if you know a reliable one. i have bad experience
17:47 < duiv> sorry I've no experience with those, I'm on irssi here...
17:47 < anitagraser> timlinux: google chat works fine, or skype if necessary
17:48 < timlinux> anyone have objections to using one of those?
17:48 < pcav> web irc worked very well lat time I tried
17:48 < pcav> years ago
17:48  * duiv prefers IRC...
17:48 < pcav> -1 for me for skype
17:48 < strk> anitagraser: http://webchat.freenode.net
17:48 < anitagraser> we can try. i blame the tech if i miss half of it ;)
17:48 < timlinux> try with web irc client?
17:49 < timlinux> shall we move on with the agenda?
17:49 < gsherman> i suggest facetime :P
17:49 < anitagraser> strk: ok, i've tried that before, maybe it works now
17:49 < anitagraser> will try
17:49 < anitagraser> just set a time
17:49 < pcav> so, should we postpone all next topics?
17:49 < timlinux> not facebook chat gsherman ?
17:49 < strk> you guys should try out tox.im while still fresh (warning: beta)
17:49 < timlinux> I can get back here in about 10 min
17:49 < gsherman> facebook is old news
17:49 <@jef> doing this in german would be nice too. :)
17:49 < timlinux> I just need to log out and run home
17:50  * duiv prefers to plan another meeting
17:50 < gsherman> jef: nice for you and others---i'm monolingual :)
17:50 < pcav> ok, let's plan it now
17:50 < timlinux> lets not wait three weeks then
17:50 < timlinux> but do week after next when Paolo is back
17:51 < duiv> next friday? because if we do it the wednesday after next week it is just 8 days before the next one
17:51 < anitagraser> so 26th to 30th?
17:51 < duiv> 26th is ok for me
17:51 < pcav> yes
17:51 < timlinux> I'm fine for next fri
17:51 < dassau> me too
17:51 < duiv> that is 23th
17:52 < pcav> 23 not for me
17:52 < pcav> 26 fine
17:52 < duiv> 26 ok for others?
17:52 < timlinux> yup
17:52 < gsherman> si
17:52 < pcav> h 15 or 16 CET?
17:52 < pcav> gsherman: ;)
17:52 -!- anitagraser [[email protected]] has quit [Read error: Connection reset by peer]
17:52 < duiv> I prefer 16
17:53 -!- strk [~strk@unaffiliated/strk] has left #qgis_meeting_150116 []
17:53 < pcav> so 26 16-18?
17:53 <@jef> 15
17:53 < pcav> +0 for me
17:53 -!- anitagraser [[email protected]] has joined #qgis_meeting_150116
17:53 < duiv> others (anita 15 or 16 cet)
17:53 < timlinux> earlier is better for me
17:53 -!- anitagraser [[email protected]] has quit [Read error: Connection reset by peer]
17:54 < duiv> 15 ok for me too
17:54 < pcav> let's make it 1530 then
17:54 < timlinux> cet = utc+1?
17:54 < duiv> yes
17:54 < pcav> timlinux: yes
17:54 < timlinux> ok
17:54 -!- anitagraser [[email protected]] has joined #qgis_meeting_150116
17:54 < timlinux> porr gsherman will need to get up even earlier
17:54 < duiv> anitagraser: are you no a webclient now?
17:54 < anitagraser> duiv: no and it still sucks :P
17:54 <@jef> 23th, 1430 UTC?  half an our earlier than today?
17:55 < pcav> 26
17:55 < duiv> if we do 15 then it is maybe doable for nathan to tell something about QEP voting
17:55 < pcav> if I need to be there
17:55 < duiv> jef: +1
17:55 < anitagraser> pcav: most agenda points will require you to be there :)
17:56 < timlinux> ok thanks folks
17:56 < timlinux> will catch you on the flip side
17:57 -!- timlinux [[email protected]] has quit [Quit: Leaving]
17:57 < duiv> I'll sent an email unless somebody comes up with a veto for 1430 UTC/1530 CET
17:57 < anitagraser> duiv: 23rd or 26th?
17:57 < duiv> 26th otherwise pcav cannot make it
17:57 < anitagraser> ok
17:58 < dassau> ok
18:00 -!- anitagraser [[email protected]] has quit [Read error: Connection reset by peer]
18:00 < pcav> ok
18:00 < pcav> thanks
18:00 < duiv> poor anit
18:00 < duiv> a
18:00 -!- anitagraser [[email protected]] has joined #qgis_meeting_150116
18:00 < anitagraser> it's been a pleasure! see you around soon. bye
18:01 < duiv> lol, bye anitagraser 
18:02 < pcav> ciao

Log 26th of january

13:35 -!- duiv [[email protected]] has joined #qgis_meeting_150126
13:35 [Users #qgis_meeting_150126]
13:35 [@anitagraser] [ duiv] 
13:35 -!- Irssi: #qgis_meeting_150126: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
13:35 -!- Channel #qgis_meeting_150126 created Mon Jan 26 09:59:58 2015
13:35 -!- Irssi: Join to #qgis_meeting_150126 was synced in 1 secs
13:36 < duiv> hi anitagraser, you are early :-)
14:06 -!- jef [fischer@qgis/developer/jef] has joined #qgis_meeting_150126
14:17 -!- alexbruy [~alexbruy@2a02:228:300:1::119] has joined #qgis_meeting_150126
14:38 -!- dassau [[email protected]] has joined #qgis_meeting_150126
15:03 <@anitagraser> duiv: testing how well it works :)
15:05 < duiv> anitagraser: I do not see not so much join/leave messages now :-)
15:10 <@anitagraser> duiv: great
15:13 <@anitagraser> I'll have to leave after an hour today but most of the agenda topics are not my expertise anyway
15:14 <@anitagraser> will "QGIS3/long term planning" stay on today's agenda? (that's new, i.e. wasn't on the list two weeks ago, right?)
15:25 -!- aneumann [bc3ed06f@gateway/web/freenode/ip.188.62.208.111] has joined #qgis_meeting_150126
15:25 -!- timlinux [[email protected]] has joined #qgis_meeting_150126
15:25 < timlinux> hi all
15:26 < aneumann> hi
15:26 <@anitagraser> hi
15:26 < dassau> hi
15:27 < aneumann> Is PSC only meeting by IRC - no voice involved?
15:27 < timlinux> anitagraser: before I start can you make a replacement for the developers group opic in about screen (alexbruy was asking for it)
15:27 < duiv> aneumann: nope, only text
15:27 < timlinux> using the last hackfest pic
15:28 < duiv> timlinux: the splash screen is already updated
15:28 < duiv> is it another pic?
15:28 < timlinux> not the splash
15:28 < timlinux> the one in the help -> about -> developers dialog
15:29 < duiv> I know there is one there too, but should it not be exact the same image (in code I mean)
15:29 <@anitagraser> timlinux: can you send me a mail with the size requirments
15:29 < alexbruy> duiv: this was same photo as used in previous splash, so I was curious if should update them both
15:29 < timlinux> no because the splash will change to the mappy one for the release
15:29 < duiv> yep clear
15:30 [Users #qgis_meeting_150126]
15:30 [@anitagraser] [ aneumann] [ duiv] [ timlinux] 
15:30 [ alexbruy   ] [ dassau  ] [ jef ] 
15:30 -!- Irssi: #qgis_meeting_150126: Total of 7 nicks [1 ops, 0 halfops, 0 voices, 6 normal]
15:30 -!- mhugent [[email protected]] has joined #qgis_meeting_150126
15:30 < duiv> hi mhugent 
15:30 < mhugent> hi duiv
15:31 < timlinux> hi mhugent
15:31 < timlinux> who are we missing? pcav was going to come right?
15:31 < timlinux> Gary?
15:32 <@anitagraser> i've pinged pcav
15:32 < timlinux> I pinged Gary
15:32 < timlinux> might be a bit early for him still
15:32 < duiv> http://i.imgur.com/0edWDKI.jpg
15:33 < duiv> ^^ BJ Jang from S Korea sent me some printed manuals
15:33 < aneumann> Question: will you discuss another round of paid bug fixing for 2.8 LTS?
15:33 <@anitagraser> duiv: nice :D
15:33 < timlinux> lets start if we can they can read the logs - we are still following this right: https://hub.qgis.org/wiki/17/PSC_Meeting_16_January_2015 ?
15:33 < duiv> look realy cool (2cm thick booklets)
15:33 < duiv> yes
15:33 < timlinux> aneumann: I would be happy to add it to the agenda
15:34 < aneumann> timlinux: thanks
15:34 <@anitagraser> timlinux: i think the next agenda point was trademark status (Paolo)
15:34 -!- pcav [[email protected]] has joined #qgis_meeting_150126
15:34 < duiv> anitagraser: not sure when I put the QGIS3 stuff in it
15:34 < pcav> hi all
15:34 < duiv> hi pcav
15:35 < duiv> but I think it would be great if we put either in wiki or in docs some 'general long term plan'
15:35 < pcav> are we ready to go?
15:35 <@anitagraser> yes
15:35 < timlinux> aneumann:  I added it to here https://hub.qgis.org/wiki/quantum-gis/PSC_Meeting_16_January_2015
15:35 < duiv> pcav: your item: trademark status is next
15:36 < pcav> yep
15:36 < pcav> ok, then
15:36 < pcav> we have several requests 
15:36 [Users #qgis_meeting_150126]
15:36 [@anitagraser] [ aneumann] [ duiv] [ mhugent] [ timlinux] 
15:36 [ alexbruy   ] [ dassau  ] [ jef ] [ pcav   ] 
15:36 -!- Irssi: #qgis_meeting_150126: Total of 9 nicks [1 ops, 0 halfops, 0 voices, 8 normal]
15:36 < pcav> and notifications of possible infringements
15:37 < pcav> I feel that we do not have a clear and common idea
15:37 < pcav> so it is often difficult for me to deal with these casee
15:37 < pcav> I'd appreciate if we could share ideas and views about it
15:37 < timlinux> I think we also scared off people that might usefully use the name
15:37 < pcav> any comments?
15:38 < pcav> should I start with practical examples?
15:38 < timlinux> e.g. OpenGIS guys are calling their native android QGIS app QField
15:38 < timlinux> instead of QGISMobile
15:38 < pcav> they didn't ask, however
15:38 < timlinux> opengis?
15:38 < pcav> I do not think so
15:38 < timlinux> no they didnt ask
15:39 < timlinux> they just chose a less obviousname
15:39 < pcav> so we scared off someone
15:39 < timlinux> so they dont have to worry about upsetting us
15:39 < pcav> and let go others ;)
15:39 < timlinux> I think that is not the outcome we want
15:39 < pcav> +1
15:40 < duiv> I agree with that, though the code is not in the QGIS repo, so it IS not yet a QGIS project...
15:40 < timlinux> have you got example of misuse that we are not able to deal with well
15:40 < pcav> yes
15:40 < pcav> *possible* misuse
15:40 < timlinux> sure - but rather we should encourage them to just ask us to make a repo for them
15:40 < timlinux> in QGIS org
15:41 < pcav> timlinux: agreed
15:41 <@anitagraser> imho it's ok that they chose QField, probably better than QGISMobile in the long run
15:42 < pcav> BTW, I asked why thay cose not to release it early, and they did not reply
15:42 < pcav> choswe
15:42 < pcav> argh
15:42 < pcav> chose
15:42 < timlinux> pcav: what questions must someone wishing to use the QGIS brand answer?
15:43 <@anitagraser> which aspects/examples do you want to discuss?
15:43 < aneumann> pcav: sometimes it is really too early to release - and would generate more harm/fuss then it would without releasing it
15:43 < pcav> ok, I see
15:43 < pcav> thanks for the reply
15:43 < timlinux> it is anyway realease - all the code is open and you can build it if you like
15:43 < timlinux> released
15:44 < pcav> we have a few cases
15:44 < pcav> http://nextgis.ru/en/nextgis-qgis/
15:44 < pcav> http://www.gis3w.it/en/node/462
15:44 < pcav> https://www.facebook.com/groups/200837213325923/739166809492958/
15:44 < duiv> sidenote: should we remove the 'qgis-android' stuff from the website? Because only Marco B and Matthias were working on it I think?
15:44 < pcav> use of the logo in course certificates
15:46 < pcav> then a generic question on "use the QGIS trademark in our marketing and sales activities" 
15:46 < pcav> that's about it
15:46 <@anitagraser> so nextgis and gis3w provide custom installers (I cannot see the facebook content)
15:46 < pcav> I'd appreciate your feelings about this
15:46 < pcav> not
15:46 < duiv> nextgis seems old, they talk about latest stable 2.01 in the popup for downloading
15:46 < pcav> nextgis yes, it's a custom installer
15:47 < pcav> boudless too BTW
15:47 < alexbruy> duiv: no. they have 2.6 and 2.7 too
15:47 < pcav> gis3w is a different beast
15:47 < duiv> alexbruy: yes I see now
15:47 < pcav> software (apparently non free) that involves qgis and django
15:48 -!- mkuhn [[email protected]] has joined #qgis_meeting_150126
15:48 < timlinux> I asked mkuhn to join here
15:48 < mkuhn> hi
15:48 <@anitagraser> ok, do we want to bother about those things? they all seem to make it very clear that they provide QGIS in different packaging which is not direclty governed by the qgis project
15:48 < jef> mkuhn: hi
15:48 < aneumann> mkuhn: hi
15:49 < alexbruy> anitagraser: if I understand correctly they use QGIS trademark without permission
15:49 < timlinux> pcav: can we separate the discussion between what we are legally oblisged to do in order to retain our trademark defensibly
15:49 < alexbruy> IMO we should as for some fee in such cases of commercial usage 
15:49 < timlinux> and what we think is a polite way to recognise QGIS
15:49 < alexbruy> *ask
15:50 <@anitagraser> +1 for [15:49] <timlinux> pcav: can we separate the discussion between what we are legally oblisged to do in order to retain our trademark defensibly
15:50 < pcav> anitagraser: I'm not saying we should deal 
15:50 < timlinux> so for me the the nextgis example is exactly how I *like* the QGIS brand used
15:50 < pcav> with this, just that we should have a policy
15:50 < timlinux> they make it clear it is their own roll of QGIS and its not from the master project
15:51 < timlinux> though adding TM after the word QGIS would not harm
15:51 <@anitagraser> good point ad TM!
15:51 < pcav> so:
15:51 < timlinux> I think we should just have a policy that if you use QGIS in a brand you should prefix it with your company name if it is not a parto fhte official QGIS project
15:52 < pcav> * we should ask to always add TM
15:52 < timlinux> that was my main objection (with apoligies to mhugentfor always using this as example) of QGIS Enterprise
15:52 < pcav> * we accept custom installers and the like, provided that is is clear they are not affiliated with the project
15:52 < pcav> right?
15:52 < timlinux> yes
15:52 <@anitagraser> +1
15:53 < pcav> should we vote for this?
15:53 < timlinux> we dont have a choice anyway - anyone can make a custom installer as long as it compiles with GPL
15:53 < pcav> yes timlinux 
15:53 < pcav> but we could prevent them from using the name or the logo
15:53 < timlinux> pcav: hold on vote please
15:53 < aneumann> timlinux: s/compiles/complies/ ;-)
15:54 < pcav> theoretically, if this would be an advantage for us
15:54 < timlinux> haha yes that one :-)
15:54 < pcav> (which I do not feel is the case)
15:54 < timlinux> probably it needs to do both actually :-) (compile and comply)
15:55 < mkuhn> has the logo case already been discussed?
15:55 < timlinux> pcav: so we want to make this painless as possible and yet show we have protected our trademark right?
15:55 < timlinux> mkuhn: no
15:55 < jef> mkuhn: you're using it in qfield?
15:55 < timlinux> before you arrived I was saying I was sad because you called QField instead of QGISMobile
15:56 < alexbruy> so, am I right that this mean that anyone can create custom build/installer and sell it without getting permission from PSC?
15:56 < mkuhn> we do currently but we were looking for something else. But it may have references / partly consist of the QGIS logo
15:56 < pcav> timlinux: sounds good
15:56 < timlinux> I mean because the perception is if you make a project with the name i QGIS in it is is going to cause you trouble
15:57 < timlinux> it should be rather a case that you have a simple way to ask to use it and we liberally give permissions
15:57 < timlinux> and save the big guns for somewone selling QGIS VIagra or whatever
15:58 < duiv> timlinux: even more lenient? Only if you create *software* products with QGIS in it, you should ask for permission?
15:59 < duiv> we now have seen questions from people asking to write books or giving courses... that is not what we want to discourage is it?
15:59 <@anitagraser> mkuhn: imho logo usage is covered by http://www.qgis.org/en/site/getinvolved/governance/trademark/index.html
15:59 < duiv> and creating custom installers has always been possible already?
15:59 < timlinux> yeah the books thing is a can of worms
15:59 < pcav> timlinux: our trademark holds only in the field of software and related
16:00 < timlinux> related == books about the software?
16:00 < pcav> if you want to produce QGIS soap, I think we cannot prevent you
16:00 <@anitagraser> "If you write articles, books, blog articles, tutorials, study materials for university, and similar, you do not need a permission to cite QGIS name and use the logo in it" 
16:00 < pcav> but of course we should ask a lawyer
16:00 < pcav> and it is not our problem anyway
16:02 < timlinux> ok that sounds good
16:02 < timlinux> so yes duiv's point "even more lenient? Only if you create *software* products with QGIS in it, you should ask for permission?" is good
16:02 < mkuhn> anitagraser: It's software, so it probably does not fit into this categories. I guess we require a permission
16:03 < duiv> so then the only obvious 'infringment' is the gis3w guys (/me does not do facebook so cannot check the other link)
16:03 <@anitagraser> mkuhn: yes, i think so "If you plan to market a QGIS-based product or service to the public using a trademark that includes the element “QGIS,” such as “Super QGIS” or “Professional QGIS” you are required to apply for and obtain a permission from the QGIS Project Steering Committee (QGIS-PSC). " 
16:03 < alexbruy> duiv: nextgis also uses qgis code in their web platform
16:03 < pcav> re: facebook: it's a group called QGIS
16:04 < pcav> they asked for permission to use the name
16:04 < timlinux> so basically if you are writing software the watershed is: if it is an official QGIS project (hosted in our repo as the master upstream) you can brand it QGIS foo, if it is hosted outside of our repo, you should prefix it with your company name and include the TM - no need to ask permission
16:04 < timlinux> if you want to use it in another context, just ask and we decide on a case by case basis
16:05 <@anitagraser> should we then contact nextgis and gis3w and encourage them to apply for permission?
16:05 < timlinux> doesnt that cover everything?
16:05 < mkuhn> Can I use the logo with a TM and "prefix" it with a company name?
16:05 < pcav> timlinux: any policy about releasing the product with QGIS on it?
16:05 < pcav> mkuhn: good point IMHO
16:06 < pcav> I think this is ambiguous
16:06 < pcav> it seems that *your* product is covered by trademark then
16:06 < duiv> mkuhn: I do not think so
16:06 <@anitagraser> we have the logo with tm logo in http://www.qgis.org/en/_static/images/trademark.png
16:06 < timlinux> I was thinking we could just embed something like this: https://docs.google.com/a/kartoza.com/forms/d/1YvY2kTCBg_XS2BUI-t8Aj4Pjy4-fgUBLMtRn7uv317s/viewform?usp=send_form
16:07 < timlinux> pcav dont the same rules just apply
16:07 < aneumann> anitagraser: the tm in the logo http://www.qgis.org/en/_static/images/trademark.png is a bit big - don't you think?
16:07 <@anitagraser> timlinux: the form is restricted
16:07 < pcav> You need permission
16:07 < pcav> This form can only be viewed by users in the owner's organization.
16:07 < pcav> Try contacting the owner of the form if you think this is a mistake. Learn More.
16:07 < pcav> ;)
16:08 < timlinux> e.g. if I make QGIS for Rocket Scientists custom install
16:08 < timlinux> I must have it in the main repo  or explicit permission from the project to use QGIS as the primary brand
16:08 <@anitagraser> aneumann: depends on the usecase. imho the (R) should be as big as the standard text around it
16:09 < timlinux> if I call it 'NASA QGIS For Mars Men' I can just add the tm
16:09 < timlinux> anitagraser: sorry figureing out why 1 sec
16:09 < pcav> I'm getting lost :)
16:09 < duiv> isn't the difference that if you create the installer it is ok, but if you are going to sell/market it then it is wrong?
16:09 < timlinux> anitagraser: refresh please?
16:10 <@anitagraser> timlinux: no change
16:10 < timlinux> pcav: Im trying to say that if you create a product with QGIS as the primary brand you need our permission
16:10 < timlinux> QGIS for watches -> creater should apply
16:10 < pcav> so this applies to gis3w and sourcepole, did I understand you right?
16:11 < timlinux> TAG HUER QGIS(TM) Edition -> no need to apply
16:11 < timlinux> yes
16:11 < alexbruy> timlinux: even if this TAG HUER QGIS(TM) Edition is cell to others?
16:11 < mkuhn> What about "HiggsBosson for QGIS"?
16:11 < timlinux> alexbruy: for me its not about sale
16:12 < timlinux> its about presenting your product as if it comes directly from the QGIS project
16:12 < timlinux> I would like it to be clear that you are using a derivative product, not something created and endorsed by QGIS.org
16:12 < timlinux> I dont think using a TM as a revenue gathering tool makes much sense
16:13 < timlinux> so if Sourcepole are selling their spin of QGIS I think its great and fine
16:13 < timlinux> I just dont want people to think that somehow the QGIS project has gone to a 'you have to buy qgis' model
16:14 < timlinux> which is my objection to calling QGIS Enterprise
16:14 < duiv> fully agree with that
16:15 < timlinux> anitagraser: tweaked perms - should load now
16:15 < pcav> timlinux: would you like to resume it all and call for a vote?
16:16 <@anitagraser> timlinux: no luck here, sorry
16:16 < jef> anitagraser: use the original url
16:16 < aneumann> anitagraser: you need to remove the restricted_form stuff at the end of the URL
16:16 < timlinux> I see some peopel are on it
16:17 < timlinux> Its just a rough mock up 
16:17 <@anitagraser> jef: thanks, works
16:17 < timlinux> just to show the idea
16:17 < timlinux> ie make a simple form and let people self register
16:17 < timlinux> and at the end we could provide some guidelines
16:18 < timlinux> pcav: so my proposal is simple (at least in my small brain)
16:18 <@anitagraser> looks good, but maybe replace the book example with a software example
16:18 < timlinux> yeah
16:19 < timlinux> anitagraser: done
16:19 < pcav> timlinux: could you make it explicit?
16:19 < pcav> thanks
16:19 < timlinux> We could simple embed that into our site and hook it up to our qgis.org google apps account
16:20 < timlinux> pcav: sorry yes I was about to here goes:
16:21 < duiv> http://boundlessgeo.com/solutions/solutions-software/qgis/ 'QGIS Documentation' link is NOT linking to our docs, but to boundless ones :-(
16:21 < timlinux> 1) if you wish the QGIS name as the primary brand of your product (e.g. 'QGIS Smartwatch Edition') you need to host it in the official QGIS repository and obtain permissions from the PSC
16:22 < timlinux> 2) If you wish to use the QGIS name as a secondary brand in your product (e.g. 'ACME Corp. QGIS Watch Edition) you should register using the form provided here (Url)
16:23 < timlinux> 3) In all cases where the QGIS name and logo are used, it should include the TM sign and you should provide a clear link back to the QGIS project
16:23 < timlinux> We encourage all users of the QGIS TM to register at (URL)
16:23 < timlinux> ---
16:23 < timlinux> do we need to do anything more than that?
16:24 < pcav> I do not understand well the difference between 1) and 2)
16:24 < timlinux> ok lets say you make a QGIS derivative
16:24 < aneumann> pcav: the difference is the order
16:24 < pcav> and: should we say something about *publishing* the resulting software?
16:24 < timlinux> and call it QGIS Super Duper
16:24 < timlinux> you would fall in category 1
16:25 < timlinux> if you call it Faunalia QGIS Super Duper you fall in category 2
16:25 < mkuhn> timlinux: As I read it, I am free to use the QGIS logo for whatever I want as long as the TM and a link back is in there?
16:25 < timlinux> mkuhn: that is my intent in the above (assuming others agree)
16:26 <@anitagraser> I would be ok with that
16:26 < timlinux> mkuhn: further in your specific case because you are making a derivative which the whole world and its auntie wants, I would also encourage you to go for category 1)
16:26 < timlinux> ie simply ask us to make you a new repo in QGIS.org gh account
16:27 < pcav> timlinux: so, Faunalia QGIS does not require permission
16:27 < timlinux> and use the primary brand
16:27 < pcav> and QGIS Faunalia does?
16:27 < timlinux> correct
16:27 < timlinux> in both cases you should register your product
16:27 <@anitagraser> pcav: sounds like a release name :P
16:27 < aneumann> timlinux: it sounds good to me (but I am not PSC)
16:27 < mkuhn> timlinux: we will consider this
16:28 < aneumann> One open question: are derived projects allowed to slightly modify the logo?
16:28 < timlinux> mkuhn: my point is that we (QGIS community) should be a welcoming place for new derivative projects to host their stuff and use the branding - rather then forcing (socially) people to silo their work off elsewhere
16:29 <@anitagraser> aneumann: i would prefer that colors remain unchanged and nothing is removed
16:29 <@anitagraser> but this hasn't been discussed in detail yet
16:29 <@anitagraser> maybe a good point for next meeting agenda
16:29 < aneumann> anitagraser: yes - agreed - I am more thinking along the lines of adding stuff to the logo
16:30 < aneumann> such as the QGIS logo and attached the company logo
16:30 < mkuhn> timlinux: thanks for the clarification, and to be clear: that is how I experience the community in general
16:30 < mkuhn> got to leave, will happily follow the rest of the discussion on the log
16:30 < mkuhn> bye
16:30 < timlinux> it seems obvious that people would want to do it. Personally I would prefer category 2 projects to create their own logo (non derivative)
16:30 < timlinux> again to avoid brand confusion
16:30 < timlinux> thanks mkuhn
16:31 <@anitagraser> timlinux: would be ok for me too
16:33 <@anitagraser> ready for voting?
16:33  * timlinux is
16:33 < mhugent> timlinux: we probably can live with your proposal of having the company name before the QGIS. Though I didn't discuss it with the others at Sourcepole
16:34 < timlinux> mhugent: cool will you raise it with them?
16:34 -!- aneumann [bc3ed06f@gateway/web/freenode/ip.188.62.208.111] has quit [Ping timeout: 246 seconds]
16:34 -!- mkuhn [[email protected]] has quit [Ping timeout: 245 seconds]
16:35 < timlinux> pcav: still there? shall we vote and move on with the agenda?
16:35 < mhugent> they are in holidays, so it might take 2 weeks until I have confirmation
16:35 < pcav> yes
16:35 < timlinux> no problem from me mhugent
16:35 < pcav> mhugent: we're not in a hurry anyway
16:35 < pcav> ok, voting
16:35 < pcav> 0 for me
16:36 < mhugent> 0 from me too
16:36 -!- aneumann [bc3ed06f@gateway/web/freenode/ip.188.62.208.111] has joined #qgis_meeting_150126
16:36 <@anitagraser> +1
16:36 < duiv> +1
16:37 < timlinux> +1 from me (assuming we are voting on the 3 categories above)
16:37 < dassau> +1
16:37 < duiv> pcav: why is it you vote 0? Do you prefer other phrasing or ...?
16:38 < pcav> because I did not understand the rationale behind having a name before or after QGIS
16:38 < pcav> and I think it will be difficult to explain
16:38 < pcav> but given that most of you find it undarstandable, it must be me :)
16:38 < pcav> so I do not oppose
16:38 < jef> +1
16:38 < pcav> thanks for asking
16:38 < timlinux> I think it is quite common concept of 'primary brand' versus 'sub brand'
16:39 < pcav> ok, so:
16:39 < timlinux> hopefully people understand it, if not we clarify things and iterate
16:39 < jef> pcav: something else in front immediately suggests that it's not the official QGIS.
16:39 < pcav> should we something about publishing something that has QGIS on it?
16:39 < pcav> my doubt is:
16:40 < pcav> people may start thinking that we are slowly moving away from our long standing "free and available for all" policy
16:40 <@anitagraser> pcav: haven't heard such concerns yet
16:40 < pcav> timlinux, jef : thanks, I accept your position
16:40 <@anitagraser> not saying that it's not possible
16:40 < duiv> pcav, I do not think we can stop people from using QGIS in their names and products, but (at least to me) a 'Faunalia QGIS' is clearly NOT a QGIS project, while 'QGIS Faunalis' could be
16:42 <@anitagraser> do you want more time to discuss, or should we move on to "funding for specific tasks (Paolo)" 
16:42 < timlinux> pcav: in which cases would e.g. anitagraser publishing a book called 'The QGIS(TM) beginners guide' create the impression that we are not free any more?
16:42 < jef> maybe a language thing.  GIS is SIG in italian too, is it?
16:43 < pcav> timlinux: I'm talking about software
16:43 < timlinux> or can you give a more concrete example of things that erode the impression that we are free
16:43 < pcav> if I publish my own Faunalia QGIS
16:43 < pcav> may I keep it private
16:43 < timlinux> Its still beholden to the GPL
16:43 < pcav> (please note: I'm *not* implying anything - just trying to develop a common position)
16:44 < timlinux> so you must make the source available to whoever you give the binaries to
16:44 < timlinux> so yes you can keep it private as long as you distribute the source with it
16:44 < timlinux> and do not place a restriction on the person you give it to that they do not redistribute
16:45 -!- gsherman [~gsherman@qgis/developer/gsherman] has joined #qgis_meeting_150126
16:45 < timlinux> My hope is that people dont do this, but there is no reason why they cant
16:45 < duiv> hi gsherman, you just missed 45 minutes of discussion about trademarks..
16:45 < timlinux> all scintellating of course :-)_
16:45 < gsherman> oh, i thought the meeting started 15 min ago
16:46 < gsherman> oops
16:47 < timlinux> pcav: can I suggest we move on with the agenda? or agree that we just sit and thrash this one thing out and save the rest of the agend for our feb meeing
16:47 < duiv>  5:30 AKDT, is that now? I was not sure if that was your timezone....
16:47 < timlinux> (I'm ok with either)
16:47 < gsherman> no, it's 0647 now
16:47 < gsherman> i can't tell time
16:48 < gsherman> i thought the meeting started at 1530 UTC; been lots of distractions here and i didn't keep up...
16:49 < timlinux> gsherman: there is the backlog: https://gist.github.com/timlinux/2a37fa775d02dbc34d7d
16:49 < duiv> let's move on on the agenda, I have the feeling that this trademark stuff has to be discussed more but it also takes up a lot of time...
16:49 <@anitagraser> duiv: +1
16:49 < pcav> duiv: right
16:50 < timlinux> ok
16:50 < pcav> we just need to provide answers to long standing questions
16:50 < pcav> I'm embarrassed not replying
16:51 <@anitagraser> pcav: do you want to discuss a specific question or move on to the next point now?
16:51 < timlinux> Funding for specific tasks?
16:51 < timlinux> perhaps we can combine aneumann 's question about hiring bugfixers for 2.8 with this?
16:51 < aneumann> yes, please - we need to decide fast
16:51 < aneumann> if we want to help 2.8 LTS
16:52 < pcav> I'd like to have guidelines to give answers to the issues above:
16:52 < pcav> nextgis, gis3w, etc.
16:52 < timlinux> So at last HF mhugentsuggested we should use a more open recruitement process for bug fixers
16:52 <@anitagraser> timlinux: e.g. any core dev can apply?
16:53 < timlinux> but the problem is always that we do it last minute and it will take a week just to filter out who can do it
16:53 < aneumann> hopefully we can plan this better for upcoming releases
16:54 < aneumann> now with the fixed release schedule it is very clear when the decision should be made
16:54 < timlinux> maybe it would be better if we ask those who would like to do paid bug fixing to simply register their interest on an ongoing basis
16:54 < timlinux> and then each release we can jsut split up the available funds between them
16:54 < timlinux> anyone can ask to be added to the list at any time
16:54 < timlinux> and the PSC must approve that they have the techical know how to do it
16:55 < aneumann> maybe it would be more efficient not to split it up too much
16:55 < timlinux> another thing is - yeah I was about to say
16:55 < timlinux> it wont help having 10x devs for 4 hours
16:55 < duiv> pcav: should we not come up with some 2 standard emails (nice and polite) both to 'infringers' and to people who just inquire and are ok?
16:55 < aneumann> maybe a dedicated week, as we did it in the past, works well?
16:56 < timlinux> yes I think so aneumann
16:56 < pcav> duiv: yes
16:56 < timlinux> since we have a bit of funding why dont we do this:
16:56 < pcav> but I do not know who is infringing
16:56 < duiv> I do not think we should try to be too formal, as we are not...
16:56 < timlinux> ask jef and martin if they can help again
16:56 < timlinux> and put out a call for anyone else interested and who can dedicate a week
16:57 < timlinux> to let apply
16:57  * timlinux doesnt remember if we have funds for that
16:57 < timlinux> if we kept say 10k of our funds for hte upcoming hf
16:57 < pcav> timlinux: yes, we do
16:57 < aneumann> We currently have >20k Euro
16:57 < timlinux> and earmarked the rest for bug fixes that would seem reasonable right?
16:58 < aneumann> I think we can spend 10k for 2.8
16:58 < timlinux> yes thanks - I saw the spreadsheet - I meant I dont recall what it costs for a week each of jef + martin and if we can cover more devs with 10k
16:58 < aneumann> QGIS-CH will most likely help out financially with the next release
16:59 < aneumann> timlinux: not much more than 2 devs. Maybe 2.5 - depending on the country
16:59 < timlinux> aneumann:  thanks for making the spreadsheet btw
16:59 < timlinux> pcav: we nee to have more formal statement of accounts if we are going to get funding
16:59 < jef> timlinux: expense sheet first free columns.  btw our rows contain aas installers iirc
16:59 < timlinux> ie a section on the web site with annual reports
16:59 <@anitagraser> timlinux: we spent 8-9k on two devs the last releases
17:00 < pcav> timlinux: yes
17:00 < timlinux> with annual income and expenditure detailed
17:01 < timlinux> jef ah thanks I missed the expenses sheet
17:01 < jef> s/free/few/
17:01 < timlinux> goddit thanks
17:01 < aneumann> My plan is to have two versions of the financial report: the more detailed one (like this spreadsheet) and a consolidated one, without personal details
17:02 < aneumann> the consolidated one would be published, the detailed one would stay private
17:02 < timlinux> yeah that seems like a good way to go since there are addresses etc in there
17:02 < aneumann> Can I upload and maintain the financial spreadsheet with the qgis.org google account?
17:03 < timlinux> yes - I will make an account for you
17:03 < timlinux> I will put the trademark reg form there too
17:03 < aneumann> this would make it easier to share and keep up-to-date
17:05 < timlinux> username? andreas ok?
17:05 < aneumann> timlinux: I use "neumann" for OSGeo
17:06 < timlinux> ok sent
17:07 < timlinux> so for the devs - jef are you available for a weeks bug fixing for QGIS 2.8?
17:09 < jef> timlinux: sure.
17:09 < aneumann> jef: thanks
17:10 < duiv> pcav: anything else you want to discuss in this one?
17:11 < jef> thank you.
17:11 < timlinux> so the proposal is we 1) agree to spend +- 10k on bug fixing 2) ask martin and Juergen to do it this time and 3) create a register of paid bug fixer devs so that in future we can round robin bix fixing work between them
17:11 < pcav> duiv: in theory yes
17:11 < pcav> this was meant especially to discuss how to proceed on the suggestion of Tim
17:12 < mhugent> timlinux: we might also ask e.g. Nathan or Matthias already this time
17:12 < pcav> of building up a formal budget to cover for all QGIS expenses
17:12 < pcav> etc.
17:12 < jef> larry?
17:12 < pcav> but of course we are short of time now
17:12 < timlinux> mhugent: good
17:12 < timlinux> but lets just cap how much time we spend getting them lined up
17:14 < timlinux> rather than thinking of who we can invite, isnt it better to let interested devs self register?
17:14 < timlinux> otherwise we are just makeing the closed circle bigger :-P
17:15 <@anitagraser> timlinux: do we want anyone but core devs?
17:16 < timlinux> so alternative proposal: 1) agree to spend +- 10k on bug fixing 2) create a register of paid bug fixer devs so that in future we can round robin bix fixing work between them 3) select two from the register to work on bug fixes 
17:16 < timlinux> anitagraser: probably not
17:17 < aneumann> timlinux: Google asks me for a ">25" character pw for my new account - insane!
17:18 < timlinux> aneumann: keepassx is your friend :-)
17:19 < timlinux> ....thoughts?
17:20 < aneumann> timlinux: this sounds good to me
17:20 < aneumann> hopefully our funds will increase in the future, so that we can have more devs working on it
17:21 <@anitagraser> vote? +1 from me
17:21 -!- mhugent [[email protected]] has quit [Remote host closed the connection]
17:21 < duiv> +1 for me too
17:21 < timlinux> when asking for a vote can we as a matter of course state what we are voting for
17:21 < timlinux> we are voting to approve alternative proposal above?
17:22 < timlinux> or original one?
17:22 < jef> timlinux: do we need a procedure for the "select two"?
17:23 < timlinux> well options are 1) select on appropriate skills, 2) select on round robin basis 3) random selection
17:23 < aneumann> 1) core developer 2) needs to dedicate one week of time within bug fixing period
17:24 < timlinux> we can probably discount 1 since we should not allow folks onto the bugfixer candidates list if they dont have the needed skills
17:24 < timlinux> 1) I don think core developer is enough
17:24 < timlinux> if you paid me to do it it would be a waste of money compared to e.g. jef
17:24 < aneumann> maybe a weight on the number of commits on github ;-)
17:25 < timlinux> I think we 'know' which devs are able to do it
17:25 < timlinux> and we can just vote to approve each of the applicants
17:26 < aneumann> agreed
17:26 < timlinux> I suspect only 4 or 5 devs would come forward as paid bug fixers
17:27 < aneumann> Ideally Giovanni could triage and say in what the area the most severe bugs are and we can assign by expertise?
17:27 < timlinux> can we pay giovanni for that too? I think its only fair
17:27 < timlinux> if we allocate e.g. 1k for bug triaging
17:28 < timlinux> and 9 for bug fixers
17:28 < aneumann> or 10 and 1 ;-)
17:28 < timlinux> yeah or that :-)
17:28 < timlinux> so what is the final input on how we select devs?
17:29 < timlinux> random from the 'certified' list or round robin?
17:29 < duiv> I think PSC should decide
17:29 < timlinux> or based on skills e.g. nyall because we have lots of composer issues we want fixed
17:29 < jef> although I'm still not on the same page with everyone what a blocker is.  it has to be severe to be a blocker - a new bug or a regression is not enough
17:29 < timlinux> duiv: agreed I am asking on how should they decide
17:30 < aneumann> +1 for PSC to decide
17:30 < timlinux> yes but how?
17:30 < timlinux> round robin or just qualitative choice?
17:30 < aneumann> maybe better not fully random
17:30 < duiv> based on skills, availlebility and in case of both are ok, divide between different devs
17:30 < timlinux> ok
17:30 < duiv> over the versions
17:31 < timlinux> so proprosal is:
17:31 < timlinux> 1) we allocate 10k + 1k funding for bug fixing
17:31 < timlinux> 2) we invite devs interested in being bug fixers to apply
17:31 < timlinux> 3) PSC selects two + giovanni
17:31 < timlinux> ---
17:32 < timlinux> can we vote on that?
17:32 < timlinux> or is there something else we should consider?
17:32 < dassau> yes, we should also consider documentation update
17:33 < timlinux> we decided 2.8 was going to be LTR right?
17:33 < timlinux> in which case agreed getting docs updated is also something we should look at funding
17:34 < duiv> I was even thinking to only do doc updates for LTR versions...
17:34 <@anitagraser> sorry i have to go. I'll read the logs.
17:34 < duiv> non-LTR versions have (english) master version?
17:34 < timlinux> yes that is what I was thinking too - I think we discussed this at Essen right?
17:34 < duiv> maybe yes
17:34 < dassau> would be possbile, anyway it would be helpful, because it is very hard to motivate people for that
17:34 < timlinux> duiv: yes basically non ltr dont get updated docs
17:35 < timlinux> and docs team have one big release per year
17:35 < timlinux> to produce an updated manual
17:35 < timlinux> sorry folks I also need to leave in a few minutes
17:35 < dassau> sorry I have to catch a train now, too.
17:36 < timlinux> ok so shall we move vote for bug fixers to mailing list?
17:36 < aneumann> so who takes the task to ask the core devs for the registry of bug fixing devs?
17:36 < timlinux> I'm happy to write a draft email that we can send to thedev list
17:36 < aneumann> timlinux: thanks
17:36 < timlinux> np
17:37 < duiv> if everybody is leaving: should we just go for the next meeting on fri 6h of feb?
17:37 < timlinux> yes
17:37 < duiv> 6th I mean
17:37 < timlinux> I think it is better
17:37 < jef> time?
17:37 < duiv> did anybody respond to Lene's question to the PSC members
17:37 < dassau> yes, and 6th would be ok for me
17:38 < timlinux> not yet
17:38 < timlinux> jef can we do the same time as today?
17:38 < timlinux> if gshermancan copy
17:38 < gsherman> :P
17:38 < duiv> I'm ok with that
17:38 < duiv> :-)
17:38 < jef> timlinux: sure.
17:39 < timlinux> duiv: Ill try to write to her tonight
17:39 < timlinux> cheers all
17:39  * duiv is looking into the hackfest wiki page now
17:39 < duiv> timlinux: thanks
17:39 -!- timlinux [[email protected]] has quit [Quit: timlinux]
17:40 < dassau> I have to leave now , too. Bye
17:40 -!- dassau [[email protected]] has quit [Quit: Verlassend]
17:44 -!- anitagraser [3edaa47e@gateway/web/freenode/ip.62.218.164.126] has quit [Ping timeout: 246 seconds]
17:48 -!- aneumann [bc3ed06f@gateway/web/freenode/ip.188.62.208.111] has quit [Quit: Page closed]