Re: Broader vision
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 leader@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.GA24202@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 more
packages, and not restrict changes to only fixes for security or
critical bugs. Other distributions are facing the same problem and are
working on some ideas (like Fedora's concepts of rings and modules
[2]). Yet, the challenge is still to provide a stable and coherent set
of packages. So allowing anyone to update anything is not the way to
go (and it already exists (modulo some rules), it is called
stable-backports). But we should acknowledge that many softs are
obsolete in Stable and work on a solution to make them less so.
Another way could be to take advantage of containerization
technologies. So another solution to the above problem could be to
write a new tool or promote an existing one that solves the problem
(of getting a newer version of a package) easily for users.
As Stefano has outlined in his talk back in DebConf14 [1], computing
moved from desktops to the cloud. This is not only about where things
are stored and used, it is also about services for users. I believe
that providing free services (?) is something that can be achieved
with free distributions. So we have to tackle the problem and work on
a solution. This is another argument to enhance our release strategy:
If we are unable to provide a stable yet usable set of packages to our
users, then we somehow failed and we should fix that!
This is not specific to web services, but also valid for various
programming languages. We've seen many specialized package managers
appearing for different programming languages. Developers are only
interested in delivering their product the quickest way possible.
As described in lucas talk [3], integrating some software using our
tools is not an easy task. Doing packaging tasks in Debian has never
been easier than today, but it is still not enough (nothing as easier
as npm, opam, etc…).
Fundamentally, I think the problems described in this mails have some
common roots, such as:
- complexity of packaging tasks, for someone not familiar with our
tools
- time spent from the ITP to apt-get'able packages
- lack of promotional material about our philosophy and strengths of
our solutions and tools.
Once a product is finalized, time to market is crucial. Packaging it
and integrating it into a distribution should not take more time than
it took to write the product itself. Of course, this greatly depend on
the complexity of the stack being packaged… But all in all, we also
have some some processes that could sped up.
Last but not least, users' needs changed and developers' methods
evolved. People push some line of codes to github, and call it
"open-sourced". Other write a file for npm, and call it
"packaged". Once a release is made, users want it to be
installable. This obviously doesn't work since many details are
missing to call something F/OSS and having working packages for
them. So our educational role in the FOSS ecosystem will remain
important and we will remain relevant there.
It is reasonable to expect a first version for the roadmap and new
promotional materials by the end of this year. This could also include
a new way to help users find their way our into our big project.
The other issues require more time since they may require some
development and a review of our processes to better understand where
things stall and for which reasons. Being understaffed cannot be the
answer for all difficulties.
[0] https://lists.debian.org/debian-vote/2015/03/msg00094.html
[1]
http://debconf14-video.debian.net/video/240/debian-in-the-dark-ages-of-free-software
[2] http://lwn.net/Articles/680278/
[3] http://blop.info/pub/20150131-fosdem-distros-boring.pdf
Regards,
--
Mehdi
Reply to: