Debian Voting Information / 2007 / Platforms for Project Leader Candidates / Platform for Gustavo Franco

Platform for Gustavo Franco

Introduction

I was born in Rio de Janeiro, Brazil - some time ago. I work for a NGO called Information Network for The Third Sector - that is focused on strengthening civil society organizations and social movements, where I am coordinating the technology team, supervising the internet services from our own ISP and leading the development of a custom Debian distribution.

I've been using free software for ten years and Debian for seven years, during this time I give a lot of FOSS related talks across the country. Besides GNU/Linux, I have also used FreeBSD and OpenBSD operating systems. I like them and look forward to a Lenny release with kfreebsd-i386 and kfreebsd-amd64, at least.

Why vote for Gustavo Franco?

I've started contributing to the Debian project almost six years ago and waited for my account creation after recommended to the DAM for more than three years, it happened two years ago. During these two years I have done much more than before, and the keyword is: motivation.

I ask your vote to keep motivated people working to meet our goals, during my term. I'll cover these goals in detail below and if you share a lot of them, I think I am your candidate, otherwise if you share just a few of them I think you should rank me just below your preferred candidate. There's the possibility that I haven't outlined any common goal we've here, don't hate me instantly. Drop me a message privately and tell me about your goals into the Debian project. I'll do my best to point out at least one we've in common and work on it during my term, if elected.

I would like to inform that considering that we can't force volunteer work, people on key positions that are overloaded or unable to do volunteer work for some reason, will need to share their roles with others for the better of our universal operating system. Voting in me means that you respect people's legacy and skills but don't accept not well documented and immutable positions in our organizational structure.

History in Debian

After joining pkg-perl team and contributing into the group as a whole, including policy updates. I figured that we had not a similar project for python modules so I founded the Debian Python Modules Team with Guilherme Pastore right after we were joined by Raphaël Hertzog and many others contributors. I've also started the pkg-ltsp group after talking in real life with Otavio Salvador about the ltsp packaging status and how we lagged behind Ubuntu. Then I organized a online meeting with Ubuntu ltsp maintainers and Debian ltsp maintainers to discuss cooperation, as a result we've now almost the same set of features in unstable and Debian Etch can easily be used as a thin-client server.

I've also managed to glue: Debian Desktop development website, debian-desktop mailing list and debian-desktop project in alioth - including pkg-gnome, pkg-kde and pkg-xfce members to work around a real Debian Desktop with common artwork and set of features, during Etch development cycle. Also with cooperation from tasksel, debian-cd and debian-live project members, I think we've in Etch the best Debian desktop experience ever.

I'm also a member and contributed to the following groups: Debian web pages, GNOME Team, tasksel, debtags, Debian-BR, Ubuntu Backmerging Team and pkg-galago.

My platform

I plan to dedicate more time on the key topics below. I want to send monthly or as-it-happens updates to debian-devel-announce with the related bug numbers (if any) or report summary. I'll keep you informed about what I consider as key and others issues that I am sure will appear:

• The Core Teams

  I consider the Debian server administration (including ftp archives), keyring management, documentation, ports, security, release management and installer the key areas into the project. These areas and the corresponding core teams except for documentation, release management and installer are easily the most criticized groups for more than six years. During this time we've released slink, woody, sarge and are challenged by some children distributions that in the next six years or less will be more relevant than Debian in every area and will be able to claim that they are really developing the universal operating system.

  I will request from the core teams clear procedures on how a Debian developer can contribute to them and join them after some time, by merit. I want to make clear how a assistant role differs from a full member of a core team and how a assistant can apply to be a full member. In less than one year, there will be no single point of failure in any key area, if you really don't want it.

  Let make clear that I won't candidate myself as member of any core team during my term.

  I will also work to keep Debian's Organizational Structure page updated and document every position listed there.

• Release goals

  The Debian project has no fixed release schedule and the basic argument from those who support this approach is that it enhances quality. Regardless of how much time you spend during a development cycle, if you don't do the work there will be no enough quality to promote. The other point is if you keep working without clear goals besides the better quality possible, you will never release.

  I heard that a company based on Redmond is known to spend a lot of years between their operating system release and this approach alone have not increased the product quality nor they have the greatest and latest tools bundled with the OS.

  Previous DPL candidates proposed Debian to increase its tempo and a fixed release schedule. Unfortunately, I have seen no real actions from them besides the hard work from the release team during Etch development cycle.

  I want to move forward and clearly define Lenny release goals during my term. I think that there is a lot of key software and projects (involving groups or groups of groups) in Debian that can be used as backing track for our releases (eg.: kernel, installer, the most used web server, the most common desktop environments). With backing track, I meant that once we have the upstream versions defined previously by us in place, that's time to freeze and establish the operating system as a whole. Like we've a procedure for qualify an architecture for release, I want to discuss with the release team and you a procedure for qualify a software or project as a release goal.

• The Bug^W Debian Tracking System

  Actually, we're not using our Tracking System's full potential. The code behind bugs.debian.org, with just a few add-ons, some tweaks and usertags proper usage can act as what I call the Debian Tracking System. You're free to keep calling this BTS though, but if elected I will push for the following changes:

  • Add vote support. If well implemented, a contributor or developer can easily spot bugs that affect many users. Every release critical bug receive attention before release, the same can't be said about non release critical bugs, but a lot of them annoy many users.
  • Add report a bug in the web. Let the users write bug reports against packages or pseudo-packages into the bugs.debian.org/packagename page, requiring an submitter email and maybe implementing CAPTCHA. Send the submitter a confirm your bug report message before sending the bug report to the package maintainer and listing it into the web interface.
  • Add debian-admin pseudo-package. I would like to see debian admin team preferably using the system to track public pending issues. Please also read #408150 at https://bugs.debian.org/408150
  • Add a statistics page. It would contain at least the recent top 5 bug closers, bugs closed and bugs opened.
  • Extend the usertags concept to implement userbugs, as in bugs that only the submitter or a group of subscribed people (including the maintainer or not) can manage through the email, but won't be displayed in the bugs web page of a package or pseudo-package. This feature is useful for projects like utnubu and could also be used for transitions.

  I also want to make sure that any localization initiative involving a web interface to coordinate translations will not turn the current wishlist bugs approach we've into BTS a maintenance nightmare. I think we can deprecate the current behaviour periodically importing the pending translations into the new system, but it would be better if the new system could coexist and respect the BTS bug numbers. This way importing a translation for a package release, would still close a bug.

  Unfortunately I haven't discussed yet these proposals (except for #408150) with the BTS admins due to time constraints, but if elected I will prepare with help of others a more detailed proposal for each feature and initial patches for them.

• New Developers

  That's clear we need new and skilled developers, Debian Developers are a rare resource, Debian regular contributors aren't so common and we have many users to satisfy. It isn't easy as it sounds, keep the fresh blood coming. I would like to see Joerg Jaspert with full DAM privileges (including keyring maintenance capabilities), promoting a well known AM by its results as DAM assistant to work together with Joerg and James.

• New Packages

  I think that one or two new people can handle packages in NEW queue that are not really new, but just old source packages generating new binaries without licensing changes. This change will be done if needed, after ftpmaster team review. Who and why assistants are assistants and what they can't do that full members are supposed to do.

• The Technical Committee

  The Technical Committee is established by the Debian constitution, section 6. It is the body which makes the final decision on technical disputes in the Debian project. If the web page is up-to-date their last technical decision was in 2004, the committee was extended after that though. I would be glad to see a more active technical committee during my term.

  I also plan to propose a General Resolution to change our constitution (6.6) to bring at least two elected members into the technical committee during my term and be sure that the changed constitution will allow us rotate the technical committee members from time to time. I believe that we will see interesting platforms coming from skilled people into the project interested in review and work on to solve our problems exposed by the Bug^W Debian Tracking System (pseudopackage: tech-ctte). I think it can be the next logical step to active and vibrant members of the community with a interesting history into the project, and feel they can act like a bridge between any Debian contributor and the core of the project on technical issues.

• The Debian hidden treasure: Groups, subprojects and supergroups

  There's a lot of Debian users and enthusiasts that don't realize how much we've evolved in terms of groups, subprojects and supergroups. I understand groups as any group in alioth; subprojects as more official groups with a page into our official website and supergroups as a group of groups (eg.: debian-desktop).

  I think that without our GForge setup (in alioth) we wouldn't have so much organized groups, supergroups and even some subprojects that already existed but weren't much active. During my term I will discuss with the technical committee if it's worth write detailed technical procedures to a alioth group apply and be promoted to a subproject. It would be special useful for service oriented groups (eg.: backports and sponsors), because some users simple don't know or refuse to use them because their non-official status.

  Groups, subprojects or supergroups, I think as a community we should use and promote more what's cool and working. I see proposals involving stuff that mentors and sponsors does for ages. Spread the word about your favorites alioth projects now!

• New software in a stable release and backports

  Based on the criteria to promote groups to subprojects, I would like to see backports promoted during Lenny development cycle. This way we will be able to add new but officialy supported software in a stable release. The security support and criteria for inclusion needs further discussion, that I plan to do with the involved teams and technical committee.

• Debian is a universal operating system

  Where's the Debsphere then? The Debian project needs more official events and a calendar to track them. I think that the debconf (our major yearly event) current and past organizers can share their experience with local event organizers on how to obtain and handle funds from sponsors and put local conferences out of the paper. I'll discuss with the parties involved the possibility of create a formal events team too.

  I'll do my best to see at least debconf asia, debconf north america and debconf latin america happening after our global debconf in Scotland this year and before the global debconf in Argentina. These local Debian conferences should be smaller and focused on reunite developers and contributors that couldn't attend the global event due to its distance and schedule, give local related talks, develop the local related agenda, work on to organize bug squashing parties. With the possibility of invite and welcome some foreigners of course.

  I want to promote the week of Debian, a week in August where Debian user groups, some Linux user groups and the Debian community as a whole will be encouraged to promote user related events. Developers can participate help organizing such events or giving talks. The groups interested in developers talks from distant areas will be able to contact us and we can act as a router between the organizers, sponsors and the developer to fund the travel and cover others costs. The week of Debian organizers will prepare a list with developers willing to give talks in a volunteer manner, close to their home or in distant areas.

  I'm all for development hands on groups meeting, a events team could do the hard work of organize such specialized kind of conference and the development group can dedicate most of its time to do what they do better. The events team also can act as a gateway between the press team and the group busy working on our next big feature, to make sure that the development summit results are well known by anyone interested.

• Debian ports

  I will do my best to motivate more people to help us release Lenny supporting kfreebsd-i386 and kfreebsd-amd64, and try to push a major vendor to officially support Debian GNU/KFreeBSD servers, if elected.

  I also want to discuss source-only uploads and the possibility of force a source-only upload compile on a fast enough architecture before trying in a slower one. I would like to see and help Lucas Nussbaum working on piuparts over testing during Lenny development cycle to spot bugs that passed unnoticed and if successful enable basic upgrade/install/remove tests on almost any package, after compiling on a fast enough architecture.

  I'm all for virtualized build tests, specially on architectures we will not release in Etch. The people interested on this project, if elected, can contact me. I will make a proposal for the technical committee related with buildds results guidelines. Hopefully with Lenny+1 this discussion will be a thing of the past and we will have full and stable virtualized autobuilders.

• Debian friendly hardware and vendors

  During my term I want to make at least one major desktop hardware vendor sell and support machines with Debian Etch desktop pre-installed. I also want to make one major Linux powered gadget vendor use Debian Etch. Based on HP results during 2006, in theory it will be easier see a major vendor add support to a product line or two in the server camp. Anyway, it will encourage their competitors, also medium and smaller players to also sell Debian support. There are two interesting and intentional side effects: Our users will have more options to run Debian, and we will enlarge the universe of possible Debian contributors employers.

  I'll work on with the related teams to write specific documentation for vendors interested in pre-load unmodified Debian on their systems. It is easier than they think using debian-installer preseeding, we just need to tell them.

  I am aware of the computer vendors that pre-install Debian list at: ../../../distrib/pre-installed. I'm not sure the list is really accurate, but I will work with the press and www teams for a wider usage and to make sure we keep the entries updated.

• Debian website

  We've a fantastic website in terms of content and localization but without search engines I don't enjoy browsing it and I am sure others will share the same view. I want to review with the web team the most common Debian website use cases and where we fail to cover them, a small design update, possibility of integration with some wiki content and work on Debian web guidelines for content not hosted by us. I want to make it easier to people working on websites around the Debian ecosystem use a similar design and promote it as a best practice.

  I am open to temporarily 'fork' the website to test new ideas, with access restricted to developers-only and collect feedback at debian-www mailing list. These new ideas can be be tests to cover some use cases and the small design update, as cited above. I like the bar in one of the proposals to the debian-community.org layout (http://www.debian-community.org/dc_proposal2.png), and I think that details like these could be tested over our current website content.

• Debian Publicity

  I will discuss with the press team and debian-publicity mailing list, strategies on how to promote more what is actually so good about Debian project and Debian GNU/Linux operating system. There are tons of possibilities, like promote more alioth and sponsors.debian.net usage for newcomers. Issue more press releases with relevant content or with companies, publishing that they had good results using Debian or selling support. I would like to read more Debian articles on general technology related websites and magazines than just only on FOSS dedicated websites and I will do my best for this during my term.

• Non-Maintainer Uploads

  I'll promote the LowThresholdNMU, that is today in the wiki and is opt-in for each maintainer, for each package. We can do this using a new optional file into debian directory, called nmupolicy containing something like the following:

  Format: 1
  NMUFriendly: Yes|No
  NMUNotes: <comment>
      

  • Packages without both fields should be NMUed following the current rules or if otherwise stated by the release management team.
  • Packages with the NMUFriendly set to yes and no NMUNotes field should be still treated as maintained by the person or group listed in the Maintainer field but uploadable by any other developer, following a simple rule: Patch attached to a bug in the BTS before upload.
  • Packages with the NMUFriendly set to yes and with NMUNotes should state in this field clear notes on how the NMUer should proceed different than patch attached to a bug in the BTS before upload. The following sentences are valid examples: Contact [email protected] and wait at least 4 days.; Just NMU for normal bugs or greater; Just NMU for RC bugs;
    No NMU for wishlist bugs.
  • Packages with the NMUFriendly set to no and no NMUNotes field should be treated as if both fields weren't being used.

  Debian Policy and new maintainers guide (at least) should be updated to document nmupolicy file usage. dh_make code could be updated to create a debian/nmupolicy template. PTS, bugscanner, lintian and linda codes could be also updated to use these fields.

I will also tattoo a swirl in the end of my term. — stratus

Rebuttals

Wouter Verhelst

I'm sure he has some general ideas about how to solve some Debian problems and improve the situation, my problem with his platform is that he failed to make clear what he's going to do. I want a more communicative and transparent atmosphere and Wouter started failing as a lead right from his platform. He is a great contributor, though.

Aigars Mahinovs

Debian aims to be a Universal Operating System. A Universal operating system with no releases makes no sense from my point of view, but if Aigars wants something Debian that will never be released as is and actually is a trunk. He is free to use and advocate unstable (sid). There's no need to be DPL and change nothing.

Sven Luther

Rebuttal Coming Soon.

Sam Hocevar

Sam has a interesting platform, with some good points. It seems that we sit and write our platforms together, but we didn't. I don't know him, really. I just don't think that make fun of his own ideas will bring us to a better atmosphere. I hope he push to do a lot of stuff he proposed on his platform if not elected. It seems that his decision to not change any delegations will put him on a frozen state if elected.

Steve McIntyre

Steve seems to be a great person, and I had the pleasure to work with him while fixing Simple-CDD to work with the new debian-cd. Unfortunately, I fail to see where he as the 2IC during the last term, pushed to do what was on his and/or Anthony's 06' platform. I can't trust that he has enough motivation and commitment to his current platform then.

Raphaël Hertzog

Raphaël usually has good ideas from what i've seen. The DPL board isn't a bad idea and I wasn't expecting him to declare that a 8 person board would perform 8 times better than a DPL alone. My problem with his platform is that there are just a few ideas coming from him, and nothing from the other 8. Are they going to do something really? Why not bring more visibility to the technical committee and ask members advice, as I've proposed? There are 3 candidates listed as possible board members. Why these other three aren't writing about the DPL board on their platforms? Is this a trap? I hope not.

Anthony Towns

I think if he focused more on his platform from the last year he would be a better DPL. I feel sorry for so many critics he's receiving due to his legacy and skills into the project, really. Unfortunately, it seems that he failed again using his current platform to publish a sort of past year schedule than apologies for mistakes, consider what he did and wasn't evaluated yet and justify why he haven't moved on with the changes proposed on his 06' platform.

Simon Richter

Same deal as Wouter, with the fact that Simon wrote even less.

Back to the Debian Project homepage.