Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Jonathan Carter]

Hi Benda

On 2021/04/19 05:30, Benda Xu wrote:
> I would like to congratulate you for becoming our next DPL.

Thanks!

>> However, I don't think we're quite in a position to pat ourselves on
>> the back here. This vote has once again highlighted some problems in
>> our methods for making decisions. I think that we should set up a
>> working group to specifically deal with voting, polling and
>> project-wide decision making so that we can deal more efficiently with
>> problems in the future.
>>
>> While this vote caught a lot of heat, essentially it's quite a trivial
>> vote. Ultimately it had become a question of if and how we should
>> respond to an external situation. I think that as Debian grows, as the
>> free software eco-system grows, and as software gets ever more ingrained
>> in our every day life, the questions and problems we're going to face
>> will become increasingly complex and that we should adapt to be able to
>> deal with those as a project.
>>
>> Can we go ahead and set up such a working group? I'm thinking that it
>> would involve mailing list discussions, video calls, sessions at
>> DebConf, probably at least one GR, research on different voting methods
>> that could be used, voting software, etc. Fortunately, we're not the
>> only organisation in the world facing issues like these and we can make
>> use of some external experts too. Although all of this will also take
>> some time and effort so I'd really like to have you on board as one of
>> the drivers of this project and also others who have a keen interest in
>> this. What do you think?
> 
> The winning option "Debian will not issue a public statement on this
> issue" implies that the majority of DDs is not interested in such
> non-technical affairs.  Such a working group will distract us from
> achieving technical excellence.

That's more than just a big assumption, I'd go as far to say that it's a
big leap to assume that from that option. Additionally, you're assuming
that that attempts to fix the problems in our voting system would
somehow make us more political? How do you come to that conclusion?
We've had very large technical GRs which have shown significant problems
in that process causing huge amounts of pain and frustration in our
community, and it comes up regularly how useful it would be to take a
formal project-wide poll on something. At the same time, there's often
confusion about what exact vote rankings actually mean. To the point
where a significant people either don't vote at all exactly because of
that, or their vote actually has a significantly different effect than
what they intended.

Why would anyone in their right mind be apposed to fixing these problems!?

-Jonathan

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Bernd Zeimetz]

On 2021-04-19 08:57, Jonathan Carter wrote:



That's more than just a big assumption, I'd go as far to say that it's 
a

big leap to assume that from that option. Additionally, you're assuming
that that attempts to fix the problems in our voting system would
somehow make us more political? How do you come to that conclusion?
We've had very large technical GRs which have shown significant 
problems

in that process causing huge amounts of pain and frustration in our
community, and it comes up regularly how useful it would be to take a
formal project-wide poll on something.


So how does changing the voting system change the way we come up with
"something" to vote on? It doesn't matter which voting system you are
using if your problem is to decide what you want to vote on.



At the same time, there's often
confusion about what exact vote rankings actually mean. To the point
where a significant people either don't vote at all exactly because of
that,


How do you come to that conclusion? If I remember right we had
40-50% voter turnout, so you think that 30...40% fail to understand
rankings? And out of these none bothers to ask for explanations?
(I know that there were some questions regarding the meaning of FD,
but the amount of participating non-voters in that discussion is
way too low to support your statement).


or their vote actually has a significantly different effect than
what they intended.


Care to explain that?
A voting system works as designed and the Debian voting system is
actually one of the easier systems to understand. Ranking options
is not that hard. Maybe we should educate voters about the voting
system if necessary?


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Bernd Zeimetz]

On 2021-04-19 02:46, Brian Thompson wrote:

Is it really still an open question whether Debian is a political



project that has opinions on non-technical topics like the board of

the


FSF or the legal status of Taiwan, Palestine and Kosovo, or whether



Debian is a technical project where people of diverse backgrounds

and


political opinions can work together on making a good distribution?


I'm very new to the project, but for those who were unaware of this
discussion, it makes the project a lot less appealing to contribute to
upon hearing about it.  It doesn't make any sense for a "FOSS" project
to have any weight whatsoever on political on goings.  To put it
bluntly, political opinion shouting is repulsive, and very
disappointing at best.  I can probably safely say that many people who
are a part of this project already work for the elite IT companies who
push their garbage political agendas all day, every day.  The last
thing people want to do is contribute to a project in their free time
that does the same thing.



Exactly what I'm thinking.
And exactly the reason why I like the outcome of the GR.

Please lets get back to technical issues.

--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Jonathan Dowland]

On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote:
> The winning option "Debian will not issue a public statement on this
> issue" implies that the majority of DDs is not interested in such
> non-technical affairs.

The vote in fact shows the opposite.  That interpretation of the result
would be true if the majority of people voted for that as their first
preference. They did not: it was the most-agreed upon preference between
two ideologically opposite factions. The majority of voting DDs
expressed a strong preference one way or the other.


-- 
👱🏻  Jonathan Dowland
✎   j...@dow.land
🔗   https://jmtd.net

Proposed mass-bug filing: missing support for build-arch or build-indep

[Lucas Nussbaum]

Hi,

I would like to propose a mass bug filing on source packages that miss
support for build-arch or build-indep targets in debian/rules.

Those targets were made mandatory in Debian Policy 3.9.4 (released in
August 2012). From the changelog:
  * build-arch and build-indep are now mandatory targets in debian/rules,
implementing the Technical Committee ruling in #629385.  Wording
review by Jonathan Nieder, Jakub Wilk, and Roger Leigh.
(Closes: #374029)

There are currently 411 packages in testing that do not include those
targets, according to lintian's debian-rules-missing-recommended-target
tag.  (I will also file a bug against lintian to reflect that those
targets are now required).

I do not particularly care about those targets, but I believe that it is
a good idea to use this old policy change as a way to identify packages
whose packaging should be upgraded to newer practices.

Here is the template I plan to use:
-->8

Source: SOURCE
Version: VERSION
Severity: serious
Tags: bookworm sid
Usertags: build-arch-indep

Hi,

According to lintian, this package does not implement
build-arch/build-indep targets in debian/rules. Those are mandatory
since Debian Policy 3.9.4, released in 2012.

This mass bug filing was discussed on the debian-devel mailing list. See
URL

While fixing this bug, please also consider upgrading this package's
packaging to newer standards or best practices (such as using dh,
maintaining the package in git on salsa, using a newer source format,
etc.)
-->8

I attached a dd-list.

To limit the noise on the debian-bugs-rc list, I will wait until after
the bullseye release to file those bugs.

Any comments?

Lucas
A Mennucc1 
   libppd

Adam Majer 
   lpr
   sc

Adam Sloboda 
   gkrellm-thinkbat
   gkrellm-xkb

Adi Zaimi 
   gkrelltop

Adrian Bunk 
   gkrellmoon

Alan Baghumian 
   myspell-fa (U)
   myspell-hy

Alberto Capella Silva 
   squidtaild

Alberto Furia 
   wbox

Alex Pennace 
   dircproxy
   pentium-builder

Alexander Gordeev 
   madwimax

Alexander Wirt 
   libmail-verify-perl
   libmp3-info-perl
   mp3burn

Alexandre Ratchov 
   midish

alice ferrazzi (aliceinwire) 
   abr2gbr

Amaya Rodrigo Sastre 
   perforate

Andreas Barth 
   netpbm-free

Andrew McMillan 
   whereami

Angel Ramos 
   hunt

Anibal Monsalve Salazar 
   bootp
   elida
   xfsdump (U)

Antoine Jacquet 
   fapg

Anton Zinoviev 
   console-cyrillic
   fortunes-bg
   scalable-cyrfonts
   trscripts

Antonin Kral 
   minisapserver

Ari Pollak 
   gav
   gav-themes
   gltron
   jnettop

Arjan Oosting 
   hugs98 (U)

Armando Segnini 
   gpsim-doc

Asheesh Laroia 
   cue2toc

Atsuhito Kohda 
   jtex-base (U)

Atsushi KAMOSHIDA 
   libjcode-pm-perl

Aurelien Jarno 
   fortunes-fr

Aurélio A. Heckert 
   ink-generator

Barry deFreese 
   hawknl (U)
   pixbros (U)

Bartosz Fenski 
   libuninum

Bastian Blank 
   sysconfig (U)

Benjamin Mako Hill 
   libtext-wikiformat-perl
   libwww-mediawiki-client-perl

Benoit Mortier 
   vncsnapshot

Bill Allombert 
   menu
   menu-l10n
   menu-xdg
   pari-elldata
   pari-galdata
   pari-galpol
   pari-seadata
   popularity-contest (U)
   toppler

Bradley Smith 
   libview
   plib-doc

Brandon Barnes 
   xevil

Breno Leitao 
   cappuccino

Carlos Laviola 
   bplay

Chris Boyle 
   aewm++
   sapphire

Chris Butler 
   xinv3d

Chris Halls 
   myspell (U)
   python-ooolib (U)

Chris Hanson 
   libapache2-mod-lisp

Christian Bayle 
   gatos
   libibtk

Christoph Egger 
   cl-irc (U)

Christopher James Halse Rogers 
   gtk-nodoka-engine

Craig Small 
   lprng-doc

Cyril Lacoux (Yack) 
   digitools

Dale E. Martin 
   pccts

Dave Holland 
   floatbg

David Banks 
   sisc

David Nusinow 
   discover (U)

David Symons 
   plait

Debian CLI Applications Team 
   graphmonkey

Debian CLI Libraries Team 
   log4net

Debian Common Lisp Team 
   cl-irc
   cl-pg

Debian Games Team 
   geki3
   hawknl
   pixbros
   plib-doc (U)
   spacearyarya

Debian Install System Team 
   discover

Debian LibreOffice Maintainers 
   mythes

Debian LibreOffice Team 
   python-ooolib

Debian OCaml Maintainers 
   pagodacf

Debian OpenOffice Team 
   myspell

Debian QA Group 
   abicheck
   apsfilter
   cfingerd
   cldump
   convlit
   crip
   dbmix
   docbook-simple
   doschk
   efax
   esekeyd
   fbpager
   gaim-themes
   galib
   glbsp
   hashcash
   iog
   libapache-mod-encoding
   libapache2-mod-encoding
   mp3rename
   ncdt
   osdclock
   partimage-doc
   playmidi
   poppassd
   pppconfig
   quickml
   scribus-template
   sendfile
   sgml-base-doc
   snmptrapfmt
   sntop
   stfl
   stymulator
   swish++
   tegaki-zinnia-simplified-chinese
   tmexpand
   xfonts-bolkhov
   xgammon
   xstarfish

Debian S/390 Team 
   sysconfig

Debian VDR Team 
   libmdsp

Debian VoIP team 
   asterisk-prompt-fr-armelle
   asterisk-prompt-fr-proformatique

Debian X Strike Force 
   xfonts-100dpi
   xfonts-75dpi
   xfonts-base
   xfonts-cyrillic

D

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Julien Puydt]

