Discussion:
Questions for Mehdi: roadmap?
(too old to reply)
Steve McIntyre
2017-03-18 22:02:54 UTC
Permalink
Hi Mehdi,

First of all, thanks for standing again!

Do you have any specific things that you'd like to see on a Debian
roadmap yourself?

Assuming that roadmap ideas are forthcoming, how do we ensure that
teams responsible for the various areas have the will and effort to
follow through?
--
Steve McIntyre, Cambridge, UK. ***@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Mehdi Dogguy
2017-03-23 09:10:56 UTC
Permalink
Hi Steve,
Post by Steve McIntyre
Hi Mehdi,
First of all, thanks for standing again!
Do you have any specific things that you'd like to see on a Debian
roadmap yourself?
I have some specific ideas. I didn't want to share them (although
already mentioned elsewhere by other DDs) but I understand the need
to read some examples to better understand the spirit of the roadmap.

- deprecate source format 1.0 (though this one will require a project-wide
discussion and a concensus).
- debci as a testing migration blocker
- “Essential:yes” and “Required” packages are reproducible
or even better "Every stable release is 100% reproducible" (and becomes
a release criteria).
- All packages with daemons provide a unit file for SystemD
- Move from menu system to .desktop files
- Secure Boot

Depending on our investment for each goal, we may be able to implement them
in time for Buster.
Post by Steve McIntyre
Assuming that roadmap ideas are forthcoming, how do we ensure that
teams responsible for the various areas have the will and effort to
follow through?
We are not going to fix manpower, motivation and commitment issues with
the roadmap. But, I believe that it is fairly reasonable to expect:

- More people paying attention to important changes going on in the project
and important goals set by contributors. This means that we could potentially
have more contributors for each goal. More people working on a goal also
increases motivation.

- Promoting our work and encouraging participation in conferences around those
goals is rewarding.

- Communicating about our roadmap and its progress is putting more light on
all those little projects that make Debian better after each release.

- Encouraging at least one sprint per year for each goal increases
productivity. You may argue that we already do that today w/o a roadmap and
I would agree. But it is really much easier to approach contributors when
you know on which specific "change" they are working on. The sole type of
event we organize where we encourage collective work is Bug Squashing Party.
We can imagine collective sprints on a roadmap goal. A taskforce that has
in mind a shared goal for two days.

I tend to believe that a mix of those 4 points will have a positive effect
on people's motivation and commitment.

We also tend to focus on packaging tasks too much (in my opinion). One goal
behind the roadmap is to show that packaging is only a tool that helps us to
reacher a higher goal of making the best operating system and enriching the
FOSS ecosystem (thanks to our incremental contributions to every packaged
projects). It opens new ways to contribute in Debian.
--
Mehdi
Loading...