I've gotten somewhat behind and so I'm publishing a bits mail including both October and September. This is just updates on things I've discussed before and talks I'll be giving. * We are seeking final comments on the current round of Git discussions by November 5. We need more comments especially confirming that I have correctly summarized the discussion to move forward. * I said last month that I might consider a GR for init system policy. I'm in talks preparing ballot text; read below for what convinced me we need that. * I'll be on a panel talking about some issues I brought up in my DebConf keynote at the Software Freedom Law Center's conference Friday. * I spent some money. Git Packaging============= I sent out a summary of the Git packaging discussion [1]. It would really help if people who participated in the discussion could confirm I've accurately summarized that discussion, or indicate areas where I got it wrong. Other comments are also very welcome. Comments are most appreciated prior to November 5. The summary includes other areas where you can help. [1]: https://lists.debian.org/msgid-search/tslv9t0uj2x.fsf@suchdamage.org Init System Policy ================== last Bits mail, I talked about how I was considering whether we needed a GR on Init System Policy. I've decided we do. I'm working with a number of people putting together a draft ballot that I think represents some reasonable options. I'll float text publicly before actually proposing the GR. Several things happened that convinced me we need to come together as a project and figure out where we are on this issue. 1) On one hand, the elogind maintainers and others are working as hard as they can to respond to concerns that are being raised and to work within our processes to get a new elogind into testing. Mark Hindley has been great to work with. A couple of others who want to see elogind succeed have gotten frustrated at times. The discussion overall has been professional and something we should support. 2) I've talked to people who have concerns about elogind. There's a lot of burn out. Several key people have told me that they are ignoring the issue because sysvinit will eventually just die off. It's all well and good for us to focus on projects that interest us. However, when we find ourselves in gatekeeper roles and are raising concerns about work others do in the project, we need to engage responsively and respectfully. We can do that by helping discuss our objections and trying to resolve them. We can do that by confirming that the project doesn't have overall interest in the work. I don't find stonewalling respectful even though it's a lot less work than facing hard questions. 3) The policy editors have said on debian-devel and repeated to me multiple times that they cannot get consensus to resolve important open issues surrounding init systems in policy. 4) Even within communities with nominally similar interests there's a significant disconnect about what is going on. I've run into multiple rounds of conversations that look like this: person: "Why don't you just talk to x or do y?" me: "That was tried; they said they couldn't help, or were blocked, or burned out." Again, I'm seeing that sort of disconnect on different sides of the issue. I'm absolutely convinced we've reached a point where in order to respect the people trying to get work done, we need to figure out where we are as a project. We can either decide that this is work we want to facilitate, or work that we as a project decide is not important. If we choose to facilitate the work, then I can help. I can work with teams to help them get the resources they need to respond to concerns. The policy editors will likely be able to break some of their deadlocks. We'll never force people to engage in work they don't want to do. But those of us in leadership positions will benefit from understanding where the project wants to go. Talks this Month ================ In September, I gave a talk at the MIT Student Information Processing Board's 50th anniversary on my experiences building teams. I talked about the positive effects in believing in people and challenging them to succeed. I talked about cases where solutions were found that I considered impossible because I worked to listen and not to be dismissive. This Friday, November 1, I'll be on a panel at the Software Freedom Law Center's conference in New York. We'll be talking about the changing aspects of software distribution--things like application containers, language specific repositories, and the role of distributions. This is stuff I talked about in my keynote panel. I'll say right up front that I think our community is harmed by the Software Freedom Law Center's decision to sue the Software Freedom Conservancy over trademark infringement. I don't support that decision, and I wish the Software Freedom Law Center made different choices surrounding that issue. However, I think communities are stronger when we work past differences. I strongly support much of their other work, including the FreedomBox project and creating a community where lawyers can focus on issues unique to free software. Obviously I'm looking forward to discussing the issues I brought up in my DebConf keynote. I also think it will be valuable for Debian to be part of the larger conversation at this conference. It's a very different community than we normally interact with. Yet bringing in the viewpoints of user freedom and community driven efforts like Debian are an important part of a broad conversation on the legal issues surrounding free software. I'll do my best to bring that voice. Spending Money ============== * Approved reimbursements for people to travel to the GSOC summit * Approved reimbursements for a sprint to work on packaging the Open Build Service * Approved a second Outreachy slot * Approved buying SSDs for reproducible builds machines * Approved replacement hardware for DSA * Approved travel reimbursement for travel to the recent mini DebConf Feedback ======== This note is somewhat more brief that past bits mails. The summary at the top is intended to help address concerns about these mails being long. I'll make a few other changes to allow these to be easier to skim going forward. However, I've gotten a large number of private comments over the months that my detailed bits mails were appreciated. I will work to meet the needs of that audience too. This month, I had less time, and most of the issues had been discussed in previous mails. As always, I value your feedback at leader@debian.org or on appropriate mailing lists.
Attachment:
signature.asc
Description: PGP signature