Debian

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

I am going to DebConf12!

Submitted by gwolf on Fri, 03/09/2012 - 17:10

I have just bought our plane tickets to Managua, so I can finally say this:

Going-to-banner-180x150-grey

Yes, many of you will ask what happened, I was bragging everywhere I wanted to go by land, driving from Mexico City to Managua. I'd love to, and I'm sure it's completely doable... But we have family issues to attend on July 21, in Argentina. So we will have a beautiful flight schedule (and carbon footprint) for this July:

June 30
Mexico→San Salvador→Managua, 17:35-20:30. Yes, this means I will not be in Mexico to cast my vote on July 1st. Well, I had already accepted this would happen... And the price difference was quite sensible.
July 15
Managua→San José→Mexico, 16:25-22:20
July 16
Mexico→Santiago→Buenos Aires (AEP), 20:30-09:55
July 23
Buenos Aires (EZE)→Lima→Mexico, 08:35-19:00

Several people have asked me on the best airline options for this trip. In our case, to Managua, it was with TACA, US$518 total. You can get tickets for ~US$30 less, but the flight goes through Panama instead of San Salvador, for an extra 1000Km – And instead of ~3hr it makes slightly over 6. Yes, on our way back we will be routed a bit South to San José, but it's not as bad, and it's for a very short layover.

For Argentina? Well, we have always found LAN to be the cheapest and most convenient. This time, TACA/Avianca was a very close second, which lost due to almost doubling the flight+layover time

Why aren't we taking a Mexico→Managua→Buenos Aires flight instead? Because it's ~US$150 more expensive per person. Not *that* much, but still some money. And by returning to Mexico and having a night at home, we will save us the hassle of carrying Winter clothes to Nicaragua and Summer clothes to Argentina.

Oh, and if you are planning on dropping by home while we are away and robbing all of our stuff: There's not that much to take from there, and we have already arranged for somebody to be there while we are away. But thanks for thinking about us, anyway!

[update] And what about DebConf12 registration? When is the system opening for us all to register? Soon, dear friends, we are talking about some related issues, and you will have your registrationi open soon.

One bug less!

Submitted by gwolf on Thu, 12/01/2011 - 11:50
One bug less!

At our BSP in nul-unu, Debcember 2007

( categories: )

BSP at nul-unu

Submitted by gwolf on Thu, 12/01/2011 - 11:48
BSP at nul-unu

December 2007

( categories: )

LVM? DM-RAID? Both? None?

Submitted by gwolf on Sat, 09/17/2011 - 13:06

Patrick tells about his experience moving from LVM to RAID.Now, why do this? I have two machines set up with LVM-based mirroring, and they work like a charm - I even think they work with better flexibility than setting it up in a RAID-controlled way, as each of the partitions in a volume group can be easily set to use (or stop using) the mirroring independently, and the requisite of having similar devices (regarding size) also disappears. Of course, this flexibility allows you to do very stupid things (such as setting up a mirror on two areas of the same rotational device - Good for toying around, but of course, never to be considered for production). And the ability to online grow and shrink partitions is just great.

So, Patrick, fellow readers, dear lazyweb, why would you prefer LVM-based mirroring to a RAID alternative? Or the other way around?

( categories: )

Morning in the hacklab

Submitted by gwolf on Fri, 08/12/2011 - 11:01
Morning in the hacklab

It's still early and few people have shown up in the lower hacklab. DebConf 11; Banja Luka, Republika Srpska, Bosnia i Herćegovina.

Photo by Robert "Blars" Larson

( categories: )

At the "DebConf and Debian (vs. no more!)" BoF, DebConf11

Submitted by gwolf on Fri, 08/12/2011 - 10:59
At the "DebConf and Debian (vs. no more!)" BoF, DebConf11

Left to right: Me, Stefano Zacchiroli (Debian Project Leader), Moray Allan and Holger Levsen.

Photo by Robert "Blars" Larson.

( categories: )

Free Software must migrate to become Free Culture

Submitted by gwolf on Tue, 07/12/2011 - 00:45

Cineast and Free Culture activist Nina Paley wrote some days ago a rantifesto on why the FSF has a double standard: Why are the Freedoms guaranteed for Free Software not guaranteed for Free Culture?, by not following its own very strict rules on software when it comes to culture as a whole. Her post was widely circulated, and got (at least) one reply by fellow Debian Developer Wouter Verhelst, largely agreeing with her, and an anti-rantifesto by Joe Brockmeier — Which was promptly answered again by Wouter with a very fun and inspired post, written from the right angle: From the viewpoint of a person who is both a programmer and a musician, and understands the concepts at hand.

I'd love to write a longer, better thought post — But I'm tired and frankly stressed by many things, so I am just echoing their very interesting discussion to other people who might want to read it.

I have been thinking and writing bits on that subject over the last couple of months. An example of that was the talk I gave at the Senate ~6 weeks ago. Following that talk, I wrote a short article for Revista Zócalo (a widely circulated magazine mainly dealing with Mexican politics and social issues) called simply Software libre, cultura libre (full text available, but in Spanish only — You can try reading an automated translation if it suits you). I wrote the article, mind you, with very limited time, and I'll be the first to recognize the prose was quite poor this time :(

Anyway — My point is that our nature is to share culture, to build it in a collaborative fashion, and having the Internet as a practically zero-cost, zero loss medium with which we can interchange our creativity with other like-minded people will naturally boost creativity. Free Software emerged before other Free Culture groups just because programmers had privileged access to Internet in the 80s and early 90s; as network access –and digital creation tools– have got to more people, it's just natural for all kinds of free culture to grow.

Software is just a form of knowledge. Code is just a notation for a certain kind of ideas, just as the mathematical or musical notations. I believe (and hope) it's just unavoidable for us all to eventually switch to a mainly free cultural creation system.

( categories: )

DebConf13 at home? Why not?

Submitted by gwolf on Sat, 07/02/2011 - 21:30

We are few weeks away from the start of DebConf11. Excitement runs high in Debian-land. The two most worthy weeks of the year, every year, loom close. Our Bosnian friends have done a great job of finding and defending an amazing proposal, and are now facing the hard work and permanent adrenaline levels of being in charge of the closest I have seen to a herd of (well-behaved but wild and untamable) cats.

I have organized DebConf in my country. It was hellish, but at the same time, it's one of my most cherished experiences. And I'm sure the same will be said by the leaders of each successive bid — It is one of the most rewarding experiences you can imagine.

Next year, DebConf will be held in tropical Managua, Nicaragua. But, where will we meet in 2013? Well, that depends on you, my dear reader! Do you want to work your ass off for Debian and have utter fun? Do you want to show and share your country with this huge family of developers? Start thinking about pushing for a DebConf13 bid!

Do you have to be at Banja Luka to propose your bid? No. You can proxy via somebody — I'd suggest to do it via somebody who knows the location you are suggesting, but basically, choose a friend that you trust that trusts you. Of course, you can participate in the presentation session via IRC.

Do you have to be a Debian Developer to propose a bid? No. For DebConf9, none of the Cáceres guys was a DD; for DebConf10, some of the people most involved from the local New Yorkers were not DDs. For DC11, none of our dear and overworked hosts in Bosnia are DDs. And for DC12, the Nicaraguan crew is also made from people interested in getting closer to the Debian project, but not DDs.

Do you have to decide now? No. This is just a call for a first presentation, but the decision regarding DC13 will be taken probably around March 2012. However, giving a nice presentation at DebConf helps a lot, gives you visibility, and will get the ball rolling.

Is there a geographical bias? Slight. So far, and since the second DebConf, we have kept the tradition not to repeat continents on two successive DebConfs. This is not a hard condition, however!

What do you need to start thinking about? Go visit our prospective location checklist at http://wiki.debconf.org/wiki/LocationCheckList. You can also look at what other teams have historically presented. Finally, I just learnt about the existence of http://wiki.debconf.org/wiki/DebConf13 — Register there, even if you are just in the early phases of finding data.

We will be holding a DebConf13 bids presentation session, most probably (the schedule is close to being presented officially!) on 30-07-2011, at 17:00.

( categories: )

I am going to DebConf11 — Banja Luka, Bosnia & Herzegovina

Submitted by gwolf on Thu, 05/05/2011 - 12:02

Yay!

I'm going to DebConf11 As others have started posting in Planet Debian, I'll do my part: Yesterday I finished booking our flights, so if everything goes as planned, Reg and me will be arriving to Zagreb (Croatia) at 21:30, Monday July 18, to take part of the 12th Debian development conference, DebConf11, in Banja Luka, Bosnia & Herzegovina!

Of course, reiterating this will never hurt: Do you want to support a global-scale, well-recognized, community-based Free Software project development? Be a sponsor for DebConf11!"

Be a sponsor for DebConf11!

Want some more DebConf11 banners and posters?

( categories: )

Lets go to Nicaragua, 2012!

Submitted by gwolf on Tue, 03/22/2011 - 17:55

Ok, so finally it is official!

We just had the DebConf 12 decision meeting. We saw two great proposals, from the cities of Belo Horizonte, Brazil and Managua, Nicaragua.

If you are curious on the decision process: We held it over two IRC channels — The moderated #debconf-team channel, where only the five members of the decision committee (Marga Manterola, Andrew McMillan, Jeremiah Foster, Holger Levsen, Moray Allan) and two members from each of the bids (Marco Túlio Gontijo e Silva and Rafael Cunha de Almeida from Brazil; Leonardo Gómez and Eduardo Rosales from Nicaragua) had voices, and the open #dc12-discuss channel where we had an open discussion. Of course, you can get the full conversation logs in those links.

I have to thank and congratulate the Brazilian team as they did a great work... The decision was very tight. It was so tight, in fact, that towards the end of the winning all of the committee members were too shy to state the results - so I kidnapped the process by announcing the winner ;-) (I hope that does not cast a shadow of illegitimacy over it)

And, very much worth noting, both teams were also very professional: In previous years, we have seen such decisions degenerate into personal attacks and very ugly situations. That has always been painful and unfortunate. And although the Brazilians will not be able to go celebrate tonight, the decision was received with civility, knowing it was a decision among equals, and a decision well carried out.

Well, that's it — I am very much looking forward for that peculiar two weeks when the whole Debian family meets, this year to be held in Banja Luka, Bosnia-Herzegovina, and I am very eager towards meeting in 2012 in Managua, Nicaragua!

Yay!

( categories: )

Back with Ruby on Debian polemics

Submitted by gwolf on Thu, 01/06/2011 - 09:38

Once again, a polemic regarding how to properly integrate the Ruby language and libraries with the Debian distribution has been ignited. Similar arguments were presented in November and December 2008 and September 2010 — And excuse me for just refering to my own blog, but there are links to some other posts from there... and there will surely be many others I just missed. There were even nice collaboration attempts (such as DebGem, announced in January 2009... But which apparently never stuck on, as it is still listed as in its public Beta period and lists only support for Debian 4.0 and Ubuntu 8.04 and 8.10).

Some days ago, while I was on vacation, I received a mail from Lucas Nussbaum expressing the burnout he had been suffering from this situation. Some days after that, he posted a corresponding blog post - Giving up on Ruby packaging. The comments following his post are most interesting — The one comment I'd like to highlight (noting I skimmed a whole deal of them) is by Paul Brannan, one of the original RubyGems authors. Yes, possibly the design criteria for Gems included some mutually-conflicting goals, and they cover some of Debian's goals. Unfortunately, this conflicting criteria... Was resolved to the opposite way we would have wanted (specifically, that a sysadmin should be able to install software with the same tools he was already familiar with). And of course, there are deeper disagreements, which are rightly stemmed from different priorities: Debian (+derivatives) is meant to make user's and sysadmin's lifes simpler. Gems are meant to make developers' lifes simpler. And while all developers are some sort of users, and sysadminsthe reverse is (obviously) not so.

A developer maintaining several different codebases will surely suffer (well, this particular developer has surely suffered) if he has to maintain them all using coherent versions of system libraries. When a system is programmed, its developers want to use the greatest, latest tools to offer the best experience and functionality. And it's natural for libraries to evolve over time. However, any sysadmin will grind their teeth at the prospect of having many different versions of libraries, as the Gem model proposes. Why? Well, I was bitten by a minor example of it — Bug fixes do not get backported. Of course, if simple bugs are not backported, security and stability of the system as a whole suffers. Often, new software versions will not only add functionality, but improve on how things are done. Not only bugs get corrected, but we get better response times, better memory handling, etc.

It might sound harsh to say this, and even more, as a developer it feels I am talking against myself — But while development time should be minimized during the system design/implementation, once systems are in production, it should be used to allow for friendlier sysadmin relations.

I have to wear both hats at my real-life job. So, what is my take on this? Of course, blaming myself for choosing the wrong version is a no-go. When evaluating a library before using it in my projects, I try to look at its history and API-stability. APIs that change often speak about immature libraries which are still trying to get the right way to implement their functionality; just-started projects might be great and revolutionary, but they do not yet show any kind of long-term committment... And can lead (and have often led me) to painful rewrites when the Next Big Thing is reached.

As for the users: Even if your favorite language has the best and friendliest distribution method, users just do not care about what language was a particular piece of software implemented in. Users want to be able to install and uninstall with their system's usual tools. Directly using Gems, CPAN, PEAR and whatnot is just unnatural for users, however convenient they are for developers. Distributions offer a non-technical advantage in this regard as well: A human filter. As an example, as I write this there are 19392 Ruby Gems and 19092 Perl modules in CPAN (note that CPAN stores some older versions but discourages authors from keeping too many - So no, they are still very different in size). Debian has around 30,000 packages. Why is that? Because all Debian packages _must_ be human-generated, human-reviewed, human-submitted. This means, a person must think each packaged piece of code is worth packaging, is stable enough and provides value to users as it is, and is fit for being part of a stable release. I am not saying with this that 90% of CPAN and Gems are crap — I am saying that they are probably early implementations, to be installed, tested and improved by developers, and still not apt for general public use. Or maybe not interesting enough to be packaged as a service for the non-techie public at large.

Oh, and one last point: Ruby is not a new language anymore. It is a mature, powerful language with different implementations, every time more stable... But it is a language deeply affected by the (not so new anymore either) the appearance of Rails. Why do I say this? Because although the language is in no way tied to Web development, many of its strongest uses are Web-oriented. How does this affect the current discussion? Well, because many people argue that users are no longer needed to install the software. Web systems are installed by sysadmins and used via a Web browser, and sysadmins are expected be more skilled than casual users. Still, in Debian (and in other distributions, surely) we try to make sysadmin's lives simpler — I have (again, talking out of personal experience) installed several webapps (and system tools, and whatnot) for which I never followed any instructions besides aptitude install foo — Using different languages, frameworks, and so on. Can I troubleshoot their installs? Probably, as there is a common logic for how the distribution I have chosen and specialized in works. Can I find causes for bugs in them? Possibly, although there are some languages and frameworks I dare not touch. Can I get help on getting them out of a tight spot? Surely, as there is a central bug tracking system for my distribution — And one of the maintainer's tasks is to separate the problems related to the distribution (packaging, installing, simple user questions and misconceptions) to those derived from real bugs upstream.

Anyway — I am not saying that our way is the best way. No, by a long shot. Again, developers should have an easy, convenient way for installing whatever they want to play with. And to publish it without jumping through hoops. With this post, I'm only trying to express –again– why Debian works the way it does. And hope for better cooperation in the future.

And as for several comments of what I read in Lucas' post, I think that there is interest for this synergy among some of the most committed Ruby people.

( categories: )

Ruby dissonance with Debian, again

Submitted by gwolf on Wed, 09/29/2010 - 11:48

Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian – The first one, on September 12 and the second one, on September 29.

I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for — Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions.

The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in – They should only care that it works. We, as packagers, should take care of all the infrastructural stuff.

And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application".

As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years.

That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post – This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work.

And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains.

PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/

( categories: )

Damage control: Cleaning up compromised SSH keys

Submitted by gwolf on Wed, 09/22/2010 - 13:36

This morning, my laptop was stolen from my parked car while I was jogging. I do not want to make a big deal out of it.

Still, even though I am sure it was not targetted at my data (three other people at least were reporting similar facts in the same area), and the laptop's disk will probably just be reformatted, I am trying to limit the possible impact of my cryptographic identification being in somebody else's hands.

GPG makes it easy: I had on that machine just my old 1024D key, so it is just matter of generating a revocation certificate. I have done that, and uploaded it to the SKS keyservers - Anyway, here is my revocation certificate:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: A revocation certificate should follow

iHIEIBEIADIFAkyaOZwrHQJBIGNvbXB1dGVyIGNvbnRhaW5pbmcgdGhpcyBrZXkg
d2FzIHN0b2xlbgAKCRDYDvNai7UnrzWAAKC34eF76JQjxrZqSjNwcC0dU/5VbACg
gMIMmYg91Sl3y8KsZXdGj/rV7UE=
=rdlT
-----END PGP PUBLIC KEY BLOCK-----

But… What worries me more is access to the computers my ssh key works for. Yes, the ssh key uses a nontrivial passphrase, but still — SSH keys cannot be revoked (and this makes sense, as SSH should not add the delay, or potential impossibility, to check with a remote infrastructure whenever you want to start a session).

So, I generated a new key (and stored it at ~/.ssh/id_rsa.new / ~/.ssh/id_rsa.new.pub) and came up with this snippet:

  1. $ OLDKEY=xyHywJuHD3nsfLh03G1TqUEBKSj6NlzMfB1T759haoAQ
  2. $ for host in $(cat .ssh/known_hosts | cut -f 1 -d \ |cut -f 1 -d , |
  3. sort | uniq); do
  4. echo == $host
  5. ssh-copy-id -i .ssh/id_rsa.new.pub $host &&
  6. ssh $host "perl -n -i -e 'next if /$OLDKEY/;print' .ssh/authorized_keys"
  7. done

Points about it you might scratch your head about:

  • .ssh/known_hosts' lines start with the server's name (or names, if more than one, comma-separated), followed by the key algorithm and the key fingerprint (space-separated). That's the reason for the double cut – It could probably be better using a regex-enabled thingy understanding /[, ]/, but... I didn't think of that. Besides, the savings would be just for academic purposes ;-)
  • I thought about not having the ssh line conditionally depend on ssh-copy-id. But OTOH, this makes sure I only try to remove the old key from the servers it is present on, and that I don't start sending my new key everywhere just for the sake of it.
  • my $OLDKEY (declared in Shell, and only literally interpolated in the Perl one-liner below) contains the final bits of my old key. It is long enough for me not to think I'm risking collision with any other key. Why did I choose that particular length? Oh, it was a mouse motion.
  • perl -n -i -e is one of my favorite ways to invoke perl. -i means in-line editing, it allows me to modify a file on the fly. This line just skips (removes) any keys containing $OLDKEY; -n tells it to loop all the lines over the provided program (and very similarly, -p would add a print at the end – Which in this particular ocassion, I prefer not to have). It is a sed lookalike, if you wish, but with a full Perl behind.

Caveats:

  • This assumes you have set HashKnownHosts: no in your .ssh/config. It is a tradeoff, after all – I use a lot tab-expansion (via bash_completion) for hostnames, so I do have the fully parseable list of hosts I have used on each of my computers.
  • I have always requested my account names to be gwolf. If you use more than one username... well, you will have to probably do more than one run of it connecting to foo@$host instead.
  • Although most multiuser servers stick to the usual port 22, many people change the ports (me included) either because they perceive concealing them gives extra security, or (as in my case) because they are fed up with random connection attempts. Those hosts are stored as [hostname]:port (i.e. [foo.gwolf.org]:22000). Of course, a little refinement takes care of it all.,/li>
  • Oh, I am not storing results... I should, so for successive runs I won't try to connect to a system I already did, or that already denied me access. Why would I want to? Because some computers are not currently turned on. So I'll run this script at least a couple of times.

Oh, by the way: If you noticed me knocking on your SSH ports... please disregard. Possibly at some point I connected to that machine to do something, or it landed in my .ssh/known_hosts for some reason. I currently have 144 hosts registered. I am sure I triggered at least one raised eyebrow.

And I will do it from a couple of different computers, to make it less probable that I miss some I have never connected from while at the particular computer I am sitting at right now.

So... Any ideas on how to make this better?

( categories: )

Unambiguous name for Free Software without ideological dillution

Submitted by gwolf on Sun, 09/19/2010 - 11:21

Asheesh posted When "free software" got a new name, which mentions about the transition period where the Free Software movement started its quest towards being understood by non-geeks, and when people started finding terms better suited for general (and specifically, business-minded) audiences.

We are talking about facts that reached concretion 12 years ago, when the term Open Source was coined and divulgated. That is already far in the past to try and change it – Still, during DebConf I was talking with several friends about it. In my opinion, there was never really the need to choose such an ambiguous name – In English, the word Liberty unambiguously refers to free as in freedom, with no conceptual links to gratuity. Liberty is also a concept held dear by the values of the USA society (which is the birthplace of our ideological movement, so it's specially important). Jimmy Kaplowitz pointed out a reason: Liberty is an incomplete word. You could translate what Asheesh's post mentions, Freed SoftwareLiberated Software, but libertydoes not exist as an adjective by itself, only when used as contrasting with an earlier more restricted situation. We can say some piece of software was liberated if it was born unfree, but what about things that were libre since the beginning?

So, yes, as beautiful as Liberty is, and as advantageous as such a concept would have been for us... Liberty seems to be too imperfect to be able to represent our movement.

( categories: )

Posts explaining DebConf

Submitted by gwolf on Tue, 08/24/2010 - 07:51

Just echoing what happens in Planet Debian for people who follow my blog (or any other planet where it is syndicated) and is interested in DebConf processes — I'm specially thinking about people interested in preparing a bid for hosting a future DebConf, as well as people organizing hacking conferences who are interesed in understanding how DebConf works:

Richard Darst, a.k.a. our very invaluable MrBeige, started a series of posts describing various processes of DebConf organization. He explicitly asked me for comments while this series was still in planning/wiki stage, but I failed miserably at doing so ;-) So at least I'll publicize his work, linking from here:

  1. DebConf and Debian: Introductory message, basically outlining (Richard's view on) the relation between Debian and DebConf. This is not yet a clear thing — It seems we are converging on the fact that DebConf *is* part of Debian, but there are several things to clear before it is viewed as a done deal.
  2. Timeline of a DebConf: Running a DebConf as a local team is not (just) becoming crazy for two weeks, leaving life behind ans working hard for having your friends and peers in your hometown. It is an interesting full two year process, with different phases and aspects for the work. Richard has been involved as an organizer for the last two years, and he summarizes the main periods here.
  3. What is the DebConf team?: We talk about the localteam and the globalteam as if those terms make any sense. Then again, we have had people as part of localteam who live in different countries... What does this mean? What are the tasks of the teams? How do you join? What kind of work is expected from you? What is the real difference between the teams, if there is any?
  4. The DebConf selection process: How does the next year's venue selected? How is this "contest" held? When do you have to submit your proposal? How is it ranked/judged/decided? As I have told several people, the first document you should check is always the location checklist (also linked from Richard's text), but having this timeline will surely help you know what to expect.
  5. How DebConf manages money?: How should the DebConf fundraising process be, and how it actually is; what is the money relation with the whole Debian project... and a couple of points where you can step in and help, as managing money is really difficult
  6. DebConf budgeting for a single conference: A bit further details on how fundraising, negotiations and money spending was handled for DebConf 10
  7. The DebConf registration process: What are the parts of our registration process? When does it open/close? Why are the deadlines set so early? How has this been determined in the past? What is corporate and professional attendance?
  8. DebConf Fundraising (this text by Pablo Duboe): If you want to host a DebConf, an important part of the job is to get money. How should you do it? Who should you ask, what can we show to potential sponsors, how can we approach them?
  9. How DebCamp relates to DebConf: What is DebCamp? What are the terms for participation? what can you expect to have (and to lack)?
  10. The DebConf travel sponsorship process (this text by Michael Schultheiss): How is the money for travel sponsorship (travel fare only, lodging and food not included here) awarded to the people requesting it? How does the team reviewing this work decide on whom to grant to? What are the decision criteria?

I don't know if MrBeige is planning further parts for this series; if the past four were interesting, you should check on his weblog. Update: Yes, he is planned, and he has delivered. Adding them to the list as they flow...

( categories: )
Syndicate content