Le blog de pingou

To content | To menu | To search

Tag - Fedora

Entries feed - Comments feed

Wednesday, March 25 2015

Progit is dead, long live pagure

You may have heard of a little pet project I have been working on recently, I called it progit but there already a more well-known project named progit (the pro git book).

So, after long deliberations, we decided to rename the project: pagure.

What is Pagure?

Pagure is a small git-centered forge project. You can host your code, your documentation, your tickets and have people contribute to the project by forking it and opening pull-requests.

All the information about the project is hosted in different git repositories, the code of course, but also the documentation as well as the metadata (discussion) of tickets and pull-requests. The idea being that one could host a project in multiples instances of pagure and keep them in sync.

What about the name?

Pagure is the generic (French) name for animals of the Paguroidea family which includes the well known Pagurus bernhardus. This little crab moves from shell to shell as it grows up. I found it was a nice analogy with this forge where project can move from place to place.

Where can I see it?

Pagure is still under development and pretty much changes every day. However, you can already see it, test it and poke at it via the dev instance we have running.

As you will see, pagure itself is being developed there, so feel free to open a ticket if pagure does not do something you would like (or does something you do not like).

Tuesday, March 24 2015

New package & new branch process

A little while ago, I blogged about the new package and new branch request processes.

These changes have been pushed to production yesterday.

What does this change for you, packager?

New package

If you already a packager, you know the current process to get packages into Fedora, you know that once your package has been approved on bugzilla, you have to file a SCM request.

With the new process, this step is no longer necessary. You can directly go to pkgdb and file the request there.

From there admins will review the package review on bugzilla and create the package in pkgdb (or refuse with an explanation).

New branch

If your package is already in Fedora, you can now directly request a new branch in pkgdb. Here there are multiple options

  • You have approveacls on the package (thus you are a package admin) and the request is regarding a new Fedora branch: The branch will be created automatically
  • You have approveacls on the package (thus you are a package admin) and the request is regarding a new EPEL branch: The request will be submitted to the pkgdb admins who will process it in their next run
  • You do not have approveacls on the package, then your request will be marked as: `Pending`, this means that the admins of the package have one week to react. They can either approve your request and by setting it to Awaiting Review, or they can decline the request (for which they must specify a reason). After this one week (or sooner if the package admin set the request to Awaiting Review) the pkgdb admin will process the request like they do with the other.

Note: Even with this new workflow, requests are still manually reviewed, so the requests will not necessarily be processed faster (but if it is easier for the admins, they may run it more often!).

What does this change for you, admins?

Hopefully, the process will be much simpler for you. In short

  • no need to log onto any system, you can do everything from your own machine and it should work out of the box
  • much more automated testing (including checking if a package is present in RHEL and on which arch for EPEL requests)
  • one tool to process the requests: pkgdb-admin distributed as part of packagedb-cli (aka: pkgdb-cli)



I hope this process makes sense to you and will make your life easier.

You are welcome to already use these processes, just let us know if you run into some problems, but for the time being both the old and the new processes are supported :-)

Wednesday, February 25 2015

Check your packages in pkgdb and anitya

The question was asked on the devel list earlier if there was a way to check all one's packages for their status in pkgdb and whether they are in anitya.

So I just cooked up quickly a small script to do just that, it retrieves all the packages in pkgdb that you are point of contact or co-maintainer and tells you if its monitoring flag is on or off in pkgdb and if it could be found in anitya.

For example for me (partial output):

$ python pkgs_not_in_anitya.py pingou
   * point of contact
     R-ALL                                Monitor=False   Anitya=False
     R-AnnotationDbi                      Monitor=False   Anitya=False
     ...
     guake                                Monitor=True    Anitya=True
     igraph                               Monitor=False   Anitya=False
     jdependency                          Monitor=True    Anitya=True
     libdivecomputer                      Monitor=True    Anitya=True
     metamorphose2                        Monitor=False   Anitya=False
     packagedb-cli                        Monitor=False   Anitya=False
     ...
   * co-maintained
     R-qtl                                Monitor=False   Anitya=False
     fedora-review                        Monitor=True    Anitya=True
     geany                                Monitor=True    Anitya=True
     geany-plugins                        Monitor=True    Anitya=True
     homebank                             Monitor=True    Anitya=True
     libfprint                            Monitor=True    Anitya=True
     ...

