Debian Project Leader Debate, 2005

Debate Transcript


we're just giving Jonathan a couple of minutes to join us, incase he is delayed by something
martin_krafft starts a drum roll
ok! :) Hi everyone and welcome to the 2005 Debian Project Leader IRC debate.
I am Helen Faulkner, and will be chairing the debate with madduck (Martin Krafft). The candidates in this election are MatthewGarrett, AndreasSchuldei, AngusLees, AnthonyTowns, JonathanWalther and BrandenRobinson. we are missing JonathanWalther at this point, hopefully he will join us really soon...
The debate format has been described in In the first half of the debate, I will be asking time-limited questions of all of the candidates. They will be pasting their replies into #debian-dpl-replies, which is not open to the public, though the logs will be made available later. martin_krafft will be collating the replies and pasting them in here.

Debate Part 1 - Question and Answers

Release Cycle Strategy

question 1 has a time limit of 5 minutes:

A constantly returning topic is the release cycle and strategy,and -- arguably -- the current cycle is suboptimal. Assuming that you agree, please state what you consider to be a good (or the optimal) release strategy, and briefly say why. How do you see the position of the DPL with respect to the release strategy? If you were elected, what might be your next steps in leading Debian towards the cycle you envision? If you disagree with the above and think that the release cycle and strategy is good enough, please explain your position.

I think the primary responsibility of the DPL with respect to release management is to make sure the release managers have the support and resources they need. The recent proposal which I've decided to call the "Vancouver Prospectus" has done a good job of getting the ball rolling, when it comes to exposing the developers at large to the exigencies of release management. There's a lot more to it than fixing RC bugs, as critical as that is. As I said in my recent message to -vote, this is a beginning, not the end of the release management process. The current RM team certainly has my full trust and respect. As DPL, I pledge to work with them to the best of my ability to see that their needs are met. Sometimes, that includes deflecting a flame or two, of course -- though they're amply equipped in their own regard on that front. :)
The release strategy is primarily the release manager's responsibility. I think the key focus for the DPL is on supporting their role, andensuring they have the resources to act appropriately, such as byorganising meetings like AndreasSchuldei and Steve did in Vancouver, and be making sure that other teams are aware of what the release team needs, and vice-versa. There's a lot of benefit to be had tothe release team from simply ensuring other teams -- such as the GNOME/KDE teams or the d-i team -- are functioning effectively. I think the ideal release strategy would result in regular releases, on either a six, nine, twelve, or eighteen month basis; ideally predictable to the day. I think the release team's proposal for sarge and etch is good, and working out the kinks in it on the mailing lists is the best approach.
I believe that Debian should release faster, but beyond that I believe the details should basically be left up to the release team. The current proposals are somewhat controversial, and I'll happily admit that I'm not a big fan of the idea of reducing our support of other architectures. However, the release team are the people doing the work. Now that they've provided more information about the problems they face, there's an opportunity to try to find other ways of tackling the problems. The release team are the people responsible for actually doing the work - if nobody else can come up with an acceptable plan, then we should support them in their choices.
The DPL should represent the projects views on the release cycle, and that means the views of the release team. Being DPL should give little weight over the average developer. Personally I think reducing the number of archs will be a necessary part of this. Given the existence of testing, I think the optimum release cycle for stable
I believe OpenBSD has developed the optimal release strategy. However I believe that the release team, at their meeting in Vancouver, came up with a very welcome step forward, which will benefit Debian greatly.
The DPLs job is to find the right people to manage the release. I think the present team is excellently qualified and has worked on the issues involved for some time already. My job as DPL would try to help them sort out problems outside their power. It would be their job to find the best release strategy.

New Maintainer Process

Question 2 has a time limit of 4 minutes:

The New Maintainer queue has recently been "revived" thanks (in part) to additional manpower. Where do you see the strengths of the current approach to new maintainers, and which weaknesses can you identify? In what ways does the current NM process ensure the necessary skills of a prospective developer, and where does it fall short? What might you do after your election to further improve the situation?

It has been 8 years since I went through the New Maintainer process. I haven't looked at it since then. Since we keep bringing new developers on board, it must be working well. If anyone knows of any problems with the New Maintainer queue, they are welcome to bring them up to me before, after, and during the election. Vote Jonathan Walther!
The new maintainer process helps people entering the project to reach a good skill level on technical terms today. It still has probems with the socal skills. somehow we filter for endurability and patient, not for the ability to cooperate.It might help to add a SocialSkills part to the process and communicate how the new maintainer should try to behave.
I haven't had any particular reason to complain about the skills of any of the recent new maintainers, so I'm happy enough with the amount of testing that we're performing. Again, I don't really see it as the DPL's job to interfere with the working of a system unless there's obviously something wrong, and as far as I can tell the majority (if not all) of the people working on NM are doing an excellent job of it.
The NM process is strong in that it probably weeds out those who are only very casually interested. The downside is that it is so rigorous that it might scare off, or drain, people who could otherwise contribute valuably. Some of this year's DPL candidates (including aj and myself) came in under the old system, and I don't think anyone can deny that we've contributed a lot to the project. A good start, as DPL, would be to simply talk to the NM team and find out what gets complained about by the actual applicants. Also, there's a legendarily difficult dynamic loader question that's in T&S that might, perhaps, be overkill.
I've posted about NM on -vote; but to summarise. I think there are a few flaws remaining in NM; most notably that it takes a long time to go through. I was accepted into Debian within a week or so of applying, and only to maintain "distributed-net-pproxy", in non-free. Now, people routinely have to wait months before they can get in, which is far from ideal. I'd like to see NM focus more on a mentoring role; so that the "tasks and skills" section at least, and someof the procedures/policies section to mostly consists of working on real packages with real maintainers, rather than often filling in questionnaires, or working on new packages that aren't necessarily very useful. There are some more details in my post ot -vote, and I think the example of the -women mentoring project is worth following, but more details will need to be worked out over time as well.
The new maintainer process is to weed out people who are unsuitable (either technically or because they're just downright unhelpful). My (uneducated) understanding is that few people are actually *actively* turned away by this process, and certainly Debian has little in place to deal with such people once they make it into the project So this probably shows that almost all people in NM are appropriate and we should optmiise the process a little on that assumption. In particular, I'm not at all confident that existing DDs would survive what we ask of new DDs now, which says a lot. Perhaps forcing *all* DDs to "reevaluate" regularly might force us all to pay more attention to the suitability of NM - as well as giving us a way to weed out MIA or maintainers that no longer reach our increasing demands.

Size of Debian

Question 3 has a time limit of 5 minutes:

It has often been claimed that Debian is growing too large. What positive and what negative influences does Debian's current size have on the project? Depending on where you see Debian in the future, what steps would you take as DPL to shrink or grow the project, or to help it maintain its current extents?

Debian's great as a large project; the more architectures and packages and developers and users we can support the better. Each of those have problems though; lots of architectures are a hot topic right now; but the others cause problems too: lots of packages make it hard for users to know what to install, make it hard to track bugs, and make it hard to provide services (like the buildds or the archive or mirrors or that work on all of them. Lots of developers make it hard to reach consensus on issues, and understand what everyone else in the project is doing. And lots of users mean that you're never allowed to make mistakes. :) I think Debian's about solving those problems as well as possible, and making an OS that works as effectively as possible for everyone.
It's not clear whether the question refers to the size of the archive or the number of people involved. If the former, I think that's up to the release team - if they believe we can release with an archive this size, then we should do so. If they don't, then we'll need to start thinking about approaches to reduce the size. The wide range of software we offer is obviously something our users like, and it would be good to be able to continue supporting that. If it's in terms of the number of people involved, then the obvious issue is that it's harder to keep a strong sense of a single community. I don't think that Debian growing in size is an intrinsic problem, but we need to be able to communicate more clearly within the project. With a small set of developers, information can be trusted to pass back and forth. With a thousand people involved, we need to be more rigerous in terms of making sure that people are told everything that they need to know.
Beyond its free software stance, Debian's size is probably its most significant asset. Because the number of developers is (pretty much) allowed to scale with the amount of free software packaged, Debian is able to give each package a much larger amount of attention than any other distro. This is evident in the complexity (and usefulness) of our postinsts compared to (say) the average redhat ".tar.gz with deps" package. I think the project is growing at a reasonable rate currently, and all we (and the DPL) really need to do is watch out for bottlenecks that aren't scaling with the number of members. One such point was DAM, which is now being addressed - perhaps the security team might be next (I have no idea without talking with people involved in various areas).
Groups that dont grow stagnate. But Debian can grow a lot bigger if it manages to handle the process smoothly. It has reached several chokepoints now, limiting its growth severly. The SmallTeams approach i presented in my platform is a unique and proven way of letting social groups grow larger without losing their charater or vision. With its help there would be a smooth entry point for developers and users to help along on most levels.
Many hands make for light work. The more the merrier! As DPL I will let things develop organically, as they have so far. When we reach the natural limits to our growth, we will stop growing without any need for DPL intervention.
The large size of Debian, in terms of our developer population, our userbase, and the size of our archive (thanks to both package coverage and architecture support) is both a blessing and a curse. Large size makes us appealing to a broad audience, and often an official Debian package of a FLOSS project you've heard of is just an apt-get away. Still, the large size means we've accumulated a lot of cruft. I think Martin Michlmayr has done a great job with MIA, but we probably need more people doing it, if we can find the volunteers. Likewise, we might want to more strongly consider an MIA review process for packages themselves. Some packages in sarge haven't been revved since woody -- they should be looked at, at the very least. Managing growth is a major challenge for all organizations -- many businesses fail because they can't manage this. The DPL's primary role in many respects is to manage growth. IMO the best way to do this is keep one's ears open, and remember the Social Contract: We Won't Hide Problems.

Debian and SPI

Question 4 has a time limit of 5 minutes:

SPI is Debian's legal chaperone and holder of all assets. It was instituted to allow Debian to concentrate on the Debian system without having to worry too much about administrative issues. How has the relation between SPI and Debian changed since SPI was founded? What is Debian's role in SPI, and what would you like it to be? How could Debian make better use of the SPI?

As DPL I would immediately canvass the developer base for recommendations for a good bookkeeper, and hire her on a part time basis to handle all of Debians accounts. By extension, this would include SPI's accounts. Last year Debian last $18,000 dollars due to lack of proper infrastructure for handling donations. This doesn't need to happen. If the SPI board is agreeable, it won't happen. The cost of a parttime bookkeeper is only $6,000 a year. Considering the amount at stake, ($18,000), that is well worth it.
In my view, the relationship between Debian and SPI has not changed that much over the years, and that's not a good thing. SPI appears to be viewed by many Debian developers as a black box, or as someone else's problem. The truth is that SPI is a wholly volunteer-run organization just as Debian is. SPI, however, has vastly less manpower. I'd like to see Debian developers much more involved in SPI, to exercise their rights as contributing members, and help SPI live up to the noble goals upon which it was founded. We can always use more eyes and more hands at SPI. I feel certain I know that better than anyone else running this year. :)
SPI was founded as Debian's legal chaperone, with some in the end trivial side projects like OpenHardware. It's had a whole range of problems over the years, which now seem to be being sorted out. Currently, SPI holds copyrights and trademarks on behalf of the Debian project, and a large proportion of funds, and is increasingly doing the same for other projects. Other organisations in countries outside the US are doing likewise. I think continuing that trend -- ie, diversity at both ends, and increasing effectiveness, is ideal.
In an ideal world, Debian would take more interest in SPI. However, it's clear that there's no great desire from the developers to do so, and I don't see any especially good reason to motivate them - what SPI does for Debian is fundamentally not that interesting. However, it's important to ensure that SPI continues to take good care of our finances, and if there is any evidence that there are problems there in future then we should take more action. One thing that I would like to see improved is SPI's handling of our trademarks - we've had contradictory legal advice from SPI, and as a result we've taken no great deal of action against possible infringement. That's not good for the project.
SPI is in the process to get its internal process worked out. Current events show that those effords start to take effect. As DPL i will try to help in that process and get involved. Branden, who is on the dpl-team is of course deeply involved allready and could serve in this capacity.
There are several issues with SPI. SPI has some issues resulting from its nature as a volunteer organisation - I don't see why Debian would be any different here. Its 501c3 status, however, is only meaningful to US donors, and I think SPI (themselves) overstate their usefulness to Debian because of this. I would rather see the existing loose arrangement of tracking distributed piles of money with more formalised non-profit entities in many countries. SPI would be but one of these and Debian would oversee and manage them. On a different track, I see SPIs reason for existence as purely a financial entity - I am nervous about the few plans people have had for growing SPI into some political force. If that happened, we'd need to find a new bank account.

Under-represented groups in Debian

Question 5 has a time limit of 4 minutes:

While from all over the world, Debian contributors tend to come from a fairly homogeneous background, and a number of groups are obviously under-represented in the project. For example there are very few Indian, female or elderly developers. What challenges and benefits do you see for Debian in encouraging greater participation from under-represented groups? What strategies do you deem feasible for the project to deal with the challenges and maximise the benefits?

People organize themselves on the basis of interests and abilities. Debian is a self-organizing project. Those who are interested in Debian will be the best developers. If Debian is doing something to discourage any of the groups mentioned (women, Indians, and elderly) then it needs to stop doing those things at once. The squeaky wheel gets the grease; noone will know something is wrong until someone speaks up and talks about it. As DPL, I am inviting everyone to bring their problems out into the open where they can be dealt with.
Debian developer's aren't that homogenous, IMO. But there are certainly some groups that're underrepresented. I think we can only solve this for the people who actually want to join and are being prevented somehow; and I'm not aware of large Indian or elderly groups who'd like to contribute more to Debian but feel unable. I think the -women and translation projects set a good example to follow here of catering to special needs, and I think we should work on making the project as a whole better at those as we learn more those needs.
I don't think its appropriate for Debian to seek out contributors from certain groups - if people from under-represented groups wish to join then that is up to them. What Debian should do is make sure that there are no barriers that unfairly affect certain groups - if/when they are identified, we should all do what we can to remove them.
Unfortunately, I'm not sure there's a lot that Debian can do in an official outreach capacity. I haven't seen many proposals along those lines. It should be noted that some groups are underrepresented due to the "digital divide" -- in many countries, socioeconomic stratification keeps Debian from being accessible to people. Educational opportunities are lean for many people worldwide as well. Focussing on the "developed" world, I think it's mostly a matter of creating a less threatening environment. I don't mind good rip-roaring debates, but we can all remind ourselves that group-oriented prejudices and stereotypes are out of place. The good news is that I only hear of these mostly because they have been forced underground in our project. Overall, Debian is a really tolerant place. I welcome folks' thoughts on how we can capitalize further on that trait.
Again, SmallTeams is a possible answer here. With an on-team-translator, even people from other language groups could contribute, for example. (I talked to developers from India about this and he thought it was more of a cultural thing with free software, though). Debian-Women is making an effort to integrate more women in the project already and seems to do a good job at it. Other underrepresented groups could follow their example.
The debian-women project has done a great deal to make Debian more accessible to women, and the increased number of women in the NM queue shows that it's beginning to take effect. I think we need to look at making Debian more accessible to other underrepresented groups, and I think debian-women is a good model to work from here. More input from a wider range of groups makes it easier for us to produce a distribution that's useful for as many people as possible, and that's good for the spread of free software.

Managing DPL Duties and Life

OK, last question for Part 1: Question 6 has a time limit of 2 minutes.

How do you plan to integrate your duties as DPL with your real life and your duties as Debian developer? On a hypothetical level, how would you react to substantial criticism that you are not devoting enough of your time to the job?

I'm sorry, I don't have enough time to answer that question. :) Umm, mostly I expect to be able rely on other developers to help me out if there gets to be a lot to do; most of the projects in Debian I've workedon have had co-maintainers, teams, or NMUers, or patchers or similar, andI expect if I'm DPL, I'll try to follow the same philosophy there.
I believe I mostly addressed this issue in my platform, and I urge people to review it. My real-life duties are already largely integrated with my life as a Debian developer, since I work on "Debian stuff" as part of my job (and career). If time constraints impose, I expect to be able to seek assistance from others. Delegation is good. The DPL team of which I'm a proud part is just one source of candidates for delegates. Above all, regular reporting and accountability are key to preventing time limitations from becoming crippling.
Criticism is not a problem. I am accustomed to controversy. Technical excellence is what is important here. You will NOT get excellence without debate and competition. As for time, I have a job which is very flexible in hours. My availability to meet the needs of the project is excellent, probably the best of all the candidates.
If there is justifiable concern that I am not devoting enough time to the role of DPL, and if I am unable to alter the situation, then I will resign. I don't believe that that will be necessary, though. I've been reducing my other time commitments over the course of the past few months, and the student lifestyle is fairly well suited to having timeto devote to Debian... Fundamentally, the role of DPL should not be a huge time sink. It's about ensuring that the right people are doing the right job, not micromanagement.
I consider travelling as an extremely important factor of being DPL. Before nominating, I carefully considered the time I will have available and I am confident that I can do what is required and it will not impact on my existing (minimal) Debian duties. micromanagement.
I think that I established very well that i prepared and planned ahead for this not to happen: i can work on Debian and DPL issues during work hours and have the DPL-team to fall back on. Even with flames and critizim, which can hurt individuals and demotivate them severely, the team can help by offering moral support.
That concludes the first half of the debate. Thankyou to all the candidates and to the people contributing interesting comments on the discussion channel. We will now break for 10 minutes to allow people to grab more coffee (especially those in UTC and similar timezones!).

