Re: An Analysis of the RFS Process
+++ Paul Wise [2013-09-20 09:44 +0200]:
> On Thu, Sep 19, 2013 at 2:37 AM, Dave Steele wrote:
>
> > I was curious about the current efficacy of the BTS-based RFS process,
> > and so created some charts[1] to provide visibility.
>
> Interesting stuff,
Indeed - thank you for doing this analysis and bringing the issue to
the list.
> some thoughts...
>
> Your conclusions are similar to what we know already anecdotally. The
> problem is and always has been how to get existing members of Debian
> to be interested in sponsoring and mentoring instead of doing their
> own work. At DebConf13 the DPL mentioned what tends to work right now
> and there were a couple of other mentoring related events,
I will just add my own experience as a fairly typical DD view, I
suspect.
As a result of one of those talks saying 'mentors needs help, please
sign up', I signed up, having sponsored people in the past for various
things, and believing that it is useful work.
I've now seen just how many packages are going past, but I have not
volunteered to actually upload any as nearly all of them are not in my
area of interest/expertise or if they are, are in a language I don't
know. I feel that if I volunteer to sponsor something, that I need to
give it some review and will be at least somewhat responsible for it
in the future. This is a non-trivial hurdle, and I already have more
than enough debian stuff I'm not getting done (my own packages,
cross-toolchain stuff, the arm64 port) so I am only going to jump in
for things that I recognise/have some interest in.
I expect most other devs are in a similar boat. I'd like to help,
because I don't want to see all this packagaing enthusiasm going to
waste (I know how much work packaging can be), but am very short of
time and resist aquiring new responsibilities. And for all I know,
some of this stuff may be complete crap best kept out of the archive -
I have no way of knowing.
So, there are packages going by which look interesting (to me)
(OSM-related stuff for example) and loads of stuff I've never heard of
from people I've never heard of. I have absolutely no idea of the
relative importance of these things, and maybe that shouldn't matter -
it's just software, but we do resist pointless bloat to some degree at
least.
Graphs like these are useful because it shows whether things are even
getting review (which must be the first stage). Being able to see that
there is a pile of stuff no-one even reviewed is a first step. Some
way of measuring interest/importance and review would help. A BTS
response could be a detailed review or a minor comment or a 'yes
please', so simply counting those is not realy sufficient, although
it's better than nothing.
So, no real answers there, but I would appreciate some feedback on
just how much responsibility sponsors are expected to take. I assume
it's the same as a package you upload yourself in terms of
quality/security-review, but hopefully you can pass all the actual
prep/work onto the packager. Right?
If people have caving, terrain-modelling, mapping, GIS, CAD, embedded,
build-system, or cross-build related stuff, then I am much more likely
to get off my arse and sponsor. Should DD's hobbies/interests be such
an important factor in what gets sponsored? If not what other metrics
can we use?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: