When voting on the current Debian Maintainers General Resolution, I think it’s worth to think about the following questions: What is the difference between a Debian Maintainer and a Debian Developer? Who is interested in becoming a Debian Maintainer and not a Debian Developer and why? Will this Debian Maintainer class really improve the situation for New Maintainers?
I suppose most of our New Maintainers will aim to become a Debian Maintainer just to bridge the time until they’re full Debian Developers. And I predict that this is also the major target audience for this new Debian Maintainers class. Some people said on -vote that there are people actually interested in becoming a Debian Maintainer and not a Debian Developer. Personally I find their reasons questionable, but after all I suppose there won’t be many people going this route. On the other side, I don’t see how this new class enhances the situation for the New Maintainers. Now they not only wait for the Application Manager, Front Desk and Debian Account Managers — No, now they will also search for someone who advocates them to become a Debian Maintainer and have to wait for their key being added to the Debian Maintainers keyring.
So my question is: If this General Resolution mainly helps New Maintainers, why must it be so complicated? Why another class of contributers, all those complicated rules to set it up and this additional layer of bureaucracy? Why don’t we aim for something simple, like improving our New Maintainer process. I would rather see some of those Debian Maintainer rights granted to New Maintainers after a certain point in their New Maintainer career, but not in this complicated and overengineered way the Debian Maintainer class proposes.
does anyone know a small web calendar which has a web frontend and does not rely on a database server? It should save it’s data directly into .ical (or .ics) files so I can fetch and alter them with a desktop calendar application too.
I don’t need fancy features like multi user support or the ability to publish calendars, I just want do see and edit my calendar/todo stuff when I’m not at home and have the .ical saved on a centralized (my) server to make it available for desktop calendar software.
For privacy reasons it has to run on my own server.
I’ve just uploaded a new version of reportbug-ng including an Italian and a Hebrew pony and a cool enhancement to the buglist filter: Now the filter doesn’t try to match the whole string anymore but splits the input by whitespaces and tries to match all words. Now you can even exclude words by prepending a leading minus to it.
The Syntax for the filter is:
[-]keyword [[-]keyword2] ...
Multiple keywords are separated by whitespaces and can have a leading minus. A leading minus means “exclude” the whitespaces represent the logical AND.
foo bar -baz means all bugs containing the words foo, bar and not baz
outstanding -wishlist means all bugs which are outstanding and not wishlist
-resolved will show all open bugs
Please note the the filter does look into the actual bugreports (the fulltext), it currently tries to match against the packagename, the bugnumber, the summary, the status and the severity.
The best thing about this new filter? It’s not even slower than the old one, the only delay you’ll notice is when filtering packages with a huge amount of bugs (like wnpp) and even there the filter just needs a fraction of a second. The delay of a few secons comes acutally from the QTable when I remove all the rows not matching the filter.
-showRow(int) seem to be very expensive even when I temporary disable all graphic updates for this widget during this operation. If someone knows a trick to circumvent this, please tell me (you may get a pony…).
This feature isn’t spectacular, but it should make filtering big buglists a lot easier.
Waiting ten days for rng to slip into testing, I had enough time to stuff the next version with new features and small bugfixes. The most interesting ones are:
- Added SOAP support and enabled it by default. Feel free to mess around with the look and feel of our BTS, rng doesn’t depend on it anymore.
- Support for WNPP bugs. Well, you could use rng to file WNPP bugs before, but now rng actively supports you with a nice template for ITP and RFP reports.
- Mayor user interface overhaul.
- Use freedesktop.org’s xdg-utils to decide which browser to use to open URLs. This should allow rng to open the browser you set as default in your desktop environment.
In totally unrelated news, I finally managed to master Rubenstein’s Revenge.
Gustavo writes about python, it’s webbrowser module, os.fork and parsing bugreports from our BTS via html. This all sound very familiar, so here are some hints from me:
- You don’t have to fork a new process just to call a browser, try threading instead:
thread.start_new_thread(webbrowser.open, (url,)). No need to clean up the child process after it has finished, just call start_new_thread with the function and it’s parameters and forget it.
- Python’s webbrowser module is nice, but it often fails to find the right browser. The problem is to find the users (read: not the system’s) default browser across the different desktop environments. xdg-open from the package xdg-utils (from freedesktop.org) seems to do a very good job.
Rng doesn’t use it yet, but I’m definitely planning to replace the webbrowser call with xdg-open. Rng uses it and falls back to python’s webbrowser.open()-call if xdg-open failed.
- If your project suffers from changes in the html code of our BTS, try SOAP instead. It provides all the infos in machine readable format and also comes with backwards compatibility: the namespace for debbug’s SOAP interface is
Debbugs/SOAP which always calls the latest versions of the remote functions. But you can also use
Debbugs/SOAP/V1 (Version 1 currently matches
Debbugs/SOAP). This will ensure that changes in debbugs SOAP interface don’t affect your implementation.