Le lundi 19 avril 2021 à 14:05 +0100, Jonathan Dowland a écrit :
> On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote:
> > The winning option "Debian will not issue a public statement on
> > this
> > issue" implies that the majority of DDs is not interested in such
> > non-technical affairs.
> 
> The vote in fact shows the opposite.  That interpretation of the
> result
> would be true if the majority of people voted for that as their first
> preference. They did not: it was the most-agreed upon preference
> between
> two ideologically opposite factions. The majority of voting DDs
> expressed a strong preference one way or the other.

All sides agreed Debian was not the right place to fight on such a
matter.

Let's move on.

JP

Re: Proposed mass-bug filing: missing support for build-arch or build-indep

[Holger Levsen]

Hi Lucas,

On Mon, Apr 19, 2021 at 03:11:21PM +0200, Lucas Nussbaum wrote:
> Those targets were made mandatory in Debian Policy 3.9.4 (released in
> August 2012). From the changelog:
>   * build-arch and build-indep are now mandatory targets in debian/rules,
> implementing the Technical Committee ruling in #629385.  Wording
> review by Jonathan Nieder, Jakub Wilk, and Roger Leigh.
> (Closes: #374029)

thanks for following up on these long standing issues! I'm glad to see
we're getting closer in fixing these for all packages in stable ;)

> There are currently 411 packages in testing that do not include those
> targets, according to lintian's debian-rules-missing-recommended-target
> tag.
[...]
> Severity: serious

seems sensible for something being mandatory since nine years.

[...]
> To limit the noise on the debian-bugs-rc list, I will wait until after
> the bullseye release to file those bugs.

I think this is a good plan, thank you!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

There are many ways to kill. You can stab someone in the guts, take their bread
away,  not heal someone from disease,  put someone in a bad living space,  work
someone to death,  drive them to suicide, lead someone to war etc.  Only few of
these are prohibited in our state." (Bertolt Brecht)


signature.asc
Description: PGP signature

Re: Proposed mass-bug filing: missing support for build-arch or build-indep

[Mattia Rizzolo]

On Mon, Apr 19, 2021 at 03:11:21PM +0200, Lucas Nussbaum wrote:
> I would like to propose a mass bug filing on source packages that miss
> support for build-arch or build-indep targets in debian/rules.

+1

> There are currently 411 packages in testing that do not include those
> targets, according to lintian's debian-rules-missing-recommended-target
> tag.  (I will also file a bug against lintian to reflect that those
> targets are now required).

That's way more than I'd expected, but as you mentions it's a good
indicator of not-greatly-maintained packages, so I'm cool with them.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Theodore Ts'o]

