If you hang out with local team people at some place, they must not have to buy beer themselves.
If you hang out with local team people at some place, they must not have to buy beer themselves.
We are organizing another BSP in Munich on the weekend of 17th/18th July. Like the last BSP, it will take place in the LiMux office in the city center. See the coordination page for further information and directions and in order to sign up for it.
Food and drinks for the event are partly sponsored by the City of Munich and this amount (100 €) has been again matched by credativ GmbH.
Contributions by non-DDs are welcome as always; the BSP will be attended by several Debian Developers who will be able to upload fixes. Attending BSPs is a great way to get involved in the Debian community!
We cannot guarantee crash space to people from outside Munich at this point, so if you want to attend please contact the Munich list (area-muc@teams.debian.net) beforehand or arrange your own accomodation.
We probably start the BSP at some point after 6PM on Friday evening already, but the main action will be on Saturday and Sunday. As usual, people should bring their notebooks and possibly an ethernet cable. Wireless will be present as well, but a certain bandwidth cannot be guaranteed.
Bug-Squashing Introduction
I also plan to give an introduction to bug-squashing at this month's Garching Debian Stammtisch, which will take place next Wednesday, July 14th in the campus-cneipe (or its beergarden) as usual (the monthly Stammtisch is always on the second Wednesday of the month). If you study/work in Garching and would like to attend the BSP, come to the Stammtisch for a tutorial (and beer)!
Debian Packaging Tutorial
Some time ago, I gave a tutorial on Debian packaging in the TechTalk series of the Open-Source- School. The audience seemed to be pleased with the talk, and as more people requested to attend than there were seats in the room, we decided to reprise the event on September 7th. Attendence is free, but you have to register (see the event page). There are still some places left at this point.
This year's Debconf will probably have for the first time tracks pertaining to certain subjects. One of the proposed tracks will be "Math and Science and Debian" and I was asked to organize it.
We have some talk proposals already, and we will have a panel discussion about Debian science packaging between the major contributors of the various packaging teams, but more talks are welome! Talks could be about science with/on Debian, or Debian development in scientific fields.
Additionally, I would like to encourage contributions on three types of topics:
Full length talks are not required, we could split up each topic among a number of people depending on interest and submissions.
Talks can be officially submitted until the end of tomorrow (Saturday May 1st, 23h59 UTC), but even afterwards, if you plan to go to Debconf and would like to give a talk about Math, Science and Debian, please contact me and we will see what can be done. Especially contributions to the three topics above can be made later as the events will be registered already.
This evening, the final decision on which city will host Debconf11 next year will be taken.
For the last half year, mostly Andreas Barth, Jan-Marek Glogowski and I have been working hard to make the Munich bid as good as possible. One thing we wanted to make clear from the beginning was that we would go for a conference in the city center - not some conference center in some nearby village or in an industrial area far away from where the city life happens.
It was not easy, since the german-wide decision, we had to reshuffle venue plans a couple of times.
In the end, thanks to Jan-Marek, we managed to get an excellent venue offer. Our bid consits mostly of:
The biggest strong points about Munich are, in my opintion:
It the end, it seems Banja Luka seems to have the stronger bid, especially due to their 150000 EUR governemnt sponsorship. We will see who wins, I believe we did the best we could.
I always thought Canonical could do a bit more to contribute to the GNOME project, so I was happy to see the work on application indicators proposed to GNOME. Application indicators are based on the (originally KDE-driven, I believe) proposed cross-desktop status notifier spec. The idea (as I understand it) is to have a consistent way of interacting with status notifiers and stop the confusing mix of panel applets and systray indicators. This is a very laudable goal as mentioned by Colin Walters:
"First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here."
The discussion that followed was very useful, including the comments by Canonical's usability expert Matthew Paul Thomas. Most of the discussion was about the question how this proposal and spec could be best integrated into GTK, the place where most people seemed to agree this belongs (rather than changing all apps to provide this, this should be a service provided by the platform)
However, on the same day, Canonical employee Ted Gould proposed libappindicator as an external dependency. The following thread showed a couple of problems, both technical and otherwise:
What I personally disliked is the way the Cody Russel and Ted Gould are papering over the above issues in the thread that followed. For examples, about point one, Ted Gould writes in the proposal:
Q: Shouldn't this be in GTK+?
A: Apparently not.
while he himself said on the same day, on the same mailing list: "Yes, I think GTK/glib is a good place" and nobody was against it (and in fact most people seemed to favor including this in GTK).
To the question about why libappindicator is not licensed as usual under the LGPL, version 2.1 or later, Canonical employee Cody Russell even replied:
"Because seriously, everything should be this way. None of us should be saying "LGPL 2.1 or later". Ask a lawyer, even one from the FSF, how much sense it makes to license your software that way."
Not everybody has to love the FSF, but proposing code under mandated copyright assignments which a lot of people have opposed and at the same time insinuating that the FSF was not to be trusted on their next revision of the LGPL license seems rather bold to me.
Finally, on the topic of copyright assignments, Ted said:
"Like Clutter for example ;) Seriously though, GNOME already is dependent on projects that require contributor agreements."
It is true that there are (or at least were) GNOME applications which require copyright assignments for contributions (evolution used to be an example, but the requirement was lifted), however, none of the platform modules require this to my knowledge (clutter is an external dependency as well). It seems most people in the GNOME community have the opinion that application indicators should be in GTK at least eventually, so having libappindicator as an external dependency with copyright assignments might work for now but will not be future proof.
In summary, Most of the issues could be dealt with by reimplementing it for GTK when the time comes for this spec to be included, but this would mean (i) duplication of effort, (ii) possibly porting all applications twice and (iii) probably no upstream contribution by Canonical. Furthermore, I am amazed at how the Canonical people approach the community for something this delicate (their first major code drop, as far as I am aware).
To be fair, neither Ted nor Cody posted the above using their company email addresses, but nevertheless the work is sponsored by Canonical, so their posts to desktop-devel-list could be seen as writing with their Canonical hat on. Canonical does not have an outstanding track record on contributing code to GNOME, and at least to me it seems this case is not doing much to improve things, either.
Munich traditionally used to have a lot of Debian Developers, but over the last couple of years quite a few of us who used to be students graduated and moved elsewhere or became very busy with their day jobs. We still meet for having a beer and a chat, but not as much as some years ago. We used to meet about once a month, but in 2009 we only managed to meet four times (however, we organized a Bug Squashing Party in November and had a special meeting as Lenny Release Party in February)
As the meetings are really rather informal and not necessarily very Debian related, it is difficult to attract new people this way. So Johannes Wiedersich and I decided to try a more hands-on approach by having a second meeting in Garching, in the student-run bar on the campus of the Technische Universität München (TUM). The idea was to get more of the local science, mathematics and computer science students (as well as possibly interested faculty members) involved.
We tried a first time about a year ago, but after two or three meeting in late 2008 and early 2009, we lost momentum. However, we began organizing the meetings again with the start of the winter term, and had two rather successful meetings so far. For the first meeting, we basically handed out some information on how to get involved locally (the Debian-Munich list, its subscription address, the wiki etc.) and discussed Debian in general and Debconf11 in Munich in particular. About half a dozen people showed up, and two of these attended the Bug Squashing Party later that month, and another one (a faculty member) got very active in Debconf11 organization. Thus, I was quite happy with the outcame of that meeting.
Some days ago, we had another meeting, and this time I was doing a live-tutorial on Debian package building. As Johannes was ill, we did not manage to announce or publicize the meeting well in advance, so only three people showed up. Still, I think it went rather OK, and we will be doing another Debian package-building tutorial for the next meeting, and possibly other turorials/workshops afterwards (ideas so far include library maintenance, Debconf, how the Debian community is organized and how to get involved in it). As doing a live-tutorial on one notebook is a bit difficult if you both have to type on it and people should see what happens, we will either use some extra hardware next time, or move to some nearby seminar room with a projector, this will be announced in advance.
So if you are on Garching campus or nearby and interested in Debian development (and Debian package-building in particular), come to the next meeting on January 13th! We decided to meet on the second Wednesday of each month, at 18h. Subscribe to the Debian-Munich list to get the invitation or watch out for the flyers on the campus.
We are organizing a BSP in Munich on the last weekend of November (28th/29th). It will take place in the (new, they are moving to the neighboring building this week) LiMux office on Sonnenstr. 25, between U-Bahn stations "Stachus" and "Sendlinger Tor".
If you are from outside Munich and want to attend the BSP, please let me know (mbanck@debian.org) so we can maybe arrange something like limited travel sponsorship or lodging (some of us can offer crash space at least). We specially invite people from within 150 km, like Nuremberg/Erlangen, Salzburg, Ulm, Augsburg and Innsbruck.
We probably start the BSP at some point on Friday evening already, but the main action will be on Saturday and Sunday. As usual, people should bring their notebooks and possibly an ethernet cable. Wireless will be present as well, but a certain bandwidth cannot be guaranteed.
Debconf was as awesome as expected and the days in Madrid afterwards were great as well.
My two sessions went alright in my opinion, I am especially glad that so many people showed up to the debian-devel session as early as 10 AM! I have now posted a summary of the session to the debian-project mailing list.
The key points of my short presentation were:
I also summarized the various code of conducts the above distributions/projects employ and they are somewhat different each:
So where are we going from here? I proposed a couple of possible steps, and after merging in the discussions at the BoF, the following might b e feasable:
If you have additional ideas or comments, please join the discussion on the debian-project list.
Tomorrow, I am joining the Debian crowd at Caceres, Spain for Debconf9. The last few days were quite nice in Munich so the projected 35-40 degrees will hopefully not be too much of a shock for me now (even more so now that I just got my brand new summer haircut!).
Apart from looking forward to meet a lot of good friends, I mostly have two Talk-BoFs scheduled (besides the debian-science round-table). They are both rather non-technical, but about topics which I consider important (at least to myself), so I am hoping a lot people attend and (more importantly) participate in the discussions.
Non-English IRC Support
on Day 2, 2009-07-25, 13:00 in the lower talkroom
This session will be about Debian IRC support in general and support for people who do not speak english in particular.
While #debian is working rather well (we think) these days, it is unclear what happens to the people who have to be redirected to language-specific channels because they do not speak english.
I would like to start a discussion about what we should do to make sure those users get helped in those channels and maybe discuss shared guidelines for some channels.
So if you are already doing Debian support in a non-english channel, or interested in making Debian support in general or IRC support in particular better, please come around and discuss/voice your opinions!
(edit: oh, and if somebody wants to discuss #debian itself, we can do that as well, of course, should time permit)
The debian-devel List
on Day 5, 2009-07-28, 10:00 in the lower talkroom
I believe the athmosphere on the main Debian development mailing list has become somewhat better over the last year or so, but there is certainly room for improvement!
So in this session I would like to present some small research I have recently done about other distribution's/major project's mailing lists and how they approach possible issues like flamewars, disruptive persons, off-topic posts etc.
If you are interested in making debian-devel a better place and/or know about particularly good (or bad) examples of development mailing list handling in other projects you think might be applicable (or should be ruled out), join the BoF and its discussion.
The other day, while "travelling Deutsche Bahn", I read an article in the venerable Frankfurter Allgemeine Zeitung. To my slight surprise, it included a link to some government document in form of a tinyurl.com URL - (http://tinyurl.com/cr8qso). As I had no internet acccess at the time I read the article, I had to defer checking out the link to some later time. Then I began to wonder how stable those URLs are compared to the stability of the link they service and of the newspaper article itself. The description of the link would probably allow for some targetted google searching, but is it not the responsibility of the newspaper to allow their readers to research the link in a couple of days, months or maybe years? Does tinyurl.com maybe have an enterprise feature where they guarantee long-living links to newspapers and similar customers?
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!