Re: Firmwares (was Re: Bits from the DPL)

[Dmitry Baryshkov]

On Mon, 1 Apr 2024 at 19:28, Vincent Bernat  wrote:
>
> On 2024-04-01 18:05, Jonathan Carter wrote:
> > The included firmware contributed to Debian 12 being a huge success,
> > but it wasn't the only factor.
>
> Unfortunately, the shipped firmwares are now almost a year old,
> including for unstable. I am following the progress since quite a few
> years and I have seen many possible contributors trying to help and
> fail. The current situation is that Debian does not work well with
> recent AMD-based laptops due to firmware being too old. Therefore, we
> are back at users trying to update the firmware by copying them from
> random places (as for myself, I am using the deb generated by upstream's
> Makefile).
>
> My personal impression is that we are repeating a common scheme in
> Debian: maintainers don't have time to move forward due to the task
> being non-trivial for reasons of our own, people are proposing to help
> (6 people in [1]), but this is ignored by the maintainers as they don't
> have time.

As one of the persons who tried and failed to do the update, I
wouldn't blame maintainers ignoring my PR. I would have appreciated
getting more prompt feedback, but I understand that we all are doing
this during our spare time.

There was another issue which I could not find my way through. I found
it pretty troublesome to update debian/config subdirs. There is no
clear reference whether the Version should follow the WHENCE or the
firmware version from the git commit message (they differ for Intel BT
files). So, my 2c, packaging infrastructure should use WHENCE file
where possible instead of duplicating a significant part of it.


-- 
With best wishes
Dmitry

Re: Firmwares (was Re: Bits from the DPL)

[Didier 'OdyX' Raboud]

Le lundi, 1 avril 2024, 19.41:45 h CEST Andrey Rakhmatullin a écrit :
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not up to date).

My recollection, after getting some MRs merged in the firmware-nonfree package 
last cycle (oh, a year gone already), is that it's a mix of:

* the maintainers in position to review, then merge the proposed changes are 
few, and have plenty on their hands;

* firmware packages seem to have lower priority during the development cycle, 
in favour of larger updated shortly-before (or during) the freeze;

* upstream and Debian (maintainers) are not in complete agreement on what can, 
or should be shipped in packages; from README.source:
> Also, some of its contents are not clearly redistributable, and some are
> obsolete for Debian's purposes.

So almost every file addition needs a careful `git log` review to check for 
origin, updates, reasoning, version strings, etc. Unless there's tooling I 
have not found; it's tedious, error-prone (and not very interesting) work 
(although quite arguably necessary).

* packaging is very smart, but peculiar (or at least, quite different to what 
I had been used to before I touched it). Despite good documentation, it's 
quite a steep intro for newcomers.

All-in-all, I think it's an all-too-classical case of "we don't have enough 
humanpower for the job we set out to do". Add a team of motivated individuals 
to gain the confidence of the existing "already-plenty-on-their-plates 
maintainers", to then maintain the package on their own. Oh, wait…

-- 
OdyX

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

Re: Firmwares (was Re: Bits from the DPL)

[Gunnar Wolf]

Andrey Rakhmatullin dijo [Mon, Apr 01, 2024 at 10:41:45PM +0500]:
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not up to date).

There are many firmware packages that don't come from the linux
sources. i.e., I maintain raspi-firmware, the blob needed to boot the
Raspberry Pi family of computers.

And not even following upstream is always enough --- as a data point,
up until a year ago, the Raspberry Pi foundation used to regularly tag
releases in their Github repo¹, but they no longer do that. Of course,
I am not inclined to ship to Debian an unsanctioned what would amount
to just a random snapshot (of course, impossible to review or bugtrack
in any meaningful way) of their blob :-\

¹ https://github.com/raspberrypi/firmware


signature.asc
Description: PGP signature

Re: Bits from the DPL

[Christian Kastner]

Hi Jonathan,

just a brief correction:

On 2024-04-01 18:05, Jonathan Carter wrote:
> I don't want to single out DSA there, it's difficult and affects many
> other teams. The Salsa CI team also spent a lot of resources (time and
> money wise) to extend testing on AMD GPUs and other AMD hardware. It's
> fantastic and interesting work, and really more people within the
> project and in the outside world should know about it!

The AMD GPUs are not part of the official CI yet, as both our official
infrastructure (hosting the GPUs) and our policies (expressing hardware
relationships) do not permit it.

We are running a fork of debci and other packages at
https://ci.rocm.debian.net. Our forks have a number of experimental
features, notably our architectures are [CPU ISA]+[GPU ISA], for example
amd64+gfx1030 (Navi 21) or amd64+gfx1100 (Navi 31).

Our fork currently automatically tracks all Debian packages which
reverse-depend on any of our libraries. Developers are invited to add
ROCm support to their packages if it's supported upstream, and the
packages will automatically be tested on over a dozen AMD GPU
architectures within our infra.

We're finalizing our upgrade to ROCm 5.7+ (also on Ubuntu), and a proper
write-up will follow on Debian Planet.

Best,
Christian

PS: Our intention is of course to feed back all our changes to debci,
Policy and so on, but some of these are entirely novel and require
experimentation first, followed by discussion.

Re: Firmwares (was Re: Bits from the DPL)

[Andrey Rakhmatullin]