If you are interested, feel free to use the script

About SourceForge and anitya

There are a couple of reports (1 and 2) about anitya not doing its job properly for projects hosted on sourceforge.net.

So here is a summary of the situation:

A project X on sourceforge.net, for example with a homepage sourceforge.net/projects/X, releases multiples tarball named, X-1.2.tar.gz, libX-0.3.tar.gz and libY-2.0.tar.gz.

So how to model this.

The original approach taken was: the project is named X, so in anitya we should name it X and then the sourceforge backend in anitya allows to specify a Sourceforge project allowing to search X, libX or libY in the rss feed of the X project on SourceForge. Problem: when adding libX or libY on anitya, the project and homepage are all X and sourceforge.net/projects/X, while this is actually used to make project uniques in anitya (in other words, adding libX and libY won't be allowed).

So this is the current situation and as you can see, it has problems (which explains the two issues reported).


What are the potential solutions?

1/ Extend the unique constraint

We could include the tarball name to search for in the unique constraint, which would then change from: name+homepage to name+homepage+tarball

2/ Invert the use of name and tarball

Instead of having the project name be X with a tarball name libX, we could make the project be libX and the tarball be X.

This sounds quite nice and easy, but looking at the project currently in anitya's database, I found projects like:

        name         |                          homepage                           |                  tarball
                     +                                                             +
 linuxwacom          | http://sf.net/projects/linuxwacom/                          | xf86-input-wacom
 brutalchess (alpha) | http://sourceforge.net/p/brutalchess                        | brutalchess-alpha
 chemical-mime       | http://sourceforge.net/projects/chemical-mime               | chemical-mime-data

So for these, the tarball name would become the project name and they would be pretty ugly.

I am not quite sure what is the best approach for this.

What do you think?

Thursday, January 22 2015

New branch request process

A little while ago I blogged about a new process to request a new branch on an existing package.

The code to support this change is now under review but I thought I should document the workflow a little bit, so here is how I tried to design things:

pkgdb_new_branch_flow_2.png

Ideally, when the branch is approved and created in pkgdb by the admin, pkgdb will send a message on fedmsg, message that will be seen by a fedmsg-consummer that will automatically update the git repos within, say 2 minutes. That last part if almost ready and hopefully will be running soon.

Tuesday, December 30 2014

Firefox private browsing directly

I use the private mode of firefox quite often, for example when I want to test an application while being authenticated in one windown and not authenticated in another window.

I also use this mode when I want to browse some commercial websites that I know do a lot of tracking (hey there amazon!).

Finally, my firefox always have few windows and a bunch of tabs open and when traveling quite often I want to open firefox quickly to check something but I do not want to have it coming with all its windows and tabs.

Until now, I used either different browser or midori that allows starting it directly in private mode in these situations.

So this morning I took myself by the hand and looked closer at fixing my system for my use-case:

The recipe turned out to be pretty simple:

1/ Get the firefox.desktop file:

 cp /usr/share/applications/firefox.desktop ~/firefox-private.desktop

2/ Adjust it as follow:

-Name=Firefox
+Name=Firefox (private browsing)
[...]
-Exec=firefox %u
+Exec=firefox -private-window %u

3/ Install the new desktop file:

3.1/ In /usr/share/applications/ for every users on the system

 sudo cp ~/firefox-private.desktop /usr/share/applications/

or

3.2/ In ~/.local/share/applications/ for your user only

 sudo cp /.local/share/applications/

With this trick, you can now start firefox in private browsing mode directly from the menu.

Monday, December 15 2014

Fedora 21 release day, 7 days later

Last week Tuesday, we released the 21st version of Fedora. The morning of the release we noticed that the load of some of the proxies was running very high. So we started checking our monitoring for the incoming traffic. A week later, this is an overview of the traffic on our proxies over the last ten days (so 3 days before the release and 7 days since).

collectd_f21.png

The third one is quite impressive and looking at more of these graphs we can see a similar pattern where the traffic for F21 release really bumped on release day and the following two days and is now slowly recovering.

If you want to see more of these pretty pictures/graphs, check our collectd

Friday, December 12 2014

Infra FAD 2014 - Part 2: Ansible

Part 1: MirrorManager

It has been two days since I came back and others have already reported about our progress (Ralph, kevin day 0 & 1, kevin day 2, kevin day 3, kevin day 4 and finally, kevin day 5) but I wanted to came back on it as well :)

So seven of us from the Fedora Infrastructure team meet up in Raleigh in the Red Hat office there. We had Matt Domsch for the first couple of days to help us understanding and apprehending how MirrorManager works (see Part 1).

The second part of the FAD was dedicated around moving forward the infrastructure task of moving away from puppet in favor of Ansible. This is led to the most productive week we ever had on our Ansible git repo. I have been able to start porting things like varnish or haproxy while Ralph was doing the heavy lifting on working on porting the proxies themselves. Patrick worked on porting the nameservers and managed to actually re-install them using Ansible (and moving them to RHEL7 while at it). Smooge has been poking at the setup for fedorapeople.

With all that we also managed to get MirrorManager2 in staging and Luke wrote some awesome unit-tests for mirrorlist which already allowed us to make still some small optimizations.

All in all, I have to say that I have had a great time. I have the feeling that we achieved a lot of what we wanted to do and that we have been really efficient at it :-)

To remain critical about the organization. I think I agree with Ralph that for the next FAD we should be extra-careful to really organise some sort of social event. We have had strange hours (having lunch at 3pm or even 5pm once) and the one afternoon where we said we would take off we ended up working... Being involved in the organization while not on site makes it difficult to find something nice for the social event, but I think we/I should have tried harder to find something nice to do.

Anyway, like I said, I have a great time and I'm thankfull to everyone that have been able to make it to Raleigh, to the OSAS team at Red Hat that funded most of this FAD and to Ansible for inviting us for dinner on Friday evening :-)

Thanks a bunch folks!

DSC_0026.1.JPG

Saturday, December 6 2014

Infra FAD 2014 - Part 1: MirrorManager

The last two days have been quite busy for the Fedora infrastructure team. Most of us are indeed meeting up in Raleigh, in the Red Hat tower down-town and together with Matt Domsch, the original developer of MirrorManager, we have been on MirrorManager2.

It was really great for us that Matt could join. MirrorManager is pretty straight forward in theory but also full of small details which can make it a hard to understand fully. Having Matt with us allowed us to ask him as many questions as we wanted. We were also able to go with him through all the utility scripts and all the crons that make MirrorManager working.

The good surprise was that a significant part of the code was already converted for MirrorManager2, but we still found some crons and scripts that needed to be ported.

So after spending most of the first day on getting to understand and know more about the inner processes of MirrorManager, we were able to start working on porting the missing parts to MirrorManager2.

We also took the opportunity to discuss with Matt, Luke and David how things should look like for atomic and Ralph was able to make the first changes to make this a reality :-)

So yesterday evening we had all the crons/scripts (but one in fact that one isn't needed for MM2) converted to MirrorManager2 \ó/

That was a good point to stop and go quickly to the Red Hat Christmas party before meeting Greg who invited us for a dinner sponsored by Ansible. We had a really nice meal and evening, thanks Greg, thanks Ansible!

Today started the second part of the FAD: Ansible, but more on that later ;-)

Wednesday, October 15 2014

Fedora-Infra: Did you know? The package information are now updated weekly in pkgdb2!

The package database pkgdb2 is the place where is managed the permission on the git repositories.

In simple words, it is the place managing the "who is allowed to do what on which package".

For each package, when they are created, the summary, the description and the upstream URL from the spec file are added to the database, which allow us to display the information on the page concerning the package. However, until two weeks ago, this information was never updated. That means that if you had an old package whose description had changed over time, pkgdb would present the one from the time the package was created in the database.

Nowadays, we have a script running on a weekly basis and updating the database. Currently, this script relies on the information provided by yum's metadata on the rawhide repo. This means that packages that are only present in EPEL or that are retired on rawhide but present in F21, will not have their information updated. This is likely something we will fix in the future though.

