19:19:44 <Akien> #startmeeting
19:19:44 <Inigo_Montoya`> Meeting started Tue Sep 15 19:19:44 2015 UTC.  The chair is Akien. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:19:44 <Inigo_Montoya`> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:19:48 <Akien> #chair ennael
19:19:48 <Inigo_Montoya`> Current chairs: Akien ennael
19:20:13 <Akien> Welcome everyone to this packagers meeting! (first one of 2015? :p)
19:20:19 <rindolf> Hi all.
19:20:39 <anaselli> hi
19:20:44 <DavidWHodgins> Here to observe. :-)
19:20:53 * doktor5000__ lurks
19:21:00 <marja> :-)
19:21:14 <Akien> Now that the usual summer downtime is passed, we really need to build up some momentum in the team to work efficiently towards our next release, and try to do a better and funnier release cycle than for Mageia 5
19:21:33 <Akien> #topic Packagers meetings reloaded
19:22:19 <Akien> So we all know it, meetings can be boring, I just had two today at $dayjob plus council meeting yesterday, so I'm pretty tired right now - still, we really need to gather and discuss stuff the get the dev team better organised IMO
19:23:12 <Akien> We've discussed this with ennael and the idea would be to try to have packagers / devs meeting from time to time (we haven't discussed a schedule yet, not sure if we should enforce one or just do meetings when we need them)
19:24:05 <Akien> One idea that we had though would be to make part of the meetings like an informal seminar, where knowledgeable contributors would speak about a topic that could be relevant for everyone in the team
19:25:37 <Akien> e.g. we could have a topic about Luigi12's work regarding security, a topic about docker, about the java stack, etc.
19:26:46 <Akien> Not sure about which specific topics would be relevant yet, but we thought this format could help share knowledge and bring some momentum
19:27:14 <Akien> Meetings would then probably partly about the day's theme, and partly regular packager meeting where we would discuss the current packaging topics
19:27:35 <Akien> WDYT about this, and do you have other ideas regarding meetings?
19:27:56 <Stormi> Via IRC or spoken channels such as mumble? IRC can be slow (although easier to understand)
19:27:58 <DavidWHodgins> The primary cause of the delay of Mageia 5 was getting the installer to work with various uefi firmware. We need to have more packagers learn how to fix installer problems.
19:28:26 <Akien> DavidWHodgins: Indeed, that's a topic further down today's agenda ;)
19:28:46 <Stormi> and an interesting subject for sharing knowledge
19:29:29 <Akien> I think IRC would fit most contributors, even though we know that everyone does other stuff while attending an IRC meeting :)
19:29:30 <marja> Akien: are those topics only intended for full packagers, or also for apprentices?
19:29:47 <Akien> marja: Also for apprentices, and probably also for curious non-packagers
19:29:54 <marja> nice :-)
19:30:13 <Stormi> I think we could use real talks with slides, ability to show your screen and voice
19:30:31 <Akien> Like TEXxMageia? :)
19:30:32 <Stormi> a kind of webex meeting
19:30:45 <Stormi> but probably separated from actual meetings
19:31:12 <Stormi> I like the idea but see it more separated, except for small subjects that can fit in 15 minutes on IRC
19:31:35 <Akien> Yeah that could be an idea, if we have contributors who would be willing to prepare this kind of talks, it could be great
19:32:06 <ennael> I'm very sorry. My train was 1h late tonight...
19:32:20 <doktor5000__> \o/ ennael is there
19:32:35 <Akien> ennael: No problem, we just started
19:32:42 <ennael> ok :)
19:32:42 <marja> ennael: ouch, glad you made it now!
19:32:43 <ennael> hi all
19:33:19 <anaselli> Akien: let's say we could have both, since packager meetings are more important when we have to fix bug in the final rush... some e-learning corses could be performed during the first phase
19:33:27 <anaselli> hi ennael :)
19:33:37 <pasmatt> hi all
19:34:24 <marja> pasmatt: :-)
19:34:47 <anaselli> what a beautiful day! :D
19:34:48 <marja> anaselli: that makes sense
19:34:55 <rindolf> ennael: hi.
19:34:59 <rindolf> pasmatt: hi.
19:35:19 <marja> anaselli: that, too, but I meant the courses at the beginning of the release cycly, not at the end
19:35:32 <marja> s/cly/cle/
19:35:41 <Akien> anaselli: That's true, though the idea right now is to get us started on the right track.
19:35:42 <anaselli> marja: that is my idea too :)
19:36:11 <anaselli> i mean we could have some meetings anyway to make the point of the situation
19:36:15 <marja> anaselli: yeah, it was your idea, I picked it up :-)
19:36:35 <Akien> One of the issues with Mageia 5 is that we had very little feature proposals documented, and very little coordination, so there was little work done generally speaking until the beta. Then most of us just had to wait on UEFI support to be implemented and debugged, so that was long.
19:36:41 <anaselli> but learning that new feature or that change during the first phase it could help later
19:37:09 <Akien> anaselli: So we do need meetings and discussions now to better define what we want to work on in the coming months.
19:37:21 <anaselli> Akien: sure
19:37:23 <doktor5000__> maybe the packaging seminar videos that Malo did IIRC for mentoring should be put in a more prominent place?
19:37:31 <Akien> If we have precise objective, we'll likely be more efficient and have more fun doing it :)
19:37:36 <anaselli> it's a possible way to... not a must ;)
19:37:56 <Akien> doktor5000__: Yes, we should probably review the whole packaging documentation
19:38:12 <Oro_Valley> I agree on that one
19:38:14 <marja> it is a pity malo never got around to redoing them (as he intended to do, to remove unneeded pauses etc.)
19:38:15 <anaselli> Akien: anyway i was very busy with manatools during the UEFI waiting time though.... :p
19:38:28 <DavidWHodgins> Other than the change to kde5-plasma, I'm not expecting any other big changes in Mageia 6.
19:38:38 <doktor5000__> Akien: and maybe for mga6 it would be a good idea to finish some polishing and work on features that haven't been implemented yet, but were proposed
19:39:03 <Stormi> I had polishing in mind but I kept it for me because it's not a "feature" :)
19:39:08 <Akien> doktor5000__: Indeed
19:39:10 <Stormi> so +1
19:39:25 <doktor5000__> Stormi: yep, being polished is a feature 11
19:39:29 <doktor5000__> ^^
19:39:56 <marja> who is being polished? :-)
19:40:12 <Akien> DavidWHodgins: That would be a motivational problem though. For Mageia 5 it was "apart from UEFI support, nothing new", and it felt pretty poor IMO. In the end we made a great release with tons of bug fixes, but we also need fancy new features to work on :)
19:40:16 <doktor5000__> marja: Mageia 6 - hopefully :)
19:40:25 <marja> doktor5000__: I was trolling ;-)
19:40:34 <anaselli> marja: i'd say pasmatt: he's just come back home :p
19:40:47 <DavidWHodgins> Akien: I don't agree on any need for fancy new features.
19:40:48 <marja> anaselli: :-)
19:41:19 <Akien> DavidWHodgins: Not a need per se for users, but IMO a need for packagers and developers to keep their motivation
19:41:43 <doktor5000__> Akien: well there would be some new "features", like kf5 integration, samba4, maybe networkmanager instead of net_applet, systemd in installer ...
19:42:02 <Akien> doktor5000__: That's already quite good yeah.
19:43:30 <Akien> Anyway, I guess for the current topic ("more packagers meetings") we have a general consensus that having meetings every now and then could be good, and that thematic presentations could be interested (form to be defined)?
19:43:55 <marja> yep
19:43:58 <Stormi> And meeting summaries sent to the list?
19:44:19 <anaselli> i hope so Stormi
19:44:25 <anaselli> to have more followers
19:44:35 <anaselli> or potential
19:44:45 <Akien> Indeed, it would be nice if we had a volunteer at each meeting that would quickly sum up the meeting minutes in a friendly format that MeetBot's
19:44:45 <Stormi> Who wants to do tonight's one?
19:44:51 <Akien> s/that/than/
19:45:02 <Akien> A plain text email that people might be tempted to read :p
19:45:18 <Stormi> With no need to click a link to get the information
19:46:07 <anaselli> Ah ops, i misunderstood the point :/
19:46:22 <Akien> Looks like anaselli volunteered :p
19:46:29 <anaselli> I thinkt that is not easily feasable
19:46:40 <ennael> do we really need this? looks to me to be a waste of time...
19:46:47 <anaselli> for me too
19:46:55 <ennael> people not reading meetbot will likely not read mails
19:46:56 <Stormi> Does everyone here read meeting logs?
19:47:04 <Akien> ennael: Not true IMO
19:47:11 <pasmatt> I think that's good to put a summary inside a plain/text email but let people click the links to the meetbot log, it's less time expensive
19:47:11 <Stormi> I for sure would read mails more eagerly than meetbot
19:47:15 <anaselli> just set the right Meebot keys and we should have a summary
19:47:16 <Akien> I read all mailing lists, I almost never check minutes of meetings I did not attend
19:47:19 <ennael> Akien: was just my pov
19:47:23 <Stormi> meetbot doesn't tell me much, I end up reading full logs if motivated
19:47:27 <Stormi> same as Akien
19:47:43 <anaselli> indeed
19:47:43 <Stormi> I volunteer for this meeting
19:47:50 <Stormi> let's move forward
19:48:09 <anaselli> but if you are motivated... and reading a short log could motivate or not you...
19:48:12 <Akien> Yeah we can decide afterwards if the summary was useful or if Samuel lost 20 minutes of his time
19:48:25 <anaselli> :)
19:48:35 <Akien> #topic Initialize a development group about all the tools included in the distribution (basically drakx*)
19:49:17 <Akien> So this topic is about awaking the "dev" in dev team
19:49:29 <Stormi> (note: the one redacting the summary gets to influence people, if smart enough:))
19:49:47 <marja> lol
19:49:52 <pasmatt> :)
19:49:55 <anaselli> :D
19:50:43 <Akien> As you know, we have a good deal of home-grown tools (typically the drakx* stuff) that we are relatively proud of, and advertise everywhere as one of the things that makes Mageia so great
19:51:33 <Akien> It's partly true, but it's also true that our drakx* tools are mostly maintained by tv, and apart from some exceptions, don't get as much attention as would be expected of a real upstream
19:51:52 <anaselli> hi lousab :)
19:51:59 <Akien> The idea is then to become this "upstream" and have more contributors directly involved in developing these tools
19:52:26 <Akien> For this we need at least two things:
19:53:08 <Akien> - A way to review code before it's merged into our repos, so that people could more easily contribute patches and have them reviewed by our few drakx* experts
19:53:44 <anaselli> something like a pull request on github...
19:53:58 <Akien> - A way to share the knowledge between our "drakx* experts" and the other contributors who could be interested in contributing but don't know where to start
19:54:01 <Akien> anaselli: Indeed
19:54:49 <Akien> For the first point, I think neoclust is having a look at reviewboard, a nice tool which does exactly what we'd need
19:54:54 <Akien> See e.g. KDE's reviewboard: https://git.reviewboard.kde.org/r/125136/
19:54:55 <[mbot> [ Add an interface which allow plugin to show custom overlay icons | Review Request | Review Board ]
19:55:14 <DavidWHodgins> Have I mentioned "I hate trying to read perl!" Would prefer to see things rewritten in python or C.
19:55:31 <Akien> If we could have a tool like that on top of our git repos, this might help a lot
19:55:35 <anaselli> Akien: i think we have two issues in our tools
19:55:38 <anaselli> perl and gtk
19:55:58 <Stormi> gerrit is good too (not pretty, but good at its job), and gitlab not bad
19:56:21 <Stormi> but to be honest, although I'm not a github fanboy, I would use github
19:56:41 <anaselli> I mean before thinking to reviewing patches, we *need* to have contributors who produce them...
19:56:48 <pasmatt> anaselli: not perl itself, imho
19:57:06 <anaselli> i think pasmatt most scare perl
19:57:32 <Akien> anaselli: But the assumption is that we don't have contributors who produce patches because it's a PITA to get patches upstreamed, when our only way to get patches reviewed is to harass tv in a bugzilla bug report
19:57:35 <anaselli> i have experienced two possible contributors giving up...
19:58:07 <Akien> If we have a user-friendly way that lets any interested contributor review (or just read) what other contributors are doing, it could help IMO
19:58:12 <anaselli> Akien: moreover if he considers them
19:58:20 <pasmatt> DavidWHodgins: it's not hard to read perl if the code is written properly (I mean using modern perl and putting inside explicative comments)
19:58:34 <anaselli> pasmatt: agreed :)
19:58:46 <Akien> I learn C++ just by reviewing pull requests on GitHub, I'm pretty sure I could learn perl the same way. But currently I don't have the motivation to just read all single commit that gets pushed on git.mageia.org without context
19:59:07 <anaselli> Akien: yes but if we have contributors that can push them also
19:59:13 <anaselli> so internal ones
19:59:22 <DavidWHodgins> I find the drakx tools very hard to figure out what they are doing, or trying to do.
19:59:37 <Akien> anaselli: Of course, that would be the point.
19:59:58 <pasmatt> DavidWHodgins: yes, of course
20:00:18 <Stormi> Code documentation would help a lot, I mean, a written introduction to code organization and conventions in our tools
20:00:18 <anaselli> DavidWHodgins: if you look at what AL13N is doing on manatools, you could see a better way to write our tools in perl
20:00:33 <Stormi> That's the kind of thing I would want to read before trying to contribute anything
20:00:36 <Akien> anaselli: That's also the purpose of my second point: share the knowledge. If our tools were better documented (and maybe we can manage to start a documentation effort) and written in easy to read perl, it would be easier to contribute too.
20:00:37 <marja> DavidWHodgins: I underdstood some of the code was cleaned when ported to manatools, maybe manatools code is a bit easier to understand
20:00:43 <DavidWHodgins> The gui part's are good, but the underlying code is very hard to deciver.
20:01:12 <anaselli> Akien: that what i meant with who produce pathces... first the ones that are in than the occasional contributors...
20:01:20 <pasmatt> DavidWHodgins: and you can compare current drakxtools to manatools
20:01:39 <anaselli> Akien: very true (knowledge point i mean)
20:02:05 <anaselli> And that is what pasmatt, AL13N and I are trying to do...
20:02:19 <DavidWHodgins> s /deciver/decipher/
20:02:44 <DavidWHodgins> I haven't looked at manatools yet.
20:02:55 <pasmatt> DavidWHodgins: we managed to port the every working piece of code inside drak* inside mana* using modern perl, properly commenting the more complex methods/subroutines
20:03:23 <pasmatt> DavidWHodgins: errata, we're still porting stuff and it's a quite a job :)
20:04:00 <pasmatt> AL13N , he is also doing a great job on manatools
20:04:41 <anaselli> so Akien ithink we should consider this people also for reviewers
20:05:20 <anaselli> even if i don't want to be promoted as one :p
20:05:28 <Akien> anaselli: Well I think every packager/dev should be reviewer. It's already the case: any one of can merge code into git.
20:05:49 <Akien> We just all fear to be grabbed by tv afterwards and shown our mistakes :p
20:05:50 <anaselli> Akien: yes!
20:06:00 <anaselli> and yes :)
20:06:03 <marja> :-)
20:06:09 <pasmatt> :)
20:06:12 <Oro_Valley> yes
20:06:21 <DavidWHodgins> lol
20:06:25 <Akien> If we have 2 non-tv developer reviewing a patch, we can merge it after a reasonable amount of time to let more experienced drakx* gurus tell them we're breaking everything
20:06:26 <Stormi> You say that with humour but it's actually scary for now contributers and even some old ones
20:06:36 <Stormi> s/now/new/
20:07:30 <Akien> Stormi: Yes, that's way a review system could help put some pressure off tv's shoulders too. Since he's THE reviewer, we are too often waiting for his approval when other contributors could check that it's good perl code, and that it seems to do what it has been designed for.
20:07:39 <Akien> We can workaround this bottleneck by working together.
20:07:59 <Stormi> A review system is a must-have
20:08:02 <Akien> A corollary being that we need very good documentation on how to _test_ changes to each drakx* tool
20:08:10 <Stormi> you can publish draft and ask for comments
20:08:45 <Akien> And that could also be a topic for workshop/seminar meeting, "How to test a patch using drakx-in-chroot" for example
20:08:47 <anaselli> Akien: that's not easy.... you can if you know well what they do and in which context they work
20:09:03 <anaselli> i mean both installer and gui tools for instance
20:09:03 <Stormi> well, reviewing code also helps understanding it
20:09:10 <anaselli> Stormi: yes
20:09:36 <anaselli> but i could say that in my experienced i tested a fixing a lot and worked very well
20:09:41 <Stormi> it costs nothing to say "it looks ok to me but I'll let tv / blino / pterjan / tmb approve"
20:09:41 <anaselli> but failed in installer
20:09:41 <Akien> Once we have a review system, I guess the first time should be to document the code (with the help of people who already know the code well if they're willing)
20:10:03 <Stormi> I agree with that
20:10:10 <Akien> s/time/task/
20:10:20 <anaselli> Akien: e.g. tv :p
20:10:50 <anaselli> i mostly studied the "standalone" part
20:10:50 <Akien> anaselli: He's actually pretty good at explaining stuff when he has the time, so he'd probably take part in the effort
20:11:10 <anaselli> Akien: i do hope so...
20:11:15 <Oro_Valley> and he was so busy fixing packages after upgrading rpm shortly before release
20:11:38 <Akien> Note that we also have "simpler" tools in python like msec or mgarepo, and those would also greatly benefit for a review system
20:11:41 <marja> Akien: about documenting the code, I think it is better to put your hopes and everyone's energy on and into manatools
20:11:50 <pasmatt> Stormi: yes, reviewing code helps understanding (as I've done for rpmdrake) and then you discover how old is that code and how cryptically it has been written
20:12:18 <DavidWHodgins> pasmatt: Agreed!
20:12:56 <pasmatt> do not scare newcomers with that stuff (even if it works!) and try focus them on something modern and exciting for the times being, pls
20:13:36 <pasmatt> brb
20:14:08 <DavidWHodgins> Give me a program written in python, C, or even asm, when a problem is found, I can usually figure out what needs to be fixed and let the packager know. With perl, I can't decipher it.
20:14:16 * anaselli has not paied marja :)
20:14:31 <marja> anaselli: ??
20:14:35 <pasmatt> marja: agreed
20:14:59 <anaselli> "<marja> Akien: about documenting the code, I think it is better to put your hopes and everyone's energy on and into manatools"
20:15:01 <anaselli> :)
20:15:04 <anaselli> paid
20:15:16 <marja> anaselli: :-)
20:15:34 <anaselli> DavidWHodgins: i've learnt perl in these two/tree years i started working on manatools
20:15:43 <Stormi> Well, drakxtools or manatools, it doesn't prevent from putting review into place
20:15:44 <pasmatt> marja: porting code from drak* allows people to better understand how it works and -at the same time- brings new energy (ideas) inside manatools (or everything new inside our distribution)
20:15:51 <anaselli> just reading and studying it
20:16:05 <DavidWHodgins> Is manatools written in perl too?
20:16:06 <Stormi> until manatools is the main tool, we still need to fix bugs
20:16:10 <anaselli> Stormi: true, the point is in the team
20:16:11 <pasmatt> marja: sorry, my last message was for everyone not just for you :)
20:16:12 <Stormi> and review the fixes
20:16:26 <marja> pasmatt: np ;-)
20:16:48 <marja> DavidWHodgins: yes, it's perl
20:16:57 <Stormi> so IIRC Akien wanted to address two topics, reviewing and documenting
20:16:59 <pasmatt> DavidWHodgins: yes, modernperl using Moose (for OOP) and it's written using English module as suggested by Guillame long time ago
20:17:00 <DavidWHodgins> Argh!
20:17:01 <pasmatt> iirc
20:17:01 <anaselli> DavidWHodgins: is perl yes, it was meant to catch more mageia developers... continuty
20:17:02 <marja> DavidWHodgins: that is, perl stays perl
20:17:03 <Stormi> we all agree about code review
20:17:04 <philippem> hi sorry , I'm late
20:17:22 <marja> philippem: welcome
20:17:26 <ennael> I've asked neoclust to check about reviewboard
20:17:27 <Akien> I guess we should do the manatools vs drakxtools another time, else it will take all the night :)
20:17:36 <Stormi> and documentation too although theres not a consensus about whether to spent time documenting drakxtools or rather manatoos
20:17:37 <ennael> it's a code review tool used by KDE
20:17:37 <Stormi> tools
20:17:43 <ennael> easy enough to use
20:17:52 <anaselli> Akien: :)
20:18:00 <ennael> still it needs to have up to date server which will be done in coming weeks
20:18:00 <Stormi> I'd propose to first document the installer
20:18:06 <Akien> As Stormi says, we have a consensus that we _need_ reviewing tools; whether it's to put the focus on drakx on manatools, that can (and _should_) be discussed later on.
20:18:36 <anaselli> Akien: i say both
20:18:57 <marja> Akien: reviewing for both
20:18:58 <Luigi12_work> DavidWHodgins: the yui stuff supports other languages like python, so right now they're just porting existing perl stuff to perl, but things can be rewritten in python later
20:19:02 <pasmatt> reviewing tools are more than welcome :)
20:19:06 <philippem> reviewboard is a nightmare to package
20:19:07 <Akien> marja: Yes reviewing should be for everything
20:19:20 <anaselli> Luigi12_work: yes that's true
20:19:43 <pasmatt> Luigi12_work: exactly, we have a small module written in python - contribfinder.py - iirc
20:19:47 <marja> Akien: the only reason I said focus on manatools for documenting the code, is that there is little chance that tv can do much
20:19:52 <DavidWHodgins> I find procedural languages much easier to debug than object oriented languages.
20:20:10 <anaselli> pasmatt: and the papoter one also
20:20:19 <pasmatt> oh yes, definitely
20:20:40 <Luigi12_work> doing user interfaces without OOP is extremely difficult
20:20:59 <Stormi> let's not turn this meeting in OOP vs procedural :)
20:21:03 <Akien> Hehe
20:21:06 <Akien> Yeah let's move on
20:21:10 <DavidWHodgins> :-)
20:21:16 <DavidWHodgins> Yep
20:21:26 <Stormi> So sysadmins have a look at reviewboard and will report later?
20:21:29 <Stormi> Any ETA
20:21:31 <Stormi> ?
20:21:40 <Akien> At least we've seen that there is still a real interest in working on our tools, so that's a good point. Now we need the infra.
20:21:43 <ennael> as said before it needs up to date server
20:21:57 <anaselli> Stormi: as far as i know coling told me we have a kind of pull request already though....
20:22:01 <ennael> so buy new hardware, install and migrate it
20:22:40 <anaselli> Akien: :D
20:22:52 <DavidWHodgins> Getting new hardware installed and configured should be a top priority. We have the money.
20:23:56 <Akien> #topic Relaunch mentoring and check people who need help
20:24:19 <Akien> Some now something that does not need new infra :D
20:24:46 <Stormi> yeah, just new victims
20:24:51 <marja> lol
20:25:01 <Akien> Malo did an awesome work on putting momentum in the mentoring program, but since he's less available, things have been relatively quiet
20:25:01 <ennael> do we have a clear view of the current trainees ?
20:25:13 * marja hides
20:25:18 <Akien> We do have ysoft who graduated recently though :)
20:25:35 <marja> he learned very fast :-)
20:25:35 <Luigi12_work> most awesome apprentice ever
20:25:51 <Akien> Yeah he was really skilled from the start though :p
20:26:48 <Akien> Here's our list of apprenticeships in progress, probably not 100% up to date: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Apprenticeship_in_progress
20:27:48 <Stormi> not up to date, Akien is still listed in it :)
20:27:51 <marja> is the wiki slow, or is it me?
20:27:59 <Akien> marja: slow indeed
20:28:11 <Akien> Stormi: Yeah but the "Graduation email" column means full packager :)
20:28:38 <Akien> Should probably be cleaned up, it does not add much clarity
20:29:14 <Akien> I'll try to contact all apprentice/maintainer pairs to know if they are still willing to become packagers, and update the list accordingly
20:29:15 <DavidWHodgins> wiki is working fine here. A little slow, but not bad.
20:30:02 <Akien> Now, we need idea to make the mentoring more appealing/easier
20:30:24 <Akien> We did talk about updating the wiki documentation, that's definitely something that needs doing
20:30:42 <philippem> about mentoring and webmeeting, seems that https://jitsi.org/ is a good solution
20:30:43 <[mbot> [ jitsi.org | Jitsi ]
20:30:52 <marja> Akien: first of all, our documentation should be cleaned out, it is outright confusing
20:30:52 <zezinho> The mentoring is good, main problem is apprentices that nobody answers
20:31:17 <Oro_Valley> A lot depends again on people like TV, they know the insides
20:31:42 <Akien> Oro_Valley: For mentoring?
20:31:57 <Akien> Ah you mean for the documentation
20:31:57 <Oro_Valley> for updating the WIKI
20:32:18 <Akien> Well we have some pretty good packagers who could help with that
20:32:42 <Akien> But the problem is not so much the technical documentation about very advanced features, but more the way things are organised
20:33:30 <Akien> I remember having to give links to 3, 4 or 5 different wiki pages to apprentice packagers, telling them to read that as the basic doc
20:33:59 <Akien> But many pages speak about similar stuff, it's kind of hard to really know where to start IMO
20:34:19 <Oro_Valley> rpm macros are another things are are pretty hidden
20:34:46 <Stormi> and rpmlint messages and their signification
20:35:01 <marja> and I'm not sure everything is true for Mageia in some pages
20:35:02 <anaselli> Akien: for this point i'd prefer to stay on the developer part, i cannot afford both devel and package mentoring
20:35:22 <anaselli> but i'm often around when needed ;)
20:37:12 <Stormi> so
20:37:13 <Akien> Apart from technical documentation, I think we need to make sure that the mentoring packages put a very strong focus on the other tasks of a packager that are not only writing spec files : fixing bugs (especially security vulnerabilities), triaging bugs, discussing changes on the ML, etc.
20:37:20 <Akien> *puts
20:37:30 <Akien> s/*puts//
20:37:42 <Akien> s/packages/pages/
20:37:45 <Akien> Ok sorry I'm getting tired :p
20:37:56 <ennael> we spoke about having typical process to become packager some months ago with malo
20:37:59 <marja> Akien: np, we all are ;-)
20:38:07 <Stormi> the steps already help in this regard, and the mentoring guide already tells that, we just mustn't forget
20:38:42 <ennael> process including fixing bugs, QA tasks and then apckaging
20:41:36 <Stormi> I think everyone agrees. Do we list actions and volunteers for these actions?
20:42:52 <Akien> We should, but I admit I'm too tired to think straight about what should be assigned.
20:43:08 <ennael> update current list
20:43:15 <ennael> contact trainees and mentors
20:43:20 <Akien> Yep, that's for me.
20:43:36 <ennael> maybe propose some questions about thier needs
20:43:38 <Akien> #action Akien updates the apprentice list, contacts trainees and mentors
20:44:53 <Akien> #info Wiki documentation about packaging and mentoring needs to be reviewed and improved, especially to make it clearer and better organised
20:45:18 <Oro_Valley> I' try to start a page about rpm macros.
20:45:46 <Akien> Oro_Valley: Regarding the most technical stuff like new RPM features, we should probably remove our oudated documentation and point directly to Fedora's
20:46:19 <Oro_Valley> Akien: We are still far away from Fedora
20:46:38 <Oro_Valley> I see that when I use a spec from Fedora
20:47:05 <Stormi> specs from Fedora are sometimes far away from the latest fedora guidelines :)
20:47:14 <Akien> Well Fedora specs are often pretty hideous
20:47:26 <Akien> But for autoreq/autoprov for examples, we can use their doc
20:47:56 <Oro_Valley> Opensuse has a nice tables of existing rpm macros
20:48:04 <Stormi> and of rpmlint messages
20:48:17 <Stormi> at least it used to be my reference for that
20:49:45 <barjac> Oro_Valley:  Pharaoh_Atem mentioned a page the other day that compared SUSE/Fedora rpm macros and suggested that we add ours to it
20:50:16 <Oro_Valley> I am not gainst that
20:50:24 <Oro_Valley> What is the page?
20:50:43 <barjac> Oro_Valley: I'll need to searh hexchat logs
20:50:47 <Oro_Valley> Seems to be a good idea
20:52:00 <Akien> Ok, we have still a couple subjects to discuss but I think the meeting was already long enough
20:53:01 <Akien> The Mageia 6 specification topic is quite important (we have only 2 feature proposals so far...), but I'll send an email about it tomorrow to try to get things better documented and discussed
20:53:33 <marja> barjac: is it this page: http://rpm.org/wiki/Problems/Distributions
20:53:37 <marja> ?
20:54:38 <marja> ah, probably: 2015:09:08:23:46< Pharaoh_Atem> you know, I kind of wish someone would fill in how Mageia does things on http://rpm.org/wiki/Problems/Distributions vs Fedora and SUSE
20:55:08 <Akien> Anybody against ending the meeting now? :)
20:55:10 <barjac> marja: Yes - thanks :)
20:55:20 <marja> Akien: please end it :-)
20:55:26 <marja> barjac: yw
20:55:28 <zezinho> bye
20:55:33 <Akien> Then thanks everyone for attending :)
20:55:37 <Akien> #stopmeeting
20:55:41 <Akien> #endmeeting