On Mon, Apr 01, 2024 at 06:27:29PM +0200, Vincent Bernat wrote:
> On 2024-04-01 18:05, Jonathan Carter wrote:
> > The included firmware contributed to Debian 12 being a huge success,
> > but it wasn't the only factor.
> 
> Unfortunately, the shipped firmwares are now almost a year old, including
> for unstable. I am following the progress since quite a few years and I have
> seen many possible contributors trying to help and fail. The current
> situation is that Debian does not work well with recent AMD-based laptops
> due to firmware being too old. Therefore, we are back at users trying to
> update the firmware by copying them from random places (as for myself, I am
> using the deb generated by upstream's Makefile).
> 
> My personal impression is that we are repeating a common scheme in Debian:
> maintainers don't have time to move forward due to the task being
> non-trivial for reasons of our own, people are proposing to help (6 people
> in [1]), but this is ignored by the maintainers as they don't have time.
> 
> [1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests
Why is updating the firmware packages not trivial? Is it because of
licensing issues? I always thought it's just copying a bunch of files from
the linux-firmware repo (but I also often wondered why is the package
often not up to date).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Firmwares (was Re: Bits from the DPL)

[Vincent Bernat]

On 2024-04-01 18:05, Jonathan Carter wrote:

The included firmware contributed to Debian 12 being a huge success,
but it wasn't the only factor.


Unfortunately, the shipped firmwares are now almost a year old, 
including for unstable. I am following the progress since quite a few 
years and I have seen many possible contributors trying to help and 
fail. The current situation is that Debian does not work well with 
recent AMD-based laptops due to firmware being too old. Therefore, we 
are back at users trying to update the firmware by copying them from 
random places (as for myself, I am using the deb generated by upstream's 
Makefile).


My personal impression is that we are repeating a common scheme in 
Debian: maintainers don't have time to move forward due to the task 
being non-trivial for reasons of our own, people are proposing to help 
(6 people in [1]), but this is ignored by the maintainers as they don't 
have time.


[1]: https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests

Re: Bits from the DPL

[Jonathan Carter]

On 2022/04/20 08:25, j...@debian.org wrote:

2022-01-12  - Milestone 1 - Transition and toolchain freeze 2022-02-12  -
Milestone 2 - Soft Freeze 2022-03-12  - Milestone 3 - Hard Freeze - for key
packages and packages without autopkgtests To be announced - Milestone 4 
- Full

Freeze


Oops, that was a copy and paste from an initial incorrect mail, the 
dates are of course meant to be for 2023, not 2022.


-Jonathan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bits from the DPL for March 2020

[Eike]

Hello Sam,

Am Montag, 6. April 2020, 11:34:12 CEST schrieb Sam Hartman:
> Thinking about Covid-19 and what this means for the world has taken up
> much of my emotional bandwidth in March.

I haven't read anything that describes what has happened to me
as matching like this.

*distance hugs*
Eike


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

Re: BITS from the DPL For September/October 2019

[Paul Wise]

On Sat, Nov 2, 2019 at 7:06 AM Bernd Zeimetz wrote:

> That leads to the question how long it takes until these bugs are being
> noticed.
>
> I am definitely not going to test init scripts properly when the systemd
> units are exactly doing what they are supposed to. The number of people
> not using systemd are probably low enough to ensure bugs are not found
> until its to late.

It seems like autopkgtests might be the right answer here, but I don't
know if debci also runs the tests on sysvinit/etc based systems.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: BITS from the DPL For September/October 2019

[Bernd Zeimetz]

On 10/31/19 8:07 PM, Alf Gaida wrote:
> I read it the same way - and also a logical consequece: if these
> patches lead to bugs, the maintainer should not be forced to fix the
> mess. I for myself would just remove buggy things that nobody care in a
> certain amount of time.

That leads to the question how long it takes until these bugs are being
noticed.

I am definitely not going to test init scripts properly when the systemd
units are exactly doing what they are supposed to. The number of people
not using systemd are probably low enough to ensure bugs are not found
until its to late.


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

Re: tomcat9 using systemd specific stuff is now vendor lock-in [was: BITS from the DPL For September/October 2019]

[Mathieu Parent]

Le ven. 1 nov. 2019 à 00:48, Thomas Goirand  a écrit :
>
> On 10/31/19 9:56 PM, Moritz Mühlenhoff wrote:
> > This isn't limited to just shipping an init script, have a look at the
> > tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
> > Continuing to support an init script also means to retain on all the
> > packaging boilerplate which got obsoleted by systemd config declaratives,
> > forcing the least common denominator of init system features.
>
> Ok, let's have a look.
>
> So I saw this:
>
> * Simplified the postinst script by using systemd-sysusers to create
> the 'tomcat' user
>
> and then investigated a little bit what systemd-sysusers is (I didn't
> know it). And it's really a disaster ... at many levels!
>
> Instead of using well understood parameters to adduser, which we've been
> using for decades, and understand well the parameters, systemd provides
> now a mechanism through /usr/lib/sysusers.d. Tomcat uses it by adding a
> file in /usr/lib/sysusers.d/tomcat9.conf. I'm immediately questionning
> myself is it wouldn't have been better in /etc/systemd/sysusers.d, so
> that we get CONFFILE, but that's Red Hat tooling, so... and maybe we can
> override it in /etc/systemd? Anyways...

The reasons why it's not in /etc are here [1], and this is
overridable, see SYSUSERS.D(5).

[1] http://0pointer.de/blog/projects/stateless.html

> So, this is supposed to be "more simple". Really? I'm not convinced.
> Looking into the script, I now also have to look into the indirection of
> that data file, and package that file.
>
> What's for sure now, is that tomcat9 is vendor-locked-in, as in, no way
> to escape systemd, otherwise the postinst will crash. I suppose the
> maintainer perfectly understands it, but doesn't mind/care. [I by the
> way wonder why tomcat9 runtime depends on both lsb-base *AND* systemd]
>
> Probably, systemd-sysusers got the logic to check with getent if the
> user is present before adding it and such things. So it may be useful
> (hard to tell, but looking quickly at its source code, it seems doing
> that, and even a lot more, to the point that it starts to get scary).
> But that's not the point.
>
> The question is, why is systemd-sysusers part of just systemd, and not
> packaged / shipped somewhere else? This really looks like something that
> could be taken away from systemd itself, and proposed as a separate
> tool, in a general way, so that other init system could use it. To the
> point that, IMO, even upstream should have separate it from systemd
> itself (in another project?).
>
> This is precisely what a distribution should do through a policy:
> enforce common tooling for our maintainer scripts, so we can do things
> together. Of course, that's not on the systemd agenda, where the goal
> seems to be to take over everything. But maybe as a distribution, we
> could be smarter than this?
>
> Finally, this really shows we don't have enough in our policy. Indeed,
> using systemd-sysusers *OR* some common Debian tooling should be
> documented somewhere, and not left as a decision to the package
> maintainer. I have to admin that I wrote my own tooling around adduser /
> addgroup / getend / usermod, but considering how many traps there,
> probably a more generic tooling should have been written and generalized
> for all of Debian.
>
> The other things I saw from the changelog are less controversial:
> * Let systemd automatically create /var/log/tomcat9 and /var/cache/tomcat9
>
> this can easily be added in the init script
>
> * Restart the server automatically on failures
>
> that's a nice standard systemd feature, which we don't have to enforce
> on other init systems.
>
> Did I miss something else?

This is #925473 which was fixed in 9.0.16-5 (in experimental [2]) and
lost by the upload of 9.0.22-1 to sid.

Those patches should be brought back to sid, but it seems that there
is not so much interest.

[2]: 
https://tracker.debian.org/news/1041550/accepted-tomcat9-9016-5-source-all-into-experimental/


Cheers

-- 
Mathieu Parent

Re: BITS from the DPL For September/October 2019

[Vincent Bernat]

 ❦ 31 octobre 2019 21:49 +01, Thomas Goirand :

> The idea has always been that it would be on best-effort from people who
> volunteer, without forcing anyone to do any sysv-rc support if they
> don't feel like it. What you describe goes along this line.

I have raised my concern about this a few months ago and it seems this
is not the consensus:

 
 

My impression is that there are some people pushing sysvinit related
work to all maintainers through this policy item but keeping quiet
during discussions like this. A GR would give us a better view of what
the project thinks.
-- 
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"


signature.asc
Description: PGP signature

Re: tomcat9 using systemd specific stuff is now vendor lock-in [was: BITS from the DPL For September/October 2019]

[Marco d'Itri]

On Nov 01, Thomas Goirand  wrote:

> Instead of using well understood parameters to adduser, which we've been
> using for decades, and understand well the parameters, systemd provides
Personally I never remember the exact semantics of many adduser/addgroup 
parameters and I have to double check them every time, YMMV.

> The question is, why is systemd-sysusers part of just systemd, and not
> packaged / shipped somewhere else? This really looks like something that
The simple answer is "because nobody else actually did that elsewhere".

> could be taken away from systemd itself, and proposed as a separate
> tool, in a general way, so that other init system could use it. To the
> point that, IMO, even upstream should have separate it from systemd
> itself (in another project?).
Upstream has no reason to do this, since upstream likes to share code 
among these programgs.
The people who care about not using systemd should bother forking and 
packaging it standalone.

> maintainer. I have to admin that I wrote my own tooling around adduser /
> addgroup / getend / usermod, but considering how many traps there,
LOL: "well understood", indeed.

> probably a more generic tooling should have been written and generalized
> for all of Debian.
And thankfully now we have one, also available in all other relevant 
distributions.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: tomcat9 using systemd specific stuff is now vendor lock-in [was: BITS from the DPL For September/October 2019]

[Thomas Goirand]

On 10/31/19 9:56 PM, Moritz Mühlenhoff wrote:
> This isn't limited to just shipping an init script, have a look at the
> tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
> Continuing to support an init script also means to retain on all the
> packaging boilerplate which got obsoleted by systemd config declaratives,
> forcing the least common denominator of init system features.

Ok, let's have a look.

So I saw this:

* Simplified the postinst script by using systemd-sysusers to create
the 'tomcat' user

and then investigated a little bit what systemd-sysusers is (I didn't
know it). And it's really a disaster ... at many levels!

Instead of using well understood parameters to adduser, which we've been
using for decades, and understand well the parameters, systemd provides
now a mechanism through /usr/lib/sysusers.d. Tomcat uses it by adding a
file in /usr/lib/sysusers.d/tomcat9.conf. I'm immediately questionning
myself is it wouldn't have been better in /etc/systemd/sysusers.d, so
that we get CONFFILE, but that's Red Hat tooling, so... and maybe we can
override it in /etc/systemd? Anyways...

So, this is supposed to be "more simple". Really? I'm not convinced.
Looking into the script, I now also have to look into the indirection of
that data file, and package that file.

What's for sure now, is that tomcat9 is vendor-locked-in, as in, no way
to escape systemd, otherwise the postinst will crash. I suppose the
maintainer perfectly understands it, but doesn't mind/care. [I by the
way wonder why tomcat9 runtime depends on both lsb-base *AND* systemd]

Probably, systemd-sysusers got the logic to check with getent if the
user is present before adding it and such things. So it may be useful
(hard to tell, but looking quickly at its source code, it seems doing
that, and even a lot more, to the point that it starts to get scary).
But that's not the point.

The question is, why is systemd-sysusers part of just systemd, and not
packaged / shipped somewhere else? This really looks like something that
could be taken away from systemd itself, and proposed as a separate
tool, in a general way, so that other init system could use it. To the
point that, IMO, even upstream should have separate it from systemd
itself (in another project?).

This is precisely what a distribution should do through a policy:
enforce common tooling for our maintainer scripts, so we can do things
together. Of course, that's not on the systemd agenda, where the goal
seems to be to take over everything. But maybe as a distribution, we
could be smarter than this?

Finally, this really shows we don't have enough in our policy. Indeed,
using systemd-sysusers *OR* some common Debian tooling should be
documented somewhere, and not left as a decision to the package
maintainer. I have to admin that I wrote my own tooling around adduser /
addgroup / getend / usermod, but considering how many traps there,
probably a more generic tooling should have been written and generalized
for all of Debian.

The other things I saw from the changelog are less controversial:
* Let systemd automatically create /var/log/tomcat9 and /var/cache/tomcat9

this can easily be added in the init script

* Restart the server automatically on failures

that's a nice standard systemd feature, which we don't have to enforce
on other init systems.

Did I miss something else?

Cheers,

Thomas Goirand (zigo)

Re: BITS from the DPL For September/October 2019

[Moritz Mühlenhoff]

Thomas Goirand  schrieb:
> "I’d very happily maintain the init script."
>
> I haven't read all the bug entry, but if someone is claiming that
> accepting such contribution is mandatory, then that's very much right,
> at least that the consensus we're in right now, indeed.

This isn't limited to just shipping an init script, have a look at the
tomcat9 9.0.13-1 changelog entry which dropped the sysvinit script.
Continuing to support an init script also means to retain on all the
packaging boilerplate which got obsoleted by systemd config declaratives,
forcing the least common denominator of init system features.

Cheers,
Moritz

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

On 10/31/19 8:07 PM, Alf Gaida wrote:
> I read it the same way - and also a logical consequece: if these
> patches lead to bugs, the maintainer should not be forced to fix the
> mess. I for myself would just remove buggy things that nobody care in a
> certain amount of time.

I'd be very much fine with this type of move.

The idea has always been that it would be on best-effort from people who
volunteer, without forcing anyone to do any sysv-rc support if they
don't feel like it. What you describe goes along this line.

Thomas Goirand (zigo)

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

On 10/31/19 7:36 PM, Moritz Mühlenhoff wrote:
> Thomas Goirand  schrieb:
>> My understanding is that the current guidance is that doing init script
>> isn't mandatory.
> 
> With policy not updated, people claim it's mandatory, see e.g.
> #925473 on Tomcat.

Well, the policy is wrong, and should be updated then. I do believe we
all agree on this already.

Now, looking at the said bug, we have Thorsten Glaser proposing:
"I’d very happily maintain the init script."

I haven't read all the bug entry, but if someone is claiming that
accepting such contribution is mandatory, then that's very much right,
at least that the consensus we're in right now, indeed. Which is *very*
different from mandating the package maintainers to do the work all by
themselves.

> The discussed GRs would provide clarification on what the project
> at large actually wants (and what policy should spell out).

So, if I understand well, you guys want to remove the mandatory
acceptation of contributed sysv-rc init scripts. At this point in time,
we could do that, but well, if it's this way, I do believe we must as well:
- stop any non-linux port effort, and remove them from ports.d.o.
- remove sysv-rc, filerc and openrc from Debian.
- edit the policy and mandate each package having .service files.
- file (probably non-rc) bugs against things providing a sysv-rc script,
asking for its removal.
- make a release goal for Bullseye so that we get rid of any non-systemd
startup scripts.

Because if we can't provide support for these, we may as well remove
them all together, and if we do, we should do it the right way.

In the text of the said GR, please make all of this very clear,
otherwise, we'd be misleading the voters!

Cheers,

Thomas Goirand (zigo)

Re: BITS from the DPL For September/October 2019

[Gunnar Wolf]

Simon Richter dijo [Wed, Oct 30, 2019 at 12:46:21PM +0100]:
> Hi,
> 
> On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote:
> 
> > If we have such vote again, I'll continue on this direction: I'd prefer
> > if we didn't have to vote.
> 
> >From a Policy perspective, packages are supposed to integrate into the
> system by providing init scripts, and Policy has a lengthy definition of
> how init scripts need to behave.
> 
> We need to at least mention systemd unit files at some point, so action is
> needed, and that action needs to be backed up by a vote to avoid being
> more divisive than necessary.

I completely agree with this -- It is time for Policy to specify at
least the equivalence of init scripts to systemd units.

Policy has always documented standard practice, so it was right for it
to lag before doing this. It is, I guess, time to revisit...

> So far, systemd adoption has been mostly smooth sailing because the
> ecosystem effectively consists of two blocks: the systemd core, which is
> centrally coordinated, and some traditional Unix daemons hanging off it,
> but essentially not integrating. This is about to change as projects
> actually start using systemd.

Yes. And that will be a thorn for people investing time in maintaining
Debian as an init-system-agnostic distribution. Or worse, following
the examples you provide :-\

> (...)
> All that requires way more complex unit files than anything we normally
> deal with in Debian, and we need to decide how much control we want to keep
> over package integration here, because that is what Debian does: take
> upstream software and provide a coherent integrated whole.
> 
> By leaving it unspecified in Policy what systemd features are expected in a
> particular Debian release, we essentially take a back seat in what should
> be our core competence.

Although by taking advantage of them, we will not be able to support
on an equal tier other init systems.

> If the project feels that these use cases are not worth supporting, then
> that is a policy decision that needs to be voted on, not just silently
> implemented, last but not least so we can update our marketing materials
> with footnotes on the "universal operating system" tagline, and users (who,
> after all, are one of our priorities) can adjust their expectations.
> 
> So yes, having a vote is necessary at this point. We've neglected setting
> policy way too long, the scope of the project is unclear at this point, and
> people are pulling in all kinds of directions.

Very much agree with this. It is time to revisit and think clearly
about what we win/lose, and where are we heading as a
project. Probably the only way forward is via the full GR process.


signature.asc
Description: PGP signature

Re: BITS from the DPL For September/October 2019

[Alf Gaida]

On Thu, 31 Oct 2019 18:40:58 +0100
Thomas Goirand  wrote:
> On 10/29/19 11:19 PM, Russ Allbery wrote:

> > of clear project guidance, no one is clearly empowered to prevent
> > it from bitrotting.  
What is wrong with bitrotting if nobody cares about - in case nobody
cares about it's the logical consequence. And please don't even try to
enforce this care. 

> My understanding is that the current guidance is that doing init
> script isn't mandatory. What is mandatory, is to ACK init scripts /
> patches when contributed (through the BTS).
I read it the same way - and also a logical consequece: if these
patches lead to bugs, the maintainer should not be forced to fix the
mess. I for myself would just remove buggy things that nobody care in a
certain amount of time.
 
> I think that's fair enough for everyone, and I don't see why we need
> to change anything to this rule.
Dito

> Make what deferred decision? That we want to actively dismiss patches
> adding init script support? This IMO would just destroy any work
> attempted in the non-linux ports, or anyone willing to add support
> for a new init system. I don't think that's fair for these. Voting
> them out would not feel right.
See it different: if the provided scripts/patches are good, why not
take and keep them - systemd users are not hurt. If the scripts/patches
don't work - ignore the upcoming bugs and downgrade everything about to
whishlist - or if interested in: Fix the bugs. Default will work and
good. And i don't want to provoke, i see it exactly this way, if people
spend time one something, why blocking or discourage if it do no harm.
I even merge patches for kfreebsd and the hurd upstream - but i would
never active work on it.

> As much as I understand, we never wrote or decided we would. We just
> need to accept patches to add or fix sysv-rc scripts. What makes you
> think sysv-rc scripts are mandatory?
Good question - if these things are not mandatory nothing needs to
change.

> 
> Thomas Goirand (zigo)
> 



-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

Re: BITS from the DPL For September/October 2019

[Moritz Mühlenhoff]

Thomas Goirand  schrieb:
> My understanding is that the current guidance is that doing init script
> isn't mandatory.

With policy not updated, people claim it's mandatory, see e.g.
#925473 on Tomcat.

The discussed GRs would provide clarification on what the project
at large actually wants (and what policy should spell out).

Cheers,
Moritz

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

Russ,

On 10/29/19 11:19 PM, Russ Allbery wrote:
> [...] we do not have clear
> project consensus that sysvinit support is mandatory in new packages, so
> the support is starting to bitrot, and given the lack of clear project
> guidance, no one is clearly empowered to prevent it from bitrotting.

I think we mostly agree on the topic, but now what the consensus is.

My understanding is that the current guidance is that doing init script
isn't mandatory. What is mandatory, is to ACK init scripts / patches
when contributed (through the BTS).

I think that's fair enough for everyone, and I don't see why we need to
change anything to this rule.

> The current Policy text is a mess, and everything it says on the topic is
> essentially accidental, being left over from text that was added to
> clarify how to support upstart, before the TC decision on the default init
> system.  It's unclear what requirements Policy should actually set on
> packages that want to ship daemons, and any attempt to hammer that out is
> likely to be contentious and have great difficulty reaching consensus.

Sure, the Debian policy text needs some love and contributions, though
what I wrote above is more or less what we all agreed on. Besides this,
the state of the policy is (unfortunately, and because the policy needs
updates) orthogonal to this discussion.

> I think it was the right thing to do to refuse to make a clear long-term
> decision at the time, when the project had just gone through a bruising
> and awful argument.  Now that we have some distance and have seen how the
> ecosystem has subsequently evolved, I think it's time to circle back and,
> hopefully with more accumulated wisdom, a bit of emotional distance, and a
> bit more calm, make the deferred decision.

Make what deferred decision? That we want to actively dismiss patches
adding init script support? This IMO would just destroy any work
attempted in the non-linux ports, or anyone willing to add support for a
new init system. I don't think that's fair for these. Voting them out
would not feel right.

> If we're really going to continue to fully support sysvinit

As much as I understand, we never wrote or decided we would. We just
need to accept patches to add or fix sysv-rc scripts. What makes you
think sysv-rc scripts are mandatory?

Thomas Goirand (zigo)

Re: BITS from the DPL For September/October 2019

[Holger Levsen]

Sam,

thanks for the bits mail. Very interesting as usual! Just a minor
nitpick...

On Tue, Oct 29, 2019 at 01:16:21PM -0400, Sam Hartman wrote:
> * I spent some money.

No, you didn't, Debian did, as you correctly described below. You
approved that spending.


-- 
cheers,
Holger

(I'm not sure why it is important to me to point this out, but as I
thought to write this mail yesterday and still want to write it
today... I hope this is just a joke/witty way of putting things which
got lost in translation...)

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: BITS from the DPL For September/October 2019

[Simon Richter]

Hi,

On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote:

> If we have such vote again, I'll continue on this direction: I'd prefer
> if we didn't have to vote.

>From a Policy perspective, packages are supposed to integrate into the
system by providing init scripts, and Policy has a lengthy definition of
how init scripts need to behave.

We need to at least mention systemd unit files at some point, so action is
needed, and that action needs to be backed up by a vote to avoid being
more divisive than necessary.

So far, systemd adoption has been mostly smooth sailing because the
ecosystem effectively consists of two blocks: the systemd core, which is
centrally coordinated, and some traditional Unix daemons hanging off it,
but essentially not integrating. This is about to change as projects
actually start using systemd.

For example, libvirt needs to tightly integrate with systemd because a lot
of the automatisms for the desktop are actively harmful in a VM hosting
setup.

My VM host starts with two visible network cards, loading the driver
enables fourteen more virtual functions, so I start with sixteen Ethernet
devices, fifteen of which need to be completely ignored by
systemd-networkd, and one has static configuration. When VMs start up, LVM
logical volumes are activated, but should not have fsck run on them,
because they are then having their permissions changed so KVM can open them
exclusively and make them available to the guest. The virtual network cards
then have their drivers unbound from them, making the interface disappear,
and the PCIe device is passed through to the guest. In addition, libvirt
creates a tap device, and connects it to a bridge device whose IP
configuration lives inside libvirt's configuration database.

All that requires way more complex unit files than anything we normally
deal with in Debian, and we need to decide how much control we want to keep
over package integration here, because that is what Debian does: take
upstream software and provide a coherent integrated whole.

By leaving it unspecified in Policy what systemd features are expected in a
particular Debian release, we essentially take a back seat in what should
be our core competence.

At the very least, I'd like Policy to spell out what types of unit files
are supported, what keywords in those unit files exist, and what target
names are used to denote certain points in the boot sequence (similar to
how we define priority ranges for init scripts). We probably don't need to
replicate the full documentation for these things, but we are deviating
from upstream systemd by doing stable releases, and we need to at least
document the deviation.

We should probably also make some inroads into when unit files should
specify dependencies and which. Systemd explicitly differentiates between
functional and order dependencies, and lots of daemons just specify both.
Are these required, or just cargo-culted from somewhere? I'd expect Debian
maintainers of services that ship unit files to understand exactly what
these dependencies do, and whether they are needed, and that means adding
that information to Tasks&Skills in the New Maintainer process.

All of these are exactly the kind of bureaucracy that Debian is (in)famous
for, but which has enabled us to build a high-quality distribution, and
which will be necessary going forward if we actually want to use more of
systemd's features and still keep our reputation.

In my opinion, keeping the other init systems around is also still useful,
because there will always be installations where the default behaviour of
systemd is counterproductive, and keeping the system running after updates
is playing whack-a-mole with newly introduced features that also need to be
turned off.

If the project feels that these use cases are not worth supporting, then
that is a policy decision that needs to be voted on, not just silently
implemented, last but not least so we can update our marketing materials
with footnotes on the "universal operating system" tagline, and users (who,
after all, are one of our priorities) can adjust their expectations.

So yes, having a vote is necessary at this point. We've neglected setting
policy way too long, the scope of the project is unclear at this point, and
people are pulling in all kinds of directions.

   Simon

Re: BITS from the DPL For September/October 2019

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:


Wouter> Having said that,

Wouter> Sam: I notice that you've not sent a draft of your GR
Wouter> proposal to the -vote mailing list yet. It has been my
Wouter> experience over the years that that is not generally a good
Wouter> idea. The DPL does have the power to bypass much of the GR
Wouter> procedure, and in urgent situations this is probably a good
Wouter> thing; but I believe that the drafting of GR ballots in the
Wouter> open on a public mailinglist is actually an essential part
Wouter> of the whole GR procedure, which allows people to form an
Wouter> opinion together, resulting in fewer (but better) options on
Wouter> the ballot.

I think we agree in part.  I think that an open discussion of the ballot
prior to any formal procedure happening is important.

When I'm ready for that I'll send a draft to debian-vote.

I'll also note that it's rare that the DPL has used their power to call
for a general resolution, and so we actually don't have a lot of
experience with how best to handle things when the DPL is trying to
facilitate a project poll.

Both in DPL facilitated GRs and in other GRs I actually think there's
some important leg work that can be done ahead of the public process.  I
want to come with a ballot that I think is reasonable and an
understanding of some of the issues involved at the beginning of the
public process.  It will make ith easier for me to answer questions and
to facilitate a discussion.

I absolutely agree that a public discussion prior to anyone pushing the
button and getting the secretary involved is important.

I expected to be ready for that a week ago, but I got distracted by my
day job.

--Sam

Re: BITS from the DPL For September/October 2019

[Wouter Verhelst]

On Tue, Oct 29, 2019 at 03:19:03PM -0700, Russ Allbery wrote:
> We've now had several years of essentially declining to make a decision
> and trying to see if the project can muddle through, and while I feel
> somewhat vindicated by the fact that this didn't immediately fall apart
> and has sort of worked, I think it's becoming increasingly untenable.  We
> now have contributors who are far-removed from the original debate and who
> may have only used a systemd-based Debian system and we do not have clear
> project consensus that sysvinit support is mandatory in new packages, so
> the support is starting to bitrot, and given the lack of clear project
> guidance, no one is clearly empowered to prevent it from bitrotting.

Hear hear.

While I was reading Sam's message, I was a bit apprehensive about having
a vote about this; but his arguments, and yours, make sense in that it
is a good idea to either tell people we're no longer interested in
multiple init systems as a project, or to empower those who want to work
on it that we, as a project, think it is a sensible idea to do so and
that not supporting alternative init systems should be considered an RC
bug.

(FWIW, even though one of my packages doesn't currently have an init
script where it should, I happen to think the latter is true; but it has
become very clear to me over the past few years that this opinion is far
from common in the project, and that is precisely the reason why this
vote would be a good idea).

Having said that,

Sam: I notice that you've not sent a draft of your GR proposal to the
-vote mailing list yet. It has been my experience over the years that
that is not generally a good idea. The DPL does have the power to bypass
much of the GR procedure, and in urgent situations this is probably a
good thing; but I believe that the drafting of GR ballots in the open on
a public mailinglist is actually an essential part of the whole GR
procedure, which allows people to form an opinion together, resulting in
fewer (but better) options on the ballot.

It is times when we are divided, such as in the case of GR 2004_004,
that this process breaks down and the number of options on the ballot
skyrockets. This is also the reason, I think, why ballots that are
drafted in secret almost always immediately receive amendments as soon
as they are proposed, thereby negating any perceived benefit that they
might have provided.

For that reason, I would like to urge you to draft the ballot in the
open, unless you think there is little time for this and you need to
have something to move forward urgently -- which would be something I
would disagree with.

Thanks,

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: BITS from the DPL For September/October 2019

[Russ Allbery]

Thomas Goirand  writes:

> The last time we've had a GR on init systems, the general response was
> that we don't want to vote, and we preferred the TC to decide.

I don't think the core questions here are technical questions.  I think
they're more fundamental questions of project direction and questions
about what burden we want to put on ourselves as package maintainers in
order to support a variety of init systems.  This seems like a good set of
issues to resolve democratically, at least for lack of a better
alternative.  Resolution by TC on this issue seems likely to lead to lead
to challenges to the TC's impartiality or legitimacy.  That's really not
very much fun to go through when you're on the TC.

We've now had several years of essentially declining to make a decision
and trying to see if the project can muddle through, and while I feel
somewhat vindicated by the fact that this didn't immediately fall apart
and has sort of worked, I think it's becoming increasingly untenable.  We
now have contributors who are far-removed from the original debate and who
may have only used a systemd-based Debian system and we do not have clear
project consensus that sysvinit support is mandatory in new packages, so
the support is starting to bitrot, and given the lack of clear project
guidance, no one is clearly empowered to prevent it from bitrotting.

The current Policy text is a mess, and everything it says on the topic is
essentially accidental, being left over from text that was added to
clarify how to support upstart, before the TC decision on the default init
system.  It's unclear what requirements Policy should actually set on
packages that want to ship daemons, and any attempt to hammer that out is
likely to be contentious and have great difficulty reaching consensus.

I think it was the right thing to do to refuse to make a clear long-term
decision at the time, when the project had just gone through a bruising
and awful argument.  Now that we have some distance and have seen how the
ecosystem has subsequently evolved, I think it's time to circle back and,
hopefully with more accumulated wisdom, a bit of emotional distance, and a
bit more calm, make the deferred decision.

If we're really going to continue to fully support sysvinit, we should
commit to doing so clearly and empower people to test that support and
report bugs of appropriate severity (and also to create a stronger
incentive for making that support easier to achieve).  If we're not, we
should unambiguously free people from doing additional work that they
don't want to do and can't test easily, and also more clearly communicate
the project's intentions so that our partners like Devuan can make
informed decisions about how to proceed.  The simmering uncertainty and
low-level tension of not having a decision eventually becomes its own
problem.

A GR may not be the best mechanism to make that decision, but I'm not sure
what method would be better.

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

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

On 10/29/19 6:16 PM, Sam Hartman wrote:
> Init System Policy
> ==
> 
> last Bits mail, I talked about how I was considering whether we needed a
> GR on Init System Policy.

The last time we've had a GR on init systems, the general response was
that we don't want to vote, and we preferred the TC to decide.

If we have such vote again, I'll continue on this direction: I'd prefer
if we didn't have to vote.

Thomas

Re: Bits from the DPL (August 2019)

[Thomas Goirand]

On 10/1/19 9:24 PM, Samuel Henrique wrote:
> and the centralization
> of the discussion in a "tree like" structure are things that I miss a
> lot here.

Are you saying that you're reading -devel without the "tree like"
display of the thread? Outch! I'd strongly suggest using a better client
if yours isn't capable of such a display... (FYI all of these clients
can do it: thunderbird, evolution, mutt)

Thomas

Re: Bits from the DPL (August 2019)

[Thomas Goirand]

On 9/19/19 6:30 AM, Jerome BENOIT wrote:
> 
> 
> On 19/09/2019 00:46, Sam Hartman wrote:
> 
>> Init System Diversity
>> =
> 
>> So perhaps sysvinit and init scripts have had their chance and it is
>> time to move on.  We could move away from init scripts as the default
>> representation.  We could stop caring about sysvinit (which isn't quite
>> the same thing but is related).  That would leave non-linux ports in an
>> unfortunate position.  But right now there are no non-linux ports in the
>> main archive.  So perhaps we don't even care about that.  Again, a
>> change, but a change that we can ask ourselves if we are ready to make.
> 
> This does not look as diversity.
> 
> Otherwise I am very surprise that Devuan was not mention at all.
> May be it is time to work with the Devuan team and merge Devuan to Debian.
> 
> hth,
> Jerome

FWIW, I'd be very much against aggressively dropping the support for
sysv-rc, and I've completely missed the discussion. Was it on -devel?

Thomas

Re: Bits from the DPL (August 2019)

[Thomas Goirand]

On 10/1/19 5:06 PM, Enrico Zini wrote:
> If I say something that 1000 people like and one person hates, the
> net visible effect in my inbox is probably one angry reply.

I very much agree with that. Which is why I don't feel comfortable when
Sam making summaries and conclusions of discussions we have.

I also find it difficult to read long threads, and Sam "summaries" are
also too long too read for me (sorry Sam, I do feel like you're putting
a lot of effort on this, but that's harsh reality).

Cheers,

Thomas Goirand (zigo)

Re: Bits from the DPL (August 2019)

[Wouter Verhelst]

Sorry about the lateness here, been busy...

On Tue, Oct 01, 2019 at 12:22:34PM -0400, Sam Hartman wrote:
> > "Sean" == Sean Whitton  writes:
> 
> Sean> You might separate your detailed, narrative descriptions of
> Sean> how discussions went from what you took away from the
> Sean> discussions.  You could either drop the former, or put it in a
> Sean> "read this if you want more details" section.
> 
> I've found that if you do that, people get surprised and upset when it
> is not obvious how you got to a decision.  Basically I've found that
> enough people are upset without a narrative that you get much more
> overall mail and less confidence in the process without.
> 
> I do organize my mail so people can skip sections, and I do try to
> consistently put the conclusions after the narrative.

That's great. It does help to be explicit about it then:

"if you're short on time and/or not interested in the details, please
skip ahead to the conclusion in section XYZ".

I did miss that in your most recent "Bits" email, and I do think it
could be useful for those of us who are short on time.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Sean Whitton]

Hello,

On Sat 05 Oct 2019 at 10:13PM +01, Samuel Henrique wrote:

> I don't understand the argument of it being a social problem, isn't our
> own constitution a technical solution to a social problem?

Hmm, I think that "social problem" is not what I meant.

It's difficult to communicate effectively in writing, and we do not have
good ways of collating best practices for doing that and passing them on
to new and existing contributors.  Further, communicating effectively in
writing takes energy that isn't always available.

To my mind, this is what's responsible for us communicating less
effectively.  When I say that's it's not a technical problem, I just
mean that it seems like a problem we can't program our way out of.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Jeremy Stanley]

On 2019-10-05 22:13:49 +0100 (+0100), Samuel Henrique wrote:
[...]
> And the problems with relying on the tree view of email subthreads
> have already been exposed here as it depends on people formatting
> the subthread in a specific way, which does always happens.
[...]

Not necessarily. For me at least, mutt shows proper branching
subthreads regardless of whether folks remember to modify the
subject when they're changing topics. But as you already pointed
out, expecting people to use available tools which solve these
problems is unrealistic--they'd rather keep using the tools they're
familiar with and then complain about the medium--asking for (or
better still, implementing themselves) improvements in the tools
they use is going to be the last thing they consider.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Samuel Henrique]

On Wed, 2 Oct 2019 at 14:51, Antonio Terceiro  wrote:

> On Wed, Oct 02, 2019 at 01:37:58PM +0100, Samuel Henrique wrote:
> > On Wed, 2 Oct 2019 at 10:48, Mathias Behrle  wrote:
> >
> > > ...BTW no discussion tool can help in automating
> > > separate discussion threads when the topic changes.
> > >
> >
> > They can, I think reddit and hackernews are good at this.
> > That's the "tree-like" structure that I mentioned in my email.
>
> Note that email already has a "tree-like" structure, since forever. You
> just don't see it if you (ironically) use web application email clients
> like gmail that decided to not show it. Most console/desktop clients
> that I ever saw do support it.
>

Hm, but I wonder of the ones you saw how much they are used, because from
the ones I see people using, I would say less than 5% (by usage) has this.

And even then we are talking about tools that are either console or
desktop-only, there is still the smartphone user cases and, most
importantly, being able to follow the discussions without the need
to authenticate and being subscribed to the list, which would be
useful for outsiders (and an outsider is someone who will become
a contributor eventually).

And the problems with relying on the tree view of email subthreads
have already been exposed here as it depends on people formatting
the subthread in a specific way, which does always happens.

On Wed, 2 Oct 2019 at 15:29, Jeremy Stanley  wrote:

> If you find that mailing list discussions lack a tree-like
> structure, that's a failing of the mail client you've chosen, not
> the medium itself.


I don't think it helps with having new contributors to require them
to use specific mail clients that are used by a small niche of
mail users (talking about client percentage usage). Besides it
also require one to be subscribed to the list and authenticated,
so outsiders can't easily follow. I know there is a web interface
for the archives but is isn't good to follow the threads as well.

On Wed, 2 Oct 2019 at 15:36, Sean Whitton  wrote:

> > BTW no discussion tool can help in automating separate discussion
> > threads when the topic changes.
>
> Yes, and more generally, what we are trying to deal with seems to be a
> social problem, not a technical problem, so moving away from mailing
> lists is unlikely to have a large impact.


I don't understand the argument of it being a social problem, isn't our
own constitution a technical solution to a social problem?
When dealing with behavior/social problems, it's fine if you don't
solve 100% of the cases, but you can certainly help by having tools
that makes it harder for one to follow trough the wrong way of doing
things, that's the whole point of UX.

In this case, for example, this subthread started by saying that the
titles need to be formatted in a correct way so it's easier to follow
the big picture. Reddit and Hackernews doesn't have this problem
as you're always replying to a given comment, if it's not the OP,
it's a subthread. It's very hard to accidentally not open a subthread
when you want to, as the "add comment" screen shows you only the
one you're replying to.

In the end, I'm not saying the hackernews and reddit solution are
perfect, they still probably do have other problems when used
as a discussion tool.

I'm fine with not talking about changing the status quo anymore,
I thought there would be people exposing the problems and
talking about the pros/cons of the tools but it's clear that I'm
the outlier here. It seems most of the community doesn't think
we could have a better tool for discussions.

-- 
Samuel Henrique 

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Sean Whitton]

Hello,

On Wed 02 Oct 2019 at 11:30AM +02, Mathias Behrle wrote:

> first of all it would help a lot to identify when a new subthread is
> openend and make this visible in the usual way (like this mail does). It would
> increase a lot(!) the readability of Debian lists where this is an
> often encountered problem.

