19:10:49 <ennael> #startmeeting
19:10:49 <Inigo_Montoya> Meeting started Tue Sep 17 19:10:49 2013 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:10:49 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:10:59 <ennael> hi all and thanks for attending tonight
19:12:11 <rindolf> The /topic should be set.
19:12:18 <ennael> so 2 subjects for now, features and adoption campaign for unmaintained packages
19:12:33 <ennael> #topic Mageia4 features review
19:14:22 <ennael> as a reminder https://wiki.mageia.org/en/FeatureMageia4_Review
19:14:30 <ennael> arf
19:14:39 <ennael> he is already tired :)
19:15:34 <ennael> we have an answer from philippem about Python features
19:16:38 <ennael> do we have other contributors around about these features ?
19:17:25 <sander85> seems we don't
19:18:33 <ennael> coling: ?
19:18:51 <coling> Yup?
19:19:01 * coling has no python features.
19:19:11 <ennael> ahah :)
19:19:17 <coling> Or do you just mean generally :)
19:19:23 <ennael> generally :)
19:19:32 <ennael> a quick review on what is in progress
19:20:14 <coling> OK, so other than initial disapproval and issues the network interface names seem to be mostly OK, but needs some more work in installer+drak* to cope fully.
19:21:11 <coling> Separately, I've made a good start with the usermode-consolehelper -> polkit conversion in drak* tools.
19:21:51 <coling> Still have a bit to do there with some of the tools, but it's pretty defined as a process now - still need to work out how to do i18n on the policy files nicely tho'
19:22:03 <coling> There is also the question of msec settings to control the policies.
19:22:07 <ennael> great to hear
19:22:33 <coling> (it turns out I was unaware, but msec would adjust the pam.d and /etc/security/console.apps/ files based on it's own settings.
19:23:11 <coling> So help with this area in particular would be nice. msec is likely suffering in other areas from lack of maintenance these days :(
19:23:24 <ennael> yep indeed
19:23:29 * coling might have some python features after all it seems....
19:23:33 <coling> (msec is python right?)
19:23:47 <ennael> #info coling needs some help with msec (people knowing msec and/or python)
19:24:00 <Luigi12_work> not sure msec has anything to do with it, it's draksec that controls those settings
19:24:35 <Luigi12_work> or something, maybe drakauth
19:24:51 <coling> Oh OK, I wasn't really aware of the difference.
19:25:01 <philippem> so that's Perl as usual I guess ;)
19:25:02 * coling hadn't poked in any depth yet
19:25:09 <Luigi12_work> yeah there's two drak tools for security stuff, one for Mageia tools and one for msec
19:25:15 * coling is equally rubbish with perl and python
19:25:29 <ennael> blino: around by chance?
19:25:29 <AL13N> i have a feature too... it's likely not alot of work, and i was nearly there in the past, but my VM was rebooting when i pressed refresh for diskdrake...
19:25:43 <AL13N> i kinda need help with someone who knows about diskdrake
19:26:12 <Luigi12_work> yeah draksec is the one for the Mageia tools
19:26:24 <coling> OK, so it's still ultimately on my radar anyway.
19:26:55 <adamw> AL13N: i've been on vacation.
19:27:53 <coling> Moving on, I've not made much progress on testing systemd-in-ramdisk, but this has been worked on by various others outside of Mageia. I'll look to enable it by default at some point, but I still need to do more testing to be happy with it.
19:28:30 <ennael> ok thanks for this information
19:28:41 <coling> And ultimately, I've not really done much on the "paths tidying" yet, but it's more of an ongoing thing anyway.
19:28:47 <AL13N> adamw: we should talk in private, there's a meeting
19:29:02 <ennael> hi adamw :)
19:29:04 <coling> And it's really something that I would like to put in place for mass-rebuild anyway.
19:29:10 <ennael> ok
19:30:01 <coling> So I think that's me mostly summarised.
19:30:07 <ennael> ok
19:30:15 <coling> I still need to do a couple last git repo conversions and tweaks but that's not a "feature" as such.
19:30:20 * Luigi12_work has submitted a patch to implement chrony for coling to review, so that's in progress too
19:30:27 <coling> \o/
19:30:30 <ennael> :)
19:30:37 * coling forgot about /o\ Installs now.
19:30:48 <ennael> about checkbox to choose DE screen
19:30:51 * coling remembered something else too but has now instanly forgotten it.
19:31:13 <ennael> it has been reverted for alpha1 as it was buggy and needed some more work on it
19:31:27 <ennael> I don't know if it was restarted
19:31:33 <Luigi12_work> who are working on that feature?
19:31:37 <ennael> and we spoke also to use a git branch for this
19:32:36 <coling> I think also Derek was on holiday?
19:32:49 <coling> So he'll presumably be back soon and can look at finalising it?
19:33:20 <ennael> yep waht about a specific branch for it in Drakx
19:33:21 <ennael> ?
19:33:34 <coling> Well.....
19:33:51 <coling> A branch would be fine, but by the same token, we need people other than Derek to test it too....
19:34:04 <coling> Branches sadly lack a little in the testing department.
19:34:05 <ennael> indeed
19:34:18 <AL13N> but the screenshot is pretty complex
19:34:22 <AL13N> too complex
19:34:39 <AL13N> 9 choices is over the top
19:34:51 <ennael> indeed also this has to be discussed when Derek is back
19:34:59 <Luigi12_work> the issue isn't how many choices, it's when the choice is presented
19:35:00 <coling> But a branch would be fine I think - provided he can get perhaps myself and tv and maybe a few others to actively test it?
19:35:12 <ennael> coling: yep
19:35:46 <AL13N> Luigi12_work: yes, i meant that first screen where we used to have 3 options
19:36:12 <coling> And it probably makes sense to get the design decision about how it should glue together solved first, but IMO, if it's unweildy but works, then it can still go in with the caveat that it would need refined... not working at all is not an option obviously :D
19:36:27 <ennael> :)
19:36:41 <Luigi12_work> indeed
19:37:24 <coling> fwiw, /me would favour a "big two" KDE+GNOME+Other first screen with the the others listed on a separate pane.
19:37:40 <ennael> so basically our old screen
19:37:48 <ennael> maybe redesign a bit
19:38:12 * AL13N too
19:38:56 <ennael> #action discuss again about the desktop choice screen as the current one proposed by Derek is too complex
19:39:18 <ennael> AL13N: what about diskdrakrescan ?
19:39:41 <AL13N> it's not alot of work, but my VM consitently rebooted when i tried my code
19:39:56 <AL13N> in short, i need some help from someone who knows diskdrake to get me started
19:40:03 * coling goes insane trying to workout the code paths in diskdrake :s
19:40:17 <ennael> AL13N: maybe try to ping pterjan
19:40:21 <AL13N> maybe a review of my code
19:40:26 <AL13N> ok, will try
19:40:47 <coling> In theory diskdrak really needs a refresh to make much more use of udev info which these days is a better approach than a lot of the probing code done in diskdrake IMO
19:40:56 <coling> But that's too big a job for me just now sadly
19:41:11 <ennael> a feature for mageia 5 ?
19:41:26 <coling> If you can bribe someone :D
19:41:40 <neoclust> coling: hello
19:41:41 * coling will likely have plenty to work on already even for then.
19:41:56 <ennael> :)
19:42:09 <ennael> what about DoNotShipSysVInitScripts ?
19:42:13 <AL13N> i can help with that for mga5
19:42:31 <coling> ennael, well, I've not make much progress on that directly to be honest
19:42:33 <neoclust> ennael: we would need to list "sysVinit only" packages
19:42:40 <neoclust> coling: you have a list ?
19:42:48 <coling> But again, it's more a general aim.
19:43:07 <coling> neoclust, urpmf "/etc/(init.d|rc.d)"
19:43:10 <AL13N> it's not something that needs to be strictly done, but all to have a systemd unit is more important
19:43:22 <AL13N> maybe we can list them and file bugs for those
19:43:46 <coling> AL13N, well there is no point in shipping both a unit and a sysvinit script, so it's kinda the same thing really.
19:44:10 <neoclust> coling: as this is something i can need on MBS, i can try to help a little
19:44:32 <blino> ennael:
19:45:14 <coling> neoclust, any help would be very much appreciated.
19:45:17 <ennael> blino: could you give a hand to coling on draksec?
19:45:27 <blino> yep
19:45:39 <ennael> coling: quick ! he is ok :)
19:45:46 <neoclust> :)
19:45:49 <AL13N> :)
19:45:56 <neoclust> blino: and me with drakx ? <3
19:45:58 <neoclust> :D
19:46:15 <ennael> neoclust: what about kscreen ?
19:46:41 <neoclust> ennael: i need to do a fresh install but should be installed by default on new installs.
19:46:52 <neoclust> ennael: i will do an install tomorow to make sure.
19:47:11 <ennael> thanks
19:47:16 <coling> neoclust, did you also look at the new KDE login manager I mentioned a while back? I still think we should drop kdm...
19:47:45 <neoclust> coling: i agree, i started to look, missed time for more but i am interested in a kdm replacement.
19:47:56 <neoclust> coling: i fwd your mail to mikala too
19:48:08 <coling> Great.
19:48:34 <neoclust> coling: if not done for mga4 i think i will add this as a feature for mga5
19:48:58 <coling> Yup, tho' I would really hope to get it in for mga4 personally.
19:49:20 <neoclust> coling: i can't promise but i can look more.
19:49:47 <coling> If you need help with pam related bits or logind stuff, let me know.
19:50:01 <neoclust> ok  deal :)
19:50:06 * coling can also test with new seat h/w
19:50:34 <sander85> is sddm the replacement? or whatever it was called
19:50:45 <sander85> its pam is a mess :)
19:50:56 <neoclust> sander85: sddm is a candidate
19:51:02 * sander85 tried and failed to log in with that dm :)
19:51:14 <neoclust> sander85: we will make sure next time you pass the test ;)
19:51:30 <sander85> ok, good :)
19:51:58 <AL13N> there's another feature i would like to talk about
19:52:17 <ennael> yep ?
19:52:27 <AL13N> RpmDrakeShowsAdvisories
19:52:35 <AL13N> pterjan has himself listed for this
19:52:49 <AL13N> i saw a mgaadvisories entry on git
19:53:45 <AL13N> so, i'm a bit unsure, i know there is likely not alot of work needed for this one either
19:54:14 <AL13N> then there's NetworkDrakToolsImprovements, where the owner seems to be missing... :-(
19:54:15 <ennael> well he is not around maybe mail -dev rather
19:54:33 <ennael> any news from MTP support ?
19:54:56 <AL13N> afaik yannick needs some packaging help
19:55:12 <philippem> I can certainly help on systemd unit or any other task, as soon as blino and or tv validate my change on spec-helper and explain me how to rebuild this package (https://ml.mageia.org/l/arc/dev/2013-09/msg00295.html)
19:55:13 <[mbot> [ dev - Developement discussion list - arc_protect ]
19:55:14 <coling> AL13N, so the mgaadvisories in git is a tool by boklm to generate the web interface to the advisories. I'm not sure how related it is to the rpmdrake feature (tho' obviously it can write data that rpmdrake consumes)
19:55:17 <AL13N> or it needs to be installed by default or something so that alpha installs work
19:56:02 <AL13N> coling: rpmdrakeadvisories is mostly just writing descriptions file, but one field of data was missing or something
19:56:24 <coling> OK, you know more than me then :)
19:56:47 <AL13N> i had talked to pterjan about this
19:57:08 <AL13N> i think the src.rpm name was missing
19:57:18 <AL13N> i know it was something that could be easily found though
19:59:27 <AL13N> anyway, i'll send another email about the features which will sum it up
20:00:32 <AL13N> i think there's more topics to be talked about?
20:00:46 <ennael> MageiaWelcome is now in a good shape
20:00:50 <ennael> is it packaged already?
20:01:03 <ryoshu> :summary mageiawelcome
20:01:03 <Sophie> ryoshu: Mageia welcome screen // core-release (Mga, cauldron, x86_64), core-release (Mga, cauldron, i586)
20:01:14 <ennael> thanks
20:01:18 <AL13N> i thought it needed someone from Art team to check it?
20:01:22 <AL13N> has that been done?
20:01:27 <ennael> not yet
20:01:35 <ennael> is it now in git repository ?
20:01:45 <ryoshu> yes
20:01:52 <ennael> great  thanks :)
20:02:10 <ryoshu> however napcok reported problems accessing it
20:02:26 <AL13N> there was activity 11days ago
20:02:35 <ennael> ok so it still needs some work on it
20:02:42 <neoclust> some tests do be done with mageiawelcome ?
20:02:49 <AL13N> i thought he had fixed the git access problems
20:03:13 <AL13N> :v mageiawelcome
20:03:13 <Sophie> AL13N: 0.3-2.mga4 // core-release (Mga, cauldron, x86_64), core-release (Mga, cauldron, i586)
20:03:23 <AL13N> 0.5 is committed in git
20:03:54 <neoclust> maybe someone could submit it
20:04:06 <neoclust> would allow some feedbacks
20:04:21 * AL13N is not sure if the 0.5 is ready though
20:04:31 <ryoshu> Yes, it was
20:04:35 <AL13N> ah ok
20:04:39 <neoclust> /usr/lib/mageiawelcome
20:04:45 <neoclust> shouldn't it be in /usr/share ?
20:04:50 <neoclust> i think this would be better
20:04:53 <neoclust> this is no libs
20:05:05 <AL13N> who reviewed the package before submitting it?
20:05:06 <ryoshu> Feel free to contribute it
20:05:06 <ennael> neoclust: can you review it as you are strting :)
20:05:33 <neoclust> ennael: yes i can
20:05:36 <neoclust> just started it
20:05:40 <neoclust> graphically this is nice
20:05:44 <AL13N> :-)
20:05:53 <ennael> great once it's done then just push it
20:06:02 <ryoshu> neoclust: Makefile wasn't complete - it missed packaging itself and the git access was gone
20:06:07 <ennael> then ryoshu you should mail or napcok on -dev asking for tests
20:06:15 <neoclust> ryoshu: ok i will take care of this
20:07:24 <ennael> thanks
20:08:47 <ryoshu> napcok is now abroad/away. so probably he can't take care of it very soon
20:08:55 * Luigi12_work loves KDM :o(
20:09:16 <neoclust> Luigi12_work: you will be able to use it :)
20:09:50 <ennael> ok I guess we have reviewed most of the list
20:09:58 <ennael> any question? comment ?
20:10:41 <ryoshu> Yes. when MW can be shipped with the LiveCD/DVD?
20:11:05 <ryoshu> It needs help from the cd-mastering team
20:11:14 <ennael> well as soon as it's submitted and tested we can add it in next alpha
20:11:17 <coling> Luigi12_work, upstream is basically dead in KDM sadly - as the DMs generally cause access and session tracking issues, I'd much rather we drop them if the upstream isn't doing anything...
20:11:26 <ennael> provided it'e not too big to fit in
20:11:53 <coling> But only if there is a good/appropriate replacement that is genuinely better.
20:12:04 <neoclust> ennael: i review the paths and submit a new version on the BS
20:12:31 <AL13N> when is the next freeze for the next alpha?
20:12:42 <ryoshu> neoclust: thank you
20:12:48 <coling> Luigi12_work, chrony working well here btw, and properly enabled/started via timedatectl dbus interfaces
20:13:05 <coling> So I'd say submit that :)
20:13:30 <ennael> AL13N: you can count about one week before
20:13:37 <AL13N> k
20:14:19 <Luigi12_work> coling: thanks, submitted!  :o)
20:14:46 <AL13N> shall we go to the other topics then?
20:15:32 <Luigi12_work> if we want more maintained packages we probably need more packagers
20:15:46 <ennael> ok next topic
20:16:05 <ennael> #topic adoption campaign for unmaintained packages
20:16:16 <neoclust> coling: i don't have the right to commit in mageiawelcome ?
20:16:38 <AL13N> neoclust: i think this is what napcok had too
20:16:48 <coling> neoclust, you should... are you sure you're using the right git:// transport for the push? (git remote -v)
20:16:56 <coling> erm ssh:// transport***
20:17:14 <AL13N> ssh://git@git.mageia.org/software/mageiawelcome
20:17:19 <neoclust> [remote "origin"] url = git://git.mageia.org/software/mageiawelcome fetch = +refs/heads/*:refs/remotes/origin/*
20:17:20 <coling> but this is off-topic for meeting
20:17:26 <neoclust> coling: sorry yes
20:17:44 <neoclust> coling: ok found the pb
20:18:23 <AL13N> neoclust: https://wiki.mageia.org/en/How_to_use_Git
20:19:01 <malo> should we talk about unmaintained packages?
20:19:08 <ennael> yep
20:19:13 <ennael> malo: want to do it?
20:19:20 <AL13N> about the adoption campaign, the way i hear it is that some people want more maintained packages, and some want less maintained packages, or rather only marking maintained if you really maintain them
20:20:01 <malo> AL13N: yes. That's pretty much it.
20:20:24 <malo> So it more about updating the maintainer database than anything
20:20:31 <malo> else
20:20:52 <malo> many unmaintained packages  are actually maintained
20:20:57 <AL13N> so in short nobody will likely stay for a good while
20:21:09 <malo> and many "maintained" are unmaintained
20:21:22 <malo> AL13N: not necessarily.
20:22:07 <malo> And recognising which packages are really left over gives opportunities to us packagers to decide what to do with them
20:22:45 <malo> So yes, we will still have nobody :-)
20:23:12 <malo> but nobody in charge of 25% of the packages is unsustainable
20:23:59 <malo> Are we all in agreement about this diagnostic?
20:24:14 <AL13N> but how are you gonna accomplish this?
20:24:26 <AL13N> it's not easy to see which are actually maintained or not
20:24:47 <AL13N> alot of them are "maintained" but bug reports aren't being looked at
20:24:47 <Luigi12_work> well there's the related idea of maintainer groups
20:24:58 <malo> As a reminder, keeping this database up-to-date is essential for the bugsquad team, any bug related-business and lots of our check.mageia.org tools
20:25:10 <Luigi12_work> like for instance some packages I help take care of, but don't want to mark myself sole maintainer and discourage anyone else from helping with it
20:25:18 <AL13N> exactly
20:25:59 <malo> Well, we don't have co-maintainers yet as part of our infrastructure.
20:26:29 <Luigi12_work> well maybe before any adoption campaigns we should get that straightened out
20:26:32 <malo> So we need to find a different solution.
20:27:03 <malo> Luigi12_work: if we wait it means we ship mga4 with 25% of unmaintained?
20:27:19 <Luigi12_work> malo: changing values in the maintdb doesn't change what packages are actually maintained or not
20:27:27 <Luigi12_work> so waiting isn't going to make things any worse
20:27:29 <sander85> if those unmaintained packages mostly work then why not?
20:27:41 <sander85> better than faking maintainership
20:28:08 <sander85> if you look at the deps report then nobody is doing pretty well currently :P
20:28:23 <sander85> there are other packages that have been in that list for months
20:28:28 <ryoshu> maybe monitor last commit in a package - to see how many of them is untouched in months and years
20:28:28 <sander85> and nothing happens to them..
20:28:35 <Luigi12_work> and unless we get a bunch of new packagers or start dropping packages in large numbers, mga4 will ship with a lot of unmaintained packages regardless
20:28:49 <Luigi12_work> sander85: indeed
20:28:58 <AL13N> the way i see it, is that we need something automatic to mark unmaintainership
20:29:06 <AL13N> and comaintainership, but that's less important
20:29:10 <malo> Then we can just drop the maintdb database alltogether
20:29:20 <malo> if it's meaningless
20:29:27 <sander85> it's not
20:29:41 <AL13N> it's inaccurate though
20:29:45 <sander85> if the package has no maintainer I dare to update and break it
20:29:57 <sander85> if it has maintainer I don't even touch the package
20:30:11 <malo> That's my point. If it's inaccurate, then either we update it or we drop it.
20:30:21 <Luigi12_work> it's not a binary decision
20:30:28 <Luigi12_work> we can't update it to be accurate in its current form
20:30:35 <AL13N> malo: i think we all agree to update it, but it's not something that happens in just a few days
20:30:36 <malo> well the 3rd option is to do nothing :-)
20:30:42 <Luigi12_work> not every package has a dedicated sole maintainer
20:30:52 <sander85> we need teams
20:30:57 <sander85> we really really need them
20:31:07 <AL13N> we already have teams: SIG
20:31:09 <Luigi12_work> either teams or allow each package's maintainer to be a list
20:31:19 <Luigi12_work> AL13N: SIG is too big and general for this I think
20:31:23 <AL13N> ok
20:31:24 <malo> Well,  ennael and I have been pushing for teams :-)
20:31:55 <AL13N> so, maintdb lacks 2 features
20:32:07 <malo> the thing is that for example the KDE team already exists and does not need infrastructure to work well
20:32:12 <AL13N> 1) automatic removal when inactivity is detected (bug reports)?
20:32:29 <AL13N> 2) some kind of team/group thing to be maintainer
20:32:37 <malo> the missing infrastructure for co-maintainance is not a good reason
20:32:37 <sander85> malo: they need pseudo user in maintdb to grab packages
20:32:49 <sander85> not all kde packages are marked maintained
20:33:11 <AL13N> so, we need to make it more accurate
20:33:25 <AL13N> even if we don't have co-maintainership yet, we can still make it more accurate
20:33:33 <malo> sander85: no, I co-maintain ocaml with blue-prawn and I have 50% of the packages and he has 50%, and it works fine
20:34:07 <grenoya> AL13N: how do you detect inactivity? some of my packages have no bugs and no new version, so no activity
20:34:24 <AL13N> no bugs means no problems, means no inactivity either :-)
20:34:36 <sander85> malo: hmm, maybe the fact that it works fine for you is the problem why you can't see how it doesn't work for others? :P
20:35:18 <malo> sander85: what I am saying is that the first step is to create the teams, then create the infrastructure
20:35:35 <sander85> we have quite a few teams already
20:35:36 <Luigi12_work> I think the teams will form naturally if the infrastructure is in place
20:35:46 <sander85> but lacking the infra
20:35:49 <malo> we can have the infrastructure, but if the teams do not exist then it'suseless
20:36:03 <AL13N> i think there are teams, but the other don't know that (ie: bugsquad)
20:36:04 <Luigi12_work> having the infrastructure can help the teams formalize more
20:36:08 <malo> sander85: we have a few teams and they work well :-)
20:36:29 <AL13N> also, it's not always about teams
20:36:41 <AL13N> but sometimes people loosely contribute
20:36:43 <Luigi12_work> true
20:36:44 <sander85> yeah, but a lot of packages are "unmaintained"
20:37:06 <sander85> because people in teams don't want to set their name behind the package
20:37:25 <sander85> if it would be the name of the team they would be OK with that
20:37:26 <malo> What I am saying is that I would like to see messages on -dev saying things like: "I want to help maintain php, but not alone, who would like to share the following packages with me? "
20:37:36 <sander85> and the package would be officialy maintained
20:38:26 <malo> sander85: I don't see the point of "people in teams don't want to set their name behind the package"
20:38:26 <sander85> malo: such sharing is hard to happen if people would have to claim packages with their name and then wait for bugsquad to assign hard to patch bugs to them
20:38:35 <sander85> about packages they really don't know much about..
20:39:39 <malo> sander85: If they don't know, they just reassign.
20:40:04 <sander85> then what's the point of grabbing package?!
20:40:07 <malo> sander85: if they know who they are working with, it works
20:40:54 <malo> sander85: because 1) the bugsquad knows one person to contact and 2) the person assigned will perhaps know the solution
20:41:04 <neoclust> /!\ mageia welcome 0.5 submited /!\
20:42:49 <AL13N> i think not having the infrastructure would work, except that it's a social stumbling block... ie: leading to one person doing all the work and then burning out
20:42:56 <AL13N> or at least that's what they are afraid of
20:43:16 <AL13N> it also could mean that they don't really want to commit to maintainership at all... that's another possibility
20:43:25 <ryoshu> neoclust: thank you!
20:43:43 <ryoshu> coling: can we have an alias gitweb.mageia,org = webgit.mageia.org
20:43:55 <neoclust> ryoshu: why ?
20:43:59 <coling> why?
20:44:07 <ryoshu> I always guess incorrectly
20:44:10 <AL13N> on the one hand: not having the infra, and doing it malo's way would force people to be more responsible
20:44:19 <coling> ryoshu, add it as a keyword bookmark locally then :)
20:44:23 <neoclust> coling: and please webgti  wbegit ewbgit    etc too :)
20:44:48 <AL13N> on the other hand: this kind of social stumbling block could reduce contribution
20:45:03 <AL13N> can we stay on topic plz?
20:45:15 <AL13N> it's late, we should need to finish, there might be more topics
20:45:29 <malo> the thing is that we don't have the infrastructure, so I'm trying to see what we can do now. When we have the infrastructure it will obviously easier.
20:45:50 <malo> On topic ...
20:46:31 <malo> Alright we have this package adoption campaign, which is actually more about keeping the maintdb up-to-date than grabbing packages at all costs.
20:46:38 <AL13N> ok, so we need to tell the people who commit to packages to communicate with the others and divide the packages equally
20:46:50 <AL13N> and agree to cc the others
20:47:31 <malo> AL13N: that's one way, yes, and it will work well on groups of packages.
20:47:54 <AL13N> for this to work, i think people will need to be pointed it out with hard facts....: ie sending an auto-email: you contributed to this unmaintained package, plz contact foo and bar and divide maintainership
20:48:01 <coling> Perhaps building the infra isn't too hard tho'? For example I feel a git-based package vcs would allow me to managed and backport fixes to older distros a lot more easily. But other things might not be too hard to knock up. e.g. stats on bugs resolved, commits, etc. for users and badges/goals could be a nice metric and encourage people.
20:48:23 <AL13N> coling: it possibly isn't, but given the low priority, this will take a few years for it to happen
20:48:50 <AL13N> (given past experience)
20:48:54 <malo> coling: it's probably not that hard, but the sysadm team needs to grow if it happens
20:49:01 <Luigi12_work> unless we get more sysadmins too :o)
20:49:17 <malo> we are still waiting on backports ... ;-P
20:49:21 <AL13N> we'll cross that bridge when we get to it
20:49:29 <neoclust> unless unless unless ...  we need to work with what we have :)
20:49:31 <Luigi12_work> malo: I'm not waiting on backports :o)
20:49:34 <coling> Well, if there are clear ideas as to what we'd like, it might make it more likely... most new infra things currently seem to be "scratch our own itch" type things, but the people with the ideas might not have the skills/access to develop the interfaces...
20:50:00 <AL13N> but, this is getting offtopic
20:50:09 <neoclust> coling: we would need a wiki page about what we want to add on our infra
20:50:09 <Luigi12_work> coling: yeah that's a common problem for us unfortunately
20:51:10 <malo> Ok. sander85 and AL13N, can you write a wiki page which would have the requirements for teams?
20:51:29 <AL13N> so, can *someone* find a way to have a generated email sending to contributors of officially unmaintained packages and telling them in a non-confusing way that they need to talk with specific co-contributors for this case and dividing the packages in whatever way they want to
20:51:42 <AL13N> malo: the infrastructure requirements? or?
20:51:53 <malo> AL13N: yep
20:51:59 <AL13N> sure
20:52:25 <AL13N> still, we should focus on the now though
20:52:36 <malo> AL13N: about your last message, that what bugsquad is doing ... CC last committer if it's a nobody package
20:52:48 <malo> AL13N: yes
20:53:02 <AL13N> malo: i mean for all nobody packages, for all the contributors in one go
20:53:10 <Luigi12_work> ,maint nss
20:53:12 <AL13N> should be +-7000 emails
20:53:15 <[mbot> luigiwalser, 16; fundawang@, 9; dmorgan, 8; blino, 3; oe@nux, 2; olav@vitt, 1; ennael1, 1; colin.g, 1;
20:53:33 <AL13N> could be 10k emails
20:53:42 <Luigi12_work> that's what bugsquad does...counts up number of commits per committer and ranks by most active commiters
20:54:22 <AL13N> yes, but they are not telling them that they need to talk to the others and grab maintainership and divide it amongs them
20:54:42 <Luigi12_work> well we don't need to heap more responsibility on the small bugsquad's shoulders
20:54:50 <AL13N> perhaps all open bugs by nobody could be sent such an email
20:55:01 <AL13N> a one-time email
20:55:18 <malo> So, I propose first that everyone looks at his own list http://people.mageia.org/g/mga-packagers.html and sees if they really maintain these packages. If some of them you don't really maintain, set to nobody.
20:55:19 <[mbot> [ people.mageia.org: g/mga-packagers ]
20:56:16 <malo> Then we should look at http://pkgsubmit.mageia.org/data/unmaintained.txt and see if there are packages that we actually maintain, or that are so close to the ones we already maintain that it's not a burden, and we grab them.
20:57:14 <AL13N> in addition to the weekly email on missing deps, perhaps we can have a similar one for open unresponsive bugs
20:57:18 <AL13N> and drop these too
20:57:37 <ennael> #chair malo
20:57:37 <Inigo_Montoya> Current chairs: ennael malo
20:57:40 <malo> Then we look at both http://people.mageia.org/g/mga-packagers.html and http://pkgsubmit.mageia.org/data/unmaintained.txt again, asking ourselves if there are packages that can be shared with others. Then we send a mail to -dev to see if others are interested in sharing maintainership
20:57:41 <[mbot> [ people.mageia.org: g/mga-packagers ]
20:57:58 <AL13N> malo: perhaps you should write this in an email on -dev
20:58:37 <malo> AL13N: well, it's for discussion here first, and I can mail -dev afterwards.
20:59:30 <Luigi12_work> there's plenty of maintainership sharing going on already, some formally, some informally
20:59:34 <AL13N> malo: i think it's a good idea, but i'm not sure it will help much, given that it's mostly about the people who aren't really responsive for such things (or are too busy)
20:59:47 <Luigi12_work> so I don't think there's a lack of interest in that, but cleaning the maintdb as best we can do right now is not a bad idea
20:59:55 <neoclust> Luigi12_work: like KDE Team :)
21:00:01 <AL13N> malo: i think it would be good to explicitly mention that bugsquad would be helped by this sort of thing
21:00:11 <AL13N> otherwise people aren't motivated to do anything
21:00:12 <malo> Luigi12_work: yes, I think it's the priority.
21:01:32 <AL13N> so we're agreed then?
21:01:51 <malo> It would be interesting to see if the packagers that are too busy can drop some of the ones that are marked as theirs.
21:02:55 <malo> for example, dmorgan officially maintains 1500 packages, but it's not true of all, and it would be better if he dropped some. It's hurting us more in terms of stalled bugs than if it were nobody's.
21:03:25 <Luigi12_work> yep, and him having 1500 is because of the last adoption campaign
21:04:07 <malo> Luigi12_work: and doing that without backup.
21:04:31 <malo> #action malo will send a mail to -dev explaining the package adoption campaign
21:04:42 <AL13N> malo: but, should we not monitor open bugs and act accordingly?
21:04:53 <Luigi12_work> I think not calling it an adoption campaign would be a good start
21:04:56 <AL13N> like the missing dep weekly email
21:05:09 <malo> Luigi12_work: name?
21:05:16 <Luigi12_work> maintdb cleaning?
21:05:23 <malo> Luigi12_work: ok
21:05:28 <AL13N> Luigi12_work: malo: "helping to unburde the bugsquad campaign"
21:06:22 <Luigi12_work> AL13N: such an e-mail from the bugs would be a LOT of work unless it could be automated somehow
21:06:52 <Luigi12_work> maybe somewhere down the line if we have maintainer lists for the maintdb we can more formally tie bugzilla and maintdb together
21:07:00 <malo> AL13N: too much work to link it to bugzilla.
21:07:10 <Luigi12_work> it could even automatically CC packagers for bugs if the correct package list is set, for instance
21:07:22 <Luigi12_work> but that's down the road
21:08:00 <neoclust> Luigi12_work: in an ideal world we would have 2 teams :) one working on stable distro and one on cauldron :)
21:08:01 <malo> Yep. I hope this process will also help make some teams more explicit.
21:08:03 <AL13N> automation is good
21:09:22 <malo> Anything else on this topic?
21:09:50 <ovitters> I like working on Cauldron, not on stable like neoclust says
21:10:16 <ovitters> as a result, I don't like 3-4 month of version freeze
21:11:01 <malo> ovitters: that's why it's great that you don't work on GNOME alone, but with a few others.
21:11:15 <AL13N> ok, so next topic then?
21:11:27 <malo> #topic Anything else?
21:11:39 <neoclust> malo: yes , for me i have the chance to have mikala and luc to look on mageia stable releases.
21:12:11 <Luigi12_work> well we don't have paid people to maintain the stable releases, so EVERYONE needs to help with that
21:12:11 <malo> ovitters: you need to find your mikala and luc :-)
21:12:22 <Luigi12_work> whether they like doing it or not, otherwise we might as well not have a distro
21:13:03 <ovitters> I do nothing while version freeze is there
21:13:09 <neoclust> Luigi12_work: you don't have to give orders ;)
21:13:21 <Luigi12_work> ovitters: I hope you fix bugs at least :o(
21:13:39 <ovitters> why?
21:14:03 <Luigi12_work> ovitters: WTF?  I mean in the gnome packages.  You just want to update them, and don't care if they actually work right?
21:14:05 <ovitters> version freeze means I have to explain every small bugfix made by upstream
21:14:07 <sander85> if noone fixes gnome's bugs on stable we have to drop it..
21:14:28 <Luigi12_work> ovitters: well I think we could loosen the freeze restrictions for mainline gnome packages
21:14:33 <Luigi12_work> we tend to do that for KDE
21:14:34 <ovitters> 3-4 months of version freeze means I cannot test the development version, means that version will not be stable
21:14:42 <neoclust> sander85: useless comment from you
21:15:01 <Luigi12_work> not useless at all, he's right
21:15:16 <malo> sander85, Luigi12_work: GNOME is too big for one maintainer
21:15:21 <Luigi12_work> I know developers always want to develop and work on the next version, but we need to help take care of our releases too
21:15:27 <neoclust> Luigi12_work: no
21:15:33 <ovitters> I am terrible at maintaining stable
21:15:47 <ovitters> either accept that, or keep thinking I can be forced to do it
21:15:48 <malo> ovitters: that's why you need help :-)
21:15:54 <neoclust> ovitters: we need to find someone for you to maintain gnome stable
21:16:00 <neoclust> ovitters: so you can focus on cauldron
21:16:06 <ovitters> there are a few who do
21:16:22 <neoclust> Luigi12_work: i won't install a stable to please you :)
21:16:22 <ovitters> and if there are bugs I just push upstream to fix things
21:16:31 <neoclust> ovitters: this is just perfect then
21:16:41 <Luigi12_work> neoclust: it's not about pleasing me, why the hell have a distro if we're not going to support it?
21:16:57 <Luigi12_work> just have cauldron and say run cauldron if you want Mageia, otherwise go away
21:17:03 <neoclust> Luigi12_work: i think you don't see the point
21:17:33 <malo> Luigi12_work: you can't force people to do things :-).
21:17:51 <ovitters> I look after the development, ensure that the next version is not total crap
21:17:56 <neoclust> Luigi12_work: this is why i told about quite 2 teams, one on stable one on dev
21:18:07 <Luigi12_work> we dont' have enough people to split like that
21:18:16 <neoclust> Luigi12_work: this would be more productive
21:18:23 <AL13N> maybe it's time to just end the meeting
21:18:23 <Luigi12_work> sure if we had a lot more people
21:18:25 <ovitters> but I get bored making it entirely stable
21:18:31 * AL13N doubts anything productive will come at this time
21:18:34 <Luigi12_work> too few people are interested in helping with stable
21:18:54 <malo> Luigi12_work: if
21:19:09 <Luigi12_work> looking after all the packages that need security updates as I do, I see this problem all the time, it's real
21:19:34 <Luigi12_work> anyway yeah we can end the meeting
21:19:37 <malo> Luigi12_work: we all know that.
21:19:49 <neoclust> Luigi12_work: i don't have time to maintain stable and cauldron
21:19:52 <malo> Ok, thanks for attending!
21:19:57 <neoclust> sander85: maybe we should remove KDE from mga too then
21:20:00 <malo> #endmeeting