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.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAl24c+UACgkQQe7SUh/W ssr7wAgAh7Lz4F5lI+ei5vLGiOdVb7iC0PmasRMF5LwAbkRX2UtFdIqnjLSl8+A9 Q5s3ZeTPg0NnFPd9SD/TZbsOAn+hddjONJ3FdWWMR+Ks0EW24PqhcL42/HbMOiGA H1XovN9/39HrPCewXQoEDXqq9vLaXDwLzRj4YRwMQkIVc5uug70boSx2rNY3JeBy 978qBsrYR/nQBjsQFqndY+Pek0puZ6ETUsfRFLt+TqcGLj/5TH7Wj2lpK/I78doj 2KrD/X5IwCkds12dmBJbpjXirW8bhv4/AWZTFJK2CnaeN+0NZxPlVUonOELshW5X wI29ofxdtpCvWZc3JsldvIeyZ6+fBg==
=EcRz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)