Thank you for the reminder about that; it's useful.

> BTW no discussion tool can help in automating separate discussion
> threads when the topic changes.

Yes, and more generally, what we are trying to deal with seems to be a
social problem, not a technical problem, so moving away from mailing
lists is unlikely to have a large impact.

> Meanwhile we are at the often introduced question if better tooling could 
> help.
> I don't think another tool can save a lot of time. We *ourselves* can help
> that with more discipline in following the good old rules in marking 
> subthreads
> when they are going offtopic. Finally the scheduling of the different topics
> led partly to the fact that only quite few members could participate. This 
> will
> be a constant problem in a project of volunteers and I think we will have to
> live with that fact.

Yes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Sean Whitton]

Hello,

On Tue 01 Oct 2019 at 12:22PM -04, Sam Hartman wrote:

>> "Sean" == Sean Whitton  writes:
>
> Sean> You might separate your detailed, narrative descriptions of
> Sean> how discussions went from what you took away from the
> Sean> discussions.  You could either drop the former, or put it in a
> Sean> "read this if you want more details" section.
>
> I've found that if you do that, people get surprised and upset when it
> is not obvious how you got to a decision.  Basically I've found that
> enough people are upset without a narrative that you get much more
> overall mail and less confidence in the process without.

That's fair enough.

> I do organize my mail so people can skip sections, and I do try to
> consistently put the conclusions after the narrative.

Okay, cool -- I must admit that I have not readily been able to observe
you doing that, so perhaps the distinction between the two kinds of text
could be made more pronounced.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Jeremy Stanley]

On 2019-10-02 10:51:22 -0300 (-0300), Antonio Terceiro wrote:
> On Wed, Oct 02, 2019 at 01:37:58PM +0100, Samuel Henrique wrote:
> > On Wed, 2 Oct 2019 at 10:48, Mathias Behrle  wrote:
> > 
> > > ...BTW no discussion tool can help in automating
> > > separate discussion threads when the topic changes.
> > >
> > 
> > They can, I think reddit and hackernews are good at this.
> > That's the "tree-like" structure that I mentioned in my email.
> 
> Note that email already has a "tree-like" structure, since forever. You
> just don't see it if you (ironically) use web application email clients
> like gmail that decided to not show it. Most console/desktop clients
> that I ever saw do support it.

Indeed, mutt is showing me a very branchy tree for this very
discussion. MUAs include references to the message IDs replied to
within each message's headers, precisely so that readers can
construct a reference graph of message relationships for this use
case. If you find that mailing list discussions lack a tree-like
structure, that's a failing of the mail client you've chosen, not
the medium itself.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Antonio Terceiro]

On Wed, Oct 02, 2019 at 01:37:58PM +0100, Samuel Henrique wrote:
> On Wed, 2 Oct 2019 at 10:48, Mathias Behrle  wrote:
> 
> > ...BTW no discussion tool can help in automating
> > separate discussion threads when the topic changes.
> >
> 
> They can, I think reddit and hackernews are good at this.
> That's the "tree-like" structure that I mentioned in my email.

Note that email already has a "tree-like" structure, since forever. You
just don't see it if you (ironically) use web application email clients
like gmail that decided to not show it. Most console/desktop clients
that I ever saw do support it.


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Nicholas D Steeves]

Samuel Henrique  writes:

> On Wed, 2 Oct 2019 at 10:48, Mathias Behrle  wrote:
>
>> ...BTW no discussion tool can help in automating
>> separate discussion threads when the topic changes.
>>
>
> They can, I think reddit and hackernews are good at this.
> That's the "tree-like" structure that I mentioned in my email.
>

Are there any good reddit or hackernews-style front-ends to mail
archives with a reply view similar to github's, including preview view?
(IIRC the email-paradigm example web-thing project mentioned earlier in
the thread didn't mention anything on this topic) Extra points if the
user can hold , highlight the passages from multiple messages, hit
reply, and get a markdown-style reply interface that enforces in-line
quoting style with no top posting or unnecessarily CCing.  And would
that be approachable enough for new members?  Are we ok with receiving
emails in markdown?  Emails sent to the list magically appear in the
right place on the web-interface, so long as the In-Reply-To header
is kept intact.

Honestly I wonder if anything with a "tree-like structure" will
intimidate users...maybe if one could bookmark one's position in the
thread it would be ok, but frankly when I look at the tree structure for
long complex threads I usually think "I don't have time for this" or
"making sense of this is too much work".

And if there's a stigma against repeating arguments/sentiments/info,
then there's also an implicit requirement to read the whole thread
before replying.  IMHO that's the biggest barrier to participation, but
on the other hand notice how many near-identical replies are found in
different branches of a sub-reddit...

BTW, would there be any value in a web-thing poll that sends out a
once-daily results to the thread?  The idea being it's a "me too" reply
option without the stigma.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Samuel Henrique]

On Wed, 2 Oct 2019 at 10:48, Mathias Behrle  wrote:

> ...BTW no discussion tool can help in automating
> separate discussion threads when the topic changes.
>

They can, I think reddit and hackernews are good at this.
That's the "tree-like" structure that I mentioned in my email.


> You will definitely lose me when I am forced to enter such an online
> platform to
> follow and participate in discussions.
>

I am 100% sure that there will be people saying they won't interact anymore
if
$something changes, and there will also be people who will actually stop
interacting if it happens, and there will also be people that say they don't
interact because of the current situation, and there will be people who will
start interacting if we address it.

It's impossible to do anything with 100% approval on Debian, and I think
when we discuss about this we are talking about trading off receiving
new contributors to the project over keeping the current ones.

Both things are bad: losing current contributors and not being able to get
new ones, due to the tools we use. So I'm not saying that we should
totally ignore one of them.

I just want to point to the fact that we need to be careful when people
start saying they will stop interacting/leave if something changes
because on the other side there are new contributors that don't join
because of it and we need to balance both.

And I mean, this is not news, almost everyone outside of Debian
that I talk to have this idea that "Debian uses old and bad tools"
for communications, bug reporting, and etc.

I don't consider our situation to be bad as some people say,
I'm here and overall happy after all, but there's definitely
room for improvement.

Regards,

-- 
Samuel Henrique 

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Holger Levsen]

On Wed, Oct 02, 2019 at 11:30:58AM +0200, Mathias Behrle wrote:
> first of all it would help a lot to identify when a new subthread is
> openend and make this visible in the usual way (like this mail does). It would
> increase a lot(!) the readability of Debian lists where this is an
> often encountered problem. BTW no discussion tool can help in automating
> separate discussion threads when the topic changes.

very true. and i'm very sceptical people will manage this. currently
most writers are already unable to avoid cc:ing when replying to list mails
even though this is against our rules which is especially ironic (and 
depressing) when talking about respect and consensus...

[discourse] 
> You will definitely lose me when I am forced to enter such an online platform 
> to
> follow and participate in discussions.

I guess I will also not participate in discussions using online tools.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Discussion tooling (was: Bits from the DPL (August 2019))

[Mathias Behrle]

* Jeremy Stanley: " Re: Bits from the DPL (August 2019)" (Tue, 1 Oct 2019
  20:45:35 +):

Hi,

first of all it would help a lot to identify when a new subthread is
openend and make this visible in the usual way (like this mail does). It would
increase a lot(!) the readability of Debian lists where this is an
often encountered problem. BTW no discussion tool can help in automating
separate discussion threads when the topic changes.

This subthread started on the question how legitimate it is to assume consensus
with the repect to the fact of the high volume of the last months, affording a
lot of time to read and of course even much more to participate. While I am
very thankful to Sam to invest his energy in driving those important
discussions I agree, that the pure volume of the different, sometimes parallel
topics exceeds at least the time I could invest to participate and I assume the
same for other fellow developers. Finally we are responsible to take care of
our packages and that is what I am prioritizing over discussion as long as I
don't feel a very strong need to say something.

Meanwhile we are at the often introduced question if better tooling could help.
I don't think another tool can save a lot of time. We *ourselves* can help
that with more discipline in following the good old rules in marking subthreads
when they are going offtopic. Finally the scheduling of the different topics
led partly to the fact that only quite few members could participate. This will
be a constant problem in a project of volunteers and I think we will have to
live with that fact.


> On 2019-10-01 16:13:03 -0400 (-0400), Sam Hartman wrote:
> > A couple of people active in Gnome have suggested discourse for
> > this sort of thing. It's got enough email integration that perhaps
> > we would not lose people who want that interface.
> > 
> > I t would be interesting if someone wanted to spend the time to
> > pilot that.  
> 
> Discourse is a Web forum platform with some mailing list features
> bolted on. An alternative might be Mailman 3, which is a mailing
> list platform with Web forum features bolted on. Both suffer from
> the same problem though, which is that people who want to interact
> via Web forums and people who want to interact via mailing lists
> have preferences for different communication styles with some
> fundamental incompatibilities, particularly where the relative
> culture and etiquette of those diverge.

Adding to that it is not easy to respond to discourse threads in the correct
quoting style and format via email. It is even not comfortable to read them
via mail. This problem seems to lead to the prefered configuration of Discourse
to only send emails, but disable answering.

You will definitely lose me when I am forced to enter such an online platform to
follow and participate in discussions.


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Bits from the DPL (August 2019)

[Salvatore Bonaccorso]

Hi Sam!

First of all thanks for your work you do as DPL, you put a lot of
energy, time and enthusiasm in it, and this is very visible!

On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote:
> > "Holger" == Holger Levsen  writes:
> 
> 
> Holger> So to me this is more the consensus of those with the
> Holger> priveledge to read, process and repond to this mailinglist,
> Holger> yet there are many more people packaging software in Debian.
> 
> I'd say it is a consensus of those who prioritize participating in this
> discussion enough to do so, consented to by the rest of the project.
> If we get it sufficiently wrong people in the broader community will let
> us know.

I noticed the above, and while I'm usually rather silent on the
mailinglist I though it might be good to comment as well from my veryp
ersonal point of view.

For me it would be important to keep on track on new stuff happening
in Debian, but on the other side I have to admit that given the free
time is limited, even though the above, I rather prefer to work on the
things I'm in directly, are already quite involving and the free time
is not infinite. This does not mean that I would agree on such
conclusions, but rather in the light of what I have just written, that
I need to prioritize and simply do not have time to be involved in
these discussions (and not all are native english speakers).

I regularly just need to mark threads as read, which would be
important to follow, or longisher mails, because of lack of the needed
time to dedicate as well for that.

Regards,
Salvatore

Re: Bits from the DPL (August 2019)

[Vincent Bernat]

 ❦  2 octobre 2019 05:47 +02, Jean-Philippe MENGUAL :

> An idea: establishing a time of discussion. At the end, if there is not
> consensus (as Gitlab), there is not. If there is, ensuring every DD can
> still have an opinion via GR or changes proposals in some guidelines
> (Debian Policy, etc). While mails are too much and so long to be
> followed by "silent" DDs, no DD can ignore a GR or a change in the
> guideline, or he is respnosible. Would help for ensuring a full
> consensus, limiting some repeats mails. We do his successfully for DPL
> election.

If a consensus is needed on debian-devel@ldo to get to the next step, we
will never have it. When was the last time we did get a consensus here?
-- 
Whenever you find that you are on the side of the majority, it is time
to reform.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Jean-Philippe MENGUAL]

Hi,

An idea: establishing a time of discussion. At the end, if there is not
consensus (as Gitlab), there is not. If there is, ensuring every DD can
still have an opinion via GR or changes proposals in some guidelines
(Debian Policy, etc). While mails are too much and so long to be
followed by "silent" DDs, no DD can ignore a GR or a change in the
guideline, or he is respnosible. Would help for ensuring a full
consensus, limiting some repeats mails. We do his successfully for DPL
election.

Regards



Jean-Philippe MENGUAL
Le 01/10/2019 à 23:12, Bernd Zeimetz a écrit :
> 
> 
> On 10/1/19 3:57 PM, Sam Hartman wrote:
> 
>> What would be more useful than this criticism  is concrete advice on how
>> I can shorten them while still accomplishing my goals.
> 
> after flying over your d-d-a mail again, my suggestion:
> 
> - create a blog post for each point you are discussing
> - summarize that post in 3-4 lines and add a link to the blog post.
> - send that to d-d-a.
> 
> That will
> - give people an overview of what you are doing without spending lots of
> time on it.
> - those who want to know the details can read your blog posts
> 
> If you really want to send everything by mail:
> 
> - create a tl;dr with the summaries on top.
> - interested parties can still read the long version below and reply to
> it. Although that will be annoying to follow as those replies will
> handle more than one topic...
> 
> 

Re: Bits from the DPL (August 2019)

[Bernd Zeimetz]

On 10/1/19 3:57 PM, Sam Hartman wrote:

> What would be more useful than this criticism  is concrete advice on how
> I can shorten them while still accomplishing my goals.

after flying over your d-d-a mail again, my suggestion:

- create a blog post for each point you are discussing
- summarize that post in 3-4 lines and add a link to the blog post.
- send that to d-d-a.

That will
- give people an overview of what you are doing without spending lots of
time on it.
- those who want to know the details can read your blog posts

If you really want to send everything by mail:

- create a tl;dr with the summaries on top.
- interested parties can still read the long version below and reply to
it. Although that will be annoying to follow as those replies will
handle more than one topic...


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

Re: Bits from the DPL (August 2019)

[Bernd Zeimetz]

On 10/1/19 3:57 PM, Sam Hartman wrote:
>> "Holger" == Holger Levsen  writes:
> 
> 
> Holger> So to me this is more the consensus of those with the
> Holger> priveledge to read, process and repond to this mailinglist,
> Holger> yet there are many more people packaging software in Debian.
> 
> I'd say it is a consensus of those who prioritize participating in this
> discussion enough to do so, consented to by the rest of the project.
> If we get it sufficiently wrong people in the broader community will let
> us know.

Several people including myself tried to do so, getting answers like
"not being part of the consensus" because mails arrive later than you
expected them.
While I think you are trying to do the right thing, the way you are
doing it is the worst I've seen in Debian so far.

> Yes, because of privilege some people can prioritize more things
> successfully.

So its privilege what counts in Debian? Not what you are doing? Or how
much time you are spending in Debian? Those, who actually do most of the
work in Debian behind the scenes, haven't been seen at all in these
discussions. Please go away with your privileges



> What would be more useful than this criticism  is concrete advice on how
> I can shorten them while still accomplishing my goals.

How can you accomplish your goals if nobody knows your goals because
nobody reads your mails till the end? Maybe because they are just not
privileged enough to have the time to do so...



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

Re: Bits from the DPL (August 2019)

[Jeremy Stanley]

