19:06:31 <misc> #startmeeting
19:06:31 <Inigo_Montoya> Meeting started Mon Nov  8 19:06:31 2010 UTC.  The chair is misc. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:31 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:38 <misc> #meetingname Founders meeting
19:06:38 <Inigo_Montoya> The meeting name has been set to 'founders_meeting'
19:06:45 <misc> #chair ennael rda
19:07:28 <misc> so first topic ?
19:07:40 <rda> wiki platform cs and choice
19:07:45 <rda> s/cs/specs/
19:07:49 <ennael> #topic wiki platform specs and choice
19:08:10 <rda> requirements have been written here: http://mageia.org/wiki/doku.php?id=wiki_requirements
19:08:39 <rda> has anyone other point to make regarding these requirements?
19:09:41 <wobo> I'd have requirements more non-technical type, but I understand that this will come later
19:09:53 <rda> wobo: you can state/list them nonetheless
19:10:07 <rda> (oh btw, sorry for coming in at the very last minute, and, hi everyone :) )
19:10:16 <wobo> rda: will list them in the wiki later
19:10:36 <ennael> wobo: it may be important to choose final wiki
19:10:47 <rda> wobo: ok, important to know nonetheless, we would like to short list candidates this evening if possible
19:11:27 <boklm> is it important to have ACLs ?
19:12:05 <wobo> it's not related to the type of wiki, more to the contents policy
19:12:09 <rda> at least to differentiate full admin and regular editor
19:12:13 <rda> wobo: oh ok
19:13:00 <boklm> ok
19:13:00 <rda> having ACLs per page could be useful, maybe, not sure.
19:13:43 <rda> (we did not have vandalism on the mandriva wiki and neither issues about "official" content being editable)
19:14:22 <misc> afaik, we used it on the CoC page and we use them at the moment on the temporary wiki for several page ( like roadmap )
19:14:29 <wobo> vandalism can always be turned back by revision control
19:14:55 <rda> misc: indeed
19:14:57 <rda> wobo: as well yes
19:15:28 <wobo> but my experiences with ACL per page are very good, ACLs come in handy when you need them and they do not hurt
19:15:33 <rda> although if we can name/have someone in charge for editing/moderating a specific page/project, we could leave edition open
19:15:45 <rda> ok, so, if possible, good to have
19:16:47 <wobo> yes
19:17:01 <ennael> #info reminder: http://mageia.org/wiki/doku.php?id=wiki_requirements
19:17:07 <rda> anything else? people having candidates to present?
19:17:22 <ennael> #info having ACLs is interestig on some part of wiki (CoC, roadmap...)
19:18:54 <ennael> ok
19:19:02 <ennael> rda: review about requirements ?
19:19:08 <rda> ok, mediawiki is one. but not necessarily the only one.
19:19:14 <rda> ennael: ?
19:19:51 <ennael> well we expected to have a choice tonight regarding these requirements
19:20:25 <rda> yes, that's where I would have liked input about potential candidates other than what we used at mandriva
19:20:42 <wobo> well, dokuwiki may be another candidate, I am not very fond of the way mediawiki handles editing conflicts. dokuwiki uses a document locking, mediawiki uses merging
19:21:39 <wobo> but that's a minor issue
19:22:52 <rda> ok, so... if we were to decide for one now, who would go for what? or shall we decide to go forward with one, and we can experiment later?
19:23:34 <boklm> is anybody against using mediawiki ?
19:23:45 <wobo> Hmm, depends on how much effort/time we will spend on customizing. That would be lost if we'd change to another one later.
19:24:21 <rda> wobo: I wouldn't say change to another, but build something else (other part of the website). so we can take a long run with both.
19:24:43 <rda> nonetheless, apart from theming and multilingual setup, there won't be so much customization.
19:24:47 <wobo> mediawiki is not my favourite but I can live with it. As most of us are used to mediawiki we should stick to that
19:24:50 <rda> (well, that's what I expect)
19:24:57 <wobo> rda: yes
19:25:29 <rda> okk, so, let's go for mediawiki for one.
19:25:39 <coincoin> \o/
19:25:58 <rda> #info mediawiki will be used as the main platform for Mageia.org main wiki
19:26:16 <wobo> with mediawiki we can also benefit from those users who contributed a lot to mdv wiki (like skiper and others)
19:26:23 <rda> #info setup, design, packaging, update process work is needed for this
19:26:41 <rda> ok, next?
19:27:06 <boklm> next topic ?
19:27:09 <wobo> next! :)
19:27:26 <rda> #topic bugtracker platform specs and choice
19:27:29 <rda> \o/ one more ! :)
19:27:56 <rda> ok, so here, we don't have a specs page as of yet, however, bugzilla is likely the easiest choice (as it's in the continuity).
19:28:01 <misc> wobo: well, the problem of database we will discuss later would like apply as well on the wiki, so do not expect much about the reuse
19:28:24 <rda> however, other platforms may be considered (among which a part of redmine)
19:28:35 <jq> misc: i guess rda was speaking of user habit
19:28:46 <rda> jq: yes
19:28:46 <wobo> misc: I mean reuse of already existing experience
19:28:50 <jq> s/rda/wobo/
19:29:07 <misc> rda: 1st question is a bug tracker to track what
19:29:08 <dmorgan> yes bugzilla seems a good choice and fit and will fit our needs i think
19:29:24 <rda> as well, there's the question of what is included into the bugtracker, and how it can be articulated: distribution packaging, specific software _development_, web sites, web apps, other services or project (for instance, mageia-app-db)
19:29:30 <coincoin> misc: bugs on the distro
19:29:42 <misc> coincoin: and so, for bug on software, we use what ?
19:29:43 <rda> misc: requests/features/bugs on web apps
19:29:53 <misc> for sysadm task, what do we use ?
19:29:58 <jq> rda: i'm not a big fan of hosting mageia related projects on the same platform
19:30:04 <dmorgan> misc: bugzilla too
19:30:06 <ennael> bugs on packages / soft / web apps ?
19:30:12 <jq> eg, mageia-app-db would be best on github or other platofrm
19:30:13 <dmorgan> misc: kde do this way and this works well
19:30:27 <rda> jq: or on some forge we manage (gitorious, redmine) ?
19:30:35 <ennael> jq: but having different bug trackers mean more things to maintain
19:30:36 <rda> jq: or shall we leave this outside of mageia inffrastructure?
19:30:38 <misc> we also have to not forget the shortcoming of bugzilla
19:30:46 <ennael> shortcoming ?
19:30:49 <rda> ennael: unless there are all based on the same model
19:30:57 <misc> ie, a bug can be filled only against one release
19:31:16 <misc> ie when there is a bug on devel version, and we release, we lose track about how to fix it
19:31:23 <ennael> ok
19:31:32 <wobo> that's a big one!
19:31:39 <dmorgan> rda: i would prefer to host them on gitorious, i don't see the benefits or having them outside,  this will become a big mess
19:31:50 <rda> misc: yep. is there a bugtracker or process that could help to prevent that?
19:32:31 <rda> one option that could be considered but it rather new for everyone, would be to use redmine as a big project manager, and have specific trackers/wiki/roadmaps for each project.
19:32:35 <rda> one such project could be packaging
19:32:35 <misc> rda: there is at least one, since launchad does it, but I do not know for others
19:32:53 <rda> misc: and would there be a way with bugzilla (but using it differently)?
19:33:08 <misc> rda: i do not know, I am not bugzilla-fluent enough
19:33:19 <dmorgan> misc: what is the pb with bugzilla in fact ? :)
19:33:32 <rda> could this very issue be described so it is discussed more widely (with other projects as well)?
19:33:44 <misc> dmorgan: see 20:30:56
19:34:16 <ennael> #info pb with Bugzilla is a bug cannot be submitted for several versions of distribution
19:34:28 <dmorgan> misc: i don't understand the pb
19:34:43 <wobo> <misc> ie when there is a bug on devel version, and we release, we lose track about how to fix it
19:34:54 <misc> dmorgan: well, a user fill a bug on gnome just before the release
19:34:54 <dmorgan> wobo: yes but i don't see the pb in fact
19:35:04 <misc> we fix it in cooker 2 months later
19:35:13 <misc> we don't fix it in stable release
19:35:22 <misc> because the bug is closed on cooker, and unfixed on stable
19:35:44 <dmorgan> misc: and do other bug trackers handle this better ?
19:36:00 <misc> dmorgan: as i said, launchpad does it, and I do not know every bugtracker on the heart
19:36:21 <misc> but we should have invited a bug triager team member to discuss of their requirement
19:36:22 <dmorgan> misc: launchpad please don't this is a mess and user unfriendly
19:36:24 <coincoin> heart, sweet! :)
19:36:33 <ennael> ahmad78: there ?
19:36:40 <ahmad78> yes :)
19:36:46 <ennael> ahah
19:36:51 <ennael> your turn :)
19:36:52 <boklm> misc: do you know if someone already asked bugzilla developers to add this feature ?
19:36:58 <coincoin> traac don't allow multiple release for a bug IIRC
19:37:08 <misc> coincoin: trac would not be suitable imho
19:37:30 <misc> do too many things at once
19:37:39 <ahmad78> well, they way it was handled in mdv, was using the "Whiteboard" field, to state that the bug affects other releases
19:37:56 <ahmad78> not too elegant but it worked
19:38:04 <rtp> misc: I would also add that trac is painful to use imho :)
19:38:19 <ahmad78> and usually the maintainer was aware to backport the fix (notable tv, fcrozat.. etc)
19:38:20 <misc> rtp: I would, but I have my name in the authors file so I can't
19:38:30 <coincoin> rtp: +1
19:38:45 <ennael> :)
19:38:53 <rtp> :)
19:38:53 <ennael> ok so what about ahmad78 proposal ?
19:39:17 <dmorgan> ennael: is the best and worked well in the past
19:39:31 <ennael> misc: have you seen it working ?
19:39:42 <ahmad78> the point is, what're the alternatives?
19:39:51 <dmorgan> ennael: i have spoke with mdv kde team on time and they told me they liked ahmad way and helped to backport fixes
19:40:02 <rda> how does mozilla handle this for instance? or gnome? if ever.
19:40:41 <tmb> one other way maybe is to clone cooker bug report for a release, and add the release bug as blocker on cooker bug?
19:41:21 <Anssi> unfortunately that may cause the discussion to be split between two pages
19:41:48 <ahmad78> tmb: yes, that too but usually a maintainer cloned a bug when a fix was available for the benefit of QA/Sec teams
19:41:55 <rtp> rda: looking at fedora may be more suited than looking at mozilla or gnome I guess
19:41:56 <misc> rda: i suspect they do not handle this
19:42:10 <misc> and I know that fedora does not handle this
19:42:15 <rda> rtp: maybe, but it's always good to see other's culture in handling similar situation
19:42:27 <rda> do they have a reason, not to deal with this?
19:42:28 <misc> and that their automated closing procedure caused a huge thread last week
19:42:59 <misc> rda: I suspect technical limitation of bugzilla model
19:43:08 <dmorgan> misc: [20:42] <LpSolit> we plan to implement something similiar to what you ask in Bugzilla 4.x
19:43:13 <rda> misc: probably, yes
19:43:32 <rda> dmorgan: could you ask how they see it? like, multiple product/version to be filed against a bug?
19:43:33 <dmorgan> misc: the functionnality you ask is planned in bugzilla 4.x so we could do w/o at the begining
19:43:54 <ennael> Anssi: what do you think about ahmad78 proposal?
19:43:57 <ennael> using white board
19:44:01 <tmb> when is bugzilla 4.0 relased ?
19:44:14 <dmorgan> ah and with x >= 2
19:44:16 <Anssi> ennael: seems sensible, at least until we get bugzilla 4 :)
19:44:27 <ennael> ok, tmb ?
19:44:52 <Anssi> I'd like it to be handled better, but I don't quite think it is enough to switch to another bugtracker
19:44:58 <boklm> there is a bugzilla 4.0rc1
19:45:38 <ahmad78> well, IINM, we won't update our bugzilla instance too much, so starting with an rc is a bit rough?
19:45:39 <boklm> Final Release: December 13, 2010
19:45:39 <dmorgan> boklm: the functionnality is planned for bugzilla >= 4.2
19:45:43 <boklm> ah
19:45:56 <misc> and when is 4.2 planned ?
19:45:57 <tmb> I guess the way ahmad78 suggests it the best for now and hope for a 4.2 in time for Mageia first release :)
19:46:24 <rda> http://www.bugzilla.org/releases/4.0/release-notes.html
19:46:33 <dmorgan> [20:46] <LpSolit> about versions, you could have a custom field named "Affected Versions" which is a free text form (not ideal, but we have nothing better so far)
19:47:04 <ahmad78> "Affected versions" == Whiteboard (or how we used it in mdv bugzilla)
19:47:05 <dmorgan> [20:46] <LpSolit> for products, maybe file the bug in the sub-component affecting all others
19:47:14 <dmorgan> ahmad78: yes exactly
19:47:50 <ennael> the thing is is it worth to start with new bug tracker or should we manage this lack for now waiting for new version
19:48:07 <ennael> are there other pb to be underlined on bugzilla ?
19:48:15 <dmorgan> ennael: is this functionnality really blocking ?
19:48:15 <ahmad78> I know it's not too elegant and  the problem is, as misc said, the bug gets fixed in cooker then closed, but usually maintainer catch on and backport the fix
19:48:29 <wobo> If I may add as a side remark: from the user's POV I'd like to stay with bugzilla, very user friendly and most ppl (who are caring to report) know how to use it. This is not unimportant if we want to get ppl using it.
19:48:33 <dmorgan> as ahmad78 told there is a "workaround"
19:48:35 <misc> well, the 2nd problem I have is why did we have to use a svn clone of bugzila
19:48:57 <dmorgan> misc: what do you mean ?
19:49:06 <dmorgan> wobo: i agree with you on that point
19:49:26 <misc> dmorgan: have you ever look on how bugzila was handled at mandriva ?
19:49:38 <dmorgan> misc: yes and i saw the patches we use
19:49:46 <misc> dmorgan: sure and what are they ?
19:50:07 <dmorgan> http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/bugzilla/patches/
19:50:19 <dmorgan> misc: one is to add the NEEDINFO Field
19:50:25 <dmorgan> which can be done w/o patch
19:50:37 <dmorgan> one is to remove some power to qa account
19:50:43 <ahmad78> misc: a side effect of wanting a vanilla setup after the warlyzilla phenomenon; i.e. there wasn't a stable release at that time? (I wasn't around)
19:50:43 <ahmad78> misc: was bugzilla instance updated much?
19:51:21 <dmorgan> misc: i don't think we need them ( maybe the NEEDINFO, that would remove lost  time to add the field )
19:51:36 <coincoin> QA is power so need power :p
19:51:46 <dmorgan> coincoin: :)
19:52:03 <dmorgan> coincoin: bugzilla-3.2-dont_give_qacontact_super_cow_powers.patch
19:52:04 <dmorgan> :)
19:52:19 <rda> super cow powers?
19:52:43 * wobo pictures a cow with a superman suit
19:52:54 <boklm> we should only give super duck powers to qa
19:53:00 <coincoin> wobo: :)
19:53:16 <ahmad78> (we're trying to keep meetings under 1 hour, right?) :)
19:53:20 <dmorgan> rda: this is the name of the patch :)
19:53:36 <boklm> so no big patchs
19:53:44 <boklm> and no really important patch
19:53:44 <rtp> rda: apt-get --help ends with "This APT has Super Cow Powers" :)
19:54:04 <dmorgan> boklm: after for the needinfo,  we can see if they want it upstream
19:54:15 <rda> ahmad78: right... /o\ :)
19:54:22 <rda> ok, so, then.
19:54:33 <rda> ok for bugzilla as the bug tracker?
19:54:42 <ahmad78> (upstream is changing bugzilla keywords in 4.0, IIRC)
19:54:45 <misc> we didn't really answered to my first question
19:54:50 <Anssi> what is the needinfo patch for? I thought we used a keyword for that and I thought those were not hardcoded?
19:55:03 <rda> is it ok to host bugs/features/requests for other things that only the distribution? (as we started to do with Mandriva Bugzilla)
19:55:12 <boklm> misc: did we use a svn clone ?
19:55:23 <misc> boklm: no, we must decide what we will use bugzilla for
19:55:29 <boklm> ah
19:55:48 <rda> so, proposition A:
19:56:02 <rda> distribution/packaging bugs/requests
19:56:07 <dmorgan> misc: _all_
19:56:07 <rda> proposition B:
19:56:18 <rda> (same) + web apps + infrastructure
19:56:21 <rda> proposition C:
19:56:28 <rda> (same as B) + various projects
19:57:03 <dmorgan> C:
19:57:08 <ahmad78> rda: if the alternative is having multiple bugzilla instances, then I'd go with B or C
19:57:13 <rda> using classification + product + component
19:57:37 <dmorgan> rda: we just need to be clever on the products, componements and we can w/o pbs use C:
19:57:39 <rda> ahmad78: the alternative would be either multiple bugzilla instances, either one bugzilla, and something else for other projects
19:57:43 <rda> dmorgan: yes
19:57:47 <rda> I'd go for C as well
19:57:55 <misc> I would go for A
19:58:02 * jq votes a
19:58:10 <boklm> misc: what would you use for the others ?
19:58:19 <misc> boklm: I would let the other choose
19:58:28 <jq> boklm: outside projects use sthg outside of mageia infrastructure
19:58:37 <dmorgan> jq: this will be a mess
19:58:37 <coincoin> C for my part (as we were doing in MDV)
19:58:59 <dmorgan> jq: this will makes bugtriage team a hard work  to look on different bugtrackers
19:59:00 <rda> misc: jq: mageia is not only about packaging a distribution, right?
19:59:16 <jq> rda: but where do you draw the line?
19:59:22 <misc> rda: well, that's why we cannot choose for others
19:59:40 <rda> misc: that doesn't prevent to propose a frame for those who prefer to rely on our direction
19:59:43 <misc> rda: ie, there was lots of discussion about having a forge
19:59:50 <rda> misc: there still is
20:00:01 <rda> question is, whether the forge is using bugzilla, or using its own tracker
20:00:06 <boklm> 20:58 < jq> boklm: outside projects use sthg outside of mageia infrastructure <-- what do you mean by "outside projects" ?
20:00:07 <ahmad78> (the problem is, reporting bugs (for e.g. web apps) on mailing list will make some of them get lost)
20:00:10 <misc> rda: so we will have a forge without using the bugtracker of the forge ?
20:00:25 <rda> jq: where would I host bugs/requests for web site, web infrastructure, web services, other mageia-related projects or mageia-hosted projects?
20:00:40 <rda> ahmad78: no way to report them on mailing-list only
20:00:57 <boklm> misc: or use a forge without bug tracker, or connected to bugzilla
20:00:58 <rda> misc: we would use something like gitorious + mediawiki + bugzilla
20:01:18 <rda> the other way around would be to use a forge with its own tracker, per project.
20:01:28 <misc> this seems saner to me
20:01:29 <rda> but then, how do you draw the line when reporting an issue? where do you go?
20:01:50 <rda> moreover, this requires more work to aggregate reports for triage team and people accross all trackers
20:01:54 <dmorgan> misc: this will make bugreporting a hell for users too, with 2 bugtrackers
20:02:09 <boklm> it makes it more difficult to search for a bug
20:02:10 <rda> dmorgan: not too. but 1 for packaging + n (one per project)
20:02:12 <misc> dmorgan: that's already what happen for every software packaged
20:02:16 * jq proposes to use launchpad :-)
20:02:20 <rda> jq: :)
20:02:31 * dmorgan slaps jq
20:02:37 <wobo> Again from the user's POV I'd prefer a 1forALL solution.
20:02:54 <misc> dmorgan: well, jq is right, launchpad does it
20:02:55 <dmorgan> misc: yes but users don't report on all bugtrackers but only on mdv one in general
20:03:06 <misc> dmorgan: they shouldn't
20:03:13 <rda> misc: but launchpad does agreggate across the whole thing, natively
20:03:17 <dmorgan> misc: they are users don't forget
20:03:17 <misc> that waste maintainers time, that force us as packager to act as proxy
20:03:25 <misc> dmorgan: and so, they are not stupid
20:03:26 <ahmad78> (most upstream projects use bugzilla, KDE, GNOME, mozilla)
20:03:26 <dmorgan> misc: they don't have to create a lot of accounts
20:03:32 <wobo> If I had to first search for the right bugtracker to report a pb I'd as well forget it.
20:03:33 <dmorgan> misc: did i told this ?
20:03:57 <rda> ahmad78: and they do it for everything they manage
20:04:06 <rda> not only their only one main product
20:04:12 <ahmad78> wobo: no, usually you file it on the distro tracker and if it's upstream triage or packager/dev will ask you to kick it upstream when necessary
20:04:17 <dmorgan> misc: please try to act like a user not like a dev that know this well
20:04:25 <wobo> ahmad78: yes
20:04:48 <dmorgan> ahmad78: or some does it for the user :)
20:05:10 <ahmad78> (that's wrong, time is "finite" by default :))
20:06:01 <blingme> IMHO, just go bugzilla, option B, related projects can do whatever they like
20:06:26 <blingme> use mageia bugzilla to track their bugs if they want, or not
20:06:43 <ahmad78> (just don't make the "Components" in bugzilla too complicated or too many)
20:06:54 <rda> blingme: ok with me provided that there is no block to add further mageia-hosted projects (not necessarily strictly related to the distribution that is)
20:07:08 <blingme> I would prefer us to spend effort improving inter-distro bug tracking than just use launchpad
20:07:09 <dmorgan> blingme: yes B  for me is acceptable too
20:07:11 <rda> ahmad78: have a look at https://bugzilla.mozilla.org/query.cgi?format=advanced that manages to
20:07:39 <blingme> and AFAIK all the other rpm-based distros use bugzilla
20:08:05 <dmorgan> blingme: + a lot of important upstream projects
20:08:17 <blingme> well, RH/Fedora, Meego, OpenSUSE?
20:08:43 <dmorgan> kernel gnome kde freedesktop
20:08:52 <ahmad78> rda: yes, but I'd still want them to be as few as can be (anyway any "unused" Components will die peacefully)
20:09:50 <rda> ahmad78: I understand that, but if list of products/components grow, it should be corelated with a growing community of contributors
20:09:58 <rda> ok, so. misc ?
20:10:08 <ahmad78> rda: yes
20:10:37 <ennael> ok so looks like B solution seems to fit most of people here ?
20:10:59 * jq agrees with b
20:11:09 * wobo agrees with b
20:11:47 <dmorgan> misc: so ?
20:11:50 <ahmad78> as I said, I am OK with b (or c), one bugzilla various componenets/classification
20:12:12 * tmb agrees with b
20:12:38 * coincoin agrees with C (so B)
20:12:57 <rda> ok, so.
20:13:34 <dmorgan> next topic ?
20:13:46 <rda> #info bugzilla is the candidate of choice, although it has shortcomings (closing a bug on cooker, not tracking it for a backport fix)
20:14:10 <rda> #info bugzilla would be used to host distribution, packaging bugs/requests as well as mageia infrastructure, web services and app bugs/requests
20:14:14 <ennael> who is doing what on installing and configuriong it?
20:14:22 <ennael> same thing for wiki
20:14:25 <dmorgan> ennael: bugzilla is installed
20:14:35 <rda> ennael: I can see for the wiki and delegate this through the webteam
20:14:53 <rda> dmorgan: you look into this with other sysadm then?
20:14:57 <dmorgan> ennael: i need to look for ldap integration or if someone wants to look i can provide in private the admin pass
20:15:42 <Anssi> I'll have to leave now, but I'll read the backlog ->
20:16:05 <rda> Anssi: ok, thanks!
20:16:23 <ahmad78> (same for me, sorry :/)
20:17:17 <dmorgan> i leave too
20:17:41 <wobo> Any topic left?
20:17:43 <rda> #info dmorgan leads for the bugzilla setup
20:17:56 <rda> wobo: yes a few
20:18:06 <rda> #info rda checks with webteam about mediawiki investigations
20:18:28 <rda> ok, next topic?
20:18:33 <ennael> yep
20:18:36 <rda> or shall we postpone it?
20:18:41 <ennael> #topic Open Invention Network proposal to join
20:18:44 <rda> oh yes
20:18:55 <rda> ennael: your turn then :)
20:19:00 <ennael> ok
20:19:10 <ennael> so we received an email end of last week
20:19:31 <rda> http://www.openinventionnetwork.com/
20:19:33 <ennael> to join this network as many other open source companies and projects
20:20:01 <ennael> so we have to decide what to answer
20:21:22 <rda> (yes or no and why)
20:21:31 <ennael> yep
20:22:15 <tmb> is it free ?
20:22:23 <ennael> yes :)
20:22:45 <jq> are there any drawbacks?
20:22:58 <blingme> but, if we have some amazing invention, which would have led to world domination, we have to share it with Red Hat ?
20:23:04 <boklm> we don't have any patents, so I don't see any drawbacks
20:23:30 <ennael> blingme: good question :)
20:23:37 <rda> blingme: if it's related to linux only
20:23:42 <rda> http://openinventionnetwork.com/pat_license.php
20:23:48 <jq> blingme: it's only about patents
20:23:53 <rda> (full text: http://openinventionnetwork.com/pat_license_agreement.php )
20:24:16 <jq> what do you promise by joining, except sharing your patent pool?
20:24:56 <ennael> nothing else for what I've seen
20:25:21 <rda> (and provided the list of licensees, their legal team would have debunked st if there was) not a real argument, still...
20:25:35 <jq> you promise to vote for rms if he presents as us president. :-)
20:25:44 <ennael> :)
20:25:54 <jq> ok, i don't see why we wouldn't join
20:25:57 <wobo> Other question: what does it give to us?
20:26:00 * jq votes for joinin
20:26:02 <jq> g
20:26:12 <jq> wobo: patent license
20:26:18 <boklm> "All OIN patents and applications for all products"
20:26:48 <boklm> short version is on http://www.openinventionnetwork.com/pat_license.php
20:27:07 * jq has to go - will read backlog
20:27:17 <wobo> Dumb question # 19,349: What do we need patents for?
20:27:19 <blingme> I see no reason not to join, but afaik there still isn't necessarily such a big benefit (see Oracle/Google case about Java/Dalvik)
20:27:44 <rda> wobo: it's more in a defensive stance, in what it concerns us
20:27:56 <rda> (in my view)
20:28:13 <rda> seeing these http://openinventionnetwork.com/licensees.php
20:28:16 <wobo> Meaning they would help us if anybodfy sues us about patents?
20:30:01 <rda> wobo: that would make sense, but they don't put it that way. see http://openinventionnetwork.com/about_faq.php last question
20:30:31 <rda> "make sense" : using their patents (or OIN pool of patents) against an entity attacking a OIN licensee
20:30:38 <rda> but we can ask
20:31:03 <wobo> So it's more like a "grouping many to make a point against greedy patent owners"
20:31:34 <rda> first OIN goal seems more "let's not call us names, let's be gentle and make a pool of ideas we openly share, provided we don't fight"
20:31:39 <rda> wobo: that would be second I guess
20:32:04 <wobo> rda: ok.
20:32:14 * wobo votes joinin
20:32:57 <ennael> same thing for me... cannot hurt anyway
20:33:04 <rda> same for me
20:33:06 <coincoin> same for me
20:33:12 <boklm> same for me
20:33:20 <tmb> yeah, lets join
20:33:37 <wobo> Although:
20:34:27 <wobo> Wouold it not be better to wait until the official structure is in place (Council, Board) and then do it from these authorities?
20:35:02 <wobo> pure formalism, sorry
20:35:32 <rda> I think we can do it from the founding board to go forward
20:36:07 <rda> given the pace (setting up/launching teams one by one), everything will be square and ready for the Fosdem. I'm not sure it will be before.
20:36:13 <rda> or long before.
20:36:22 <wobo> ok
20:36:47 <ennael> so can we say it's ok to join ?
20:37:47 <tmb> yeah
20:37:47 <wobo> Next! :)
20:38:14 <rda> ennael: that makes 6 yes
20:38:27 <ennael> #info ok to join open invention network
20:38:40 <ennael> #action send an email to confirm this
20:38:49 * wobo counts 7 yes :)
20:39:08 <ennael> #topic data import from Mandriva resources
20:39:12 <ennael> rda: ?
20:41:20 <rda> wobo: it's late
20:41:22 <rda> ennael: yes
20:42:51 <rda> so
20:43:01 <rda> let me gather my notes...
20:43:25 <rda> yes, there are two main resources we may import
20:43:32 <rda> previous bugzilla and previous subversion
20:44:23 <rda> there's a specific provision under french law (at least) that gives specific rights to databases, without regarding to rights attached to what is in the db.
20:44:49 <wobo> OMG!
20:44:50 <rda> mdv bugzilla has no specific license (and actually, no bug tracker that I know)
20:45:07 <rda> moreover, bugs collection is not a fact from a single entity, but from the whole community
20:45:17 <rda> so the legal status is grey, from both sides
20:45:53 <rda> same goes for subversion, provided that it is not seen only as a mechanism to help execute terms of licenses related to what it contents
20:46:10 <boklm> maybe on mageia bugzilla, we could explicitly put a license ?
20:46:13 <rda> (and here again, most collections from subversion are the fact of the whole community and not from a single entity)
20:46:26 <rda> boklm: yes, definitely.
20:46:43 <rda> to make it clear that it's clear to be exported, and reused.
20:46:49 <boklm> yes
20:47:01 <rda> we are several to consult lawyers to discuss this deeper
20:47:28 <rda> I am confident anyway about the subversion, and quite as well about the bugzilla, but: that's me and that does not prevent to make a clear, informed statement about this.
20:47:32 <rda> so we need to dig further.
20:47:37 <wobo> is there an option to talk with Mandriva about this?
20:47:59 <rda> wobo: maybe but I would prefer not to at this time.
20:48:12 <blingme> hmm, inter-bugzilla features ....
20:49:00 <rda> blingme: that is?
20:50:07 <rda> boklm: I started this: http://mageia.org/wiki/doku.php?id=db_policy to complete once we know the ins and outs
20:50:28 <rda> aside from this .. issue, there are two questions:
20:50:53 <rda> - should we import the old bugs db, or start with a new one? (I believe it's been discussed here and there, don't remember if it has been decided)
20:51:16 <rda> - we need to filter out specific bits related to Mandriva from the subversion trees (copyrighted stuff without a license)
20:51:23 <rda> (like logo, artwork, icons)
20:51:29 <rda> and for this filter, how do we proceed?
20:52:01 <rda> ok, looks like I killed everyone
20:52:03 <boklm> also, we need to decide if we want to import svn history
20:52:11 <rda> boklm: yes, as well.
20:53:24 <rda> so, we have several things: legal stuff to sort out (will take ~2 weeks at most, 1 at best from now), and what do we import (bugs, svn), and how (history, no history, filter out before or after)?
20:53:25 <blingme> I don't see a good reason to import bugs
20:54:13 <rda> neither do I, provided qa.mandriva.com stays alive for some time
20:54:33 <blingme> if we do import bugs, would it make any sense to report unresolved bugs on old releases? or only open bugs on cooker?
20:54:48 <rda> (so may be a static copy of it could be useful, for doc purpose, just in case)
20:55:03 <boklm> blingme: old mandriva releases ?
20:55:25 <dmorgan> for bugreports i think this is an error to start with mdv bugreports because won't fit our products
20:55:47 * blingme off to bed, will read backlog or logs later
20:56:02 <wobo> dmorgan: It will, at least for the first relase
20:56:04 <rda> blingme: good night
20:57:33 <tmb> I'd say a static copy if any...
20:58:03 <ennael> ok can we summarize situation on bugzilla and svn
20:58:10 <ennael> summarize legal issues
20:58:21 <ennael> ask pros and cons for keeping or not
20:58:24 <wobo> As Mageia will be a "continued cooker" for the most part it may be good to import cooker bugs
20:58:27 <ennael> then we will decode
20:59:00 <ennael> decide
20:59:02 <wobo> ... and leave older mdv bugs where they belong
21:00:31 <rda> is there a xmlrpc export available? or csv?
21:00:44 <rda> a search query (may be huge) + a csv export?
21:01:11 <boklm> would that be easy to import with a csv ?
21:01:25 <rda> for bugzilla, anyway, I would vote for: stay from a clean state, link against mdv bugzilla if needed, make a static cache copy and so be it
21:01:35 * boklm agrees
21:02:51 <rda> for svn, I'd counter check the status, and when it's clear, prepare it, do it, filter
21:03:15 <boklm> I'm not sure filtering svn history is easy
21:03:26 <rda> ah, yes, history.
21:03:36 <rda> no, I was speaking about copyrighted contents in last revisions.
21:03:48 <rda> about history, I guess it will be relative to the status of the whole thing
21:04:05 <rda> apart from that, what would be the rationale to not keep the history?
21:04:50 <boklm> keeping history on spec files and sources would be nice
21:05:19 <boklm> but it would be nice also to get ride of binary files which take a lot of space
21:05:37 <boklm> and copyrighed content
21:05:45 <dmorgan> boklm: i would be nice to test repsys-bin this week
21:05:50 <boklm> dmorgan: yes
21:05:50 <rda> ok
21:05:58 <rda> so, we'll dig into this and come back to it later.
21:06:03 <rda> so it's over for this meeting.
21:06:04 <boklm> dmorgan: I will test tomorrow
21:06:05 <rda> any other question?;
21:06:25 <dmorgan> rda: i think we have done all
21:06:42 <rda> yep
21:06:49 <rda> so thanks a lot everyone
21:07:02 * wobo goes http://www.pizzahut.de/0_image/title_pizza.jpg
21:07:04 <rda> ennael: don't remember how to close the session?
21:07:10 <dmorgan> #endmeeting
21:07:13 <dmorgan> i think
21:07:15 <ennael> yep
21:07:15 <rda> #endmeeting
21:07:26 <rda> hmmm
21:07:31 <ennael> #endmeeting
21:07:38 <boklm> maybe misc has to do it
21:07:57 <rda> I thought we were chairs
21:08:06 <ennael> yep
21:08:23 <boklm> maybe only the one who started the meeting can close it
21:08:29 <rda> ha, maybe :)
21:08:39 <rda> we're bound to continue! /o\ :)
21:08:45 <coincoin> :)
21:08:53 <ennael> outch
21:08:57 <wobo> rda: no, the Chair command was not executed (aka confirmed by the bot), see at begining
21:09:02 <rda> ennael: come on, one random topic then? :)
21:09:10 <rda> wobo: argh
21:09:23 <boklm> so all the #info didn't work ?
21:09:48 <wobo> right
21:09:53 <rda> \o/
21:10:03 <ennael> argh
21:10:04 <rda> does Inigo_Montoya log the channel anyway?
21:10:04 <ennael> 20:06 < misc>  #chair ennael rda
21:10:06 <rtp> "< misc>  #chair ennael rda" <- looks like there's a space
21:10:13 <ennael> a space beginning
21:10:14 <ennael> :)
21:10:15 <rda> there is
21:10:22 <rda> what's a bot that can't trim? :)
21:10:34 <wobo> a non-trimming bot?
21:10:43 <rda> :)
21:14:01 <rda> ok, meeting closed anyway. thanks guys! good evening
21:14:09 <ennael> 'night
21:14:45 <wobo> good night all
21:15:00 <coincoin> and big bisous
21:15:16 <wobo> coincoin: ???
21:15:31 <ennael> wobo: big kisses he says
21:15:38 <ennael> and yes coincoin is a mad duck
21:16:00 <wobo> Ah, I forgot all those important words of my youth....
21:16:35 <coincoin> :)
21:16:59 <coincoin> wobo: big bisous is a french song (like ennael said: "big kisses") :)
21:32:57 <dmorgan> #endmeeting
22:32:33 <misc> #endmeeting