In the mean-time, you can now enjoy a pkgdb with summary and description information for almost all packages!

As an example, checkout the fedocal page, you can now see a link to the upstream website, a short summary and a little longer description of the project.

Also, to give you a little hint on the amount of updates we did:

The first time we ran the script:

 16638 packages checked
 15723 packages updated

Last week's run:

 16690 packages checked
 50 packages updated

Friday, July 25 2014

The Joy of timezones

Today, I was looking at fedocal as I found out it could not import its own iCal files.

Well, to be exact, the import worked fine but then it was not able to display the meeting. The source of the issue is that the iCal output is relying on timezone name such as EDT or CEST while fedocal actually expects timezone to be of type US/Eastern or Europe/Paris.

So I went looking for a way to convert the acronyms to real timezone.

I finally found out the following script:

import pytz
from datetime import datetime

timezone_lookup = dict()
for tz in pytz.common_timezones:
    name = pytz.timezone(tz).localize(datetime.now()).tzname()
    if key in timezone_lookup:
        timezone_lookup[name].append(tz)
    else:
        timezone_lookup[name] = [tz]

for key in sorted(timezone_lookup):
    print key, timezone_lookup[key]

Which led me to discover things like:

  IST ['Asia/Colombo', 'Asia/Kolkata', 'Europe/Dublin']

The Indian Standard Time and the Irish Standard Time have the same acronym

but also:

  EST ['America/Atikokan', 'America/Cayman', 'America/Jamaica', 'America/Panama', 'Australia/Brisbane', 'Australia/Currie', 'Australia/Hobart', 'Australia/Lindeman', 'Australia/Melbourne', 'Australia/Sydney']

So how to handle this?

The only solution I could came up with is relying on both the acronym and the offset between that timezone and UTC

Adjusted script:

import pytz
from datetime import datetime

timezone_lookup = dict()
for tz in pytz.common_timezones:
    name = pytz.timezone(tz).localize(datetime.now()).tzname()
    offset = pytz.timezone(tz).localize(datetime.now()).utcoffset()
    key = (name, offset)
    if key in timezone_lookup:
        timezone_lookup[key].append(tz)
    else:
        timezone_lookup[key] = [tz]

for key in sorted(timezone_lookup):
    print key, timezone_lookup[key]

And corresponding output:

...
('EST', datetime.timedelta(-1, 68400)) ['America/Atikokan', 'America/Cayman', 'America/Jamaica', 'America/Panama']
('EST', datetime.timedelta(0, 36000)) ['Australia/Brisbane', 'Australia/Currie', 'Australia/Hobart', 'Australia/Lindeman', 'Australia/Melbourne', 'Australia/Sydney']
...
('IST', datetime.timedelta(0, 3600)) ['Europe/Dublin']
('IST', datetime.timedelta(0, 19800)) ['Asia/Colombo', 'Asia/Kolkata']
...

So much fun...

Wednesday, July 23 2014

New package, new branch, new workflow?

If you are a Fedora packager, you are probably aware of the new pkgdb.

One question which has been raised by this new version is: should we change the process to request new branches or integrate new packages in the distribution.

The discussion has occurred on the rel-eng mailing list but I'm gonna try to summarize here what the process is today and what it might become in the coming weeks.

Current new-package procedure:
  1. packager opens a review-request on bugzilla
  2. reviewer sets the fedora-review flag to ?
  3. reviewer does the review
  4. reviewer sets the fedora-review flag to +
  5. packager creates the scm-request and set fedora-cvs flag to ?
  6. cvsadmin checks the review (check reviewer is a packager)
  7. cvsadmin processes the scm-request (create git repo, create package in pkgdb)
  8. cvsadmin sets fedora-cvs flag to +
New procedure
  1. packager opens a review-request on bugzilla
  2. reviewer sets the fedora-review flag to ?
  3. reviewer does the review
  4. reviewer sets the fedora-review flag to +
  5. packager goes to pkgdb2 to request new package (specifying: package name, package summary, package branches, bugzilla ticket)
  6. requests added to the scm admin queue
  7. cvsadmin checks the review (check reviewer is a packager¹)
  8. cvsadmin approves the creation of the package in pkgdb
  9. package creation is broadcasted on fedmsg
  10. fedora-cvs flag set to + on bugzilla
  11. git adjusted automatically

Keeping the fedora-cvs flag in bugzilla allows to perform a regular (daily?) check that there are no fedora-review flag set as + that have been approved in pkgdb and whose fedmsg message hasn't been processed.

Looking at the number, it looks like there are more steps on the new procedure but eventually, most of them can be automated.

New branch process

For new branches, the process would be very similar:

  1. packager goes to pkgdb2 to request new branch
  2. requests added to the scm admin queue
  3. cvsadmin checks the request (requester is a packager...)
  4. cvsadmin approves the creation of the branch in pkgdb
  5. branch creation is broadcasted on fedmsg
  6. git adjusted automatically

Tuesday, July 8 2014

1 year

Today is the first anniversary of the day we said good-bye to a good friend.

There has been a number of tributes in the couple of months following his disappearance, and there are still some once in a while. Personally, I hardly spend a week without remembering him or asking myself "What would Seth say?".

Good bye old friend, may your wisdom lead us.

Thursday, June 26 2014

Faitout, 1000 sessions

A while back, I introduced faitout on this blog.

Since then I have been using it to tests most if not all the project I work on. I basically use the following set-up:

DB_PATH = 'sqlite:///:memory:'
FAITOUT_URL = 'http://209.132.184.152/faitout/'
try:
    import requests
    req = requests.get('%s/new' % FAITOUT_URL)
    if req.status_code == 200:
        DB_PATH = req.text
        print 'Using faitout at: %s' % DB_PATH
except:
    pass

This way, if I have network, the tests are run with faitout and thus against a real postgresql database while if I do not have network, they run against a sqlite in memory database.

This set-up allows me to work offline and still be easily able to run all the unit-tests as I change the code.

What the point of this blog was actually more to announce the fact that despite it's limited spread (only 25 different IP addresses have requested sessions), the tool is used and it has already reached the 1,000 sessions created (and dropped) in less than a year.



If you're not using it, I am inviting you to have a look at it, I find it marvelous in combination with Jenkins and it does help finding bugs in your code.

If you are using it, congrats and keep up the good work!!

Tuesday, June 17 2014

Fedocal 0.7

This morning I released fedocal version 0.7.1.

With this version comes a number of new features which I thought would be nice to advertise a little :-)

The main calendar view & the menu

The main calendar view has had two additions:

  • a pop-up stipulating if there are meetings present that week that are not displayed in the current window (for example, if you're seeing the meetings from 8am to 6pm and there is a meeting at 7pm, or at 4am).
  • shortcuts to interact more easily with the calendar. These shortcuts contains three actions: Add a meeting, switch to list/calendar view, iCal feed.

The menu now highlights the calendar you are looking at to make things easier on you.

popup-highlight-shortcuts.png

The list view

When viewing a calendar as list, fedocal will now automatically scroll down to the display the meetings of today or the future meetings.

In addition, this page also has the three shortcut buttons mentioned above (add meeting, switch view mode, iCal feed).

autoscroll-shortcuts.png

The detail view

We have added three new features in the page showing the details of a meeting

  • permalink: when the user clicks on the pop-up showing the details of a meeting the url is updated to provide a permalink to that specific meeting. This allows one to copy/paste the url and send it to someone.
  • countdown: with the help from mpduty we have added a countdown in the meeting detail view showing the remaining time before the meeting starts. This can nicely circumvent the timezone conversion if you are not logged in fedocal and want to know when a meeting starts
  • UTC titles: if you hover over the dates/times with your mouse, the date/time will be shown in UTC which is always handy as in our community UTC remains quite often the most used way to communicate date/time.

detail_view2.png



I would like to take here the opportunity to thank kparal, ralph, willo, red and lbrabec for their bug reports and RFE that led to all these changes which I think are making fedocal 0.7.1 its best release so far :-)

Friday, April 11 2014

Presentations at FOSDEM and DevConf 2014

This year I attended both FOSDEM and DevConf and at both conference I was given the possibility to give a presentation.

At FOSDEM, together with the Debian developer Nicolas Dandrimont, we gave a presentation about fedmsg for both the Fedora and the Debian infrastructure.

At DevConf, I gave a presentation about Automation in the Fedora lan presenting all the tools available to our developers to help them do their best work.



Both presentations have been made available now :)

Thursday, April 10 2014

Back on LGM 2014

Last week I have had the opportunity to attend my first Libre Graphic Meeting conference, this year located in Leipzig (Germany). Not being much of a graphic person, I must say that I was sometime lost a bit in some of the talks (being during a presentation or at the coffee corner), but on the other side I have learned a lot! I discovered a whole new side of the Open-Source Software community working on low-level tools and algorythms for image and video manipulation. Meeting these people with such a deep understanding of computer science and photo, for example, was a really extremely enriching experience.

I have learned about image manipulation and the cool effects provided in gimp by the g'mic project. I have met some of the dev of the darktable and inkscape projects, these guys are doing a remendous work, kudos!

On the Friday, we had a presentation about the gooseberry project by the Blender foundation. If you have not pledged to help them, go do it now!. Their project is amazing and need more help!

Another amazing talk was Sebastian Koenig presenting us his work on reviving a medial manikin with Blender. Basically the story is that a museum in Leipzig (the GRASSI Museum für Angewandte Kunst Leipzig) had this old maniki (22.5cm tall) which used to be animated, you could move her arms, legs, fingers or toes but it got old and stucked. So the museum in collaboration with the university did some sort of scan of the manikin and they asked Sebastian Köning to see if he could reconstruct the manikin using Blender. The resulting movie is now on display in the museum next to the actual manikin. I found this research amazing both from a technical and a historical point of view! And icing on the cake, since they had the mesh to reconstruct the animation on Blender they have also been able to make a 3D printed replicate of the manikin giving it back its ability to move.

On the last day, I was able to attend a workshop offered by Tobias Ellinghaus darktable developer and Patrick David about image manipulation on darktable and gimp. I had to leave before the end but the workshop was really, really interesting. Patrick did a live image editing demo in gimp, performing it on photo taken just a few minutes before. I need to practice this a little bit otherwise I'm going to forget all the good tips that were given.

I could also discovered some cool project related to DSLR such as the Magic Lantern which provides a new OS for Canon DSLR, awesome right? There is also the entangle project allowing to remotely control your DSLR, quite handy for macro or astro photos.

I was also given the possibility to contribute to the party. gnokii and I gave a presentation about nuancier as a FOSS contributing and voting application for wallpapers. I think it was well-received and there is apparently already interest to update it to support font. In addition, I took the opportunity, during a lightning talks session, to present HyperKitty and its demo instance which also seem to have brought quite some interest.



All in all, this was my first LGM meeting, I learned a lot about the whole libre graphic ecosystem, met a lot a new people and was given the opportunity to introduce a couple of projects dear to me. I really enjoyed it and would advise it to anyone interested, even remotely, into libre graphic.

Thank you for anyone that helped me attend or enjoying it (Gnokii, Ryan, Garrett, Chris and all the others ;-))!

Tuesday, February 4 2014

Evolution of our contributors in Fedora

As you may know, Fedora is under-going a rather large change with Fedora.Next proposition/evolution. One of the point that Fedora.Next addresses is the loss of users observed in Fedora for few years.

The statistics page on the wiki as well as my own representation of the same numbers are both out-dated so we don't really have a clear view on this.

However, since October 2012, all the messages sent onto the fedmsg bus are being stored in datanommer. And that's information we can use to see how we're doing with regards to our contributors.

I asked and got a dump of the datanommer database (the data is anyway publicly accessible in datagrepper) and ran my traditional script on it to gather some numbers.

I generated on a daily, weekly and monthly basis the graph of the number of (distinct) active contributors we have.

Here are the results :-)

contributors_daily_stats.png

contributors_weekly_stats.png

contributors_monthly_stats.png

Three interesting periods:

  • the period without any messages in March 2013 is the period where the bus was down and we did not realize it (since we have a nagios check for the bus)
  • on the daily graph you can really see the dip created by Christmas and its holidays
  • on the monthly graph, the pick in August 2013 coincides with Flock and the launch of badges!


Looking at the graph generated by this week in fedora, in December we launched COPR and it seems that the number of posts on the planet has also quite increased in December and January. Does this alone explain the bump we observe here?

Monday, February 3 2014

Dynamic point of contact assignment (2)

Recently I spoke about dynamic point of contact assignment in pkgdb2, I had generated some global stats about general changes but nothing specific, so here is a little more information about the impact this would have for packagers:

 652 packagers lose at least one package
 In average they lose 6.82668711656 packages
 392 packagers gain at least one package
 In average they gain 11.7168367347 packages
 
 Top 10 packagers losing packages:
    iarnell loses 305 packages : 385 -> 80
    spot loses 185 packages : 348 -> 163
    jplesnik loses 173 packages : 214 -> 41
    than loses 167 packages : 185 -> 18
    steve loses 129 packages : 137 -> 8
    eseyman loses 97 packages : 190 -> 93
    psabata loses 76 packages : 150 -> 74
    jwrdegoede loses 70 packages : 173 -> 103
    corsepiu loses 53 packages : 112 -> 59
    mathstuf loses 51 packages : 63 -> 12
 
 Top 10 packagers gaining packages:
    ppisar gains 1353 packages : 295 -> 1648
    rdieter gains 241 packages : 135 -> 376
    kalev gains 127 packages : 43 -> 170
    limb gains 123 packages : 234 -> 357
    pghmcfc gains 114 packages : 176 -> 290
    pbrobinson gains 106 packages : 58 -> 164
    remi gains 101 packages : 212 -> 313
    mizdebsk gains 97 packages : 54 -> 151
    spot gains 93 packages : 348 -> 441
    petersen gains 75 packages : 141 -> 216

Graphically this is how it looks:

packages_lost_per_packagers.png

packages_won_per_packagers2.png

What about relative lost/gained, so instead of the number of packages let's look at the % of packages lost/gained relative to the number of packages that this user is the current POC:

 Top 10 packagers losing packages (in %):
    <... 142 packagers...> lose 100.0% packages
    steve loses 94% packages
    than loses 90.2% packages
    silfreed loses 90% packages
    packaging-team loses 89% packages
    yyang, sxw lose 87.5% packages
    amdunn, rocha, kylev lose 85% packages
    pvrabec, huwang, jdornak, hvad lose 83% packages
    timn loses 82% packages
    mathstuf loses 81% packages
 
 Top 10 packagers gaining packages (in %):
    paragn gains 1325.0% packages
    atkac gains 1100.0% packages
    crobinso gains 1000.0% packages
    hegdevasant gains 700.0% packages
    aalvarez gains 550.0% packages
    ppisar gains 459% packages
    airlied gains 433% packages
    pmachata gains 417% packages
    jkastner, jpeeler gain 400% packages
    adamwill gains 350% packages

Below is a graphical distribution of the packagers by the percentage of packages they lose:

packages_lost_per_packagers_pc.png

So from this we can conclude:

  • We have two packagers standing out with regards to the number of packages they would gain with a dynamic POC assignment
  • We have one packager standing out as it appears he/she has a lot of packages but is not working on them so much anymore
  • Some packager are both losing and gaining packages
  • We need to filter out the groups maintaining packages, but with the move to pkgdb2 it will be easier to filter them out
  • Quite a number of person are losing all their packages with dynamic POC assignment. There are also two peaks around 50% and 33%.
  • Amusingly, ppisar who gains the most packages is not the one gaining the most packages relatively to the number of packages he already owns


As before I put the script I wrote to gather these stats on my cgit

Friday, January 31 2014

Conferences & talks -- Part 1: FOSDEM 2014

February is always a busy month and this year will be no exception.

Later today I am leaving for Brussel to attend FOSDEM over the week-end, with as added bonus a presentation on Sunday.

The presentation will be about fedmsg and its ecosystem and one of the particularity of this talk is that it will be done together with Nicolas Dandrimont (his blog) who is a Debian developer.

Think about how awesome it is to have in the distribution track a talk about a technology and its possibilities given by two person from two different distributions.

I must say I am looking forward this presentation :-)

- page 2 of 8 -