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 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