On Mon, Apr 19, 2021 at 02:05:20PM +0100, Jonathan Dowland wrote:
> On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote:
> > The winning option "Debian will not issue a public statement on this
> > issue" implies that the majority of DDs is not interested in such
> > non-technical affairs.
> 
> The vote in fact shows the opposite.  That interpretation of the result
> would be true if the majority of people voted for that as their first
> preference. They did not: it was the most-agreed upon preference between
> two ideologically opposite factions. The majority of voting DDs
> expressed a strong preference one way or the other.

I agree with all of the above.  I also can't help feel that the result
was probably the best one that could have been reached for the project
as a whole.  In which case, the voting system arguably did its job.

The division was not caused by our decision making process; it was
caused by the fact that this was naturally a question for which there
was nothing like unaminity amongst the voting members.

It is unclear that any change in our voting procedures could have made
things any better.

Cheers,

   - Ted

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Simon Richter]

Hi,

On Sun, Apr 18, 2021 at 04:56:34PM +0300, Adrian Bunk wrote:

> Is it really still an open question whether Debian is a political
> project that has opinions on non-technical topics like the board of the
> FSF or the legal status of Taiwan, Palestine and Kosovo, or whether
> Debian is a technical project where people of diverse backgrounds and
> political opinions can work together on making a good distribution?

Debian is a political project that promotes the autonomy of users vis-a-vis
large organizations such as corporations and governments. It does this by
promoting the creation of free software, and by fostering a community
around free software.

We have never been apolitical, because our goals are political goals, and
they have far-reaching political consequences because free software enables
diverse groups to access information technology that would not have access
otherwise, ranging from disadvantaged groups for whom cost is the main
blocker in technology adoption to dissident groups who are reliant on
verifiability and disconnected operation.

In all of this, "our priorities are our users, and free software."

This means we have dual priorities and we need to be smart about
reconciling them. We've seen proposals to open the ecosystem to commercial
software as that would be in the interest of users, and we've seen a shift
towards more complex technology stacks that are all free software but less
accessible to modification due to the learning curve, thus disempowering
users.

Free software isn't created in a vacuum, but by people in the free software
community. While stewardship of the community is neither our sole
responsibility nor are we tasked with it alone, it is part of our core
mission, and we cannot abdicate it without failing to also promote future
free software (in addition to failing as members of the community).

Make no mistake, the quest to have "apolitical" free software is deeply
political in itself: the process that decides which group can establish
their identity politics as default and therefore mark any deviation
therefrom as "political posturing" is itself a political process.

The demand to lower societal standards for "socially awkward nerds" is a
demand to symbolize a political hegemony: the identity of the "socially
awkward nerd" is to be protected politically, at the expense of the other
members of the free software community, therefore at the expense of the
free software movement and free software itself.

   Simon

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Sam Hartman]

> "Theodore" == Theodore Ts'o  writes:

Theodore> On Mon, Apr 19, 2021 at 02:05:20PM +0100, Jonathan Dowland wrote:
>> On Mon, Apr 19, 2021 at 11:30:48AM +0800, Benda Xu wrote:
>> > The winning option "Debian will not issue a public statement on
>> this > issue" implies that the majority of DDs is not interested
>> in such > non-technical affairs.
>> 
>> The vote in fact shows the opposite.  That interpretation of the
>> result would be true if the majority of people voted for that as
>> their first preference. They did not: it was the most-agreed upon
>> preference between two ideologically opposite factions. The
>> majority of voting DDs expressed a strong preference one way or
>> the other.

Theodore
pppTheodore> The division was not caused by our decision making
Theodore> process; it was caused by the fact that this was naturally
Theodore> a question for which there was nothing like unaminity
Theodore> amongst the voting members.

Theodore> It is unclear that any change in our voting procedures
Theodore> could have made things any better.

Certainly in the systemd process there were a number of short comings
that came to light that are worth improving:

1) The person who introduces a GR is treated differently than anyone who
introduces an amendment in ways that are odd, and are subject to
strategic abuse.

2) The fact that a single person ends up calling for a vote has become
problematic in three important Debian elections now--one on the TC and
and two GRs.

3) It seems like we could do better surrounding discussion time
management.

4) It seems like there is an emerging consensus that we want either all
votes secret or to be able to have secret non-DPL votes.

None of these would have made the decision different, but I think they
would together have improved the process.

However, I don't think any of the above needs a working group.
I think it needs a few people to come up with a proposal.
My understanding is that Russ and peb are working on such a proposal.
I've volunteered to help them but so far have only contributed some
questions.

--Sam


signature.asc
Description: PGP signature

Re: Thanks and Decision making working group

[Daniel Leidert]

Am Sonntag, dem 18.04.2021 um 14:04 +0200 schrieb Jonathan Carter:


[..]
> While this vote caught a lot of heat, essentially it's quite a trivial
> vote.

I think this is wrong. And here is why:

> Ultimately it had become a question of if and how we should
> respond to an external situation.

The vote was actually two votes:

a) Should Debian respond publicly as a project? (the "if)
b) How should such a response read? (the "how")

And I feel that a) should receive a supermajority before b) can be decided by a
normal majority.

FWIW: I don't believe in any of the bullshit written here that Debian should
stay neutral or that this vote backs up that Debian should stay neutral. The
vote was about a very specific case. It might have gone differently if we would
have voted about a Harvey Weinstein or another Hans Reiser within the FOSS
community.

> I think that as Debian grows, as the
> free software eco-system grows, and as software gets ever more ingrained
> in our every day life, the questions and problems we're going to face
> will become increasingly complex and that we should adapt to be able to
> deal with those as a project.

+1

> Can we go ahead and set up such a working group?

+1

Regards, Daniel
-- 
Regards,
Daniel Leidert 
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78


signature.asc
Description: This is a digitally signed message part

Re: Thanks and Decision making working group

[Daniel Leidert]

Am Montag, dem 19.04.2021 um 11:30 +0800 schrieb Benda Xu:

[..]
> The winning option "Debian will not issue a public statement on this
> issue" implies that the majority of DDs is not interested in such
> non-technical affairs.

That's neither what the option said nor was intended for. The vote was about a
specific case. No more, no less. And it certainly doesn't open space for
speculations/assumptions like yours.

Regards, Daniel
-- 
Regards,
Daniel Leidert 
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78


signature.asc
Description: This is a digitally signed message part

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Wouter Verhelst]

Hi Sam,

On Mon, Apr 19, 2021 at 10:58:51AM -0600, Sam Hartman wrote:
> Certainly in the systemd process there were a number of short comings
> that came to light that are worth improving:
> 
> 1) The person who introduces a GR is treated differently than anyone who
> introduces an amendment in ways that are odd, and are subject to
> strategic abuse.
> 
> 2) The fact that a single person ends up calling for a vote has become
> problematic in three important Debian elections now--one on the TC and
> and two GRs.

I don't think this is necessarily a problem, provided that the rules for
calling for vote vis-a-vis discussion time are reasonable.

(I don't think they are, currently)

> 3) It seems like we could do better surrounding discussion time
> management.
> 
> 4) It seems like there is an emerging consensus that we want either all
> votes secret or to be able to have secret non-DPL votes.
> 
> None of these would have made the decision different, but I think they
> would together have improved the process.
> 
> However, I don't think any of the above needs a working group.

I agree with this. In my opinion, all historic attempts to create a
ballot through a working group or something similar have failed
miserably.

Our current processes work best, I believe, if proposals are written in
the open, so that if people disagree with the proposed texts, they can
start working on their amendment right away, which is much more
difficult to do under the time pressure of a GR procedure.

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Re: Thanks and Decision making working group

[Jonathan Carter]

On 2021/04/19 20:18, Daniel Leidert wrote:
> The vote was actually two votes:
> 
> a) Should Debian respond publicly as a project? (the "if)
> b) How should such a response read? (the "how")

I agree with you, I've said something similar before, although instead
of saying it was two votes, I'd rather say it started out as a, and that
that was the initial intention of the GR, and then it morphed into b as
the additional options were added. Sam noted this phenomenon in his last
mail in this thread as a strategic abuse. I think it certainly could be
used as a strategic abuse and we should be weary of that, but I also
don't assign any bad intentions to the people who added options in this
particular vote, I don't think it was their intentions to purposely
change the nature of the vote in order to change the outcome of the
original vote, and I think it's more a failure of our process, but I
think in broad strokes we're about on the same page on this.

-Jonathan

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Eduard Bloch]

Hallo,
* Simon Richter [Mon, Apr 19 2021, 06:37:01PM]:

> Make no mistake, the quest to have "apolitical" free software is deeply
> political in itself: the process that decides which group can establish

Catch 22?

Sorry, by your definition there is no way to escape from political
discussions. No way for Debian to be just a hobby, just a tech oriented
project, because EVERYBODY (yes, even you uncle Joe) must be dragged
into political activities and go the whole nine yards, GOT IT???

Do you want to chase all people who don't CARE about "f*k t* Na*s"
slogans (or whatever the current opposite is) out of Debian community?

*justfacepalming*,
Eduard.

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Steve Langasek]

On Mon, Apr 19, 2021 at 10:58:51AM -0600, Sam Hartman wrote:
> 1) The person who introduces a GR is treated differently than anyone who
> introduces an amendment in ways that are odd, and are subject to
> strategic abuse.

This asymmetry guards against a GR discussion being allowed to continue
indefinitely as a result of a small minority of developers repeatedly
introducing amendments that prolong the discussion period.

Whether malicious or not, I think this is important to guard against.

IMHO, it's better to have a vote quickly on a limited set of GR options,
with the possibility of a second GR if there is sufficient dissatisfaction
with the first GR outcome, than to have community energy spent endlessly on
crafting a perfect set of options before we take a vote.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Russ Allbery]

Wouter Verhelst  writes:

> Our current processes work best, I believe, if proposals are written in
> the open, so that if people disagree with the proposed texts, they can
> start working on their amendment right away, which is much more
> difficult to do under the time pressure of a GR procedure.

I'm helping hash out some ideas in private only because framing the
problem and brainstorming possible solutions requires a ton of back and
forth and trying to do that initial work on a public mailing list is
exhausting and takes even longer.  My intent is that anything we might
come up with is made public for general discussion well in advance of
being formally proposed for a GR, once it's in sufficiently coherent
shape.

(This is independent of any working group and started some time ago.)

Personally, my interest is in fixing the process around the discussion
period and the construction of the ballot.  The constitution currently
says some things that we've found cause unnecessary problems and weird
corner cases, leaves some things unspecified in confusing ways, and did
not anticipate the widespread use of ballot options and is therefore
hopelessly confusing about roles.  I think those can be cleared up in a
way that will make all GR votes smoother and more comprehensible going
forward.  I had intended to work on this after the systemd vote and then
didn't, which I feel bad about because we just had most of the same
problems again.  It's obviously something that's going to affect any even
moderately controversial GR we have, including on technical topics.

I'm also interested in a secret ballot for all GRs, but I think that's a
separate discussion (and a separate GR) from dealing with the discussion
period and ballot construction process.

I personally have little interest in messing with the rules about how we
do Condorcet, although of course other people might and I will read their
proposals with interest.

-- 
Russ Allbery (r...@debian.org)  

Re: Thanks and Decision making working group

[Jonas Smedegaard]

Quoting Jonathan Carter (2021-04-19 20:37:32)
> On 2021/04/19 20:18, Daniel Leidert wrote:
> > The vote was actually two votes:
> > 
> > a) Should Debian respond publicly as a project? (the "if)
> > b) How should such a response read? (the "how")
> 
> I agree with you, I've said something similar before, although instead
> of saying it was two votes, I'd rather say it started out as a, and that
> that was the initial intention of the GR, and then it morphed into b as
> the additional options were added. Sam noted this phenomenon in his last
> mail in this thread as a strategic abuse. I think it certainly could be
> used as a strategic abuse and we should be weary of that, but I also
> don't assign any bad intentions to the people who added options in this
> particular vote, I don't think it was their intentions to purposely
> change the nature of the vote in order to change the outcome of the
> original vote, and I think it's more a failure of our process, but I
> think in broad strokes we're about on the same page on this.

I can see in hindsight how the addition of options could have been done 
deliberately to ruin the original intent of a "yes/no" style ballot.

For my part in seconding multiple options and doing so with little 
hesitation was not with an aim to twist.  Instead I was a) genuinely 
concerned with Debian as an organisation formally standing behind a 
message which I found contained allegations, and b) supported many 
options because I was worried about the limited time available for 
refining options.

Had the process not been shortened then I would most likely have waited 
longer for others more well reasoned in their phrasing proposals to have 
come forward, and probably also (like I usually do) second only few 
options if any at all.

I don't mean to blame those deciding to shorten the process - I do 
understand that their reasoning was well-intended.  My point is that at 
least for me that shortening of processing time caused stress and more 
sloppy processing than might have been the case with more time.  And, as 
pointed out by Sam and Jonathan, that stress could be seen as deliberate 
obstruction.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Jonathan Carter]

Hi Russ

On 2021/04/19 21:36, Russ Allbery wrote:
> I'm helping hash out some ideas in private only because framing the
> problem and brainstorming possible solutions requires a ton of back and
> forth...

I think that framing the problems and noting them while the last GR is
still fresh in our collective memories will be really useful. I don't
think anyone should feel too much pressure right now to come up with
solutions, and I'd urge any group of people who are brainstorming on
this whether on a public channel or among some Debian friends to not yet
propose any kind of GR or anything major like that just yet.

For the next few weeks the project focus is on releasing bullseye. Once
the dust settles on that I think it would be a good time to address the
problems in a structured manner and take it from there. It would be
great to iron out at least some of the usual kinks in the process by the
time the next (non-voting related) GR pops up.

-Jonathan

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Russ Allbery]

Jonathan Carter  writes:

> I think that framing the problems and noting them while the last GR is
> still fresh in our collective memories will be really useful. I don't
> think anyone should feel too much pressure right now to come up with
> solutions, and I'd urge any group of people who are brainstorming on
> this whether on a public channel or among some Debian friends to not yet
> propose any kind of GR or anything major like that just yet.

I'm certainly not in any hurry to do anything like that.  :)  And I also
expected everyone to not want to get into it in detail until after the
release is out.

For the record, because some folks in this discussion have been worried
that this is about one specific vote or another, here's a (nonexhaustive)
list of concerns that I have that I think we should fix.  This isn't
really intended to open a discussion or get into solutions and I probably
therefore won't respond to more discussion of that right now (I promise, I
will later and won't propose any surprise GRs).  This is just to give
people a feel of what some of us mean when we talk about procedural flaws:

* The length of the discussion period is ill-defined in multiple ways,
  which has repeatedly caused conflicts.  It only resets on accepted
  amendments but not new ballot options, which makes little logical sense
  and constantly confuses people.  There's no maximum discussion period
  defined, which means fixes for that risk introducing a filibuster.

* Calling for votes is defined as a separate action from the end of the
  discussion period, but in practice the constitution allows any developer
  to call for a GR vote via an abuse of process that probably wasn't
  intended, and even apart from that, the set of people who can call for a
  vote is strange and not very defensible.

* Calling for votes is even more of a disaster for Technical Committee
  votes, as we have alas discovered.

* The length of the process is therefore not predictable, which means that
  people can't plan around deadlines for making changes to the ballot and
  instead we get procedural arguments around last-minute changes.

* The constitution reuses the term "amendment" for both changes to a
  ballot option and for introducing a new ballot option in ways that make
  it very hard to understand what some of the rules mean.

* The original proposer of the GR gets weird powers in the process that
  don't seem appropriate and can be abused.

* A formal amendment has to be sponsored like a new GR before it can be
  accepted, but the original proposer of a GR can make their own amendment
  without having it be sponsored.  These two rules make no sense in
  combination (which is probably why the first rule is rarely, perhaps
  never, enforced).

* The constitution says that any place the Standard Resolution Procedure
  is invoked must state what the default option is, but then doesn't do
  that.

* There's a reasonable argument that using a default option of "none of
  the above" would be clearer to people who have not participated in a lot
  of Debian votes but who have experience with other voting systems where
  that's a more typical default option.  Also, some folks (not including
  me, but I do understand) have been unhappy with the plain English
  implications of "further discussion" for some time and often feel
  obliged to propose a ballot option that's functionally equivalent but
  isn't seen as calling for more discussion.

-- 
Russ Allbery (r...@debian.org)  

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Adrian Bunk]

On Mon, Apr 19, 2021 at 06:37:01PM +0200, Simon Richter wrote:
> Hi,

Hi Simon,

> On Sun, Apr 18, 2021 at 04:56:34PM +0300, Adrian Bunk wrote:
> 
> > Is it really still an open question whether Debian is a political
> > project that has opinions on non-technical topics like the board of the
> > FSF or the legal status of Taiwan, Palestine and Kosovo, or whether
> > Debian is a technical project where people of diverse backgrounds and
> > political opinions can work together on making a good distribution?
> 
> Debian is a political project that promotes the autonomy of users vis-a-vis
> large organizations such as corporations and governments. It does this by
> promoting the creation of free software, and by fostering a community
> around free software.
>...

in the 1990s I would have agreed with you, but the world has changed.

Nowadays a big part of the community around free software are
large corporations.

The member list of the Linux Foundation[1] goes from Microsoft and 
Oracle through BlackRock and Goldman Sachs to Facebook and Uber.

Recent Debconf sponsors included companies like Microsoft, IBM,
Google and Amazon. And AFAIK every one of these companies employs
at least one DD whose job includes paid work to make modifications
to Debian that benefit the company.

>Simon

cu
Adrian

[1] https://linuxfoundation.org/en/join/members/

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Adrian Bunk]

On Mon, Apr 19, 2021 at 12:31:51PM -0700, Steve Langasek wrote:
>...
> IMHO, it's better to have a vote quickly on a limited set of GR options,
> with the possibility of a second GR if there is sufficient dissatisfaction
> with the first GR outcome, than to have community energy spent endlessly on
> crafting a perfect set of options before we take a vote.

You are saying that whenever there are 6 DDs who don't like the outcome 
of the first GR, they should start a second GR that repeals the first GR
and replaces it with something better as soon as the results of the 
first GR are posted.

Or start a second GR before the first GR has been voted on, as nearly 
happened during your GR due to the shortened discussion period.


I would rather have one discussion that covers all aspects of the topic, 
with all options on one ballot, and then have the topic settled instead
of having an endless succession of GRs around the same topic.


cu
Adrian

Re: Proposed mass-bug filing: missing support for build-arch or build-indep

[Guillem Jover]

Hi!

On Mon, 2021-04-19 at 15:11:21 +0200, Lucas Nussbaum wrote:
> I would like to propose a mass bug filing on source packages that miss
> support for build-arch or build-indep targets in debian/rules.

Thanks, that'd be great!

> There are currently 411 packages in testing that do not include those
> targets, according to lintian's debian-rules-missing-recommended-target
> tag.  (I will also file a bug against lintian to reflect that those
> targets are now required).
> 
> I do not particularly care about those targets, but I believe that it is
> a good idea to use this old policy change as a way to identify packages
> whose packaging should be upgraded to newer practices.

Currently dpkg contains some backwards compatibility code required to
support the missing targets in some conditions, which I'd really rather
see go away.

Lately Niels Thykier and me have been trying to chip away groups of
packages by making these targets required on specific build conditions,
but I think we run out of easy conditions to key on. So, doing this
mass bug filing to get the last stragglers seems like a good way
forward.

> Any comments?

Given this, I'll probably be planning on removing the compatibility
code and thus making these truly required (so causing FTBFS) during
the dpkg 1.21.x series targeting bookworm.

Thanks,
Guillem

Re: Thanks and Decision making working group

[Sam Hartman]

> "Jonathan" == Jonathan Carter  writes:

Jonathan> On 2021/04/19 20:18, Daniel Leidert wrote:
>> The vote was actually two votes:
>> 
>> a) Should Debian respond publicly as a project? (the "if) b) How
>> should such a response read? (the "how")

Jonathan> I agree with you, I've said something similar before,
Jonathan> although instead of saying it was two votes, I'd rather
Jonathan> say it started out as a, and that that was the initial
Jonathan> intention of the GR, and then it morphed into b as the
Jonathan> additional options were added. Sam noted this phenomenon
Jonathan> in his last mail in this thread as a strategic abuse.

I'd like to be heard much differently.
The abuses I was thinking about are along much different lines.

I don't think having the ballot turn from something simple into
something more complex is abusive at all.
I think it's our voting system working as intended.

It's often very difficult to agree on what question to ask.
Our voting system doesn't require that.  In the systemd vote we
definitely never agreed what the question was, even though we came up
with an answer.

This discussion would have taken much longer if we had to produce a
ballot that was internally consistent where all the options focused on
one question.
It might make interpreting the results easier, but as we saw in the TC
discussions surrounding systemd, the challenge of coming up with the
ballot may become intractible.

Instead, some people viewed this as an election about how neutral Debian
should be.  Some people viewed it as a discussion of how much we should
support rms.
Some people focused on what we should say about rms.
And that's okay.
We'll never entirely be able to untangle all those answers.
But if we tried to, we might never end our discussions.


The sorts of abuses I was talking about have to do with powers of the
original proposer to muck with the process.
Steve could have dragged the process out as long as he wished by
accepting amendments.
Under a strict reading of the constitution, Steve could have made it
more difficult for other people to revise the wording of their ballot
options.
Those are the sorts of abuses I'm talking about.
None of those happened in this election as far as I am aware.


signature.asc
Description: PGP signature