Search Results: "Wichert Akkerman"

13 August 2012

Raphaël Hertzog: Looking back at 16 years of dpkg history with some figures

With Debian s 19th anniversary approaching, I thought it would be nice to look back at dpkg s history. After all, it s one of the key components of any Debian system. The figures in this article are all based on dpkg s git repository (as of today, commit 9a06920). While the git repository doesn t have all the history, we tried to integrate as much as possible when we created it in 2007. We have data going back to April 1996 In this period between April 1996 and August 2012: Currently the dpkg source tree contains 28303 lines of C, 14956 lines of Perl and 6984 lines of shell (figures generated by David A. Wheeler s SLOCCount ) and is translated in 40 languages (but very few languages managed to translate everything, with all the manual pages there are 3997 strings to translate). The top 5 contributors of all times (in number of commits) is the following (result of git log --pretty='%aN' sort uniq -c sort -k1 -n -r head -n 5):
  1. Guillem Jover with 2663 commits
  2. Rapha l Hertzog with 993 commits
  3. Wichert Akkerman with 682 commits
  4. Christian Perrier with 368 commits
  5. Adam Heath with 342 commits
I would like to point out that those statistics are not entirely representative as people like Ian Jackson (the original author of dpkg s C reimplementation) or Scott James Remnant were important contributors in parts of the history that were recreated by importing tarballs. Each tarball counts for a single commit but usually bundles much more than one change. Also each contributor has its own habits in terms of crafting a work in multiple commits. Last but not least, I have generated this 3 minutes gource visualization of dpkg git s history (I used Planet s head pictures for dpkg maintainers where I could find it). <iframe allowfullscreen="allowfullscreen" frameborder="0" height="281" src="http://www.youtube.com/embed/1x9-Etj1Ew4?fs=1&amp;feature=oembed" width="500"></iframe> Watching this video made me realize that I have been contributing to dpkg for 5 years already. I m looking forward to the next 5 years :-) And what about you? You could be the 147th contributor see this wiki page to learn more about the team and to start contributing.

No comment Liked this article? Click here. My blog is Flattr-enabled.

13 March 2011

Lars Wirzenius: DPL elections: candidate counts

Out of curiosity, and because it is Sunday morning and I have a cold and can't get my brain to do anything tricky, I counted the number of candidates in each year's DPL elections.
Year Count Names
1999 4 Joseph Carter, Ben Collins, Wichert Akkerman, Richard Braakman
2000 4 Ben Collins, Wichert Akkerman, Joel Klecker, Matthew Vernon
2001 4 Branden Robinson, Anand Kumria, Ben Collins, Bdale Garbee
2002 3 Branden Robinson, Rapha l Hertzog, Bdale Garbee
2003 4 Moshe Zadka, Bdale Garbee, Branden Robinson, Martin Michlmayr
2004 3 Martin Michlmayr, Gergely Nagy, Branden Robinson
2005 6 Matthew Garrett, Andreas Schuldei, Angus Lees, Anthony Towns, Jonathan Walther, Branden Robinson
2006 7 Jeroen van Wolffelaar, Ari Pollak, Steve McIntyre, Anthony Towns, Andreas Schuldei, Jonathan (Ted) Walther, Bill Allombert
2007 8 Wouter Verhelst, Aigars Mahinovs, Gustavo Franco, Sam Hocevar, Steve McIntyre, Rapha l Hertzog, Anthony Towns, Simon Richter
2008 3 Marc Brockschmidt, Rapha l Hertzog, Steve McIntyre
2009 2 Stefano Zacchiroli, Steve McIntyre
2010 4 Stefano Zacchiroli, Wouter Verhelst, Charles Plessy, Margarita Manterola
2011 1 Stefano Zacchiroli (no vote yet)
Winner indicate by boldface. I expect Zack to win over "None Of The Above", so I went ahead and boldfaced him already, even if there has not been a vote for this year. Median number of candidates is 4.

30 January 2009

Wichert Akkerman: An update from the Plone UI sprint

I have been told that not enough information about the Plone user interface sprint at Informaat is getting out. That is not due to a non-disclosure agreement for attendees; all of us have just been too busy working and enjoying ourselves to get to such mundane things as writing reports or blog posts. This sprint is somewhat different than normal sprints: the goal is not to produce as much code as possible, but to lay a foundation for the user interface for future versions of Plone. This requires a lot of thought and prototyping to figure out the right concepts, both in the user interface itself and the backend code on top of which it is built. A lot of this work is done on top of the work done by the little known deco group. There are a few guiding ideas behind the work done at this sprint: We divided the activities in five areas: content editing, control panels, page assembly, backend and tests. The first day was almost entirely spent on brainstorming, which is very rare for a Plone sprint. This was extremely useful, and provides us with a solid foundation for the rest of the sprint, and ongoing improvement of the Plone user interface.

12 January 2009

Wichert Akkerman: TinyMCE and jQuery0

If you ever used TinyMCE and jQuery in a project chances are that you have seen this error:
tinyMCE is not defined
This might be browser dependent: I see this in Firefox, but Safari has no problems at all. At times this can be bad enough that Firefox will block loading the page, refuses to reload it and needs to be restarted. Doing a few searches revealed that others have noticed the same problem, but I could not find an answer. It turns out the solution is simple: you have to scope your javascript properly. This breaks:
 $(document).ready(function()  
    tinyMCE.init(....);
 
but this works fine:
(function($)  
    tinyMCE.init(....);
 )(jQuery);

22 April 2007

Wichert Akkerman: Debian upgrade experience

With the recent release of Debian etch (usability note: why can't that URL be per-release? All the info on sarge suddenly is not reachable at the location people bookmarked anymore) I figured I would try upgrading some servers to it. Debian has always had excellent in-place migration handling, so this should be easy, right? If only.. I will stay with sarge for a while longer.

4 September 2006

Branden Robinson: The Lucky Winner

Last night at the "formal dinner"* at DebConf 5, Anand Kumria presented me with a nice little tote bag that says "Debian: 10 years, 100 countries, 1000 developers, 10000 packages". It's a couple of years out of date now, but still pretty cool. Anand suggested that we give it away as a sort of prize. Since I was sitting across the table from former DPL Wichert Akkerman and we had two other former DPLs in attendance, Bdale Garbee and Ian Jackson, I thought I'd sweeten the item's collectibility by having all of us autograph it. This was swiftly done. After much dithering among my tablemates and I, and many ideas that fizzled regarding closed bugs or frequency of usage of the term "cabal" on the mailing lists, we ultimately settled on a method that was reasonably fair, if boring: the old game of "guess the unsigned 16-bit integer". We went outside and proceeded by binary search, disqualifying half the group at a time. The ultimate winner was Frank Lichtenheld, who guessed that the number was between 20k and 24k. *Fortunately, the dress code was not formal — the formality was that we ate from plates instead of cafeteria trays. ;-).

4 August 2006

Wichert Akkerman: Hooking trac into CIA

If you work on open source projects and hang out on irc changes are you are familiar with CIA. CIA provides a convenient way to stay in touch with what is happening in a source code repository by reporting on all activity real time. Of course there is much more to a project than just source code changes: issue tracking is just at least as important, if not more. So wouldn't it be nice if CIA can report on activity there as well? If you are using trac now you can, with this patch: trac-cia.diff This adds a couple of new option to your trac.ini file which confifure the trac-CIA interface:
[notification]
send_to_cia = true
cia_project = YourCiaProjectName
cia_server = http://cia.navi.cx
This patch tells trac to report all newly opened tickets to CIA, which will show up like this:
<CIA-13> wichert * r #5725 Issue tracker/: [Infrastructure] trac/cia
	 testing ticket

Wichert Akkerman: Hooking trac into CIA

If you work on open source projects and hang out on irc changes are you are familiar with CIA. CIA provides a convenient way to stay in touch with what is happening in a source code repository by reporting on all activity real time. Of course there is much more to a project than just source code changes: issue tracking is just at least as important, if not more. So wouldn't it be nice if CIA can report on activity there as well? If you are using trac now you can, with this patch: trac-cia.diff This adds a couple of new option to your trac.ini file which confifure the trac-CIA interface:
[notification]
send_to_cia = true
cia_project = YourCiaProjectName
cia_server = http://cia.navi.cx
This patch tells trac to report all newly opened tickets to CIA, which will show up like this:
<CIA-13> wichert * r #5725 Issue tracker/: [Infrastructure] trac/cia
	 testing ticket

16 April 2006

Wichert Akkerman: Using a seperate Data.fs for the catalog

It has been argued that it makes sense to use a seperate ZODB to store a catalog for Zope sites. So far I have not been able to find any benchmarks that substantiate this claim. Without doing any benchmarks I can think of three reasons why this makes sense: It would be nice if someone can extend this list and do benchmarks proving that this ZODB split indeed helps (or that it does not in which case a lot of us can simplify our setups). Update: alecm mentioned a very good reason: catalog searches, which can wake up a large amount of small objects, should not cause other objects to be pushed out of the cache.

27 December 2005

Joey Hess: all this for a progress bar?

Over the past months we've been working on a big change in the debian installer, removing base-config from the installation process. Doing this has required a great many changes, some of them user-visible. The installer now configures the timezone, users and passwords, and apt all in the first stage instead of after rebooting. Some preseed values have been removed or changed, including base-config/early_command and base-config/late_command. The biggest change of all, the the hardest to get working, has been moving of the selection of tasks and the installation of all packages into the first stage of the installer. Now tasksel pops up a debconf question that looks like any other question d-i asks, and the installation of packages is hidden behind a nice clean progress bar, and if any packages use debconf to ask questions, d-i will display those questions using its frontend too. I'd include a screenshot, but really, it's just another progress bar, how boring is that? By the way, if you maintain a debian package and it prompts without using debconf (when debconf is available), then your package will obviously break this, and it's well past time to fix it. I think that all the packages d-i installs do use debconf except for possibly a few like libc during upgrades. Upgrades are theoretically possible at this step for any packages debootstrap installs, so those will need to be fixed too. This has been a long, long time coming. Some milestones include: So yeah, this has been in er, progress for 8 years, and at least three Debian derived distributions have come up with thier own approaches in between with only the last one being quite similar to the end result, and the other two being rather dead. I don't know whether this is a study in how Debian is slow, or a study in how we do eventually come up with infrastructure that is done right and ends up being used by everyone. Or both.

20 December 2005

Wichert Akkerman: Implementing a testing status for trac

As many other people, I have become addicted to the trac system. After having used it for a few personal projects and deciding that it really is cool technology and talking about it with a few other people I switched Plone from its old issue tracker to trac and the result has been marvelous: it runs smoothly with over 5000 tickets and produces great overviews such as this 2.1.x release issue status overview. However for our projects at Amaze we are missing an essential feature: the ability to have a testing status for issues. This is a seperate step between active and resolved where an issue should be resolved, but has not been certified to be resolved by full testing, which is (should) be done by other people. To support this I created a patch which added a new ticket status called 'testing', modified the milestone and roadmap to show that tickets in a testing status seperately and updated the unittests to reflect the new possible actions. screenshot of trac roadmap view with testing status In order to make this easier to use I also modified the trac-post-commit subversion hook: I added a --testing parameter which tells the hook to mark an issue as testing instead of fixed. The default is set to fixed in order to preserve backwards compability, and since I suspect that most trac installs are for small projects which do not have a need for a seperate testing status. If you are curious: you can download trac testing patch from here or look at trac ticket 2511. The patch is based on the current svn trunk for trac. Update: seems the trac folks already closed the issue since there is a larged project in progress which provides the same functionality (and more). However since there is no assigned milestone or estimate when it might be merged, so until then I still consider this patch to be a very useful addition to trac.