On 2019-10-01 16:13:03 -0400 (-0400), Sam Hartman wrote:
> A couple of people active in Gnome have suggested discourse for
> this sort of thing. It's got enough email integration that perhaps
> we would not lose people who want that interface.
> 
> I t would be interesting if someone wanted to spend the time to
> pilot that.

Discourse is a Web forum platform with some mailing list features
bolted on. An alternative might be Mailman 3, which is a mailing
list platform with Web forum features bolted on. Both suffer from
the same problem though, which is that people who want to interact
via Web forums and people who want to interact via mailing lists
have preferences for different communication styles with some
fundamental incompatibilities, particularly where the relative
culture and etiquette of those diverge.

Discourse is not currently packaged for Debian while Mailman 3 is
(mailman3-full metapackage), though I gather that distinction makes
little difference to DSA as members have stated on multiple
occasions they prefer not to rely on Debian packaging for services
they operate.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Sam Hartman]

> "Jonathan" == Jonathan Carter  writes:


Jonathan> I try to follow debian-devel really closely, and mostly
Jonathan> manage to succeed, but this was probably the toughest
Jonathan> topics for me to follow, there's lots of repetition,
Jonathan> me-toos, posts that don't really address either the issue
Jonathan> at hand and overall, it just feels like I have to
Jonathan> fine-comb it for information and my concentration span
Jonathan> just can't handle it.

This is close enough to repeating myself that I won't do some more than
this last time, but   several people have talked about the role of the
summary in the process.  It's fine if you disagree that the summaries
are sufficient, but  I'd really appreciate it if you would acknowledge
what we've said rather than just ignoring it.

I absolutely agree especially this last thread has been a lot to
follow.  Even I haven't followed it completely enough to produce a
summary yet.
I agree with you that some cultural changes could make this last round
better.
We're all learning together.

But my job as facilitator is to follow everything and produce a summary.
Your job is to follow what you choose to follow and to see if my summary
seems reasonable given how much you follow.
If my summary doesn't seem reasonable in an area, it's worth focusing
some energy there.  That energy can include letting people know that the
summary might not be right and then having people read the relevant part
of the discussion.

You do need to follow the parts of the discussion you most care about
enough to understand and think about arguments others are making so that
people aren't talking past each other.  But it's OK if you don't follow
everything.

--Sam

Re: Bits from the DPL (August 2019)

[Jonathan Carter]

Hi Sam

On 2019/10/01 15:57, Sam Hartman wrote:
> I'd say it is a consensus of those who prioritize participating in this
> discussion enough to do so, consented to by the rest of the project.
> If we get it sufficiently wrong people in the broader community will let
> us know.
> 
> Yes, because of privilege some people can prioritize more things
> successfully.

I try to follow debian-devel really closely, and mostly manage to
succeed, but this was probably the toughest topics for me to follow,
there's lots of repetition, me-toos, posts that don't really address
either the issue at hand and overall, it just feels like I have to
fine-comb it for information and my concentration span just can't handle it.

I concur with what others have said in this thread, that we need a
better discussion culture, and I think ideally one that has respect for
the time of others.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bits from the DPL (August 2019)

[Sam Hartman]

A couple of people active in Gnome have suggested discourse for this
sort of thing.
It's got enough email integration that perhaps we would not lose people
who want that interface.

I t would be interesting if someone wanted to spend the time to pilot
that.

Re: Bits from the DPL (August 2019)

[Samuel Henrique]

>
> Am I really expected to add a "me too" response every time I agree with
> what
> someone else took the time to write... making it harder for people with
> limited
> time to follow? This seems especially cruel to those that don't speak
> English
> natively, and those that rely on translation services.
>

I can't help but feel we should be using better tooling for discussions.
There are various cases where I would like to +1 but I know this is frowned
upon
when dealing with email threads.

I feel much more committed to Debian than to hackernews, although I
participate
much more in discussions there than in Debian ones.

If we remove the fact that these tools are proprietary/not-accessible,
event the worst
social networks are better at doing forum type discussions than email
threads.

The ability to +1 without having to add something substantial to the
discussion,
the ease to see all the subthreads (sub discussions) without having to dig
into
the mail box trying to figure it out which one is about what, and the
centralization
of the discussion in a "tree like" structure are things that I miss a lot
here.

Here's me hoping that somebody has the time to propose some solution
for this problem that doesn't fall into N subthreads that most of the people
don't even bother trying to find or give up participating because they can't
just "+1".

Regards,

-- 
Samuel Henrique 

Re: Bits from the DPL (August 2019)

[Sam Hartman]

> "Michael" == Michael Lustfield  writes:

Michael> On Tue, 1 Oct 2019 14:32:10 +
Michael> Holger Levsen  wrote:

>> On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote:
>> > I'd say it is a consensus of those who prioritize participating
>> in this > discussion enough to do so, consented to by the rest of
>> the project.
>> 
>> I'm sorry, but I disagree. Silence is not always consent.



Michael> When it comes to things like forcing the use of Debian's
Michael> Gitlab (& other topics), I've remained silent because my
Michael> disagreement was already voiced by others, with more
Michael> detailed reasoning than I would have provided.

Makes sense.

And for this specific issue, there is no consensus in favor of forcing
anyone to use Debian's Gitlab.

Michael> Am I really expected to add a "me too" response every time
Michael> I agree with what someone else took the time to
Michael> write

If you think the discussion is trending in a direction you disagree
with, speaking up can often help.  But it is fine for you to wait for
the summary.  If you think that whoever posts the summary has misread
the consensus of the community having the discussion, then yes please
write in.

--Sam

Re: Bits from the DPL (August 2019)

[Michael Lustfield]

On Tue, 1 Oct 2019 14:32:10 +
Holger Levsen  wrote:

> On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote:
> > I'd say it is a consensus of those who prioritize participating in this
> > discussion enough to do so, consented to by the rest of the project.  
> 
> I'm sorry, but I disagree. Silence is not always consent.

^ 100% agreed- silence does not mean consensus/consent

When it comes to things like forcing the use of Debian's Gitlab (& other
topics), I've remained silent because my disagreement was already voiced by
others, with more detailed reasoning than I would have provided.

Am I really expected to add a "me too" response every time I agree with what
someone else took the time to write... making it harder for people with limited
time to follow? This seems especially cruel to those that don't speak English
natively, and those that rely on translation services.

-- 
Michael Lustfield

Re: Bits from the DPL (August 2019)

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> You might separate your detailed, narrative descriptions of
Sean> how discussions went from what you took away from the
Sean> discussions.  You could either drop the former, or put it in a
Sean> "read this if you want more details" section.

I've found that if you do that, people get surprised and upset when it
is not obvious how you got to a decision.  Basically I've found that
enough people are upset without a narrative that you get much more
overall mail and less confidence in the process without.

I do organize my mail so people can skip sections, and I do try to
consistently put the conclusions after the narrative.

--Sam

Re: Bits from the DPL (August 2019)

[Enrico Zini]

On Tue, Oct 01, 2019 at 02:32:10PM +, Holger Levsen wrote:

> On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote:
> > I'd say it is a consensus of those who prioritize participating in this
> > discussion enough to do so, consented to by the rest of the project.
> I'm sorry, but I disagree. Silence is not always consent.

I understand this is why we have multiple rounds of discussion with
summaries inbetween.

I personally do not see the length of discussions as much of an issue
for consent here. My main worry would be the level of potential
heat that I need to accept I have to deal with, if I choose to
participate in a discussion.

I notice that it takes me a significant amount of self esteem to send
mail to a debian list, and not everyday I have it. The thing is, if
people generally approve of what I write, the feedback I usually seem to
get is mostly silence. If someone, even just one person over many, has
an issue with it, then I get criticism.

If I say something that 1000 people like and one person hates, the
net visible effect in my inbox is probably one angry reply.

I think this could still work if the criticism were polite and
constructive. Some people in Debian disagree in a way that is pure
pleasure to read, as they bring new scope and possibilities to a
discussion.

We however have frequent examples of feedback that can be very harsh[1],
or passive aggressive and not really constructive, and I need to accept
that if I post to a Debian list, I expose myself to that.

So, as long as long threads are summarised and the summary has a round
of review, I don't see a problem with mail or thread length in consensus
building.

I rather see a challenge in building a discussion culture where people
actually feel good in participating, both in reading, and in writing
when they have something to ask or say.


Enrico

[1] recent examples off the top of my head:
https://lists.debian.org/debian-devel/2019/09/msg00365.html
https://lists.debian.org/debian-devel/2019/09/msg00366.html
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Holger Levsen]

On Tue, Oct 01, 2019 at 09:57:38AM -0400, Sam Hartman wrote:
> I'd say it is a consensus of those who prioritize participating in this
> discussion enough to do so, consented to by the rest of the project.

I'm sorry, but I disagree. Silence is not always consent.
 

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Holger Levsen]

On Tue, Oct 01, 2019 at 07:21:20AM -0700, Sean Whitton wrote:
> May I ask whether you review your d-d-a e-mails, specifically with an
> eye to brevity, before sending them out?  Given how many people read
> them, time invested in editing for brevity would be well spent.

that.

> You might separate your detailed, narrative descriptions of how
> discussions went from what you took away from the discussions.  You
> could either drop the former, or put it in a "read this if you want more
> details" section.

and that.

Thanks, Sean.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Sean Whitton]

Hello Sam,

On Tue 01 Oct 2019 at 09:57AM -04, Sam Hartman wrote:

> Holger> And then, 'spreading to more places' reminds me of another
> Holger> critisism I have with your reports: they are too long. :-D
>
>
> What would be more useful than this criticism  is concrete advice on how
> I can shorten them while still accomplishing my goals.

May I ask whether you review your d-d-a e-mails, specifically with an
eye to brevity, before sending them out?  Given how many people read
them, time invested in editing for brevity would be well spent.

You might separate your detailed, narrative descriptions of how
discussions went from what you took away from the discussions.  You
could either drop the former, or put it in a "read this if you want more
details" section.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Sam Hartman]

> "Holger" == Holger Levsen  writes:


Holger> So to me this is more the consensus of those with the
Holger> priveledge to read, process and repond to this mailinglist,
Holger> yet there are many more people packaging software in Debian.

I'd say it is a consensus of those who prioritize participating in this
discussion enough to do so, consented to by the rest of the project.
If we get it sufficiently wrong people in the broader community will let
us know.

Yes, because of privilege some people can prioritize more things
successfully.

Holger> I'm not sure what to take from this observation.(!) (Because
Holger> obviously it's good to have this discussion and try to find
Holger> out what the consensus is on debian-devel@l.d.o.) Maybe just
Holger> that the information about this discussion happening should
Holger> be spread to more places and/or maybe rather that this
Holger> discussions should be given more time.

I think giving things more time makes sense.  Looking at where we are
now, let's try to get a summary of the round 2 discussion out within
October.  Let's try to have the maintainer branch/upstream discussions
in November or December, with the understanding that we may need to
spread things out more given holidays.

Holger> And then, 'spreading to more places' reminds me of another
Holger> critisism I have with your reports: they are too long. :-D


What would be more useful than this criticism  is concrete advice on how
I can shorten them while still accomplishing my goals.
--Sam

Re: Bits from the DPL (August 2019)

[Holger Levsen]

Dear Sam,

first of all, many thanks for writing these 'Bits from the DPL' mails
regularily, much appreciated!

On Wed, Sep 18, 2019 at 04:46:14PM -0400, Sam Hartman wrote:
> Git Packaging
> =
[...]
> The discussion generated enough mail that I have not yet found time to
> issue a consensus call.  Here are some of the results I'm fairly sure
> of:
[...] 
> I expect to start discussions on maintainer branch format and upstream
> tarballs in early October.

I believe you are missing a crucial detail here, that is, this
discussion spawned like 300 emails in August and September and that many
(too many?) people are not able to follow such big discussions in such a
timespan. IOW: I believe your consensus is build on much weaker ground
than I believe you believe.

So to me this is more the consensus of those with the priveledge to
read, process and repond to this mailinglist, yet there are many more
people packaging software in Debian.

I'm not sure what to take from this observation.(!) (Because obviously
it's good to have this discussion and try to find out what the consensus
is on debian-devel@l.d.o.) Maybe just that the information about this
discussion happening should be spread to more places and/or maybe rather
that this discussions should be given more time.

And then, 'spreading to more places' reminds me of another critisism I
have with your reports: they are too long. :-D (I wonder if I'm the
first to say that...)
You might not notice this or dont think its bad, but long emails are hard 
for people with a little of time and are harder to comprehend for non-native
speakers, esp. those with little time. 

(If you dont believe me and if you use notmuch, search for 
'to:debian-devel-announce subject:DPL', DPL summaries used to be roughly
half as long.)

And of course this is not a problem per se, but it has an impact on who
is able to participate in these discussions. I spent a long time on
email and still I decided to not have the bandwidth to participate in
this git packaging discussion anymore. And I ment to write this email
since two weeks.)

HTH, really.

> Feedback
> ==
> 
> As always, feedback is welcome.  Please don't hesitate to reach out to
> lea...@debian.org.

Thanks & sorry, I'd rather have this discussion in pubcic.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Bits from the DPL (August 2019)

[Mo Zhou]

On 2019-09-24 07:34, Martin Steigerwald wrote:
> Dear Mo.
> 
> Mo Zhou - 24.09.19, 04:58:06 CEST:
>> For desktop users, non-systemd init plus a mordern desktop environment
>> such as Plasma or Gnome would be impossible on Debian, as they depend
>> on systemd. Some other distro such as Gentoo and FreeBSD have somehow
>> removed the systemd dependency for Gnome but I'm sure how much amount
>> of patchwork is required.
> 
> This is clearly not true with current Debian Sid (and a little glue 
> package from experimental at the moment). This laptop is testimony to 
> that. I am writing this with KMail on a KDE Plasma desktop and no 
> systemd / libsystemd packages installed, using sysvinit instead. It is 
> running like this for *months* already.
>
> They depend on systemd-logind which can be replaced by elogind – 
> actually that is a huge part of the discussion in this thread, did you 
> actually *read* it? elogind as I remember is coming from Gentoo / BSD 
> efforts. And I am not sure whether KDE Plasma really depends on it or 
> whether it could still be used with ConsoleKit 2, which may not really 
> be maintained anymore I read somewhere.
> 
> However I did not test GNOME myself, but saw reports of Devuan users 
> that it works. And if it works in Devuan it likely would work with 
> Debian as well, as Devuan developers work on the necessary packages 
> within Debian in the debian-init-diversity initiative.
> 
> Please do not spread rumors on the state of what is possible in Debian 
> if you did not test for yourself. Thank you.

Ok. Previous post was about my observation in Jan/Feb this year,
which only works for Buster but not the current Sid. I didn't
read the threads so sorry for the discrepancy and my obsolete
comment.

Re: Bits from the DPL (August 2019)

