I just wanted to followup on one issue. I'll start with Raphael's answer
'cause it seemed strangest:
On Thu, Mar 07, 2002 at 11:55:45AM +0100, Raphael Hertzog wrote:
> > What do you consider the DPL's field?
> > - technical leadership?
> Not really, we are quite good a taking technical decisions (the leader
> can participate of course but he's not more influencial than any other
> developer). And we already have the technical committee to resolve
> the controversial issues.
I think it seems pretty strange to say that "the Debian Project _Leader_"
isn't any more influential than others when it comes to leadership on
technical issues. (It seems especially strange coming from someone whose
platform consists of a whole raft of new, technical, goals for Debian
to work on over the next twelve months and beyond, but hey)
I was a little surprised to notice the other day [0] that even way back
in the day, the constitution took something like this into account, saying:
] 5. Project Leader
] 5.1. Powers
] The Project Leader may:
] 9. Lead discussions amongst Developers.
] The Project Leader should attempt to participate in discussions
] amongst the Developers in a helpful way which seeks to bring the
] discussion to bear on the key issues at hand. The Project Leader
] should not use the Leadership position to promote their own
] personal views.
[0] "when I was skimming the constitution, as you do"...
On Sat, Mar 09, 2002 at 03:57:15AM -0700, Bdale Garbee wrote:
> > As DPL, how will you ensure the technical goals in your platform are
> > achieved?
> Leverage.
(Surely I'm not the only one that immediately thought of blackmail when
Bdale wrote that?)
> It's clear to me that serving as DPL, and taking on the additional tasks
> that go with the territory, will leave me less personal technical time than
> I have today. I have learned in my professional life that I can derive as
> much satisfaction from the accomplishments of others that I am helping lead
> as I can from personal technical achievement, so I feel well equipped to
> cope with that same transition in my Debian activities if I am elected.
>
> The key to getting my goals accomplished will be doing a good enough job
> explaining my ideas and showing how they align with our long-term vision,
> that others are motivated to go out and do the work required to make them
> happen.
I'm sure I'm not disagreeing with Bdale when I say this, but the other
half of this is getting people to... properly focus their ideas, might
be one way of putting it. A lot of... energy, or time, or, at the very
least bandwidth seems to be being spent by people working out how to
solve their problems, which is great, but it never actually gets anywhere
because they completely forget about everyone else who has an interest
in the matter.
There's a lot to be said, in my opinion, for having someone get in amongst
the people with the clever ideas and to bang their heads against all the
issues they're conveniently ignoring until they actually manage to come
up with something practical.
To take a fairly trivial example from -devel right now: people have been
going on and on about wanting to make Packages files easier to download
for ages now, and the threads take the exact same path each time:
"let's split them", "oh wait, that doesn't work properly", "let's make
them incremental", "well, why not use rsync", "no, let's rearrange the
archive" and we end up without any consensus, nor anything that works
with existing tools, nor an actual fix for the problem.
IMO, having someone with some credibility actually help the people who're
interested in these sorts of things work out a credible solution would be
helpful. To stick with the Bdale-centrism of this section, perhaps the
solution to the above problem isn't to change the Packages file at all,
or the way *apt* downloads stuff, but to encourage modem users to run a
specialised local proxy similar to that suggested in Bdale's platform,
and have some separate mirror network that includes a few days of diff's
that they can use to recreate a full Packages file. But it's hard to
know what sort of things you need to be thinking about when you're just
not aware of all the things you need to take into consideration, and,
with the size and popularity and scope of Debian these days, it's _hard_
to know all those things.
On Sat, Mar 23, 2002 at 02:08:44PM -0500, Branden Robinson wrote:
> > Should Debian (or SPI) be involved in distributing data (as opposed to
> > programs) that can be distributed, and might be useful for Debian users,
> > eg the RFCs, the Bible, books from Project Gutenburg, desktop theme
> > packages, or game data files?
> I believe we should, as long as that data is licensed in a way that is
> consistent with the DFSG. We approved the creation of a "data" section
> long ago for this purpose. However, that fact that it continues to be
> unavailable suggests to me that some people may be uncomfortable with
> that decision.
This'll serve as another example, I think. There's a whole raft of
unanswered questions with `a data section' (the bug is #38902, for
reference). Some are: does it make sense to use normal Debian packages
for data? Does all the Depends: and Conflicts: stuff really make sense,
or the preinst and postrm stuff? Is there such a thing as arcitecture
specific data? Is there even any point separating the source from the
packages, or should we just distribute the source and auto-generate
whatever formats are needed? If we get rid of all that, and use some other
packaging format, will that make it possible for users to install these
packages rather than just admins, and is that useful? If it's packaged
differently, will that make it installable on other Linux distributions,
or on non-Linux Unices, or even on Windows? What sort of licenses should
we accept? Is the DFSG the appropriate thing to use, or should we look
at the usual licenses used for data (which often have "non-modifiability"
as a key feature), and apply a different standard? What should we accept,
exactly? Just stuff that adds on to our distro, like game levels? How
about pretty pictures of naked girls that make good backgrounds? How about
guitar riffs someone thought was cool and wanted to upload? Or how about
100s of MBs of geological data in various levels of detail? How does this
work with or against things like themes.org or Prject Gutenburg? Do we
consider them co-projects, or upstream? If we start getting everything
on them, and who knows how much else, can our servers handle it? Can our
mirror network handle it? Should our mirror network handle it, or should
data be mirrored independently from the Debian operating system? Should
Debian even be doing it?
None of these questions have really been resolved particularly
well. Alternatives haven't been thought out, we've just said "oh, yeah,
as far as we're concerned, we can just add a new section like `contrib',
and stick it there". Given some of the different responses by the DPL
candidates to the above question, it seems pretty obvious that we don't
actually have any real consensus, even on the fundamentals.
It's not clear how we're going to resolve such things, or even if we are.
Debian's pretty proficient at letting difficult, unimportant things
just slide into irrelevancy, and that's probably a good thing. It's not
a good thing to get highly intelligent and motivated people donating
their time for free, then wasting it on things that don't actually turn
out to matter. Quicker "apt-get update"s and having somewhere to upload
data might be those sorts of things.
On the other hand, maybe it'd be helpful to have whoever's elected as
DPL (not to mention the RM, or people from QA, or policy writers, or
random developers) take a more active roll in actually resolving all the
difficult and unstated issues as well as the obvious and straightforward
ones.
To give another example: at the start of 2001, crypto-in-main was pretty
much at the same point as "the data section" still is: some people had
"decided" to their satisfaction that was all ready to go, but some fairly
serious issues (whether it's actually legal for Debian to do, how the
notifications were to be handled) hadn't been remotely addressed. Until
they had been addressed, it didn't go anywhere. (81852 is the bug number
this time) This might serve as a particularly good example, in that
it was our glorious DPL who stepped in and got us rolling on actually
getting legal advice that wasn't accompanied by an "IANAL".
(Or maybe this is all nonsense. Maybe this is how the fashion of DPLs
works. We want interventionist DPLs one year, then we get one and get sick
of them intervening and want them to shut up for a while, then we forget
and start over. Something seems weirdly different about all this compared
to how elections have gone in the past, anyway. Who knows? Not me)
There aren't any real questions for the candidates here, just comments,
so certain people who're overly busy needn't feel compelled to reply. ;)
Cheers,
aj, wondering if he managed to finish this before the CFV's has gone out,
and thus can at least argue to still be within the `campaigning'
period
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Debian: giving you the power to shoot yourself in each
toe individually.'' -- with kudos to Greg Lehey
Attachment:
pgpsm5F_3eT5X.pgp
Description: PGP signature