Log in

entries friends calendar profile Previous Previous Next Next
More on Fedora Packagers.... - Jef"I am the pusher robot"Spaleta
ramblings of the self-elected Fedora party whip
More on Fedora Packagers....
Aug 21st... Fedora Development Branch:

  Total Maintainers  : 770
  Red Hat Maintainers: 282

Just over a 36% of the maintainer manpower in Fedora is associated with Red Hat (not necessarily tasked to do it) So how is that spread around? Are the Red Hat associated maintainers doing proportionally more of the packaging work?

  Total Maintained Source Packages: 8693
  Total Maintained Source Packages with at least one Red Hat Maintainer listed: 3493

~40% of the maintainer workload Fedora is associated with Red Hat (not necessarily tasked to do it) That's pretty much in line with manpower split above. So to answer the question...no. The Red Hat associated maintainers don't appear to be doing disproportionately more or less work than external community in aggregate.  The issue of co-maintainership muddies things a bit..so lets dig a little deeper.

  Co-Maintained packages with at least 2 maintainers: 2157
  Co-Maintained packages where there is at least one red hat maintainer: 1480
~68% of Co-maintained packages have a Red Hat associated co-maintainer.... that's interesting.

  Solo Maintained packages: 6541
  Solo Maintained packages with red hat maintainer: 2013
~30% of Solo Maintained packages are maintained by a Red Hat associated maintainer.

So...what's that say to me? It says that generally speaking the amount of effort being expended in the Fedora packaging space is dominated by external community and that Red Hat associated maintainers are doing work in proportion to their numbers in relation to the external community.  Individuals like spot may stand out with a large number of maintained packages..but that has more to do with the fact that spot is crazy..and not a trend for Red Hat associated maintainers.  In aggregate, from a package count and maintainership count point of view Red Hat associated manpower is not dominate. It really is a community effort in a repository wide sense.  Does the analysis for the newly identified critical packageset look any different? I don't know..I could find out if someone was interested.

I will say that the Red Hat associated maintainers are however doing a disproportionately better job at forming maintainership teams than the external community.   I'll look at that in more detail next. I'd appreciate if someone could tell me how to build a script with the python fedora bindings which let me tell the difference between primary maintainer from secondary maintainers.
2 comments or Leave a comment
jkeating From: jkeating Date: August 22nd, 2009 12:30 am (UTC) (Link)

Numbers aren't everything

While numbers are interesting, numbers mean next to nothing as to the complexity of the package(s) in question, and what the maintainer does with them beyond whipping up a .spec file for it and calling it a day.

Perhaps a more fun metric to look at would be the number of RHT people maintaining in one way or another a critical path package.
jspaleta From: jspaleta Date: August 22nd, 2009 02:50 am (UTC) (Link)

Re: Numbers aren't everything

right! Accounting for complexity and difficulty level is harder. If you have some ideas on that, I'm all ears. I'm also interested in knowing what sort of questions you'd like to have answered that would be useful for what your doing day to day in release eng..even if you don't have any ideas how to answer them.

I mention the critical path workload question in the post. Is the critical package list as list of critical source package or is it a list of binary packages. The script I'm using looks at source packages (aka components) So if you can give me a list of source packages I'm totally there.

Max already asked I can do this for per-spin..but spins are defined as a set of binary packages and I'd have to convert back to source packages. Doable but extra complexity.

2 comments or Leave a comment