19:03:50 <ennael> #startmeeting
19:03:50 <Inigo_Montoya`> Meeting started Wed Apr 20 19:03:50 2011 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:50 <Inigo_Montoya`> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:03:51 <erzulie> [ MeetBot - Debian Wiki ]
19:04:41 <misc> so everybody is here ?
19:04:52 <ennael> #chair misc ennael
19:04:52 <Inigo_Montoya`> Current chairs: ennael misc
19:04:55 <anaselli> more or less here i am :)
19:05:08 <misc> #name Packager meeting
19:05:14 <ennael> I propose to keep packagers policy for end of meeting
19:05:35 <ennael> #topic version freeze and release freeze
19:06:15 <ennael> ok that point to make clear what are version and release freezes
19:06:51 <ennael> so as a reminder release freeze is for 10th of may
19:07:01 <ennael> and version freeze just after this meeting
19:07:12 <shikamaru> ah now I understand :)
19:07:22 <shikamaru> AL13N: I’ll review eduke32 if you like
19:07:34 <ennael> it means after this evening you will not be able to update new versions
19:07:43 <ennael> same thing for releases in may
19:07:53 <spturtle> new packages?
19:08:01 <ennael> no freeze for now
19:08:11 <ennael> still a lot to do
19:08:23 <anaselli> good to know it
19:08:36 <ennael> anyway it means work will have to focus rather on bug fixing until stable release
19:08:45 <misc> spturtle: usually, that work fine
19:08:46 <ennael> bugzilla is full of work to be done
19:08:58 <ennael> *but*
19:09:20 <ennael> if you really need to submit new version after tonight you can ask on -dev ML
19:09:29 <ennael> name of package and the reason
19:09:45 <ennael> usually it's about security fixes, bugs...
19:09:52 <anaselli> as in mandriva so
19:09:59 <ennael> or because we have rc release of a package in repo
19:10:01 <ennael> yes
19:10:10 <ahmad78> with "Freeze push requst:" in the subject so the email is distinguishable
19:10:15 <ennael> only few guys will be able to allow that submit
19:10:25 <ennael> ahmad78: good idea
19:10:27 <ahmad78> request*
19:10:34 <anaselli> and easy to filter :)
19:10:37 <ennael> freeze push request: package-version
19:10:56 <Nanar> who can force submission ?
19:11:04 <Nanar> for information
19:11:15 <pterjan> schedbot
19:11:16 <stewb> no bribes Nanar :)
19:11:19 <ennael> for now I guess boklm, misc, ennael
19:11:28 <ennael> maybe 1 or 2 more
19:11:36 <ahmad78> pterjan, blino
19:11:37 <Nanar> stewb: :)
19:11:42 <misc> technically, all sysadmin can
19:11:50 <ennael> Nanar: and you cannot try chocolate for submits
19:12:02 <ennael> yep we could add stewb
19:12:10 <ennael> stewb: would you be ok?
19:12:12 <ahmad78> misc: well, yes, all sysadmin have long experience anway
19:12:17 <Nanar> ennael: I'll beat any sys admin close to me
19:12:19 <Kharec> hi
19:12:19 <ahmad78> anyway (damn typos)
19:12:35 <stewb> ok for me
19:12:40 <ennael> thanks
19:12:52 <ennael> any question on that topic ? is everything clear ?
19:13:03 <ennael> it means also after 10th of may, no more submission at all
19:13:07 <ennael> except fixes
19:13:21 * Kharec will read logs for this topic :)
19:13:35 <ennael> So still 20 days for submissions
19:13:46 <misc> and verified fixes, if possible :)
19:13:47 <ennael> questions ?
19:13:47 <anaselli> ok for me
19:14:25 <AL13N> ok
19:14:36 <shikamaru> ok too
19:14:43 <ennael> ok
19:14:44 <ahmad78> next!
19:14:46 <AL13N> shikamaru: pm ping?
19:14:52 <ennael> #topic todo list for packaging for last days before stable
19:15:06 <ennael> ok we already spoke about this in last meeting
19:15:15 <ennael> this is about priorities and todo list on packaging side
19:16:02 <ennael> so here a few urls
19:16:04 <ennael> are
19:16:08 <ennael> https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=release_blocker
19:16:09 <erzulie> [ Log in to Bugzilla ]
19:16:17 <ennael> this is about release blocker bugs
19:16:31 <ennael> we cannot release if list is still there
19:16:46 <Nanar> There is no saved search named 'release_blocker'.
19:16:46 <ennael> so we need  fixes and answers from testers
19:16:55 <Nanar> according bugzilla
19:16:57 <ahmad78> was just about to say the same
19:17:12 <ennael> https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=release_blocker&sharer_id=5
19:17:13 <erzulie> [ Log in to Bugzilla ]
19:17:16 <ennael> sorry
19:17:42 <ennael> we will have also a bug tracker for security fixes
19:17:48 <ennael> stewb will manage it
19:18:13 <ennael> it will help us to release with minimal sec bugs inside
19:18:14 <misc> #url https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=release_blocker&sharer_id=5
19:18:16 <erzulie> [ Log in to Bugzilla ]
19:18:31 <misc> #info a tracking bug for security issue will be created
19:18:49 <ennael> next one is http://check.mageia.org/dependencies.html
19:18:49 <erzulie> [ dependencies global report ]
19:19:16 <ennael> apart from java packages managed by dmorgan we still have issues there
19:19:38 <ennael> and http://check.mageia.org/updates_mandriva_2010_2.html
19:19:38 <erzulie> [ updates_mandriva_2010_2 global report ]
19:19:38 <ahmad78> dralive issue is pending until mkcd is split
19:19:59 <ennael> this last url is about packages in Mageia who has lower version than in mandriva
19:20:06 <ennael> this will cause pb in upgrade
19:20:08 <pterjan> moonlight one is not a big rpoblem
19:20:15 <pterjan> we can disable the -devel
19:20:21 <ennael> just do it :)
19:20:27 <boklm> ahmad78: mkcd is split
19:20:34 <ahmad78> bash-completion is not an issue, our package has a higher Epoch (as per discussion of the issue here previously)
19:20:36 <misc> #action pterjan disable moonlight-devel
19:20:38 <pterjan> (moonlight is built with an included old mono, so the -devel require it)
19:20:49 <ennael> and finally bugzilla
19:20:57 <ahmad78> boklm: then dralive requires should be changed
19:21:01 <boklm> ahmad78: yes
19:21:14 <misc> #url http://check.mageia.org/updates_mandriva_2010_2.html package that are newer in mandriva than what we have
19:21:14 <erzulie> [ updates_mandriva_2010_2 global report ]
19:21:18 <ennael> ahmad78: feel free to shout aon -dev ML if critical bugs does not move
19:21:31 <misc> #info epoch should be taken in account to see f the problem still exist
19:21:36 <ennael> also move bugs as blocker if needed
19:21:45 <misc> #url http://check.mageia.org/dependencies.html
19:21:45 <erzulie> [ dependencies global report ]
19:21:54 <anaselli> misc mandriva 2010.2 with backports?
19:21:56 <ennael> we really need help on bugzilla to review pending bugs
19:21:57 <shikamaru> what about backports ?
19:21:59 <ahmad78> ennael: yes, I try to do that all time (except the shouting bug)
19:22:01 <misc> #info maven-* and java package are know to be broken ( and complex to fix )
19:22:14 <misc> anaselli: I do not think we take backport in account :/
19:22:35 <pterjan> hmm maybe we should
19:22:38 <shikamaru> ok so we should at least notice users about this in some way I think
19:22:50 <pterjan> just add the media in the config
19:22:51 <ennael> pterjan: can you modify that page taking it into account ?
19:22:54 <pterjan> yes
19:22:58 <ennael> ok
19:23:00 <shikamaru> pterjan: well, I agree it can be hard as they can be pushed at any time
19:23:23 <shikamaru> so not taking them into account sounds sensible
19:23:32 <shikamaru> but warn users, maybe in errata can be an option
19:24:19 <misc> #action pterjan modify youri check for upgrade of mandriva to take backport in account
19:24:31 <ahmad78> shikamaru: at least before freeze, we can update to smooth upgrades with backports packages
19:24:33 <anaselli> agree a t least a warning must be written
19:24:38 <ennael> shikamaru: let see what is impact of having backport
19:24:38 <misc> shikamaru: well, even if we do not fix every bug, we can fix the vast majority
19:25:20 <shikamaru> depends if the package is critical or not but I agree yep
19:26:37 <ennael> anything else to add on that topic ?
19:26:51 <misc> nope
19:26:59 <Kharec> nop
19:27:08 <ennael> ok
19:27:12 <shikamaru> ok
19:27:14 <ennael> #topic mageia.org mail for packagers
19:27:22 <ennael> this will be quick
19:27:43 <ennael> we will give finally mail alias mageia.org to all official packagers for now
19:27:55 <ennael> it means when you can submit in mageia
19:27:56 <anaselli> \o/
19:28:01 <misc> so people wth submit privileges ?
19:28:05 <ennael> yep
19:28:22 <anaselli> not commit?
19:28:23 <shikamaru> thanks
19:28:27 <misc> so the email is : login@mageia
19:28:30 <misc> anaselli: nope
19:28:33 <ennael> please report any pb when using it on sysadmin ML
19:28:45 <misc> it is forwarded to the email you use on identity
19:29:13 <misc> and well, I know some people used some @mageia email on identity, and I do not know if it work fine or not
19:29:49 <misc> so if you change something and see your mail do not come, just try to get in touch with us
19:29:52 <wally_> cool, is the aliases working already?
19:30:03 <misc> ( also, beware of the spamassassin setup that is quite strict )
19:30:08 <misc> wally_: in a few minutes
19:30:15 <Kharec> very cool!
19:30:24 <wally_> ok
19:30:37 <ennael> misc: some grey listing ?
19:30:46 <misc> ennael: there is some
19:30:56 <ennael> ok
19:30:59 <shikamaru> could be nice if packagers generate a gpg key for this email address
19:31:20 <ennael> #info all packagers with submit rights will have mail alias @mageia.org
19:32:08 <ennael> anything else to add ?
19:32:08 <anaselli> shikamaru: can i add it to mine or do you want a new one?
19:32:37 <Kharec> ennael: nope for me
19:32:42 <Kharec> All was clear :)
19:33:16 <ennael> ok the last but not the least
19:33:23 <ennael> #topic packagers policy draft
19:34:13 <ennael> misc: can you sum up discussions on ML about this ?
19:34:18 <misc> ennael: mhh no :)
19:34:23 <ennael> humpf
19:34:33 <ennael> ok
19:34:47 <misc> I can reread it but it may take 5 minutes
19:34:55 <ennael> so here are the ideas we had during discussions
19:35:06 <ennael> avoid ACLs in svn for packages
19:35:06 <misc> ( and i also need to forget my opinion, which is harder )
19:35:33 <ennael> no clear position about groups
19:35:45 <boklm> there was a message from philippeM about groups I think
19:35:51 <ennael> it may help in some cases but it should not be that frequent
19:36:00 <misc> ( ok I reread and I know remind why I forgot everything )
19:36:29 <ahmad78> and set a punishment system for misbehaving packagers (i.e. those who do the same mistake in violation of rules more than once)
19:36:47 <ennael> pterjan proposed to have mail for commits when not done by package maintainer
19:36:51 <ennael> mail to maintainer
19:36:52 <misc> yup
19:36:59 <misc> or mail to anybody interested
19:37:31 <ennael> still not decided: "sensible" packages
19:37:40 <ennael> we have a list for now on wiki
19:37:46 <anaselli> changelog mailing list is something like that already misc, for all i mean
19:38:07 <spturtle> ("sensitive" maybe, I hope all package are sensible)
19:38:16 <boklm> anaselli: changelog ML is sending mail about any package, not only yours
19:38:23 <pterjan> anaselli: except not everyone can read it all everyday
19:38:29 <ennael> outch yes
19:38:38 <anaselli> indeed so to one is better than to all :)
19:38:39 <ennael> spturtle: "faux ami" in french
19:39:00 <ennael> and we speak about commits not changelogs
19:39:21 <anaselli> no submits then ennael?
19:39:31 <anaselli> ok now i recall it :)
19:39:38 <spturtle> if interested in a package, why not join the maintainer group for that package
19:39:43 <ennael> I'm just recalling what was said on ML
19:39:59 <shikamaru> anaselli: nope commits you would like to follow would be drowned in the other ones
19:39:59 <ennael> spturtle: you have a fix for example on  a package once
19:40:06 <boklm> spturtle: we're talking about commits from other people on your packages
19:40:06 <ennael> but no general interest in package
19:40:41 <misc> spturtle: well, if I am interested as a user to a package ?
19:40:56 <misc> ( or as a packager, I depend on it yet do not want to maintain it )
19:43:07 <misc> ok so ?
19:43:10 <spturtle> so every package will have a public read-only "mailing list" wich commit messages?
19:43:20 <boklm> not a mailing list
19:43:26 <shikamaru> spturtle: not a mailing list
19:43:27 <boklm> but a system to be able to subscribe to packages
19:43:37 <spturtle> people can subsribe and unsubscribe
19:43:51 <shikamaru> just like on forums
19:43:54 <misc> something like the kde notification system
19:44:01 <shikamaru> when you want to follow a particular subject
19:44:14 <shikamaru> once someone posts in that topic you are notified
19:44:34 <Nanar> you mean a forum ? /o\
19:44:36 * Nanar hides
19:44:42 <boklm> like on bugzilla when you add yourself in CC on a bug
19:44:48 * ennael wants to see Nanar on forum
19:44:48 <misc> http://commitfilter.kde.org/
19:44:49 <erzulie> [ CommitFilter ]
19:44:59 <shikamaru> yep boklm
19:45:08 <shikamaru> I think we need to store that somehow
19:45:14 <shikamaru> could be in maintdb ?
19:45:22 <ennael> misc: looks nice
19:45:33 <shikamaru> with some svn hooks
19:45:55 <misc> shikamaru: I would rather do this with some postgresql backend and postfix on a specific domain
19:46:02 <misc> this is more extensible
19:46:21 <Nanar> postfix-pgsql can help for such things
19:46:41 <misc> ( ie, have some kind of alias for $rpm@packages-svn.mageia.org that redirected to people who are interested into
19:47:07 <shikamaru> ok same logic but different implementation :)
19:47:22 <misc> so all we have to do would be to manage the database from a frontend, the rest will be done by the same infrastructure
19:47:27 <shikamaru> mmh would it scale ?
19:47:36 <misc> shikamaru: as much as a mailling list
19:47:40 <shikamaru> (I mean, aliases)
19:48:33 <boklm> if we don't have thousands of commits every seconds, I think it will scale
19:48:42 <spturtle> posting would be restricted to the svn server I hope
19:48:56 <misc> spturtle: technical detail :)
19:49:19 <misc> the domain can be internal, or we could extend this to bugs, etc
19:49:30 <misc> ( or any kind of automated report )
19:50:41 <shikamaru> ok so I think we all agree here that some kind of notification system would be nice, how we do that is secondary I think :)
19:50:51 <spturtle> yes, sounds good
19:51:06 <misc> now, the question is the packagers policy
19:51:11 <misc> ie, acl, no acl
19:51:14 <misc> commit, submit ?
19:51:35 <shikamaru> why would we need that ?
19:52:14 <misc> because some package breackage can break a lot of stuff
19:52:26 <misc> ie, someone blindly upgrading glibc could wreck havoc
19:52:31 <Nanar> may I suggest "no acl"
19:52:45 <Nanar> maybe a mdv syndrom
19:53:06 <shikamaru> yes, so we agree that not everyone should touch packages blindly without being aware of consequences
19:53:20 <shikamaru> but couldn’t we just trust people ?
19:53:25 <ahmad78> Nanar: acl on submit only, maybe
19:53:35 <anaselli> Nanar: no acl means we need to have a good and quick recover team :)
19:53:46 <misc> well, no one is in favor of acl on commit , i am wrong ?
19:53:50 <shikamaru> I mean, it sounds like a lot of work to me, work that could be better spent on other useful stuff
19:53:56 <misc> shikamaru: yup
19:54:26 <Nanar> anaselli: I remember time at mdv when the acl was more to protect bugs that avoiding them
19:54:44 <Nanar> maybe I am against acl because this past
19:54:51 <anaselli> Nanar: i'm not in favour of closing ;)
19:55:11 <anaselli> i'm just considering the effect of being to open
19:55:16 <anaselli> too
19:55:19 <spturtle> and we would need a process to decide who is allowed to submit a package and who isn't
19:55:32 <pterjan> well some packages could have restricted submit yes
19:55:38 <pterjan> all th eones breaking bs :P
19:55:40 <anaselli> maybe a group of packages
19:55:40 <Nanar> anyway, acl must not be to allow only ONE guy
19:55:45 <anaselli> more than one alone
19:56:06 <boklm> maybe we can have an acl file on svn that can be edited by anybody. So when you have a package that should not be updated for some reason, you add it in the acl file with a comment, and people who want to update it need to edit acl file after reading the comment to submit
19:56:08 <shikamaru> pterjan: but these should not be touched without the maintainer being asked
19:56:08 <anaselli> Nanar: agree that's why i'm for groups
19:56:13 <shikamaru> like jq for perl
19:56:28 <shikamaru> or tmb for the kernel
19:56:34 <pterjan> boklm: interesting
19:56:37 <misc> boklm: that sound too much work, I am not sure people will do it
19:56:59 <misc> ( ie, packagers are lazy :p )
19:56:59 <ahmad78> I agree with misc
19:57:00 * spturtle agrees with Nanar, if only one person is maintainer, the package is not restricted, only if 2 or more maintainers are registered restrictions can apply
19:57:29 <ahmad78> I think a restriction on submit for sensitive packages is good
19:57:46 <ahmad78> (rpm, kernel, perl, xmoto)
19:57:57 <boklm> :)
19:58:01 <Nanar> or a team can force submission if maintainers don't react to solve bugs, or deny to solve them
19:58:09 <shikamaru> well, so I ask the question, how much time could it take to implement that ?
19:58:17 <misc> that's the model of fedora, with proven packager
19:58:19 <Nanar> ahmad78: and cowsay and hot-babe
19:58:43 <ahmad78> Nanar: no one will touch hot-babe anyway :p
19:58:54 <shikamaru> do some people have time to do it ? are there more urgent pending tasks ?
19:58:59 <pterjan> Nanar: such problem can be discussed at packagers meeting
19:59:00 <boklm> or maybe we can wait until we have problems to add ACLs if needed
19:59:12 <misc> shikamaru: there is always something urgent for sure
19:59:26 <pterjan> Nanar: and acl removed/updated if needed
19:59:27 <misc> shikamaru: but sooner or later, if we decide to do, we will do it
19:59:35 <Nanar> pterjan: indeed
19:59:36 <Kicer86> are there really serious changes in new gcc package? since it has changed I cannot compile one of my programs
19:59:42 <spturtle> how about we only reserve a "restricted" flag for packages in the maintainer db, but don't use it until further discussion after the release
19:59:44 <ahmad78> boklm: or just apply reasonable ACL and remove them if they prove to be too restrictive
20:00:03 <shikamaru> well, I’m not against nor for it, I just consider it low priority for the moment :)
20:00:35 <misc> so to summrize
20:00:56 <misc> some people do think acl are not useful : nanar, shikamaru
20:01:31 <misc> some people think we need acl for sensitive packages : ahmad78 , pterjan
20:01:33 <pterjan> I think it is important that changes are reviewed by maintainers for some packages
20:01:44 <pterjan> acl is one solution
20:01:55 <ahmad78> some people think it's useful on submit only, and for very core packages only but with more than one person with submit rights so as not to let bugs rot in hell for a long time
20:01:57 <misc> we all think that acl should be on upload, not on commit
20:01:57 <pterjan> beating people who don't respect that is another
20:02:03 <anaselli> well sooner or later we should decide something on it for instance in stable updates
20:02:23 <pterjan> yes submit is enough if maintainer is properly notified
20:02:29 <boklm> anaselli: stable update is different
20:02:31 <Nanar> misc: I am not against acl
20:02:45 <Nanar> misc: I just don't want ACL like at mdk in past
20:02:57 <pterjan> I think someone should not upload a kernel for fun :)
20:03:06 <pterjan> even if he fixed a typo in the summaray
20:03:16 <misc> pterjan: given the number of kernel rpm in mdv, people did more than once
20:03:35 <ahmad78> Nanar: it won't be like mdk, there're no employees... :)
20:03:53 <Nanar> ahmad78: it's unrelated to employees or not
20:03:59 <Nanar> it's related to people
20:04:23 <misc> well, the risk with acl is that some people, as maintainer could abuse them
20:04:35 <misc> so we want to avoid :
20:04:36 <ahmad78> Nanar: yes, but ACL was only for employees, and I guess all the old hands won't let that happen again given how much pain it caused in the past
20:04:49 <misc> - package being uploaded without maintainer to know it
20:04:57 <Nanar> ahmad78: not all employees abused of them
20:04:58 <misc> - people blocking bugfixes,
20:05:00 <misc> ok ?
20:05:04 <Nanar> yup
20:05:08 <shikamaru> I agree
20:05:21 <ahmad78> Nanar: yes, of course
20:05:24 <misc> #info packagers policy goal to keep in mind
20:05:29 <pterjan> I think the second one is easy to achieve without technical solution
20:05:37 <misc> #info some package should be acked by the maintainer
20:05:40 <ahmad78> Nanar: I meant the ones that were too restrictive
20:06:01 <misc> #info the policy should not block bugfixes
20:06:08 <pterjan> there are mailing lists and weekly meetings where an abusive maintainer can be reported
20:06:21 <pterjan> there should be a rule about maintainer
20:06:22 <shikamaru> documentation could be a good thing but it takes time
20:06:33 <pterjan> like maintainer is not the god of his package
20:06:41 <shikamaru> I mean, warning people what they should probably not do, and why
20:06:54 <misc> shikamaru: do and don't seems a good idea
20:07:03 <pterjan> if overall other packagers don't agree with him he sould listen
20:07:05 <shikamaru> what the impact could be to do some kind of change
20:07:05 <pterjan> +h
20:07:19 <ahmad78> pterjan: I agree, educating/correcting maintainers is better
20:07:34 <ahmad78> (except it doesn't work sometimes)
20:07:40 <shikamaru> misc: I think the whole thing is not about restricting things to elected people, rather educating everyone to follow good practices :)
20:07:45 <shikamaru> ahmad78: yep :)
20:07:55 <anaselli> well i believe that if we have a weekly meeting we can discover case by case when a maintainer is not responsive or committers make for fun
20:08:03 <AL13N> isn't that why we have team leaders? to decide which way to go if dispute?
20:08:14 <misc> shikamaru: we have 2 issues, we also want to prevent brekeage
20:08:37 <shikamaru> misc: shouldn’t we have backup chroots btw ?
20:08:49 <AL13N> shikamaru: +1
20:08:57 <shikamaru> that does not excuse breakages, but could allow fixing stuff in less time
20:09:06 <ahmad78> shikamaru: older chroot is already backed up iirc
20:09:12 <AL13N> shikamaru: old proven backup chroots that are updated from time to time
20:09:13 <misc> shikamaru: technically, we should, in practice, it does work as I expected :)
20:09:20 <AL13N> ah
20:09:52 <misc> #action misc check that archiving of rpm on upload work fine
20:10:53 <misc> but indeed, since we can restore old rpm in case of error, this would be sufficient
20:11:20 <pterjan> well it would be better to keep working chroot when failing to generate a new one :)
20:11:27 <pterjan> (and send an alert)
20:11:39 <misc> is there a bug report ?
20:11:46 <pterjan> I don't think so
20:11:58 <shikamaru> I willhave to leave soon :)
20:12:14 <anaselli> bye shikamaru
20:12:17 <shikamaru> later
20:12:29 <misc> #action misc fill a bug report for keeping old chroot when new one fail to be created
20:12:53 <misc> anyway, back to packagers policy, I propose to continue this oon the ml, I will post something
20:13:26 <ennael> can we open wiki page and write down things on which people agree
20:13:31 * anaselli will try to follow mailing list on that subject
20:13:39 <ennael> because it may be a mess after some time
20:13:55 <misc> ennael: after some time only ?
20:14:08 <ennael> misc: be positive :)
20:14:11 <anaselli> misc: even here :D
20:14:12 <misc> #action misc open a wiki page to keep progress
20:14:46 <ennael> ok shall we stop now ?
20:14:50 <misc> yup
20:15:07 <ennael> ok
20:15:16 <ennael> boklm: is version freeze ready to apply?
20:15:24 <boklm> ennael: yes
20:15:47 <ennael> ok go then :)
20:15:50 <boklm> ok :)
20:16:03 <ennael> thanks guys for being there
20:16:14 <ennael> #endmeeting