[Martin Steigerwald]

Dear Mo.

Mo Zhou - 24.09.19, 04:58:06 CEST:
> For desktop users, non-systemd init plus a mordern desktop environment
> such as Plasma or Gnome would be impossible on Debian, as they depend
> on systemd. Some other distro such as Gentoo and FreeBSD have somehow
> removed the systemd dependency for Gnome but I'm sure how much amount
> of patchwork is required.

This is clearly not true with current Debian Sid (and a little glue 
package from experimental at the moment). This laptop is testimony to 
that. I am writing this with KMail on a KDE Plasma desktop and no 
systemd / libsystemd packages installed, using sysvinit instead. It is 
running like this for *months* already.

They depend on systemd-logind which can be replaced by elogind – 
actually that is a huge part of the discussion in this thread, did you 
actually *read* it? elogind as I remember is coming from Gentoo / BSD 
efforts. And I am not sure whether KDE Plasma really depends on it or 
whether it could still be used with ConsoleKit 2, which may not really 
be maintained anymore I read somewhere.

However I did not test GNOME myself, but saw reports of Devuan users 
that it works. And if it works in Devuan it likely would work with 
Debian as well, as Devuan developers work on the necessary packages 
within Debian in the debian-init-diversity initiative.

Please do not spread rumors on the state of what is possible in Debian 
if you did not test for yourself. Thank you.

Of course another question would be whether such a setup would be 
supported by upstream developers or by package maintainers. For KDE 
upstream developers I am pretty confident that they would accept bug 
reports from users of such setups.  They are at least semi-officially 
supporting FreeBSD. For many bug reports it would not even matter what 
is running as PID 1. Similar goes with Debian/Kubuntu Qt/KDE team, I 
believe they would at least look at bug reports from users with of a 
different PID 1 than systemd. I did not ask them yet, so, of course this 
is only my own guessing for now.

Of course there is an increased risk that with an alternative init 
system you are a more likely being asked to keep the pieces in case 
something breaks. But I am prepared for that. I know my way with Linux 
enough in order to deal with such situations.

Best,
-- 
Martin

Re: Bits from the DPL (August 2019)

[Mo Zhou]

Hi,

On 2019-09-23 23:29, Sam Hartman wrote:
> Samuel> I'm not saying maintainers should spend time on maintaining
> Samuel> init files etc. but at least leave room for people who want
> 
> Obviously if we had a vote the project could choose to agree with you or
> not.

FYI, two important things to mention for current non-systemd Debian
users:

In Jan or Feb 2019 I did a lot of tests in virtualbox to switch from
systemd to sysvinit (or openrc). Init switching is still working well,
but apparently, services of which maintainers had decided to drop
the non-systemd support were somewhat out-of-control. For example,
the systemd-only ZFS package won't automatically mount ZFS pools
on boot by starting the corresponding services. That said, the
most important services were still within control.

For desktop users, non-systemd init plus a mordern desktop environment
such as Plasma or Gnome would be impossible on Debian, as they depend on
systemd. Some other distro such as Gentoo and FreeBSD have somehow
removed the systemd dependency for Gnome but I'm sure how much amount
of patchwork is required.

With that being said, I still agree with Samuel. If there would be a
vote, I'd vote for the anti-systemd-monopoly side.

Re: Bits from the DPL (August 2019)

[Sam Hartman]

> "Samuel" == Samuel Thibault  writes:

Samuel> Hello, Sam Hartman, le mer. 18 sept. 2019 16:46:14 -0400, a
Samuel> ecrit:
>> We could stop caring about sysvinit (which isn't quite the same
>> thing but is related).  That would leave non-linux ports in an
>> unfortunate position.  But right now there are no non-linux ports
>> in the main archive.  So perhaps we don't even care about that.

Samuel> Not being in the main archive does _not_ mean we don't care
Samuel> about it.

What I'm trying to say is that were the project to drop sysvinit, it
would make things harder for the non-Linux ports.

I think that if there were any non-Linux ports in the main archive, the
project should either keep sysvinit or remove the non-Linux ports from
the main archive when it dropped sysvinit.

I think you've done a good job of summarizing the argument in favor of
caring about the non-Linux ports:


Samuel> A problem with sticking to systemd only is that it means
Samuel> sticking to linux only, and not leaving any room for any
Samuel> alternative, since systemd is not to be seen ported on any
Samuel> non-linux.  I don't think we want to care only about linux,
Samuel> for various reasons.

Samuel> I'm not saying maintainers should spend time on maintaining
Samuel> init files etc. but at least leave room for people who want

Obviously if we had a vote the project could choose to agree with you or
not.

Re: Bits from the DPL (August 2019)

[Samuel Thibault]

Hello,

Sam Hartman, le mer. 18 sept. 2019 16:46:14 -0400, a ecrit:
> We could stop caring about sysvinit (which isn't quite the same thing
> but is related).  That would leave non-linux ports in an unfortunate
> position.  But right now there are no non-linux ports in the main
> archive.  So perhaps we don't even care about that.

Not being in the main archive does _not_ mean we don't care about it.

It only means that non-linux are not on par with e.g. hardware support
or security support compared to the mainstream linux ports, so we can't
claim they have the same quality as the released archs, that's all.

A problem with sticking to systemd only is that it means sticking to
linux only, and not leaving any room for any alternative, since systemd
is not to be seen ported on any non-linux.  I don't think we want to
care only about linux, for various reasons.

I'm not saying maintainers should spend time on maintaining init files
etc. but at least leave room for people who want to do it.

Samuel

Re: Bits from the DPL (August 2019)

[John Goerzen]

On Thu, Sep 19 2019, Bálint Réczey wrote:
> I would like to just remind ourselves that in WSL and Docker
> containers systemd is not running as the init system and systemd
> services can't be started easily but init.d scripts can be.

FWIW, with buster, systemd becomes possible in unprivileged docker
containers, and I use it extensively in my debian-base-* images:

https://hub.docker.com/r/jgoerzen/debian-base-standard

- John

Re: Bits from the DPL (August 2019)

[Jonathan Carter]

On 2019/09/19 11:18, Martin Steigerwald wrote:
> I also feel sad cause I saw the enormous efforts of Devuan and Debian  
> people as well as the new Sysvinit upstream maintainer to improve the 
> quality of sysvinit, startpart, insserv, runit, openrc you name them 
> packages and to actually introduce elogind to Debian. The great care, 
> the willingness to cooperate, the willing to step over own shadows into 
> light… all of this in vain?

FWIW, I don't think any of these efforts are in vain at all. Running
alternative (alternative as in, not the default) init systems on Debian
is easier now than it was when stretch was released. I've been trying
out runit in containers and it seems to be working really well for my
use cases (a lot lighter than systemd and does everything I want it to).
I'm also a bit curious about openrc and tini and either way I think
these are important for our non-linux kernels too (which some people
seem to like snuffing at but they are actually important).

I appreciate the work that all the people have been doing to help
preserve the possibility of having an init system other than systemd,
and I'm sure there are many Debian users who are probably not on this
list that feel the same way.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bits from the DPL (August 2019)

[Bálint Réczey]

Hi,

Sam Hartman  ezt írta (időpont: 2019. szept. 18.,
Sze, 22:47):
>
>
> Dear Debian:
>
...
> Init System Diversity
> =
..
> Honestly, I'm not entirely sure how to move forward.  Perhaps it's just
> that I haven't talked to someone I need to.  Perhaps someone will read
> this, and let me know that if I'd included them, we could get the right
> skills and authority engaged.  I'll feel embarrassed and we'll all move
> on if that's the case.  But I think we may be approaching a point where
> we need to poll the project--to have a GR and ask ourselves how
> committed we are to the different parts of this init diversity
> discussion.  Reaffirming our support for sysvinit and elogind would be
> one of the options in any such GR.  If that option passed, we'd expect
> all the maintainers involved to work together or to appoint and empower
> people who could work on this issue.  It would be fine for maintainers
> not to be involved so long as they did not block progress.  And of
> course we would hold the discussions to the highest standards of
> respect.
>
> Things may have changed since our last GR on the issue.  There are 1033
> non-overridden instances of lintian detecting a service unit without an
> init.d script [7].  The false positive rate seems high especially for
> packages that break their systemd integration.  There's been discussion
> on debian-devel about moving to using service units as the default
> rather than init scripts [8].
>
> So perhaps sysvinit and init scripts have had their chance and it is
> time to move on.  We could move away from init scripts as the default
> representation.  We could stop caring about sysvinit (which isn't quite
> the same thing but is related).  That would leave non-linux ports in an
> unfortunate position.  But right now there are no non-linux ports in the
> main archive.  So perhaps we don't even care about that.  Again, a
> change, but a change that we can ask ourselves if we are ready to make.

I would like to just remind ourselves that in WSL and Docker
containers systemd is not running as the init system and systemd
services can't be started easily but init.d scripts can be.
There is very significant interest from users to run services easily
in those and other similar environments and dropping init.d scripts
would make their life much harder.
I do see that maintaining init.d scripts is work but speaking for
myself I'm happy to maintain them
in my packages even when I use those packages only with systems running systemd.

My two cents is that in init system diversity decisions please
consider the environments where none of our packaged init systems are
running, but which are perfectly capable to run useful services.

Cheers,
Balint

...
>   [7]:
>   
> https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html
>   [8]: 
> https://lists.debian.org/msgid-search/87h86qvh1q@proton.d.airelinux.org
...

PS: I marked #856268 as wontfix before sending this email to debian-devel.
https://balintreczey.hu/blog/my-debian-devel-pledge

Re: Bits from the DPL (August 2019)

[Martin Steigerwald]

Hi Sam!

I took long time to write this even on still recovering from a pace in 
my life that feels too quick for me. But I intended this to be carefully 
worded in order to not hurt anyone. I hope I succeeded. My invitation: 
Before taking anything personal and making the choice to feel hurt about 
it, please talk to me so we can see to resolve this. I have written this 
with the best intentions as best I can.

Sam Hartman - 18.09.19, 22:46:14 CEST:
> And yet the systemd maintainers and to a lesser extent release team
> face conduct that is frankly unacceptable.  And in some cases that
> conduct is the frustrated reaction to years of interactions complex
> enough that we'll never untangle them.  No matter how unfortunate the
> conduct is, the frustrations, anger and hurt are real.
> 
> I want to stress that I can understand both sides here.  If I were
> maintaining systemd I know I'd be absolutely done dealing with some
> people who have been involved in this discussion. If I were trying to
> get an alternate init system to continue to work, I'd be really
> frustrated.  I'm not in either of those roles, and I do not fully
> understand either side's needs or feelings, but I can understand how
> we got here as a project.

As someone who engaged with the Devuan project people after a longer 
time of observing whether they are serious about it, as someone who made 
friends with them and as someone who helped to facilitate a peaceful and 
friendly cooperation between Devuan and Debian people, a cooperation 
that has been so very much fruitful and filled with the best intentions, 
and after seeing all the wonderful work of the people from the Debian 
init diversity sub project that started as a result of the decision to 
cooperate, I feel really sad after reading your above comment.

Cause it already contains a deep designation in "years of interactions 
complex enough that we will never untangle them". I see it here and 
elsewhere that the running away from moving through conflicts in a 
beneficial way for everyone involved for whatever good and understandable 
reason hurts freedom in how to use free software and more importantly 
harms communities. In conflicts there are often two, maybe three patterns 
involved:

1) Attacking and be aggressive.

2) Running away, 

3) Freeze.

Silent or not so silent resignation may be between 2 and 3.

Yet all of them stem from a time where conflicts often meant survival or 
death for a living human being. However… here is no physical survival in 
danger. *Not at all*. And conflict with all the confusion that comes with 
it is part of facilitating and creating something new and better for all 
involved. Humankind needs this in a much, much, much broader scope also 
when it comes to climate change, diversity of animals and plants and in 
general in how we treat other other and the planet.

I feel sad about giving up to use this chance to mature in how we 
interact with one another in order bring forth an even better Debian 
universal operating system than before.

I feel also sad cause I wonder whether all my meditation efforts back 
then have been in vain – all those long, carefully written mails in 
order ensure to not hurt anyone, for nothing?

Well, I bet they haven't, whatever will happen now, there will be a 
benefit. And I feel sad cause I see the running away from moving through 
conflict in a beneficial way is hurting the free software community in a 
much much greater scale in other communities as well. I was happy to see 
user space and kernel space developers talking to one another again 
about the intricacies of entropy in Linux and computers in general. 
Maybe one of my mails in that thread on LKML and other Linux kernel 
related mailing lists helped to encourage and facilitate that.

I also feel sad cause I saw the enormous efforts of Devuan and Debian  
people as well as the new Sysvinit upstream maintainer to improve the 
quality of sysvinit, startpart, insserv, runit, openrc you name them 
packages and to actually introduce elogind to Debian. The great care, 
the willingness to cooperate, the willing to step over own shadows into 
light… all of this in vain?

Again, I believe there will be a benefit, what ever the outcome of the 
discussion or decision making process you just started, Sam, will be.

And to me, most of it, is not a technical issue. It is a people talking 
with each other soft skill related issue. I am so happy to see that in 
KDE community there have been teachings about non violent communications 
recently.

It is not just technical. It never was just technical.

No amount of technical excellence which there is many to find with the 
people involved, is going to resolve this. 

Talking to, talking *with* each other can.

And if hurt can be created, healing of hurt can be created as well.

All can heal.

That is my conviction. I even have a lot of constructive ideas, but 
ultimately they all require willingness to engage.

We have enough tech

Re: Bits from the DPL (August 2019)

[Evilham]

On dj., set. 19 2019, Jerome BENOIT wrote:


On 19/09/2019 00:46, Sam Hartman wrote:


Init System Diversity
=


So perhaps sysvinit and init scripts have had their chance and 
it is
time to move on.  We could move away from init scripts as the 
default
representation.  We could stop caring about sysvinit (which 
isn't quite
the same thing but is related).  That would leave non-linux 
ports in an
unfortunate position.  But right now there are no non-linux 
ports in the
main archive.  So perhaps we don't even care about that. 
Again, a
change, but a change that we can ask ourselves if we are ready 
to make.


This does not look as diversity.

Otherwise I am very surprise that Devuan was not mention at all.
May be it is time to work with the Devuan team and merge Devuan 
to Debian.



As someone involved in Devuan: please don't pull it into this.

Sam's *full* message, and not just the bit you quoted, is what 
*Debian* needs, which is what his current role asks for.


Mark (elogind's developer) works closely with Devuan but in 
general over there, there is consensus that whatever changes are 
worth having in Debian should happen in Debian whenever possible, 
which is where it has the greatest impact, and that is what this 
is about: determining if it is possible and desirable for Debian 
that this particular bit *also* happens in Debian.


And that truly has nothing to do with Devuan or what people think 
of it.

--
Evilham

Re: Bits from the DPL (August 2019)

[Sam Hartman]

> "Jerome" == Jerome BENOIT  writes:

Jerome> On 19/09/2019 00:46, Sam Hartman wrote:

>> Init System Diversity =
Jerome> 
>> So perhaps sysvinit and init scripts have had their chance and it
>> is time to move on.  We could move away from init scripts as the
>> default representation.  We could stop caring about sysvinit
>> (which isn't quite the same thing but is related).  That would
>> leave non-linux ports in an unfortunate position.  But right now
>> there are no non-linux ports in the main archive.  So perhaps we
>> don't even care about that.  Again, a change, but a change that
>> we can ask ourselves if we are ready to make.

Jerome> Otherwise I am very surprise that Devuan was not mention at
Jerome> all.  May be it is time to work with the Devuan team and
Jerome> merge Devuan to Debian.

Devuan developers have been working with Debian to reduce the number of
differences.  Several of the people involved in these discussions have
been Devuan developers as well as members of this community.  I think a
couple might even call themselves Devuan rather than Debian, although
when you send that many messages to Debian bugs and lists, I personally
think you're part of the Debian community too.

I have explicitly been working with people in the Devuan community.  But
it's never come up whether they represent Devuan.  They were
constructively working to solve problems in both distributions so I
worked with them.

Jerome> This does not look as diversity.

What is diversity?

Is diversity about being able to develop new software?  Is it about
trying new things, trying to build better init systems over time?  Is it
about trying to consider solutions to the things people don't like about
systemd?
If that's diversity, sysvinit isn't very interesting.  The design of
sysvinit has not evolved and changed significantly.  It has not learned
from the mistakes of systemd.  It's interface has been static for years.

Or is diversity because you actually want to be using sysvinit.  If the
entire point of your interest in diversity is that static interface,
then sysvinit is  interesting to you in the diversity argument.

We can judge the second category of users based on who actually uses
sysvinit.  And honestly, that's not a lot of Debian users.  Some of them
have probably migrated to Devuan or other distros.  Many have realized
that systemd actually can meet their needs.  But for whatever reason,
not a lot of people use sysvinit on Debian.

And honestly, a lot of these technical problems get more complicated
because we want to be able to swap out implementations.  Elogind is a
lot easier to deal with if you know that your distro is always using
elogind.  Init system choice is a lot easier to deal with if you know
that you only have one init system.  Personally, I don't think there are enough
sysvinit users in Debian to justify keeping sysvinit around because
people want to use it.  If sysvinit on Linux was the only thing to
consider, I'd recommend we look at having something like Devuan be all
sysvinit and Debian be all systemd.  We could work with them as a
downstream and avoid needing to deal with the complexity of switching
init systems, libsystemd implementations, etc.


To me the question of future choice is far more interesting.  First,
current users today cannot be used as an effective argument about what
we'll do in the future.  So it's harder to answer the question.
Secondly, Debian has always put a fairly high value on enabling
experimentation and evolution.  And a significant fraction of our
community do share some of the concerns about the Systemd design
approach.

In that model, sysvinit is much more of a stub than an init system.
It's something we can run inbetween experiments as a sanity check that
things still work without systemd and that we have not locked ourselves
into systemd.  If some users actually want to run sysvinit, and it works
well for them, that's great, but at least for me personally, that is not
a priority.


Obviously some people have different values.

So, I think we have multiple questions on the table.  What is init
system diversity?  Do we want init system diversity?  What are we
willing to do to get any init system diversity we decide we want.

--Sam

Re: Bits from the DPL (August 2019)

[Jerome BENOIT]

On 19/09/2019 00:46, Sam Hartman wrote:

> Init System Diversity
> =

> So perhaps sysvinit and init scripts have had their chance and it is
> time to move on.  We could move away from init scripts as the default
> representation.  We could stop caring about sysvinit (which isn't quite
> the same thing but is related).  That would leave non-linux ports in an
> unfortunate position.  But right now there are no non-linux ports in the
> main archive.  So perhaps we don't even care about that.  Again, a
> change, but a change that we can ask ourselves if we are ready to make.

This does not look as diversity.

Otherwise I am very surprise that Devuan was not mention at all.
May be it is time to work with the Devuan team and merge Devuan to Debian.

hth,
Jerome



-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Jonathan Carter]

On 2019/08/06 09:46, Andrej Shadura wrote:
> I’m really sorry if nobody did come back to you with this, apparently
> your request fell through the cracks.

Thanks! Just received your off-list email with the details.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Andrej Shadura]

On 06/08/2019 09:44, Jonathan Carter wrote:
> On 2018/06/01 19:22, Andrej Shadura wrote:
>>> On 2018-05-31 12:33 PM, Chris Lamb wrote:
  [11] https://wiki.debian.org/MemberBenefits
>>> Oh, this reminds me of something.
>>>
>>> Has anyone gotten replies to their requests sent to
>>> debian-st...@collabora.com for the Steam subscriptions mentioned in the
>>> MemberBenefits page?
>>>
>>> I think that I have sent two mails in the past 3 years but have gotten
>>> no responses.
>>>
>>> Should we remove this benefit from the wiki page? Or do we have someone
>>> to contact about it?
>> The benefit should still be valid. The person responsible for it is
>> already looking into it, expect a reply shortly ;)
> 
> I also still haven't heard back despite having emailed a few times over
> the last 2 years, it's probably time to remove it until we hear back
> from someone who actually administers this. Perhaps someone at Collabora
> could also check there if the email alias is still going somewhere?
> 
> It's a pity because it would be nice to have access to games that use
> gamemode[1] because currently I mostly rely on users' feedback for
> testing (which is getting better now that more people use it), but I
> don't have a particular interest in buying games like the new Tomb
> Raider just to test that it invokes gamemode automatically properly,

I’m really sorry if nobody did come back to you with this, apparently
your request fell through the cracks.


-- 
Cheers,
  Andrej

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Jonathan Carter]

On 2018/06/01 19:22, Andrej Shadura wrote:
>> On 2018-05-31 12:33 PM, Chris Lamb wrote:
>>>  [11] https://wiki.debian.org/MemberBenefits
>> Oh, this reminds me of something.
>>
>> Has anyone gotten replies to their requests sent to
>> debian-st...@collabora.com for the Steam subscriptions mentioned in the
>> MemberBenefits page?
>>
>> I think that I have sent two mails in the past 3 years but have gotten
>> no responses.
>>
>> Should we remove this benefit from the wiki page? Or do we have someone
>> to contact about it?
> The benefit should still be valid. The person responsible for it is
> already looking into it, expect a reply shortly ;)

I also still haven't heard back despite having emailed a few times over
the last 2 years, it's probably time to remove it until we hear back
from someone who actually administers this. Perhaps someone at Collabora
could also check there if the email alias is still going somewhere?

It's a pity because it would be nice to have access to games that use
gamemode[1] because currently I mostly rely on users' feedback for
testing (which is getting better now that more people use it), but I
don't have a particular interest in buying games like the new Tomb
Raider just to test that it invokes gamemode automatically properly,

-Jonathan

[1] https://github.com/FeralInteractive/gamemode

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Salsa migration from foo-guest to foo [was: Bits from the DPL (May 2019)]

[Alexander Wirt]

On Fri, 07 Jun 2019, Thomas Goirand wrote:

> On 6/5/19 4:08 PM, Norbert Preining wrote:
> > This should be
> > completely independent from what one can do on salsa.
> > So I propose that whatever one's level within Debian is, it should not 
> > change the status on salsa.
> 
> I also find it surprising that the "feature" from Alioth that one has to
> completely recreate everything from an account foo-guest to just foo.
> Can't this be addressed in another way? It's *very* annoying on both
> directions (ie: non-dd -> dd or dd -> non-dd).
We will probably start doing that when we have a proper usermanagement tool
for guests in place. 

Alex
 

Re: Salsa migration from foo-guest to foo [was: Bits from the DPL (May 2019)]

[Thomas Goirand]

On 6/5/19 4:08 PM, Norbert Preining wrote:
> This should be
> completely independent from what one can do on salsa.
> So I propose that whatever one's level within Debian is, it should not 
> change the status on salsa.

I also find it surprising that the "feature" from Alioth that one has to
completely recreate everything from an account foo-guest to just foo.
Can't this be addressed in another way? It's *very* annoying on both
directions (ie: non-dd -> dd or dd -> non-dd).

Cheers,

Thomas Goirand (zigo)

Re: Bits from the DPL (May 2019)

[Alexander Wirt]

On Thu, 06 Jun 2019, Sam Hartman wrote:

> > "Bastian" == Bastian Blank  writes:
> 
> Bastian> Hi Sam
> Bastian> On Thu, Jun 06, 2019 at 11:57:41AM -0400, Sam Hartman wrote:
> >> However, it's a lot easier to get a foo-guest account on salsa
> >> than it is to get a foo guest account in Debian LDAP.
> 
> Bastian> A guest account in Debian LDAP does not get a Salsa
> Bastian> account, at least not an usable one.  Currently only users
> Bastian> in the Debian group are allowed.
> 
> No, but my understanding is that basically anyone on the internet can go
> sign up for foo-guest at salsa.
> 
> >> There are transitions like someone retiring from the project
> >> where we actually would be delighted if they continued to use
> >> salsa in some capacity.
> 
> Bastian> The largest technical problem with that is providing the
> Bastian> user with a valid e-mail address.  Apart from that we need
> Bastian> DSA to properly define states in LDAP.
> 
> OK, that's useful input.
> I do feel we're talking past each other here though.
> 
> Norbert and some other folks said they wanted salsa to behave
> differently.
> 
> Alex jumped in and said "salsa doesn't work that way."
> Sure, we all know that.
> And yet, salsa and really all of Debian can change if we want them to
> and the right we are willing to do the work.
No, I said why salsa works the way it works. If you want a special state for
"not so really disabled accounts" salsa isn't the right place to implement
that. 

Btw. nobody ever came to us and said "Hey, that account is disabled, are
there any options to behave differently". So the steps are: define how those
"not so really disabled" account should behave, implement them in udldap and
then we can adjust the syncer.

Alex



signature.asc
Description: PGP signature

Re: Bits from the DPL (May 2019)

[Alf Gaida]

> A guest account in Debian LDAP does not get a Salsa account, at least
> not an usable one.  Currently only users in the Debian group are
> allowed.Hmm - so salsa is useless at all - i don't think so. Change 
your pov and see it otherwise: A guest can open a project - all members 
of the Debian group have no saying and no rights. Some would call it 
nice and the best outcome ever. Joke aside: If i want to have any rights 
as a DM in some repositories i contribute to i had to ask for polite - 
no problem for me, as the very most people in Debian are very kind. Same 
is for Debian Developers when they want to provide to a project that was 
started by a DM - just fair, isn't it?


>> There are transitions like someone retiring from the project where we
>> actually would be delighted if they continued to use salsa in some
>> capacity.The rights to use salsa should not be coupled with the 
status as DD, DM or whatever - imho different things. The outcome is: 
People bitten by this will put their repos on github, gitlab or 
whatever. Do we really want this as a project? Imho no, if these issues 
could be solved i would go so far that i would expect that packages in 
debian are managed within debian infrastructure - SCM included.


> The largest technical problem with that is providing the user with a
> valid e-mail address.  Apart from that we need DSA to properly define
> states in LDAP.If it is only a technical problem - solve it.>
>> Making the transition from foo to foo-guest is currently incredibly
>> expensive for the person involved.
>
> Yes, it is.
>
>> This is one of the issues we will discuss later this month.  I hope the
>> salsa admins will join that discussion.
>
> Well, you could just ask.
>
> Bastian
>
Cheers Alf

Re: Bits from the DPL (May 2019)

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> Hi Sam
Bastian> On Thu, Jun 06, 2019 at 11:57:41AM -0400, Sam Hartman wrote:
>> However, it's a lot easier to get a foo-guest account on salsa
>> than it is to get a foo guest account in Debian LDAP.

Bastian> A guest account in Debian LDAP does not get a Salsa
Bastian> account, at least not an usable one.  Currently only users
Bastian> in the Debian group are allowed.

No, but my understanding is that basically anyone on the internet can go
sign up for foo-guest at salsa.

>> There are transitions like someone retiring from the project
>> where we actually would be delighted if they continued to use
>> salsa in some capacity.

Bastian> The largest technical problem with that is providing the
Bastian> user with a valid e-mail address.  Apart from that we need
Bastian> DSA to properly define states in LDAP.

OK, that's useful input.
I do feel we're talking past each other here though.

Norbert and some other folks said they wanted salsa to behave
differently.

Alex jumped in and said "salsa doesn't work that way."
Sure, we all know that.
And yet, salsa and really all of Debian can change if we want them to
and the right we are willing to do the work.

I tried to explain why some people might want a change and said I'd
bring that up as one of the points to consider.

Now you're talking about why the change would be hard.
I do think understanding the cost of a change is important, but
sometimes I also think it's helpful not to jump right to the technical
details.  Sometimes I think it might help to spend a bit of time asking
in the abstract what we want before getting micro-focused on how we'd
get it if we did.

Obviously you can't entirely separate these things.  Things cost
people's time, money, and various other things (like risk of security
compromise).
But I think sometimes it harms a discussion if you jump right to the
implementation challenges.

--Sam

Re: Bits from the DPL (May 2019)

[Bastian Blank]

Hi Sam

On Thu, Jun 06, 2019 at 11:57:41AM -0400, Sam Hartman wrote:
> However, it's a lot easier to get a foo-guest account on salsa than it
> is to get a foo guest account in Debian LDAP.

A guest account in Debian LDAP does not get a Salsa account, at least
not an usable one.  Currently only users in the Debian group are
allowed.

> There are transitions like someone retiring from the project where we
> actually would be delighted if they continued to use salsa in some
> capacity.

The largest technical problem with that is providing the user with a
valid e-mail address.  Apart from that we need DSA to properly define
states in LDAP.

> Making the transition from foo to foo-guest is currently incredibly
> expensive for the person involved.

Yes, it is.

> This is one of the issues we will discuss later this month.  I hope the
> salsa admins will join that discussion.

Well, you could just ask.

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!

Re: Bits from the DPL (May 2019)

[Sam Hartman]

> "Alexander" == Alexander Wirt  writes:

Alexander> On Wed, 05 Jun 2019, Adrian Bunk wrote:

I understand that is how it is today.
Disabling an account is something we clearly want to be able to do.


However, it's a lot easier to get a foo-guest account on salsa than it
is to get a foo guest account in Debian LDAP.

There are transitions like someone retiring from the project where we
actually would be delighted if they continued to use salsa in some
capacity.
Making the transition from foo to foo-guest is currently incredibly
expensive for the person involved.

It's reasonable for us to discuss as a community whether this is
something we want to change as part of recommending salsa more strongly.
This is one of the issues we will discuss later this month.  I hope the
salsa admins will join that discussion.  I think it would be better to
focus on what you want the state to be in the future and the
cost/requirements for any changes than to focus on where things stand
today.

--Sam

Re: Bits from the DPL (May 2019)

[Alexander Wirt]

On Wed, 05 Jun 2019, Adrian Bunk wrote:

> On Wed, Jun 05, 2019 at 10:14:50AM -0400, Sam Hartman wrote:
> > > "Norbert" == Norbert Preining  writes:
> > 
> > Norbert> I would propose something else: Debian rights are defined
> > Norbert> by presence/absence of a GPG key in certain key rings. This
> > Norbert> should be completely independent from what one can do on
> > Norbert> salsa.  So I propose that whatever one's level within
> > Norbert> Debian is, it should not change the status on salsa.
> > 
> > Well, developers are also granted rights in the debian group on salsa,
> > and that is tied to whether you are currently a developer.
> 
> But personal rights (including own repositories) do not.
If a @debian.org account is disabled in udldap it gets of course disabled in
salsa. 

Alex

Re: Bits from the DPL (May 2019)

[Alexander Wirt]

On Thu, 06 Jun 2019, Andreas Tille wrote:

> On Wed, Jun 05, 2019 at 10:14:50AM -0400, Sam Hartman wrote:
> > > "Norbert" == Norbert Preining  writes:
> > 
> > Norbert> I would propose something else: Debian rights are defined
> > Norbert> by presence/absence of a GPG key in certain key rings. This
> > Norbert> should be completely independent from what one can do on
> > Norbert> salsa.  So I propose that whatever one's level within
> > Norbert> Debian is, it should not change the status on salsa.
> > 
> > Well, developers are also granted rights in the debian group on salsa,
> > and that is tied to whether you are currently a developer.
> 
> I fully agree with Norbert.  You might argue that a developer who was
> removed from the keyring could write a script and do some harm on all
> git repositories in the debian group to take some "revenge" for becoming
> expelled.  I see no practival relevance for such a scenario.  As far as
> I understood Norberts case it was not intended to block him from
> contributing - but removing his permissions on salsa made it very hard
> for him to contribute.
> 
> I do not have any idea whether there is an easy technical implementation
> for Norberts suggestion but I'm in favour of it.
The whole group is basically ldap controlled. And in fact salsa didn't
removed any permission. The account was disabled in LDAP and therefore
disabled on salsa (which makes perfectly sense in my eyes). So unless you
create a new account state in ldap I don't see any good solution for changing
the current behaviour. Of course we want to also disable @debian.org accounts
when they are disabled in (ud)ldap.

Alex
 

Re: Bits from the DPL (May 2019)

[Andreas Tille]

On Wed, Jun 05, 2019 at 10:14:50AM -0400, Sam Hartman wrote:
> > "Norbert" == Norbert Preining  writes:
> 
> Norbert> I would propose something else: Debian rights are defined
> Norbert> by presence/absence of a GPG key in certain key rings. This
> Norbert> should be completely independent from what one can do on
> Norbert> salsa.  So I propose that whatever one's level within
> Norbert> Debian is, it should not change the status on salsa.
> 
> Well, developers are also granted rights in the debian group on salsa,
> and that is tied to whether you are currently a developer.

I fully agree with Norbert.  You might argue that a developer who was
removed from the keyring could write a script and do some harm on all
git repositories in the debian group to take some "revenge" for becoming
expelled.  I see no practival relevance for such a scenario.  As far as
I understood Norberts case it was not intended to block him from
contributing - but removing his permissions on salsa made it very hard
for him to contribute.

I do not have any idea whether there is an easy technical implementation
for Norberts suggestion but I'm in favour of it.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Bits from the DPL (May 2019)

[Adrian Bunk]

On Wed, Jun 05, 2019 at 10:14:50AM -0400, Sam Hartman wrote:
> > "Norbert" == Norbert Preining  writes:
> 
> Norbert> I would propose something else: Debian rights are defined
> Norbert> by presence/absence of a GPG key in certain key rings. This
> Norbert> should be completely independent from what one can do on
> Norbert> salsa.  So I propose that whatever one's level within
> Norbert> Debian is, it should not change the status on salsa.
> 
> Well, developers are also granted rights in the debian group on salsa,
> and that is tied to whether you are currently a developer.

But personal rights (including own repositories) do not.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bits from the DPL (May 2019)

[Sam Hartman]

> "Norbert" == Norbert Preining  writes:

Norbert> I would propose something else: Debian rights are defined
Norbert> by presence/absence of a GPG key in certain key rings. This
Norbert> should be completely independent from what one can do on
Norbert> salsa.  So I propose that whatever one's level within
Norbert> Debian is, it should not change the status on salsa.

Well, developers are also granted rights in the debian group on salsa,
and that is tied to whether you are currently a developer.

Re: Bits from the DPL (May 2019)

[Norbert Preining]

Hi,

> https://lists.debian.org/msgid-search/tsl5zpyigx4@suchdamage.org

Thanks, sounds reasonable.

> I'll take this as input that we should have better transition strategies
> for salsa when a project owner's status changes.

I would propose something else: Debian rights are defined by
presence/absence of a GPG key in certain key rings. This should be
completely independent from what one can do on salsa.
So I propose that whatever one's level within Debian is, it should not 
change the status on salsa.

> I appreciate that is unlikely to be sufficient to change your personal
> opinion, but  it is something the community should discuss.

There you are 100% correct.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Bits from the DPL (May 2019)

[Sam Hartman]

> "Norbert" == Norbert Preining  writes:

Norbert> Hi, (please Cc, not reading d-d)

Norbert> On Sun, 02 Jun 2019, Sam Hartman wrote:

Norbert> And would you be so helpful in providing a link to that
Norbert> understanding of consensus? Only posting a link to the
Norbert> start of a long thread is not really helpful.

This was an intentional choice on my part.
The summary of consensus is a tool for those who participated in the
discussion while the comment period is open.
I'll definitely post a link when we're done.

Several key factors contribute to a consensus forming discussion:

* All the participants are informed or are working to be informed

* the people are working together to try and find common ground and
address issues

It's really impossible to have that without actually participating in
the discussion and reading some significant chunk of it.

That said,
https://lists.debian.org/msgid-search/tsl5zpyigx4@suchdamage.org


>> Git on Salsa 
>> 
>> The next discussion I will drive is a discussion of whether we
>> want to strongly recommend Debian packaging be done using Git on
>> salsa.debian.org.

Norbert> Well, recent event have shown that *I* will not return to
Norbert> salsa. It did cost me an incredible amount of time to
Norbert> re-create all archives on github so that I can continue
Norbert> developing again.

I'll take this as input that we should have better transition strategies
for salsa when a project owner's status changes.

I appreciate that is unlikely to be sufficient to change your personal
opinion, but  it is something the community should discuss.

--Sam

Re: Bits from the DPL (May 2019)

[Norbert Preining]

Hi,

(please Cc, not reading d-d)

On Sun, 02 Jun 2019, Sam Hartman wrote:
> Dh as a Preferred Packaging Style
> =
> 
> As promised, I started a discussion [3] on whether we wanted to prefer
> (and in some cases require) the dh sequencer from Debhelper as a package
> building tool.
> 
> We had a great discussion.  I published my understanding of our project
> consensus.  We are seeking final comments until June 16.  At this point,

And would you be so helpful in providing a link to that understanding
of consensus? Only posting a link to the start of a long thread is not
really helpful.

> Git on Salsa
> 
> 
> The next discussion I will drive is a discussion of whether we want to
> strongly recommend Debian packaging be done using Git on
> salsa.debian.org.

Well, recent event have shown that *I* will not return to salsa. It did
cost me an incredible amount of time to re-create all archives on github
so that I can continue developing again.

Feel free to recommend it, but I won't follow this recommendation in any
case.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Bits from the DPL (April 2019)

[Esokrates]

Thanks very much for the reply!
Have you been discussing this with the gitlab people?
They seem very open to discuss with projects, e.g. see
https://gitlab.com/gitlab-org/gitlab-ce/issues/53206
I understand your points (especially agree on moving bugs between
different projects) and that there is no solution at this time, but it
would be great if Debian would try to collaborate with gitlab on this
issue so in the future the switch would be possible.

On 30.04.19 19:32, Sam Hartman wrote:
>> "Esokrates" == Esokrates   writes:
> 
> Esokrates> Hi, Thanks very much for the report!  Regarding
> Esokrates> transition to salsa: I would consider it to be a great
> Esokrates> idea to move bug reporting to gitlab too.  Most users
> Esokrates> today are more comfortable with web based bug reporting
> Esokrates> and it's more convenient to have everything in one place.
> Esokrates> For outside observers and possible new contributors it's
> Esokrates> otherwise a really a confusing situation.
> 
> There has been a lot of discussion over the years of improving our bug
> tracking, but I don't think gitlab's issue tracking meets our needs:
> 
> * bug numbers are per project not global.  Debian bugs move around too
>   much between packages.
> 
> * Gitlab doesn't have a good email interface for  bugs.  Yes, we need a
>   better web interface, but dealing with bugs via email is almost
>   certainly a must have for Debian.  As an example people want to be
>   able to manage bugs on a plane and to mix bugs and mailing list
>   conversation.
> 
> * Debian specific version tracking, cloning of bugs, and fixed version
> tracking are critical to us.
> 
> So, while I think a lot of us agree that it would be great to have bugs
> and code in one place and great to have a better web interface for bugs,
> I don't think today's Gitlab meets Debian's needs.
> 

Re: Bits from the DPL (December 2018)

[Nikolaus Rath]

On Jan 01 2019, Chris Lamb  wrote:
> Hi Nikolaus,
>
>> >  * Followed-up on progress regarding potential new "Member Benefits"
>> >[9] and ensured that some previously-promised reports for events
>> >funded by Debian ended up appearing on Planet [10].
>> >
>> >I also provided solicited (!) advice to a few other developers on
>> >conference booths and suitable/alternative conferences they may
>> >wish to attend instead.
>> 
>> Is there something missing here? Attend instead of what, and how does
>> that relate to member benefits?
>
> I don't believe anything is missing; these are two standalone
> sentences on different topics. ("X conference? Thought about Y
> conference instead?")

Then maybe a missing bullet point for the second paragraph? But even
with that I remain rather confused. What is the conference for which
these developers wanted an alternative, and why?

(I'm just very curious)

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bits from the DPL (December 2018)

[Chris Lamb]

Hi Nikolaus,

> >  * Followed-up on progress regarding potential new "Member Benefits"
> >[9] and ensured that some previously-promised reports for events
> >funded by Debian ended up appearing on Planet [10].
> >
> >I also provided solicited (!) advice to a few other developers on
> >conference booths and suitable/alternative conferences they may
> >wish to attend instead.
> 
> Is there something missing here? Attend instead of what, and how does
> that relate to member benefits?

I don't believe anything is missing; these are two standalone
sentences on different topics. ("X conference? Thought about Y
conference instead?")


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Bits from the DPL (December 2018)

[Nikolaus Rath]

On Dec 31 2018, Chris Lamb  wrote:
>  * Followed-up on progress regarding potential new "Member Benefits"
>[9] and ensured that some previously-promised reports for events
>funded by Debian ended up appearing on Planet [10].
>
>I also provided solicited (!) advice to a few other developers on
>conference booths and suitable/alternative conferences they may
>wish to attend instead.

Is there something missing here? Attend instead of what, and how does
that relate to member benefits?


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Alexandre Viau]

No, I have not received a reply.

Cheers,


On 2018-07-21 07:40 PM, Samuel Henrique wrote:
> Hello everyone,
>
> I sent an email on 1st June (when this thread started)
> to debian-steam[a]collabora.com  requesting it
> but got no response.
> Is it still going?
>
> Did you receive a reply Alexandre?
>
> Thanks
>
> On Fri, 1 Jun 2018 at 16:10, Alexandre Viau  > wrote:
>
> On 2018-06-01 01:22 PM, Andrej Shadura wrote:
> > The benefit should still be valid. The person responsible for it is
> > already looking into it, expect a reply shortly ;)
>
> Great, thanks :)!
>
> -- 
> Alexandre Viau
> av...@debian.org 
>
>
>
>
> -- 
> Samuel Henrique 

-- 
Alexandre Viau
av...@debian.org




signature.asc
Description: OpenPGP digital signature

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Samuel Henrique]

Hello everyone,

I sent an email on 1st June (when this thread started) to debian-steam[a]
collabora.com requesting it but got no response.
Is it still going?

Did you receive a reply Alexandre?

Thanks

On Fri, 1 Jun 2018 at 16:10, Alexandre Viau  wrote:

> On 2018-06-01 01:22 PM, Andrej Shadura wrote:
> > The benefit should still be valid. The person responsible for it is
> > already looking into it, expect a reply shortly ;)
>
> Great, thanks :)!
>
> --
> Alexandre Viau
> av...@debian.org
>
>
>

-- 
Samuel Henrique 

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Alexandre Viau]

On 2018-06-01 01:22 PM, Andrej Shadura wrote:
> The benefit should still be valid. The person responsible for it is
> already looking into it, expect a reply shortly ;)

Great, thanks :)!

-- 
Alexandre Viau
av...@debian.org




signature.asc
Description: OpenPGP digital signature

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Andrej Shadura]

On 01/06/18 17:31, Alexandre Viau wrote:
> On 2018-05-31 12:33 PM, Chris Lamb wrote:
>>  [11] https://wiki.debian.org/MemberBenefits
> Oh, this reminds me of something.
> 
> Has anyone gotten replies to their requests sent to
> debian-st...@collabora.com for the Steam subscriptions mentioned in the
> MemberBenefits page?
> 
> I think that I have sent two mails in the past 3 years but have gotten
> no responses.
> 
> Should we remove this benefit from the wiki page? Or do we have someone
> to contact about it?

The benefit should still be valid. The person responsible for it is
already looking into it, expect a reply shortly ;)

-- 
Cheers,
  Andrej



signature.asc
Description: OpenPGP digital signature

Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))

[Ian Campbell]

On Fri, 2018-06-01 at 11:31 -0400, Alexandre Viau wrote:
> On 2018-05-31 12:33 PM, Chris Lamb wrote:
> >  [11] https://wiki.debian.org/MemberBenefits
> 
> Oh, this reminds me of something.
> 
> Has anyone gotten replies to their requests sent to
> debian-st...@collabora.com for the Steam subscriptions mentioned in the
> MemberBenefits page?

I did in 2014. ISTR reading on some planet feed or other that the
specific person who replied to me had left collabora quite a while ago
though. Maybe things started falling through the cracks at that point?

Ian.