RE: Motivation to work on Blends
Thanks for having this discussion. I am learning a lot!
It is my understanding that it is technically possible for debian-edu to use boxer, but that that would involve considering the definition of a Debian Pure Blend as a product that uses only package lists and debconf.
@Andreas, could you assess whether it would be possible to build debian-med with boxer? I am asking because (AFAIK) you haven't had a bug#311188 report.
From: Andreas Tille [firstname.lastname@example.org]
Sent: Tuesday 28 October 2014 10:45
To: Debian Pure Blends List
Subject: Motivation to work on Blends
two recent threads on this list made me wonder whether my motivation
to work on Blends was well described.
The current framework basically exists since I tried to assemble tools
developed in different user oriented groups which in the beginning did
not really felt like Blends. They were basically doing some packaging
work targeting at certain user groups. I realised that there are good
chances for creating some synergy effects since after abstracting from
the concrete topic of the target user group some technical stuff can be
shared. Over the years we finally found the name "Blends" for those
user oriented groups.
It seemed quite natural to me to make good solutions used in one team
available for all those teams. And so I dived into the teams,
subscribed their list and started to learn about their toolsets
(basically to profit for my own work in Debian Med).
For example the package blends-dev which helps creating metapackages was
originally part of debian-edu package. I did nothing else but replacing
the string 'debian-edu' by $Blend (and some polishing). This became the
first common part of the Blends framework. It can be used perfectly
without any other part and does what the original debian-edu code did
only for Debian Edu for every other Blend. I also try to fix bugs filed
against specific Blends (for instance #720199) in a generic way for all
Once this framework existed I was thinking about how we could enhance
the Blends documentation since I realised that Wiki pages with packages
in our focus simply do not scale. David Paleino from Debian Med wrote a
first PHP based toolset for Debian Med. Later I enhanced this to the
current tasks pages which are based on the data currently available in
VCS of each Blend. So the specific tool for Debian Med became available
for all Blends. I was trying to make it as flexible and up to date
(=reading data from VCS) as possible. (BTW, I'm not proud upon the code
itself which is quite hackish and needs a rewrite for several reasons.)
I kept on diving into teams which said: Well, tasks pages are fine but
we want a simple long list. And so I created a long list (example ).
The Debian GIS team considered their "thermometer" as an important tool
and it was cheap to also create this thermometer to on one hand base
the code on the current Debian GIS data in VCS (to reduce their
maintenance work) as well as enabling this tool for other Blends (who
are free to use or ignore this).
In a GSoC project I worked on some team analysis tool to find out who is
really working on a Blend and there exist monthly recreated graphs which
I added to the entry pages of each Blend because I considered it
relevant. I have copied this information to each mailing list and asked
the individual Blend teams to enhance their own entry page since they
only show what I personally to my poor understanding consider relevant
but it does not reflect the interests of each Blend. While I realsised
that nobody changed anything on these pages I'm not sure what option
might be true:
a) I did everything perfectly OK for each Blend (I have severe doubt
that this might be true)
b) Blends team members have no time / interest on these pages
c) Blends team members are afraid of / don't know how to change
their own entry page.
I'm afraid it is a mix of b) and c) and I would like to kindly invite
everybody who is interested to take part here.
This is in the sense of my whole work: Provide *options* available for
*everybody* to pick from for the individual needs. I was told that I'm
frustrated and may be the tenor of this mail sounds like this again (I
did this and that, but ...). I do not think that I'm frustrated since
the tools are more or less working in the way I need them and I
personally use them for a general overview. So as in Free Software
you design something which works for you and you are happy if it works
for others as well. Luckily this is the case and I'm *really* happy
that the framework was successfully adopted by Debian GIS and Debian
Games. For me this is a proof that I'm not totally on the wrong track.
What I do not like is if people blame the tools to be not fit for their
work only because they fail to maintain their data (#726492). Yes, the
tools enable some QA means and you are free to use these or not. But it
is not the fault of the toolset to uncover existing problems. If there
are real bugs (for instance #766289) I surely try to deal with them ...
as usual depending from spare time. The issue was discussed here on
this list (even before the bug was filed) and up to now there was no
proper solution - that's life in Free Software development and everybody
reading this list should know that patches are always welcome.
The recent postings of Jonas about boxer made me wonder whether people
consider all this Blends stuff as some kind of "Andreas' coding
playground". I'd be afraid if this would be the outcome of the things I
wrote about above. The fact that I wrote a large amount of (bad!) code
should not lead to the conclusion that I intend to give directions or
like to exclude others. To the contrary I'm doing all this work to
enforce people to bring in their own visions (since my might be wrong or
suboptimal) for the profit of my main target Debian Med. Observing that
people (specifically those who were always very supportive for Blends)
start creating things somewhere out of our spot makes me wonder whether
I failed to be invinting enough and open enough in this project.
I'm simply astonished if people starting to code something else since
they prefer Perl over Python who obviosly never had a look into the
existing codebase (where the relevant code is actually in Perl) and also
do not mind to take influence when meeting crossroads like for instance
when specifying GSoC projects. This is so far away from my idea of Free
Software where you have pretty good chances to cherry pick from others
that I have problems to express my astonishment properly.
Assuming that you are only allowed to maintain a page below
http://blends.debian.org/ if you are using the toolset makes me wonder
again whether I might be percived as a dictator pushing his ideas onto
others. Or at least the documentation I wrote is so terribly bad / my
mails to single Blends teams so hard to understand that people have just
no idea what to do. The latter would be the positive explanation.
I have no idea what makes Debian Parl and Debian Design so different
that other Blends could not profit from adapting anything from new ideas
developed there nor do I understand why the development should profit
from staying outside of the Blends team. But lack of understanding is
probably my own problem. I just want to make sure that others do
understand my motivation to be as open as possible to new ideas to
profit from synergy effects.
As a conclusion I can say I'm happily working on Blends which was
basically looking around what others are doing, generalising things also
for the final profit of Debian Med. I hope that others will enjoy the
strategy of friendly cooperation and bring in their ideas here.
To UNSUBSCRIBE, email to debian-blends-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
Archive: [🔎] 20141028094537.GK31757@an3as.eu">https://lists.debian.org/[🔎] 20141028094537.GK31757@an3as.eu