Hello Enrico,
On 21/03/2016 16:29, Enrico Zini wrote:
> Hello Mehdi,
>
> in your platform there is a section "Vision" that deals with several
> important practical aspects of Debian.
>
> I see the DPL as a person that we choose for a year to give the project
> a broad sense of direction, to inspire, to keep people's perception of
> Debian up to date, to tell tales of what Debian has become, to tell
> tales of the wonders that are about to come.
>
Note that later you reduced this list simply to: "to inspire". I do
not think it is a good summary, but I'll keep this in mind when
writing my reply below and will consider "to inspire" below to be the
contraction of the above list.
> As a thought experiment, suppose that you managed to delegate all the
> everyday tasks of approving expenditures, facilitating practical
> decisions, even answering regular lea...@debian.org email, to good and
> skillful people you can trust.
>
Wonderful. :-) Is that also valid for social and/or organizational
issues? I believe they take a fair amount of DPL time.
> You are then left with the one thing that you cannot really delegate: to
> inspire. You are on the biggest stage in the project. Everything you are
> going to say will instantly appear on LWN and at the top of Hacker News,
> you are going to give keynotes in the most important conferences around
> the world, participate in strategic meetings where the future of IT is
> discussed, to see if and how Debian wants to be in it.
>
> How do you see Debian right now?
>
> How do you imagine Debian to be in one year, when you will be
> summarizing the recent history in your campaign for re-election?
>
> How do you imagine Debian to be in the distant future of IT, say, three
> years from now?
>
FWIW, there was a similar question last year (See [0]). This mail
intends to be also a reply to <20160322073627.ga24...@xanadu.blop.info>.
Debian is inevitably one of the biggest and most successful FOSS
projects. It has a remarkable longevity and is still very widely
used. All of that is built by a solid (evolving) community. Our
success is often linked to the stability of our releases, our free
software philosophy, and our attachment to technical excellence. Some
tools have contributed to our success, like our holly famous package
manager and our modular installer.
All of that is challenged every year and we should embrace change in
order to keep our project relevant.
The Linux distribution model became less relevant with time. It
doesn't mean that we have to stop doing what we do best, but some
things need adjustment.
We lack a roadmap. Many things are done within the project, but not
properly advertised. Our new stuff and priorities are not properly
communicated. We used to have a list of release goals which served,
somehow, that purpose but the Release Team decided, rightfully, that
it is not their job to set technical goals for the project. Now, we
have to resume that effort and publish a roadmap that will be useful
to our users and upstreams. Contrary to our historical Release Goals,
a roadmap doesn't have to be bound to a release, but should give some
idea about when each item will be implemented and where the project is
going. People may even find it interesting and decide to contribute to
Debian. But in any case, i believe this will greatly help our
ecosystem (users, upstreams, downstreams, other fellow f/oss actors,
etc…) to better understand our vision and priorities.
Software projects are releasing often nowadays. This make it difficult
for us to integrate a useful version and maintain it through stable's
lifetime. Our release strategy allows us to release highly stable
versions. Our tools make it possible to customize almost every aspect
of Debian. This strategy fits perfectly for the base system and a
perfect solution for anyone building a derivative. Other uses are left
behind because there is no match. We started making compromises once
we noticed that security support is not achievable for some important
packages (web browser, database server, ...). So our release policy is
evolving but rules are not clear yet. I think that something can be
done in that area.
Project members expressed the urge to have some equivalent to
PPAs. While I sympathize with the idea, I wonder sometimes what would
be the goal. Developers personal archives turning into a way to
release to users might be one of our new nightmares. What we do best
is to integrate various projects together and ship a coherent tested
whole. If we start releasing separately, the concept of "distribution"
will vanish. In my opinion, we are looking for ways to release
faster. A PPA is one solution. I don't think it is the best solution
for that problem. A better idea, IMHO, is to think about a new release
strategy. Packages in a Debian stable release should not all evolve at
the same speed. We are already making exceptions for some. We should
work on a set or rules that would make it possible to update
