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