[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Standardization, large scale changes, innovations

On Tue, Apr 6, 2010 at 18:46, Manoj Srivastava <srivasta@debian.org> wrote:
>> Personally, I'd draw the line more at considering Manoj as someone who
>> tends to his packages, and thus is someone worth talking to about
>> them, but who doesn't have any authority over them beyond how well he
>> can persuade other developers that his preferred course of action is
>> the right one.
>        But is this the model we have been following?

Fundamentally, yes. For instance:

> (It might be
>  entertaining to see a random developer going out and uploading, say,
>  gnome, all converted to using yada and dbs).

There are obvious consequences to doing this:
 - the current Gnome maintainers reupload the old packaging with a
bumped version number, making the random developer's upload pointless
 - the random developer gets flamed on lists
 - the upload gets blocked before being included in the archive (eg [0])
 - the random developer gets demoted to Debian Maintainer status (eg [1])

Those all tend to be persuasive reasons why some particular person
wouldn't do that, and more generally I believe most Debian people find
it pretty persuasive that having someone (or some people) who'll take
responsibility for making decisions around particular areas (such as
Gnome) is the most effective way we've got to get things done.

[0] http://lists.debian.org/debian-x/2004/01/msg00759.html
[1] http://lists.debian.org/debian-devel/2003/08/msg01625.html

But yes, if someone's /not/ persuaded by those reasons, and nobody's
persuaded to stop that someone, then NMUs, uploads changing Maintainer
fields, and forks are entirely possible.

>        So it boils down to social norms,

Social norms are, in my opinion, another way of saying "this is what
most people already believe, without needing any further persuasion"
-- the social norm that "whatever the maintainer says goes" fits that
well, eg.

Not all social norms are good though; I'm sure debian-women folks
could come up with some examples easily enough, for instance.

>  etiquette, if you will, also
>  codified in the NMU rules, tht says people listed in the maintainer or
>  uploader fields are indee dgiven some authority over packages they work
>  on, but that authority falls short of "ownership". This happens
>  orthogonal to how persuasive the maintainer is about their course of
>  action; and usually it takes concerted effort (TC, GR,  flammage) to
>  override the maintainer decisions.

On the contrary, I'd say most people have already been persuaded to
trust the maintainer. But when someone comes up with a good reason not
to, it's very important for the maintainer to be able to persuasively
argue their case -- whether that be on -devel, -ctte, -vote, blogs, or
elsewhere. Saying "it's my package, my rules" doesn't cut it.

That doesn't mean being a professional debater, or even being
particularly good at English -- technical analysis, humility, and just
a willingness to discuss things can be important elements of being

Of course, it does depend on your audience. A rhetorical flourish,
some good insults, sheer repetition, or making it appear that no one
disagrees with you because they're not allowed to participate on the
list/channel/forum or because they've just given up arguing can be
more persuasive than some statistics from some newbie, eg.

(Another example of "not being convinced to trust the maintainer" is
in Ubuntu in the sense that they often avoid giving packages
maintainers so there's no person to trust or not. Maybe that's a
better way of doing things, or maybe it's not, and maybe it's better
sometimes and worse at others. I think it's a shame if Debian's not
open to being persuaded to change that policy if it results in better
software; and I think it'd likewise be a shame if Ubuntu weren't)

>> Of course, in my world, the same would be true of other people trying
>> to convince Manoj that the best way to maintain his packages is with
>> debhelper or similar. Sometimes I think the art of persuasion (or
>> perhaps the art of be persuadable) is sadly underutilised.
>        Based on one reading of what you wrote here, the  take away I
>  have is that no one has any authority apart from their ability to
>  persuade people (persuade how many of the? All? Super majority? rough
>  consensus?)

People have legal authority over the things they own -- no persuasion
required. That's what ownership means.

But the fact is, most of the stuff people do within Debian isn't on
stuff they own -- authority is delegated, servers are loaned,
bandwidth is too, mirrors are other people's systems entirely, all the
contributions to Debian whether infrastructure development and
maintenance, package maintenance or upstream development is done by
people volunteering their time and effort to Debian, funds for
meetings are donated by people feeling charitable, and all of them can
choose to stop at any moment, the instant they're persuaded that
there's something better to do instead.

For instance, nobody can stop you continuing to package make however
you like for as long as you like, but if people are persuaded that
someone else could do a better job, you might find that users start
using a different package, mirrors and vendors might start focussing
on a different distro with different packaging of make (as might users
or your upstream), you might get flamed on lists for how you maintain
make, policy or lintian might be edited to make what you do be against
the "rules", the tech-ctte might tell you to stop doing that, the
archive might stop accepting your uploads of make, the DAM might boot
you out of the project, or something else might happen.

There are lots of different people and groups who you might or might
not be able to convince of the superiority of your way of doing things
at any point in time, lots of different degrees to which they might
need to be persuaded, and lots of different consequences of succeeding
or failing in each case. And, of course there are lots of default
beliefs people already have -- social norms -- that you don't actually
have to spend any effort convincing people of.

But -- and again, this is just my opinion, which you might or might
not be persuaded to share -- it would kind of suck if people decided
your way was wrong because either you didn't make an effort to explain
the benefits you saw, or because they were so stuck in their ways as
to refuse to consider the gains from other ways of doing things.

(Compare that to how someone might behave if they have a list of
"rules" -- there's no point spending time justifying them (they're the
rules, after all!) and anyway you can just point people at the list
archives of when they were adopted whether it deals with their
objection or not; and conversely there's no point spending time
listening to other crazy people and their weird ideas because this is
already the way things are done, and there's more important things to
worry about)

>  I don't think that is how we have behaved, though, as a project.

Like I said, I do think the art of persuasion is underutilised in
Debian, but I also think that Debian, as a volunteer organisation
supported by generous donations at every level, is (and can only be)
based on persuasion, because ultimately there isn't any other reason
or way for anything to happen.

I'm not sure whether you'd count that as saying it is how we've
behaved as a project (because it must be), or isn't (because it's
generally not at the forefront of people's minds).


Anthony Towns <aj@erisian.com.au>

Reply to: