Re: Thanks and Decision making working group

[Jonathan Carter]

On 2021/04/20 00:10, Sam Hartman wrote:
> 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.

Ah in that case I completely misunderstood you, thanks for clearing that up.

-Jonathan

Re: Thanks and Decision making working group

[Thomas Goirand]

On 4/20/21 12:10 AM, Sam Hartman wrote:
> 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.

Exactly. The GR was about all of the above (and more?).

I have to say I'm a bit disappointed to read some wants to change the
voting system because of what happened during this GR. Yes, the voting
system should be improved if it is possible to do so. But this GR
shouldn't be the main reason/motivation. We should do it because we
strive to have the most democratic system. Some of the properties we may
want to have (lamely copied from some research paper):

- Eligibility: only legitimate voters can vote, and only once.
- Fairness: no early results can be obtained which could influence the
remaining voters.
- Vote-privacy: the fact that a particular voter voted in a particular
way is not revealed to anyone.
- Receipt-freeness: a voter does not gain any information (a receipt)
which canbe used to prove to a coercer that she voted in a certain way.
- Coercion-resistance: a voter cannot cooperate with a coercer to prove
to him that she voted in a certain way.
- Individual verifiability: a voter can check that her own ballot is
included inthe election's bulletin board.
- Universal verifiability: anyone can check that the election outcome
corresponds to the ballots published on the bulletin.

Cheers,

Thomas Goirand (zigo)

Bug#987235: ITP: pcm -- tools for Intel-specific processor performance and energy metrics

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: pcm
  Upstream Author : Intel
* URL : https://github.com/opcm/pcm/
* License : BSD-3
  Programming Lang: C++
  Description : tools for Intel-specific processor performance and energy 
metrics

 Processor Counter Monitor is a set of tools to access various performance
 metrics provided by newer Intel processors.  Such metrics include:
  * instructions per cycle
  * core frequencies
  * memory/interconnect/PCIe bandwidth
  * cache misses and utilization
  * time spent in C-states
  * thermal headroom
  * energy consumption
  * NUMA accesses
 and more.

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 01:04:21PM -0700, Russ Allbery wrote:
>...
> * 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.
>...

The process to shorten the discussion period is also suboptimal.

In the latest GR the way the discussion period was shortened was 
perceived by many as an anti-democratic attempt to suppress discussions 
about the contents and alternative ballot options.

And there was plenty left to discuss (including wording of ballot 
options and secrecy of the vote) when the minimum discussion period
ended and the vote was called.

I would suggest to replace the option of shortening the discussion 
period with the possibility of early calling for a vote after a week 
that can be vetoed by any developer within 24 hours. This would ensure 
that shorter discussion periods would only happen when there is 
consensus that nothing is left to be discussed.

cu
Adrian

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

[Philipp Kern]

On 2021-04-20 10:59, Adrian Bunk wrote:

I would suggest to replace the option of shortening the discussion
period with the possibility of early calling for a vote after a week
that can be vetoed by any developer within 24 hours. This would ensure
that shorter discussion periods would only happen when there is
consensus that nothing is left to be discussed.


But K developers could have stopped this, right? (Per 4.2.2.3.) Now the 
constitution feels quite heavyweight on that ("sponsoring a 
resolution"), but I'd be surprised if the DPL would not have taken back 
the decision in that case (4.2.2.5).


A single person being able to block consensus of basically everyone else 
feels like opening up the process to unconstructive behavior.


Kind regards
Philipp Kern

Re: Thanks and Decision making working group

[Ansgar]

Philipp Kern writes:

> On 2021-04-20 10:59, Adrian Bunk wrote:
>> I would suggest to replace the option of shortening the discussion
>> period with the possibility of early calling for a vote after a week
>> that can be vetoed by any developer within 24 hours. This would ensure
>> that shorter discussion periods would only happen when there is
>> consensus that nothing is left to be discussed.
>
> But K developers could have stopped this, right? (Per 4.2.2.3.) Now
> the constitution feels quite heavyweight on that ("sponsoring a
> resolution"), but I'd be surprised if the DPL would not have taken
> back the decision in that case (4.2.2.5).

How does that even work?  The next clause is:

+---
| If the decision is put on hold, an immediate vote is held to determine
| whether the decision will stand until the full vote on the decision is
| made or whether the implementation of the original decision will be
| delayed until then.
+---[ Debian Constitution, 4.2.2.4 ]

Which leaves open quite a bit, e.g, how long would the voting period for
the immediate vote be?  The regular voting period is two weeks after
all...

Ansgar

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 Tue, Apr 20, 2021 at 11:59:31AM +0200, Philipp Kern wrote:
> On 2021-04-20 10:59, Adrian Bunk wrote:
> > I would suggest to replace the option of shortening the discussion
> > period with the possibility of early calling for a vote after a week
> > that can be vetoed by any developer within 24 hours. This would ensure
> > that shorter discussion periods would only happen when there is
> > consensus that nothing is left to be discussed.
> 
> But K developers could have stopped this, right? (Per 4.2.2.3.) Now the
> constitution feels quite heavyweight on that ("sponsoring a resolution"),
> but I'd be surprised if the DPL would not have taken back the decision in
> that case (4.2.2.5).

There is a whole can of worms around at what times the DPL can make
or take back such a decision.

Can a voting period be varied when voting has already started?
Note that the discussion period of the RMS GR was varied after
the discussion period had already started.

Can 4.2.2.3. be used to force a vote on a varied voting period
when voting is already ongoing?

Can 4.2.2.5. be used to take back a varied voting period when
voting is already ongoing?

What would it mean in practice when either the 2 week voting period or 
the varied voting period ends while the decision on the variation is
on hold due to 4.2.2.3.?

Could 4.2.2.3. have been used in the RMS GR to put the varying of the 
discussion period on hold after voting had already started?

> A single person being able to block consensus of basically everyone else
> feels like opening up the process to unconstructive behavior.

A single person whom we trust to upload anything to our archive.[1]

If the person thinks there is something left that should be discussed 
then there is no consensus, and if a DD is just trying to sabotage 
random things in Debian then GR discussion periods are not my biggest 
worry.

> Kind regards
> Philipp Kern

cu
Adrian

[1] ignoring the non-uploading special case

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 Eduard,

On Mon, Apr 19, 2021 at 08:49:56PM +0200, Eduard Bloch wrote:

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

> Sorry, by your definition there is no way to escape from political
> discussions.

You can't escape your work being tangled up in politics. Whether you
actively take part is your choice, of course.

> 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???

At the individual level, if you have the necessary privilege, nothing stops
you from ignoring the politics, but you can't really stop the other
individuals (and corporations).

Debian as an entity absolutely cannot ignore politics, because it keeps
intruding on our work.

We used to have separate infrastructure outside the United States because
the political situation at that time forbade us from exporting crypto-
graphic software from the US, and Debian spent a lot of effort to get this
changed.

The technical work is only a tiny part of what we do as an organization,
and I'd even argue that most of the technical work happens outside our
organizational structures. Pulling a technical matter before the TC is seen
as a heavy-handed approach.

Instead, what Debian does as an organization is *enable* the technical
work, by taking care of political aspects so individual developers don't
have to. Stopping Debian from doing that will not make your tech oriented
hobby less political, because it removes a shield and directly exposes you
to the politics of what we are doing here.

Apart from the "openly" political work, Debian also does community
building, and this, too, enables technical work as it pulls in new
contributors. Handling conflicts within the community is part of that work,
and how we handle conflicts decides who will be future contributors.

Taking a hands-off approach here means leaving contributors to deal with
conflicts themselves, selecting potential contributors for people who
accept that working for Debian includes interpersonal conflict that
distracts from tech work. This, again, runs counter to your intention that
people should (be able to) focus on tech work.

   Simon

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

[Wouter Verhelst]

On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:
> 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.

I agree; I believe it should be the opposite (i.e., it should reset on
new ballot options but not on modifying already accepted options)

[...]
> * 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).

I'm not entirely sure what you mean by that. Can you clarify?

[...]
> * 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.

I can understand the issue with FD, but I don't think NOTA is a good
alternative. I think any other language should be explicit about what
the result will be, and what it will *not* be. NOTA does do that, IMO;
it does not clarify that the discussion may restart, and that a new vote
may appear; it just states that none of the presented options are
appropriate.

The default option means "we don't have a valid option on the ballot, we
would therefore like to cancel the vote and possibly do it over"; I
would therefore prefer the default option to state something like
"cancel the vote, possibly restart it" or some such.

>   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.

Not sure whether you consider this an issue, but I don't see that as a
problem. There is a difference between "we can't reach an agreement and
therefore decide on a no-outcome vote" (which the default option is),
and "we have considered all the options and decide that a no-outcome
vote is the best result" (which an explicit no-outcome ballot option
represents).

To put it otherwise, due to the nature of the default option, an
explicit no-outcome ballot option is *not* functionally equivalent to
the default option, in my opinion, since the default option means "this
doesn't work, let's not do this and maybe try again", and an explicit
no-outcome ballot option explicitly means "this doesn't work, let's not
do that again".

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

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

[Timo Röhling]

* Wouter Verhelst  [2021-04-20 13:50]:

Not sure whether you consider this an issue, but I don't see that as a
problem. There is a difference between "we can't reach an agreement and
therefore decide on a no-outcome vote" (which the default option is),
and "we have considered all the options and decide that a no-outcome
vote is the best result" (which an explicit no-outcome ballot option
represents).


I think the RMS vote was somewhat unique, because (intentional or not)
the options ended up in way that was almost equivalent to asking "on a
scale from -3 to 3, how strongly should Debian as organization react to
the RMS reinstatement".  I would consider the outcome the neutral (0)
option, and FD would have been the NULL option, i.e., "we can't/won't
decide".  If Steve's original intent to have a binary decision for
signing the open letter had prevailed, an additional "no" option would
not have been nearly as useful.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

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

[Julien Cristau]

On Mon, Apr 19, 2021 at 03:11:21PM +0200, Lucas Nussbaum wrote:
> 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 think you should start with a lower severity and consider bumping it
to serious once you're down to a manageable number (and possibly a
couple of NMU campaigns).

Cheers,
Julien

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

[Holger Levsen]

On Mon, Apr 19, 2021 at 10:58:51AM -0600, Sam Hartman wrote:
> 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.

I dispute this statement. Some people said that.

I disagree that voting secrecy is (sensibly) possible. Best effort secrecy
is not secrecy, so we should not promise what we cannot deliver.

And then I'm not sure I want secret votes for transparency reasons.


-- 
cheers,
Holger

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

If you own several guns but no guitars, you are doing life all wrong.


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)

[Philipp Kern]

On 2021-04-20 12:44, Adrian Bunk wrote:
A single person being able to block consensus of basically everyone 
else

feels like opening up the process to unconstructive behavior.


A single person whom we trust to upload anything to our archive.[1]

If the person thinks there is something left that should be discussed
then there is no consensus, and if a DD is just trying to sabotage
random things in Debian then GR discussion periods are not my biggest
worry.


I mean that we have unilateral access possibilities to the archive is 
kinda bad as well. But there's much less cost to distracting a vote 
process and be obstructionist than it is to upload a compromised 
package. :)


Kind regards
Philipp Kern

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 Mon, Apr 19, 2021 at 10:45:29PM +0300, Adrian Bunk wrote:

> > 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.

Yes, and this caused a massive shift in the power dynamic between users and
corporations.

A core component of the operating system we ship is so complex that it
needs to be maintained by full-time employees. This has effectively given
the corporation employing these people veto power over our technical
decisions, because even though the software they ship is technically free
software, the cost of maintaining a fork is higher than a volunteer
organization can afford sustainably.

We already know this mechanism as "Embrace and Extend", and it is designed
to create dependence. In the past, we have called this out for what it is,
and actively counteracted it because dependence is not in the interest of
our users.

The same corporation has also issued a statement on the reelection of RMS
to the FSF board, so apparently they don't feel the need to be "apolitical"
in the interest of not alienating "valuable" contributors, so I fail to see
what we are trying to achieve here.

   Simon

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

[Holger Levsen]

On Tue, Apr 20, 2021 at 02:50:22PM +0200, Julien Cristau wrote:
> I think you should start with a lower severity and consider bumping it
> to serious once you're down to a manageable number.

agreed. thanks for changing my mind, Julien!


-- 
cheers,
Holger

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

Der Mensch is' gut, aber die Leut' san a G'sindel!


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)

[Ansgar]

Simon Richter writes:
> A core component of the operating system we ship is so complex that it
> needs to be maintained by full-time employees. This has effectively given
> the corporation employing these people veto power over our technical
> decisions, because even though the software they ship is technically free
> software, the cost of maintaining a fork is higher than a volunteer
> organization can afford sustainably.

Yes, I agree that Debian can't maintain a custom fork of the Linux
kernel and we practically have to trust employees of the Linux
Foundation like Linus Torvalds to maintain it reasonably.

> The same corporation has also issued a statement on the reelection of RMS
> to the FSF board, so apparently they don't feel the need to be "apolitical"
> in the interest of not alienating "valuable" contributors, so I fail to see
> what we are trying to achieve here.

The Linux Foundation has issued a statement on the FSF board changes?

Ansgar

Bug#987263: ITP: node-jmespath -- javascript implementation of JMESPath

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-devel@lists.debian.org, nil...@debian.org

* Package name: node-jmespath
  Version : 0.15.0+dfsg
  Upstream Author : James Saryerwinnie
* URL : https://github.com/jmespath/jmespath.js
* License : Apache-2.0
  Programming Lang: Javascript
  Description : javascript implementation of JMESPath

 Jmespath.js is a javascript implementation of JMESPath, which is a query
 language for JSON. It will take a JSON document and transform it into
 another JSON document through a JMESPath expression.

 I shall maintain this package

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:
> On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote:

>> * 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).

> I'm not entirely sure what you mean by that. Can you clarify?

Take a look at A.1.1 and A.1.2 and ask what the process is if someone
other than the original proposer notices a logical flaw (i.e., not a minor
error) and wants to ask the proposer to fix it and everyone agrees that it
should be fixed.

In practice, the expedient thing for the proposer to do is to repropose
the same amendment themselves, which bypasses the sponsorship requirement,
and then immediately accept it, and then allow the original amendment to
be discarded due to lack of sponsors.  This is silly, which is presumably
why the Project Secretary doesn't require people do this even though
technically it's required.

The sponsorship requirement only makes sense because of the confusion
between amendments and ballot options; the sponsorship is there for the
A.1.3 case.  I've done some test reworkings of this section separating
ballot options from amendments, and everything becomes more
straightforward and clear (and has other advantages in role
clarification).

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

Re: Thanks and Decision making working group

[Russ Allbery]

Thomas Goirand  writes:

> I have to say I'm a bit disappointed to read some wants to change the
> voting system because of what happened during this GR. Yes, the voting
> system should be improved if it is possible to do so. But this GR
> shouldn't be the main reason/motivation.

There are a few different threads of this, so you may not be talking about
my concerns at all, but I want to clarify that, first, I don't want to
change the voting system (beyond supporting secret ballot but I'm happy
for that to be a separate discussion), I want to change the *GR discussion
system*.  And second, I want to change the GR discussion system because of
the mess during systemd discussion, not because of this vote, although
this vote did re-raise the same issues.

-- 
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)

[Steve Langasek]

On Mon, Apr 19, 2021 at 11:25:50PM +0300, Adrian Bunk wrote:
> 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.

Not exactly.  I'm saying that whenever there are 6 DDs who don't like the
outcome of the first GR, *and believe it could be overturned with a better
worded option*, they should start a second GR.

> 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.

So, the option to overturn with a second GR if the first one is considered
satisfactory already exists (and would exist under any proposed changes to
the system).  How often has that option been exercised?

I think the existing system already gives you the result you say above that
you want.

-- 
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

Bug#987291: ITP: gnome-shell-extension-desktop-icons-ng -- desktop icon support for GNOME Shell

[Gunnar Hjalmarsson]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org

Package name: gnome-shell-extension-desktop-icons-ng
Version : 0.17.0-1
Upstream Author : Sergio Costas 
URL : https://gitlab.com/rastersoft/desktop-icons-ng
License : GPL-3+
Programming Lang: Javascript
Description : Desktop icon support for GNOME Shell

The package provides a GNOME Shell extension for showing the contents of 
~/Desktop on the desktop of the Shell. It's a fork/rewrite of an 
existing extension (package: gnome-shell-extension-desktop-icons) but 
with additional features often desired by users ("-ng" means New 
Generation).


Ubuntu 21.04 includes gnome-shell-extension-desktop-icons-ng by default.



OpenPGP_signature
Description: OpenPGP digital signature

Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result

[Bug Report]

Good Evening Kurt:

I have carefully read your complaint about Richard Stallman, and while I 
believe everyone should be entitled to an opinion on values, I find your 
condemnation of Stallman to be unfounded, and not relevant to software 
development, particularly Stallman's position on abortion and sex.  And 
for the record, I find US laws on sexual misconduct with consenting 
minors 16-18 to be a miscarriage of justice. Example:  My grandfather on 
my mother's side married my grand mother's when he was 27, and she was 
15, but by today's standard he would be guilty of statutory rape.  They 
were married for more than 46 years before he passed away. Ultimately 
whether or not a minor should be allowed to engage in such activity 
should be solely the prerogative of the parents.  A recent example of a 
miscarriage of justice  is a 17 year old who has been requested to 
register as a sex offender in Washington state because of consensual 
activities with his 15 year old girl friend.  I find this to be a 
miscarriage of justice. So when it comes to sex, I take issue with your 
position, and don't see how Richard Stallman's position on abortion, and 
sex is related to software development.


With respect to criminal justice reform, there is a strong case to be 
made with respect to overhauling our state's drug and sex laws since 
they don't protect anyone except those who make money from 
incarceration.  The United States incarcerates more people than any 
other country on earth, and many of these cases involve consensual 
activities with minors, and drug offenses.  And for the record, I am a 
big fan of the German penal code which appears to be a lot more 
functional than our own criminal justice system.


At this point, I think you owe your readers of this list a formal 
apology for attempting to use sex, and abortion as a means to bias your 
reader's views on Richard Stallman. It


Randal South


On 4/18/21 4:20 AM, Debian Project Secretary - Kurt Roeckx wrote:

Hi,

The results of the General Resolution is:
Option 7 "Debian will not issue a public statement on this issue"

The details of the results are available at:
https://www.debian.org/vote/2021/vote_002


Kurt Roeckx
Debian Project Secretary

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

[Gunnar Wolf]

Steve Langasek dijo [Tue, Apr 20, 2021 at 01:53:02PM -0700]:
> On Mon, Apr 19, 2021 at 11:25:50PM +0300, Adrian Bunk wrote:
> > 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.
> 
> Not exactly.  I'm saying that whenever there are 6 DDs who don't like the
> outcome of the first GR, *and believe it could be overturned with a better
> worded option*, they should start a second GR.

Cfr. the three votes on declassifying debian-private:

https://www.debian.org/vote/2005/vote_002
https://www.debian.org/vote/2016/vote_002
https://www.debian.org/vote/2016/vote_004

The first vote mandated the declassification of debian-private after a
three year period for "historical or ongoing significance". Eleven
years later, it became clear this mandate was untenable, and a second
GR was proposed to repeal it and set up a clearer set of rules
allowing for selective declassification under a given procedure. This
second GR did not succeed. A couple of months later, I proposed a
third GR, with the original text identical to the second one's. The
third GR had two amendments; the three options were ranked above FD,
and one of the amendments was chosen.

So, yes, a similar procedure could be done WRT any other GR decision
we have so far taken.

Well, except for de-electing a previous DPL whose term has already
finished, I guess ;-)


signature.asc
Description: PGP signature