Debate Part 2 - Question and Discussion

[07:10:21] AndreasSchuldei
Due to a self-inflicted irc fuck-up i managed to ignore everyone and everything on #debian-dpl-debate, including helen answering the questions. This was fixed during question 2. Feel free to ask me question 1 on -vote, please.
[07:10:38] martin_krafft
you can also answer now here if you want.
[07:10:58] AndreasSchuldei
what was the question, again?
[07:11:16] martin_krafft
[07:11:25] martin_krafft
5 minutes. please restrict yourself appropriately
[07:14:41] BrandenRobinson
AndreasSchuldei: not your fault. Someone posted bogus advice to #-discuss. When I took it, irssi told me I was "ignoring ALL from #debian-dpl-debate".
[07:15:00] BrandenRobinson
So I just killed the ignore and let the joins/parts wash over me :)
[07:15:02] AndreasSchuldei
yes, i noticed too late
[07:15:30] martin_krafft
/ignore * PARTS JOINS QUITS worked fine for me in irssi
[07:16:04] BrandenRobinson
what exactly I did has long since been expunged from my irssi command history, I fear
[07:16:20] BrandenRobinson
not like it would be politic to go pointing the finger of blame right now anyway ;-)
[07:16:29] martin_krafft
quiet now
[07:16:38] martin_krafft
here comes AndreasSchuldei's reply to question #1
[07:17:11] martin_krafft
[AndreasSchuldei] The DPLs job is to find the right people to manage the release. I think the present team is excellently qualified and has worked on the issues involved for some time already. My job as DPL would try to help them sort out problems outside their power. It would be their job to find the best release strategy.
[07:17:21] martin_krafft
okay, the break is over
[07:17:31] martin_krafft
would the candidates please pong to confirm they are listening?
[07:17:50] AndreasSchuldei
[07:17:51] BrandenRobinson is present and ready.
[07:18:00] MatthewGarrett
[07:18:07] AnthonyTowns
[07:18:10] AngusLees pongs
[07:18:36] martin_krafft
AngusLees: ?
[07:19:01] JonathanWalther
[07:19:08] martin_krafft
AngusLees, BrandenRobinson: ping?
[07:19:16] helen
martin_krafft: they're here
[07:19:22] AnthonyTowns
martin_krafft: they /me'ed
[07:19:34] AngusLees pings too for good luck
[07:20:08] martin_krafft
Okay, let the second part begin
[07:20:27] martin_krafft
this is open debate, so I ask you to please exercise all due rules and such
[07:20:36] martin_krafft
people might well watch at how well you are handling such a debate.
[07:20:48] martin_krafft
@world: if you have followup questions, please post them to the mailing list.
[07:20:57] martin_krafft
here comes #1
[07:21:06] martin_krafft
Is the currently available infrastructure enough for now and the future? If not, in what areas are advances most needed?
[07:21:07] AndreasSchuldei
do we get to answer questions, too?
[07:21:15] martin_krafft
[07:21:17] BrandenRobinson
AndreasSchuldei: I believe that's the idea :)
[07:21:38] JonathanWalther
infrastructure will be found when it is needed.
[07:21:43] martin_krafft
"the mailing list" is
[07:21:46] MatthewGarrett
What sort of infrastructure are we talking about? Social or technical?
[07:21:49] BrandenRobinson is not too worried about hardware infrastructure, though there seem to be concerns about mirror space and bandwidth...
[07:21:50] JonathanWalther
our growth will stay static until our infrastructure grows
[07:21:55] AnthonyTowns
And software or hardware?
[07:21:57] helen
MatthewGarrett: either or both
[07:21:58] AngusLees
that question is too open to really address properly..
[07:22:00] martin_krafft
MatthewGarrett: i believe both.
[07:22:16] AndreasSchuldei
Beeing a technical project full of geeks, we have managed well solving those problems untill now. (c:
[07:22:17] martin_krafft
Okay, let's talk about communication infrastructure
[07:22:19] AnthonyTowns
Better BTS, archive software, etc etc is always needed, anyway.
[07:22:25] BrandenRobinson
Personnel-wise, I think we could definitely stand to take a hard look at the teams we have, and ask the current membership how we can best grow the ranks constructively, if and as needed.
[07:22:43] AnthonyTowns
Mostly that's the job of various delegates to work on, and the DPL to facilitate more than ebing something the DPL can direct.
[07:22:46] martin_krafft
BrandenRobinson: what would that entail?
[07:22:51] BrandenRobinson
One of the first things I'd like to do as DPL is to survey the existing infrastructural teams with precisely this in mind> Do *they* feel they're overworked/understaffed?
[07:23:08] MatthewGarrett
Socially, I worry about both the amount of aggressive behaviour on mailing lists and the lack of communication from various parts of the project. I'm somewhat guilty of the first myself - I'm trying to improve in that respect. In terms of the second, well, I think my platform makes it clear what I think :)
[07:23:12] AndreasSchuldei
BrandenRobinson: i agree. here we cross over from the technical to the social.
[07:23:14] BrandenRobinson
If so, what sort of things would help? Does code need to be written? Are faster machines required? How about new team members?
[07:23:32] JonathanWalther
Our technical infrastructure in Debian is the best in the Linux world. Because of that, our personal problems with communication get thrown into stark highlight. We can't blame technology anymore; we can only work on improving ourselves. Who here is up to that challenge?
[07:23:41] BrandenRobinson
I forsee a large part of my first few montly DPL reports as being "State of the Project" reports on these aspects of infrastructure.
[07:23:48] BrandenRobinson
[07:23:51] martin_krafft
BrandenRobinson: interesting.
[07:24:10] martin_krafft
Let's see... walking on a tangent, what do you think are the greatest communication problems in Debian today?
[07:24:11] AnthonyTowns
So, with an infrastructure hat on, my answer would mostly be "mailing lists that aren't full of flamewars, anytime you suggest something difficult" as the most useful feature to make life easier.
[07:24:11] AndreasSchuldei
i would think debian needs a cuture change to handle the *listening* better. (c:
[07:24:22] AnthonyTowns
Obviously I've tried to address that in my platform
[07:24:22] martin_krafft
AnthonyTowns: i will return to this in a second.
[07:24:25] BrandenRobinson
On that note, I think Matthew Garrett did us a great service by describing the current state of affairs, based on his personally-conducted research.
[07:24:28] JonathanWalther
If we need more bandwidth or more disk space, we can always find those. Our bug tracking system and mailing lists are the best you'll find anywhere.
[07:24:44] BrandenRobinson
WRT one aspect of infrastructure.
[07:24:47] martin_krafft
JonathanWalther: how many BTS do you know?
[07:24:56] MatthewGarrett
The greatest communication problems? I'd tend towards the lack of it.
[07:25:07] martin_krafft
MatthewGarrett: and what would be reasons?
[07:25:10] JonathanWalther
martin_krafft: bugzilla. I use a few proprietary ones at work. I've used the BSD sendpr stuff.
[07:25:16] BrandenRobinson
What we need to do is repeat this for all the traditionally flamed-about areas. The best quencher of flames is facts, backed up and calmly reported.
[07:25:20] helen
AngusLees: what do you think about Debian's communication problems?
[07:25:37] JonathanWalther
Debians biggest communication problem is people with thin skins.
[07:25:39] BrandenRobinson
are we totally freewheeling here?
[07:25:42] JonathanWalther
Everyone loves a rollicking good debate.
[07:25:45] MatthewGarrett
To some extent, I think it's possibly due to the fact that the project has changed in size to a massive extent
[07:25:45] BrandenRobinson
i.e., will there be a "question 2"?
[07:25:48] martin_krafft
BrandenRobinson: within bounds. :)
[07:25:56] AngusLees
helen: I don't think there's much new to add.
[07:25:58] BrandenRobinson
JonathanWalther: don't quote me without citation, please ;-)
[07:25:59] MatthewGarrett
(Uh, please ignore the fact that I used the word extent twice there)
[07:26:00] martin_krafft
BrandenRobinson: kind of... :)
[07:26:07] BrandenRobinson
martin_krafft: okay.
[07:26:18] JonathanWalther
but when people with thin skins come along, it has a chilling effect on cameraderie, rough-housing, and all the high energy thinking that goes into making Great Software.
[07:26:22] AngusLees
clearly everyone seems to have recognised the same sets of problems and suggested similar solutions
[07:26:31] JonathanWalther
boys need to blow off steam. fact.
[07:26:33] helen
AngusLees: fair enough
[07:26:42] martin_krafft
let's combine communication and infrastructure... JonathanWalther wants VoIP, but what other improvements could help our communication?
[07:26:45] AndreasSchuldei
JonathanWalther: so are we discriminating against people with thin skin?
[07:26:48] MatthewGarrett
I'd like to see teams talk about what they're doing and *why* on a more regular basis, and the increased number of posts from teams to devel-announce is very heartening
[07:26:56] JonathanWalther
martin_krafft: eh? VoIP? I hate VoIP!
[07:26:57] AnthonyTowns
In response to Jonathan's point, I don't think we can afford to turn away good people with thin skins: I think the only real question we should discriminate on is how well you can contribute to the project.
[07:26:57] AngusLees
martin_krafft: s/jonothanwalther/me/
[07:27:02] martin_krafft
[07:27:03] martin_krafft
[07:27:08] BrandenRobinson thinks there is a balance to be found between the flame-heavy extreme-deathmatch list scenario, and the all-roses-and-chirping birds scenario. I know I've experienced social pressure to alter my approach to the lists over the years, and that's as it should be.
[07:27:28] martin_krafft
What are the differences between lists that have flamewars and those that don't?
[07:27:36] AngusLees
martin_krafft: size of audience
[07:27:36] BrandenRobinson
"If you can't say something nice, don't say anything at all" can lead to conflict with "We Won't Hide Problems".
[07:27:36] JonathanWalther
BrandenRobinson: you are one to complain about thin skins; you had me on /ignore for a long time. ^_^
[07:27:47] BrandenRobinson
JonathanWalther: that's not actually true :)
[07:27:57] MatthewGarrett
I agree with Branden and Anthony here. The lists could do with some cleaning up, and I think more social pressure is a good start here
[07:27:59] AndreasSchuldei
i think it is mostly the mix of individuals and the size.
[07:28:03] JonathanWalther
BrandenRobinson: ah. you did a really good job of pretending to /ignore me then ;)
[07:28:19] JonathanWalther
BrandenRobinson: which takes a stunning amount of self-control. I applaud you.
[07:28:22] BrandenRobinson
JonathanWalther: I do sometimes keep my mouth shut if someone is provoking me so badly that I might just embarrass myself by talking :)
[07:28:24] martin_krafft
What kind of social pressure are we talking about?
[07:28:31] MatthewGarrett
The biggest difference between lists with flamewars and lists without is probably down to how those lists are used
[07:28:38] AngusLees
JonathanWalther: i'm guilty of deleting your -private posts based purely on the sender
[07:28:39] AnthonyTowns
martin_krafft: Usually it's a habit of just not having flamewars -- it takes at least two to create one, and if people are in the habit of just chilling, they don't start. Debian's not really in that habit in a lot of places.
[07:29:02] BrandenRobinson
martin_krafft: calm replies to unreasonable messages that point out how a person could responsd more constructively.
[07:29:12] BrandenRobinson
martin_krafft: It's an art form. Some people are very good at it, others aren't.
[07:29:13] AndreasSchuldei
martin_krafft: is this the kind of debate you envisioned? it seems pretty chaotic.
[07:29:14] martin_krafft
AnthonyTowns: you want to "enforce"... do you see other ways than moderation?
[07:29:28] MatthewGarrett
Lists that focus entirely on a specific task (or small subset of tasks) tend to be without flamewars. People are on those lists because they're actually doing stuff, so there's much less temptation to descend into flames.
[07:29:32] JonathanWalther
AnthonyTowns: to the contrary, people with thin skins need to program alone.
[07:29:33] AngusLees
flaming seems to only be a problem where there are audiences: ie: -private, -devel, -project, -legal
[07:29:44] martin_krafft
AndreasSchuldei: you may well suggest another format. It's not easy to debate with 7 people on IRC.
[07:29:44] AngusLees
the smaller, focussed lists don't seem to have problems
[07:29:45] BrandenRobinson
Ouch. I just got ripped on -discuss.
[07:29:46] JonathanWalther
AnthonyTowns: people with thin skins are a net liability to ANY type of team effort. Debian is a massively team effort
[07:29:50] AnthonyTowns
I want to solve the problem; and I think it's bad enough that some sort of enforcement, rather than just a list policy and polite reminders is necessary. I'd love to be wrong.
[07:29:52] AndreasSchuldei
[07:30:14] JonathanWalther
AnthonyTowns: we can't afford thin-skins throwing monkey wrenches into things. That is part of why Debian has stagnated of late; too many thin skins combined with assholes.
[07:30:22] BrandenRobinson seconds AndreasSchuldei's observation that this is a bit chaotic.
[07:30:31] martin_krafft
[07:30:42] MatthewGarrett
JonathanWalther: What level of criticism do you believe people should have to put up with?
[07:30:46] martin_krafft
i can also ask questions and allow 1-3 sentences for answering to each. :)
[07:30:52] AnthonyTowns
Moderation -- ie, every post being approved by a moderator group -- is pretty extreme; delaying posts (as already happens to some extent), bouncing replies to some contentious threads, digesting mail for subscribers who've been provoked into being uncooperative, or suspending/banning people are all other options.
[07:31:04] AndreasSchuldei
JonathanWalther: thin skins just means that they take the insults they receive to hard. in my oppinon there should be no insults in the first place. it is possible. we should try.
[07:31:06] BrandenRobinson
martin_krafft: I am known for my ability to craft very long sentences -- that might give me an unfair advantage. ;-)
[07:31:12] JonathanWalther
MatthewGarrett: I think threatening someones personal safety is beyond the limit.
[07:31:16] AngusLees
i would like to see a more widely known standard for what sorts of posts are deemed better to not have been sent
[07:31:37] AnthonyTowns
JonathanWalther: Yeah, I think there's a compromise to be reached between treating people with respect and not getting in the habit of flying off the handle ro getting overly grumpy.
[07:31:39] AngusLees
and we can refer people to that. repeat offenders (and most of the problems come from them) can be moderated or something
[07:31:39] MatthewGarrett
JonathanWalther: So all criticism up to that point should be accepted? I'd disagree quite vigerously
[07:31:41] BrandenRobinson
I believe I expressed my opinions on hard-moderation tactics in -vote.
[07:31:45] helen
BrandenRobinson: I think we're doing OK. this is not as complex/confusing as some IRC discussions I've seen. People will sort it out later on anyway.
[07:31:51] martin_krafft
It has been raised that Debian encourages flames by commending their posters.
[07:31:51] AndreasSchuldei
imho this debate mostly proves that we have a lot of candidates talking. (c:
[07:32:05] martin_krafft
I have also seen people commending calm posters.
[07:32:05] JonathanWalther
AndreasSchuldei: A thin skin will ALWAYS find a way to construe criticism or humour as an insult.
[07:32:09] BrandenRobinson
I don't believe we should undertake them without having a well-documented process for appeals that has the trust of the developers.
[07:32:11] martin_krafft
Do you think more of that would help?
[07:32:18] BrandenRobinson
A gag is a powerful weapon.
[07:32:22] JonathanWalther
AndreasSchuldei: therefore there is no possibility of eliminating "insults"
[07:32:27] martin_krafft
Do you think public tar-and-feather approaches might reduce flamewars?
[07:32:40] JonathanWalther
martin_krafft: absolutely not
[07:32:42] AndreasSchuldei
JonathanWalther: not true, i am on channels and lists with sensitive people on them, and they do fine there.
[07:32:44] AngusLees
martin_krafft: public tar-and-feather approaches *start* flamewars
[07:32:47] JonathanWalther
martin_krafft: people need to be mature enough to use /ignore
[07:32:58] BrandenRobinson
martin_krafft: Some people can be "shamed", others seemingly cannot.
[07:33:01] AnthonyTowns
BrandenRobinson: A post to -devel-announce is a pretty powerful weapon too :-P
[07:33:03] martin_krafft
AngusLees: exactly.
[07:33:04] MatthewGarrett
martin_krafft: If done by someone with sufficient authority? I think so, but it depends on what you mean by "tar and feather".
[07:33:10] BrandenRobinson
AnthonyTowns: Acknowledged.
[07:33:10] AndreasSchuldei
JonathanWalther: there, we hardly have any insults.
[07:33:12] JonathanWalther
AndreasSchuldei: really? which lists and channels are these?
[07:33:22] AndreasSchuldei
#debian-devel, for one
[07:33:23] martin_krafft
MatthewGarrett: take aj's and my flamewar from February.
[07:33:27] AnthonyTowns
martin_krafft: Public tar and feathering *is* a flamewar. I don't think making them official will reduce the unofficial ones; quite the oppisite.
[07:33:34] AndreasSchuldei
[07:33:38] martin_krafft
If you had stepped in and told us both to go play with toys, do you think it would have helped?
[07:33:40] AndreasSchuldei
debian-edu, soory
[07:33:44] JonathanWalther
AndreasSchuldei: uh. right.... the channel where doogie talks about shaving his pubic hair in public?
[07:33:47] AngusLees
the "that post was inappropriate for this list" posts should be done in private - otherwise they just continue the very thread they're stopping
[07:33:58] JonathanWalther laughs
[07:34:01] BrandenRobinson
Social pressures can get out of control too. I don't think we necessarily want to go the way of shunning, or scarlet letters.
[07:34:01] AndreasSchuldei
JonathanWalther: sorry, freudean slipp. (c:
[07:34:16] BrandenRobinson
That leads to a less tolerant society, not a more tolerant one.
[07:34:18] MatthewGarrett
I think it's important for it to be made publically clear that certain behaviour is unacceptable, but I think that ought to be done in a calm and reasoned way
[07:34:26] AngusLees
i'm not confident social pressure alone can get debian out of the hole we're in
[07:34:31] martin_krafft
AnthonyTowns: i think the community might well misunderstand your desires to "enforce"... how do you plan to enforce without too much social pressure?
[07:34:36] MatthewGarrett
(I know I'm guilty of failing in this, and I've already apologised for that after people picked me up on it)
[07:34:38] martin_krafft
AngusLees: what else could?
[07:34:59] JonathanWalther
when people get into a pissing contest, they need peer pressure telling them that they've gone beyond the pale. the last thing they need is to garner yet more (as they perceive it) attackers
[07:35:00] AngusLees
martin_krafft: we need to have a fairly widely published list of what we consider appropriate (for each list)
[07:35:17] BrandenRobinson
MatthewGarrett: implying that the general subscribership (at least the subset who post) of -legal is basically nuts isn't very nice either.
[07:35:24] AndreasSchuldei
AngusLees: i think social pressure is where we need to start. we should not escalate measures of dicipline to quickly.
[07:35:25] JonathanWalther
AngusLees: baloney. everyone here is an adult and should be expected to know what that means
[07:35:26] AngusLees
martin_krafft: then we need to have known procedures in place for dealing with repeat offenders
[07:35:35] martin_krafft
AngusLees: don't we already? or even more concrete?
[07:35:48] AnthonyTowns
martin_krafft: Most of the options I said above were technical options: if things get out of hand, posts just stop going through. That can calm things down, which I think is helpful. The real trick isn't social pressure, it's.. I don't know, social reinforcement -- having an environment where people don't mind posting because they know their ideas will be treated with dignity, and don't need to flame, because they're confident they'll be
[07:36:00] MatthewGarrett
BrandenRobinson: I disagree with the viewpoints expressed, and my experience suggests that the consensus viewpoint on d-l is not the same as the consensus viewpoint amongst other developers.
[07:36:05] BrandenRobinson
Like SPI, -legal does -- or tries to do -- some gritty, sometimes unrewarding work that not all people care to fool with.
[07:36:18] martin_krafft
AnthonyTowns: and walk the thin line between that and censorship...? how?
[07:36:29] AngusLees
martin_krafft: more widely published. for example, i don't think i've ever stumbled across such a statement (although i know we have it somewhere)
[07:36:44] AnthonyTowns
martin_krafft: Carefully. :)
[07:36:44] martin_krafft
AngusLees: it's linked from
[07:36:46] MatthewGarrett
I don't believe people's viewpoints should be ignored just because they're unwilling to express them in a forum where they feel unwelcome
[07:36:47] BrandenRobinson
MatthewGarrett: I think a lot of the problem is a lack of outreach. I've been pondering a "surprising FAQ" that would expose some of the more counterintuitive aspects of copyright/patent law to the uninitiated.
[07:37:06] AngusLees
by definition, the problem posters are frequent offenders
[07:37:12] AndreasSchuldei
an interesting option that was suggested by our new DAM was to ask individuals who have a hard time restricing themself to step out for a social checkup.
[07:37:18] BrandenRobinson
MatthewGarrett: In many cases, people feel -legal is "being unreasonable" simply because people there have researched the real-world application of law.
[07:37:21] AnthonyTowns
martin_krafft: Having checks and balances on what threads/people are gagged, having different areas where people can discuss things or flame or whatever and otherwise have an outlet is good too.
[07:37:22] JonathanWalther
MatthewGarrett: that is an interesting statement, considering you banned me from the debian-women@ mailing list, based on the fact that a few women didn't like my beliefs.
[07:37:36] BrandenRobinson
MatthewGarrett: and the law, it is said, "is an ass".
[07:37:48] JonathanWalther
MatthewGarrett: how do you reconcile your real world censorship of a Debian developer from a Debian mailing list, and your previous statement about not believing in censorship?
[07:37:53] AnthonyTowns
"confident they'll be consulted." if that was truncated before, btw
[07:38:04] MatthewGarrett
JonathanWalther: I haven't banned anyone from any mailing lists
[07:38:11] martin_krafft
Here's a question from the community: Do you feel it is appropriate to delegate new people to a position within Debian without the support of the individuals already delegated, should that need arise?
[07:38:12] MatthewGarrett
I'm not even a subscriber to debian-women
[07:38:25] BrandenRobinson
As long as we labor under the perversities of the concept of "intellectual property", I fear people's intuitive notions of free software will hit the shoals of reality.
[07:38:45] AngusLees
moderation isn't censorship btw. (its simply congestion control ;)
[07:39:00] AnthonyTowns
martin_krafft: It's not whether it's appropriate; it's whether it's effective. Having two people in a team working against each other doesn't work. But there's plenty of ways of encouraging people to accept new members into teams.
[07:39:02] BrandenRobinson
AngusLees: it's not? Even if a post is bounced/rejected?
[07:39:05] martin_krafft
AngusLees: people will disagreeon that.
[07:39:15] helen
can we move on to martin_krafft 's latest question now please.
[07:39:20] AngusLees
provided reasonable posts by a "problem poster" are still allowed through, i don't see anything wrong with it
[07:39:21] MatthewGarrett
BrandenRobinson: But to a large extent, the argument is down to differing beliefs about how stringently the DFSG should be interpreted. That's not down to disagreement about how the law applies.
[07:39:43] AndreasSchuldei
martin_krafft: i think such steps need some consideration. it depends on the individual and the group, and how the group is doing.
[07:39:52] JonathanWalther
MatthewGarrett: sorry; I must have mixed you up with a different Matthew. Perhaps Matthew Palmer. Someone who has admin access to the Debian mailing lists anyway, unilaterally booted me from debian-women@
[07:40:02] JonathanWalther
MatthewGarrett: if you were DPL, what would you do to remedy that?
[07:40:10] helen
BrandenRobinson, AngusLees, MatthewGarrett, JonathanWalther : next question, please :)
[07:40:13] martin_krafft
AndreasSchuldei: well, what might a DPL do to make sure that all groups actually make it possible?
[07:40:17] AndreasSchuldei
could that community question person elaborate on the context, for a more sensible answer?
[07:40:17] BrandenRobinson
MatthewGarrett: Sometimes, that is the case. But I've seen people on -legal get angry and carry over...
[07:40:19] helen
[07:38:11] martin_krafft Here's a question from the community: Do you feel it is appropriate to delegate new people to a position within Debian without the support of the individuals already delegated, should that need arise?
[07:40:21] BrandenRobinson
helen: okay.
[07:40:42] JonathanWalther
Delegation is always volunteer.
[07:40:46] BrandenRobinson
helen: I'd regard that as an option of near last-resort.
[07:40:54] martin_krafft
JonathanWalther: see womble on -discuss
[07:40:56] BrandenRobinson
JonathanWalther: the moderators mean appointment to a team
[07:40:59] MatthewGarrett
If it's the only way to ensure that work is done to a standard acceptable to the rest of the project, then yes
[07:41:02] JonathanWalther
You can be delegated. And you can refuse the delegation. There is no need for prior consultation.
[07:41:06] AngusLees
helen: if the result is going to be harmful, of course not
[07:41:14] JonathanWalther
martin_krafft: I'm not on -discuss
[07:41:18] AndreasSchuldei
martin_krafft: "never change a running system". if the groups work well no need of additional man power is there and they dont want more people, the dpl should keep out of their way. (c:
[07:41:24] JonathanWalther
martin_krafft: I can only track two irc windows at once
[07:41:36] martin_krafft
AndreasSchuldei: but what if a group suddenly goes unwell.
[07:41:37] BrandenRobinson
JonathanWalther: the scenario is, A, B, and C are on team X. The DPL wants to appoint D, and D wants the position, but A, B, and C don't want D on the team.
[07:41:43] martin_krafft
[07:41:44] martin_krafft
[08:40 womble Can I get a retraction on that comment by krooger? I don't
[07:41:47] martin_krafft
have admin powers over any list
[07:41:55] AndreasSchuldei
martin_krafft: the reason for that would be interesting.
[07:42:03] martin_krafft
AndreasSchuldei: death?
[07:42:09] AndreasSchuldei
martin_krafft: if a new member can fix it, sure.
[07:42:11] BrandenRobinson
As I said, I'd hate to see things reach that point. I would definitely do a lot of consulting around before taking that step.
[07:42:15] martin_krafft
(to name the most extreme)
[07:42:17] MatthewGarrett
But obviously it's going to cause unhappiness and general misery, so it should only occur if there's no other solution
[07:42:17] JonathanWalther
martin_krafft: people are free to read Matthew Palmers posts to debian-women and decide for themselves what "powers" he has.
[07:42:19] AndreasSchuldei
martin_krafft: is the group dying or a memeber?
[07:42:25] BrandenRobinson
Because of course, one risks the angry resignations of A, B, and C.
[07:42:39] martin_krafft
AndreasSchuldei: let's say 50% of them stop working for the group.
[07:42:57] MatthewGarrett
But fundamentally no set of people, no matter how established they are, should have the ability to become a major bottleneck without justification
[07:43:07] AndreasSchuldei
martin_krafft: the desired state would be that the group notices that a memeber is dead. (c: and then go and find a successor.
[07:43:14] AngusLees
BrandenRobinson: exactly. so A, B and C would have to be completely disfunctional already for the DPL to even be considering forcing in a new person
[07:43:22] AndreasSchuldei
if the dpl is the only one knowing, he should tell them and help them go on.
[07:43:36] MatthewGarrett
A consensus-based solution to that is massively preferable, but if that's impossible then "hostile" delegation is the only real option
[07:43:37] BrandenRobinson
MatthewGarrett: It's interesting that 3 separate teams have veto power over adding a new architecture to the releasable group for etch, in the Vancouver Prospectus.
[07:43:38] JonathanWalther
BrandenRobinson: obviously, the right to freedom of association (gauranteed in the Canadian constitution) means that although the DPL can delegate someone to a team, if the team doesn't accept them, that is the DPL's tough luck. The real question is, is the DPL willing to sack the entire team in order to get his delegate into position?
[07:43:54] martin_krafft
alright, enough of this. i have been told to shut up more.
[07:43:58] martin_krafft
let's move on...
[07:44:02] martin_krafft
It is probably safe to say that the results of the Vancouver meeting
[07:44:04] martin_krafft
stirred the community up quite a bit. What could have been done
[07:44:05] BrandenRobinson
Delegates serve at the pleasure of the DPL.
[07:44:07] martin_krafft
better to prevent such turbulences and potential loss of
[07:44:09] martin_krafft
[07:44:14] MatthewGarrett
BrandenRobinson: If such a veto occured without justification, I'd be asking questions.
[07:44:17] BrandenRobinson
martin_krafft: nice segue from my previous remark :)
[07:44:38] martin_krafft
BrandenRobinson: unintentional, but with pleasure in the after thought. :)
[07:44:41] JonathanWalther
martin_krafft: I don't see any loss of productivity. The Vancouver meeting was a necessary bit of quiet time for the release managers to get together without distraction.
[07:44:43] AngusLees
martin_krafft: it seems the meeting was arranged hurriedly for some reason. i think there was no need for such haste (the DPL election?)
[07:44:49] JonathanWalther
martin_krafft: again, I fully support the right to freedom of association.
[07:44:54] AndreasSchuldei
martin_krafft: then the group should try to find new members, in an active way.
[07:45:00] BrandenRobinson
AngusLees: That might simply have been a matter of availability.
[07:45:01] AnthonyTowns
martin_krafft: Obviously, I like the idea of cutting off the flamewar where it starts to get nasty, non-technical or overly repetitive. :-/
[07:45:15] AndreasSchuldei
martin_krafft: the dpl should tell them to do so, if they dont.
[07:45:15] BrandenRobinson
AngusLees: recall how hard it was for the 6 of us just to settle on a time for a 2-hour debate we could do via IRC.
[07:45:17] AngusLees
BrandenRobinson: surely availability is also easy to work out if there are longer time frames involved
[07:45:20] JonathanWalther
martin_krafft: if any group of Debian developers wants to get together for a purpose involving Debian, the rest of Debian has no say in that. But it would be very rude if such a group didn't make their purposes or activities known to the public.
[07:45:26] AnthonyTowns
martin_krafft: From the other side of things, having had more debates in public in advance would have been helpful; but in the current list climate just seems impossible to me.
[07:45:31] JonathanWalther
martin_krafft: it would be anti-Debian, even.
[07:45:36] MatthewGarrett
I think would be a good set of starting points here
[07:46:10] martin_krafft
do you have any comments on the way the proposal was brought forth?
[07:46:20] MatthewGarrett
More opportunity for input in advance would have improved things, even if most of that input had been ignored. More detailed justification afterwards would have changed the character of the discussion considerably.
[07:46:26] BrandenRobinson thinks that the Vancouver Prospectus could have been written in a way that would not have poked the hornet's nest quite so badly, but I also suspect 1) the task of writing it up fell to one poor sucker of a volunteer (hi vorlon) who was under time pressure to get it out quickly, and 2) It was destined to generate a lot of discussion no matter what.
[07:46:38] BrandenRobinson
Simply because of the conclusions reached.
[07:46:50] AngusLees
and it seems the discussion started off with "we need to reduce the architectures on the mirrors down to ~4. how do we choose which?" which wasn't the way it was described at all
[07:47:03] AngusLees
when put that way (and explained why thats necessary) it all seems quite reasonable
[07:47:05] BrandenRobinson
As time goes on, I hope that some document is put together that satisfies the goal I established for the VancouverProspectus page on
[07:47:10] AnthonyTowns
For reference, the document got reviewed by everyone who was there; though Steve (vorlon) wrote most of it
[07:47:27] martin_krafft
let's look at the content...
[07:47:28] AndreasSchuldei
the proposal was really meant as a proposal. the ongoing and to a good deal productive discussion between the involved people shows that best
[07:47:28] martin_krafft
Debian is known as the universal operating system. It is also known to suffer from long release cycles. What is the purpose of Debian? Does sacrifice of the "universal" slogan warrant shorter release cycles? What do our users want?
[07:47:50] JonathanWalther
I think the Vancouver concensus was done as gently and unobtrusively as possible.
[07:47:58] JonathanWalther
I see nothing for Debian to complain about in how it was conducted.
[07:48:00] BrandenRobinson
Well, "universal" means different things to different people.
[07:48:19] AngusLees
ah. apparently vorlon has said that longer times were considered. thats cool then
[07:48:21] BrandenRobinson
Does the lack of a "stable release", itself an arbitrary thing, necessarily negate universality?
[07:48:33] JonathanWalther
martin_krafft: Debian is known for its rock-solid, easy upgrades. few of our userbase care about all the esoteric architectures.
[07:48:34] AndreasSchuldei
debian would not lose the architectures. it would be able to open up to new ones, instead.
[07:48:40] BrandenRobinson
I think that's a question we need to answer collectively. It's not something the DPL can dictate.
[07:48:47] JonathanWalther
martin_krafft: a few years ago we were also known for our easy install too
[07:49:11] BrandenRobinson 's UltraSPARC,, runs unstable.
[07:49:14] AnthonyTowns
I don't think we're dropping the "universal" slogan; we're just potentially changing the way we'll support some architectures. I certainly hope it won't mean people using non-i386/ppc not being able to use Debian usefully.
[07:49:20] AndreasSchuldei
JonathanWalther: we are on a good way to have easy installs in the furture, too. (c:
[07:49:29] BrandenRobinson
If it continues to serve its purpose soundly even as a "second-class" arch, I will not personally be too adversely affected.
[07:49:36] AngusLees
the scalability of the debian approach to building a distro is one of its most important features (as i mentioned in a respone to a question in phase1)
[07:49:41] martin_krafft
isn't "second class citizens" bound to make people reconsider?
[07:50:04] BrandenRobinson
I also hope that vested interests (read: corporations) in the community with an investment in those 'second-class architectures' will help put their shoulders to the wheel to help get them promoted back to first-class.
[07:50:06] MatthewGarrett
I don't think the length of our current release cycle is sustainable, and I think it's cost us good-will from the community. I don't want to lose stable releases of some architectures (I've got at least 7 of our supported architectures in this room right now), but if that's the only way to support the vast majority our users then I think it's something we'd have to accept.
[07:50:22] AndreasSchuldei
the current *constructive* part of the discussion will solve that problem, i am convinced.
[07:50:22] AngusLees
i think people come to debian *because* we can (and do) support all sorts of niche areas
[07:50:25] AnthonyTowns
I don't think Debian has any one purpose; it's got at least as many as there are developers, and probably an order of magnitude more than that. I like it because I think it demonstrates how software development should be done
[07:50:29] BrandenRobinson
It may be that we have a bit of a "tragedy of the commons" going on when it comes to energetic volunteers and some architectures.
[07:50:47] MatthewGarrett
But *before* we make that decision, I'd like to see more discussion of what the problems we're solving are. The release team have made it clear what they view the problems as being, and that's been immensely helpful. I'd like to see something similar from the ftp-masters.
[07:50:53] AndreasSchuldei
debian has allways excelled in solving its technical problems, and it will do so this time, too
[07:50:57] BrandenRobinson
MatthewGarrett: hear, hear.
[07:51:14] MatthewGarrett
It's possible that we can come up with another proposal that solves the problems /without/ resulting in reduced architecture support.
[07:51:37] MatthewGarrett
Debian is a resourceful organisation. If we can't fix the problem, then the problem may be unfixable. And in that case, we have to make a hard choice.
[07:51:50] JonathanWalther
I haven't used the "stable" distro in years.
[07:51:55] JonathanWalther
how many people actually use stable?
[07:51:57] martin_krafft
we have another community question:
[07:52:08] AngusLees
JonathanWalther: i use it every day at work in the products i make
[07:52:08] MatthewGarrett
As I said, as much as I dislike it, I think dropping some support for some architectures is better than taking 3 years to release
[07:52:11] martin_krafft
In what way do you think Debian can honor the labor contributions of non-DDs who do significant work for the project (e.g. translators)?
[07:52:16] BrandenRobinson
AndreasSchuldei: I like your confidence, but I wouldn't want to lull people into complacency. We'll only solve this problem if we get off our butts and work for it.
[07:52:26] AngusLees
believe me, corporate (and embedded, etc) users do *not* want 6 monthly releases
[07:52:29] BrandenRobinson
martin_krafft: Insufficiently.
[07:52:39] JonathanWalther
it is important to remember that "dropping support" is much different from dropping the architecture.
[07:52:45] MatthewGarrett
In my experience, the best reward I've obtained from my contributions to anything has been to see it being used.
[07:52:49] martin_krafft
BrandenRobinson: and that cannot change?
[07:52:52] JonathanWalther
the developers for various architectures work hard, and are proud of the fruits of their labors.
[07:52:58] BrandenRobinson
martin_krafft: When I get debconf translation updates for xfree86, for example, I always credit the submitter.
[07:53:03] JonathanWalther
even our "unsupported" architectures will live up to the high Debian quality
[07:53:04] BrandenRobinson
I've seen many other people do that too...
[07:53:22] BrandenRobinson
But given the benefits of translation, I'm not sure the people who do that work are esteemed as highly as they should be.
[07:53:22] JonathanWalther
and once we have the unsupported category, we will be able to add even more architectures in.
[07:53:38] MatthewGarrett
We need to ensure that contributions from non-DDs are incorporated rather than being dropped on the floor, and we need to make it clearer to people how they can get involved in doing that
[07:53:41] martin_krafft
JonathanWalther: in the real world, people care very much about the official vs. not 100% official labels. do you see that as a problem?
[07:53:41] BrandenRobinson
I got a bit of insight last year into just how challenging translating some of my English, for example, can be... :)
[07:53:43] AndreasSchuldei
MatthewGarrett: i actually think the people involved in solving the problems (porters, relase team and the ftp masters) are very well qualified to find a good solution. have some faith in them and give them some time to find it.
[07:54:00] JonathanWalther
AngusLees: corporate and embedded users don't want to upgrade at all; they want to take a snapshot and run with it for years and years, like NeXT did with 4.3BSD.
[07:54:09] helen
AnthonyTowns, AngusLees : do you have an opinion on that?
[07:54:09] AngusLees
i think we aknowledge contributions well already. most changelog lines will include a persons name where appropriate - and the scandle that arises when someone screws this up just shows how well we do normally
[07:54:15] BrandenRobinson
Here's an idea for a DWN feature: weekly, we could give props to a translator or l10n specialist.
[07:54:16] JonathanWalther
AngusLees: we shouldn't try to pick oranges from an apple orchard
[07:54:16] AnthonyTowns
martin_krafft: I'm not sure what more you want than already happens; mentioning the names of people who contribute patches seems fairly standard practice; and I assume the translation websites already have shout outs to the guys who do the work.
[07:54:24] MatthewGarrett
AndreasSchuldei: I think limiting the set of people working on a problem of this magnitude is not necessarily wise.
[07:54:26] BrandenRobinson
I think the KDE project used to do this for some of their developers.
[07:54:50] martin_krafft
AnthonyTowns: i think the problem is the lack of direct belonging to the project
[07:54:51] JonathanWalther
martin_krafft: do not translators get credit for their work?
[07:55:00] JonathanWalther
martin_krafft: aren't their names in the translations and changelogs?
[07:55:09] BrandenRobinson
Do translators not deserve to be DDs, though?
[07:55:09] AndreasSchuldei
MatthewGarrett: no one is excuded. some exclude themselfs by giving up or by deciding to boycott the process.
[07:55:15] martin_krafft
they are not developers and in as such they are not specially recognised outside their individual contributions. my take...
[07:55:17] AnthonyTowns
martin_krafft: If translators want to be more involved in Debian and have a use for developer access, I'm all for that of course; even if that's just the ability to Vote [1] AJ ;)
[07:55:18] BrandenRobinson
Or people who just write/edit documentation?
[07:55:35] BrandenRobinson
[07:55:39] JonathanWalther
martin_krafft: I personally would like to see our translators get a personal address; probably instead of a top-level email address
[07:55:46] BrandenRobinson writes no small amount of documentation himself.
[07:55:58] martin_krafft
were are problems with giving out 200 new accounts to translators and other contributors?
[07:56:03] BrandenRobinson
JonathanWalther: SCD? Second-Class Developers?
[07:56:13] AngusLees
hell, non-DDs can even get packages uploaded fairly easily. how much more contribution do we want?
[07:56:13] BrandenRobinson
Tiered developership has ben proposed before.
[07:56:17] BrandenRobinson
I'm pretty uncomfortable with it.
[07:56:26] JonathanWalther
BrandenRobinson: a developer writes code. a translator is a "contributor"
[07:56:34] JonathanWalther
BrandenRobinson: maybe
[07:56:42] JonathanWalther
BrandenRobinson: sort of like an honorary degree from a university
[07:56:44] BrandenRobinson
a lot of "developers" don't "write code". They maintain it.
[07:56:48] AnthonyTowns
martin_krafft: There's no problem, except that they have to pass trhough n-m just like everyone else. That's pretty time consuming for them, and comparitively little benefit for anyone, afaics
[07:56:59] MatthewGarrett
In some ways, I wonder if the Gnome foundation is a worthwhile model here - the membership requirements include you having made some contribution to Gnome, but don't require it to be in the form of code
[07:57:02] BrandenRobinson
I sure didn't do much code *writing* my first year or two as an xfree86 maintainer.
[07:57:05] JonathanWalther
BrandenRobinson: most developers CAN write or FIX the code they maintain, if called upon.
[07:57:10] AndreasSchuldei
martin_krafft: i discussed that with DAM. they think it is hard to draw a line
[07:57:18] martin_krafft
Would you, the candidates, be willing to go through NM again, anonymously, and report on your experiences afterwards?
[07:57:20] JonathanWalther
BrandenRobinson: I don't know any debian developers who can't at least program their way out of a paper bag.
[07:57:28] BrandenRobinson
JonathanWalther: Uh.
[07:57:31] MatthewGarrett
martin_krafft: Absolutely.
[07:57:35] JonathanWalther
martin_krafft: sure.
[07:57:45] BrandenRobinson
I know of Red Hat employees with their names on well-known software who can't code their way out of a paper bag :-P
[07:57:46] martin_krafft
anyone else?
[07:57:47] AnthonyTowns
Note that we've started getting non-packagers through n-m now days, and hopefully the "Must know debian/rules backwards" part of n-m won't be so crucial in the future.
[07:57:51] AndreasSchuldei
martin_krafft: the example they gave was: would a sponsor of machine and bandwidth also become a DD, with voting power?
[07:57:52] MatthewGarrett
However, it sounds like a bit of a logistical problem if it's going to be properly anonymous
[07:57:58] BrandenRobinson
but I have high standards, and I am being crotchety :)
[07:58:03] MatthewGarrett
(Faked up GPG keys, that sort of thing)
[07:58:06] AndreasSchuldei
martin_krafft: they are contributing, too.
[07:58:09] AngusLees
martin_krafft: of course
[07:58:28] BrandenRobinson
martin_krafft: Yes.
[07:58:28] martin_krafft
okay, we are nearing the end.
[07:58:33] martin_krafft
i have two more questions for you:
[07:58:52] martin_krafft
if you could not vote for yourself, whom would you vote and why? please make it short...
[07:58:53] AnthonyTowns imagines a pool of dormant piranha
[07:59:01] AndreasSchuldei
martin_krafft: i personally think that debian should try to find ways for artists, translators, fair-organizers etc to become voting members
[07:59:10] AngusLees
martin_krafft: heh. cool question
[07:59:29] BrandenRobinson would vote for Andreas. As a fellow leadership-team member, I trust him to take my proposals the most seriously.
[07:59:41] BrandenRobinson
However, as usual we have a pretty strong slate of candidates.
[07:59:44] MatthewGarrett
I fundamentally disagree with Anthony on the issue of the level of communication expected from teams, but other than that our views seem broadly aligned. So him.
[08:00:14] AngusLees
"JonathanWalther", because he probably has less of a chance at winning than I do :P
[08:00:19] AnthonyTowns
I think we have anonymous leadership ballots for a reason ;) I'm tossing up between Matthew and Andreas at the moment; but I haven't even been able to read people's answers to the first hour yet.
[08:00:25] martin_krafft
AngusLees: that was below the belt line.
[08:00:30] AndreasSchuldei
[08:00:39] AngusLees
yes it was for such a public forum
[08:00:47] martin_krafft
[08:00:49] AnthonyTowns
[08:00:51] AnthonyTowns
[08:00:54] JonathanWalther
AngusLees: fairly tame compared to what I've heard elsewhere.
[08:01:11] martin_krafft
we have one more community question:
[08:01:19] AngusLees
seriously, i'd probably say AJ because i'm nervous about the DPL team thing
[08:01:22] BrandenRobinson would point people to his rebuttal this year for more on the candidates.
[08:01:26] martin_krafft
what is the minimum level of activity we can expect from DDs?
[08:01:46] BrandenRobinson
martin_krafft: It's proportional to how much responsibility they've accepted.
[08:01:48] AndreasSchuldei
branden has the added "seriousness factor" of beeing on the dpl team. he does not underestimate the task
[08:01:52] JonathanWalther
martin_krafft: as much as they see fit to give.
[08:01:56] MatthewGarrett
An inactive DD isn't a problem. An obstructive one is.
[08:02:05] BrandenRobinson
If they maintain packages, I expect them to keep up with their bugs.
[08:02:18] BrandenRobinson
squish the RC ones, and fix as many non-upstream ones as possible.
[08:02:23] JonathanWalther
martin_krafft: most DD's are volunteers with real life jobs and careers.
[08:02:45] martin_krafft
alright... wrap it up...
[08:02:45] martin_krafft
In one sentence: what makes you a good project leader for Debian?
[08:02:50] MatthewGarrett
I don't think we have any right to demand people should work to a certain level, but if they accept responsibility without putting in sufficient effort then it should be socially acceptable for someone else to pick up that responsibility
[08:03:00] BrandenRobinson
In general, as Matthew noted, I don't think we truly notice inactive developers until they actual impede the progress of the project somehow.
[08:03:20] BrandenRobinson
And such impediments are easily noted, and recognized as problematic.
[08:03:28] martin_krafft
AndreasSchuldei, JonathanWalther: whom would you vote?
[08:04:05] martin_krafft
2 minutes left.
[08:04:05] MatthewGarrett
I'm willing to upset some people in order to make things better for everyone else.
[08:04:09] AngusLees
martin_krafft: independence, personality, and relevant experience.
[08:04:31] AndreasSchuldei
oh i said BrandenRobinson
[08:04:32] AnthonyTowns
Uh, I think asking to sum up in one sentence is biassed against me and Branden. :)
[08:04:45] AndreasSchuldei
branden has the added "seriousness factor" of beeing on the dpl team. he does not underestimate the task.
[08:04:46] martin_krafft
keep it short.
[08:04:58] martin_krafft
AnthonyTowns: ^
[08:05:06] AnthonyTowns
(And that can my sentence; if you're deciding your vote on one sentence you're going on intuition, so good for you :)
[08:05:19] BrandenRobinson
I would make a good project leader for Debian because I've worked the hardest for it, I've consistently turned my attention to difficult problem areas, I combine an ability to work well with others with a resistance to intimidation, and I live and breathe the ideals of the Debian Project every day.
[08:05:54] BrandenRobinson
Oh, and I try to know when to laugh at myself. Like now, when I've gotten much too grandiose in my rhetoric :-P
[08:06:08] martin_krafft
JonathanWalther: ?
[08:06:22] JonathanWalther
I'd be a good DPL because I am FEARLESS, just like my namesake Jonathan, son of Shaul, who climbed up a cliff and singlehandedly attacked an entire Philistine fortress.
[08:06:24] AngusLees
BrandenRobinson: and i was just about to give you the the longest sentence award :P
[08:06:29] AnthonyTowns
see, branden couldn't do it either!
[08:06:32] AndreasSchuldei
i have started to work on the issues at hand a dpl should work on. i will continue to do so, if i get elected.
[08:06:33] AnthonyTowns
[08:06:38] AnthonyTowns
cancel the debate! reschedule!
[08:06:50] martin_krafft
okay, the debate is cancelled^Wover
[08:06:52] BrandenRobinson
AnthonyTowns: that last bit was an, uhm, footnote. yeah, yeah, that's the ticket!
[08:07:01] martin_krafft
Thank you all for participating
[08:07:12] martin_krafft
we can now move back to 300 posts/day on debian-vote
[08:07:13] MatthewGarrett
Thanks very much to the moderators. I know they must be about as exhausted as I am right now...
[08:07:18] BrandenRobinson
thanks for managing this logistical challenge, Martin and Helen.
[08:07:21] martin_krafft
I hope you enjoyed it half as much as I did (at least)
[08:07:24] AndreasSchuldei
thank you for your efford, helen and martin_krafft!
[08:07:27] helen
thanks to martin_krafft for working with me to run this :)
[08:07:30] martin_krafft
MatthewGarrett: i am ready to drop dead.
[08:07:32] JonathanWalther
tchau tchau!
[08:07:34] AngusLees
thanks. i'll try to stop my eyes from jumping around so much..
[08:07:46] AnthonyTowns
and ta for the awesome timing :)
[08:07:48] martin_krafft
candidates: you are invited to continue in -discuss
[08:08:10] martin_krafft
i will followup to -vote and -devel-announce
[08:08:14] helen
and thanks to helix, slef, Rhonda and dondelelcaro for helping with the -discuss channel and forwarding questions from there to us.