About the internal and external view of Blends (Was: Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu)
Hi,
On Sun, Feb 05, 2017 at 12:38:59AM +0100, Tollef Fog Heen wrote:
> > Would it be a sensible compromise to reassign this bug to d-i tagging it
> > RC for buster to make sure a Blends menu will exist in the buster
> > installer.
>
> While I think it's important to get it fixed for buster, I don't think
> it's RC. If the d-i folks and/or the release team disagrees, I'm happy
> for them to decide otherwise, though.
May be this is the right time to clarify the role of Blends inside
Debian and I'd like to adjust my probably biased opinion. Do you
consider Blends as
A) Assemblage of low popcon packages of very specific fields
B) Strategy to establish Debian in different workfields that
could cover a wide range of applications
As I said the outer view from users of Debian it is hard to distinguish
between a derivative and a Blend. From my experiences from DebConfs
talks (which I'm holding since 2003) are not attracting many people
which makes me consider that A is a widely spread inner view inside the
Debian developers. Sometimes when it comes to what I consider pure side
effects of the Blends effort like how to attract new developers for your
team[1] people consider the concept quite interesting. Quoting Asheesh
Laroia from my talk at DebCOnf13[1]: "Is there a topic you care about,
create a Blend today." ([1] 38:45) - my answer was "This is what I'm
doing so since 2003."
In a discussion with Bdale on a conference in Malaga he even expressed
the idea that it might be feasible to distribute Debian as a set of
Blends (at this time Blends were named differently) and later Bdale
confirmed that he even forgot this idea - may its just me that I just do
not give up on a topic that has catched my interest.
My impression is that the view of the majority of the Debian developers
is basically A which is possibly shared by Tollef when he considers the
importance of the bug not RC.
I think my talk[1] gives good reasons for view B if only people would
try to become more informed about the concept. My talk[1] - even not
explicitly having Blends in the title (may be thus attracting a far
wider audience - it was even ranked higher and thus made it in the main
talk room at DebConf13 because not mentioning Blends ;-) ) contains a
lot of good reasons for the view B and finally has lead inside the
discussion part to questions of how Blends should be installed.
To not extend this mail to much I just want to address two points. In
the video[1] starting at minute 3 I'm presenting numbers how many Debian
developers confirmed that they are DDs only for the reason that the
Debian Med project exists. In my summary for the Debian Med sprint I
have updated numbers[2] that the trend continues and the Debian Med
project attracted 1 developer per year and several of them are doing
other things than only Debian Med work now. This means a small topic
like medicine and live science which makes a small fraction of Debian
usage and is honestly speaking in the end irrelevant for the overall
importance of Debian in general was able to gather more than 1% of
the active Debian developers.
The other measure is addressing the low popcon packages. Yes, Debian
Med is mostly about low popcon packages (8 packages > 100 votes) but
when doing last years GSoC I was observing votes more closely to pick
the most used packages for adding autopkgtests. I noticed that the
number of popcon votes (= really used packages) and I noticed that we
had an increase from 163 packages with >10 votes to 254 packages with
>10 votes in only 3 monthes. I think this speed of adoption of those
low popcon packages is a consequence that users realise that Debian
cares about the packages they are using.
Despite this effect I know from several personal contacts from this
field, that people stick to Ubuntu with the argument: "Ubuntu is easier
to use." A very speaking example is: I packaged a software at request
of one of these users for Debian, fighted throug its dependencies and
uploaded the package to backports. The user who requested the package
keeps on using Ubuntu (since "its easier") but was not able to install
the package in question on Ubuntu (despite I explained how to backport
to Ubuntu). We could do a pretty good service to this type of user to
make Debian "easy to install". This installation topic comes up in
every talk I have given (see [1] at 35:20) and since 14 years I can not
give a satisfying answer to the audience.
I could give a lot of other examples and reasons why I think the active
support of Blends inside the Debian infrastructure could have a positive
effekt onto the acceptance of Debian inside these workfields *and*
beyond. Blends have the power to bump the maintainer-package relation
to a team-topic relation and - provided if done right (we also have
somehow orphaned Blends like Debian Junior) - can enhance the quality of
packages covering a whole topic (see for instance Debian Med advent
calendar[3] to squash bugs and many others).
In short: If you voted for A above please dive a bit into the topic to
consider B as an option. When voting B I think it becomes evident that
the bug is RC (at least for Buster).
Kind regards
Andreas.
[1] https://www.irill.org/videos/debconf13/How_to_attract_new_developers_for_your_team.html
alternative video location
http://gensho.acc.umu.se/pub/debian-meetings/2013/debconf13/high/987_How_to_attract_new_developers_for_your_team.ogv
[2] https://people.debian.org/~tille/talks/20170113_debian-med-sprint/sprints+mentoring.pdf#15
[3] http://debian-med.alteholz.de/advent-2016/
--
http://fam-tille.de
Reply to: