Re: Withdrawing Proposal C; Option Ordering; CFV Timing

[Anthony DeRobertis]

On November 30, 2019 10:32:11 PM UTC, Kurt Roeckx  wrote:

>I have removed the proposal from the page. I'm not sure that is the
>best thing to do.

I think it'd be a little clearer to replace its title and text with 
"(withdrawn)" or similar, then it'll be clear the missing letter is not a 
mistake like something accidentally missing. That's also a common way to deal 
with, e.g., repealed laws — replace the section with a note that it was 
repealed.

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> Could you provide some more information about what your
> Russ> concern is here?  libsystemd-dev depends only on libsystemd0,
> Russ> which has a pretty tiny list of dependencies and shouldn't
> Russ> require that systemd be running so far as I know.  Are you
> Russ> thinking of test suites that assume systemd is available?

> pkg-config for systemd is in systemd not libsystemd-dev

Oh, okay.  Also, I remembered some previous discussion that some libraries
end up with dependencies on systemd components for functionality.  Thanks,
I think I understand the issue now.

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Could you provide some more information about what your
Russ> concern is here?  libsystemd-dev depends only on libsystemd0,
Russ> which has a pretty tiny list of dependencies and shouldn't
Russ> require that systemd be running so far as I know.  Are you
Russ> thinking of test suites that assume systemd is available?

pkg-config for systemd is in systemd not libsystemd-dev

Re: Question Under Proposal D: Compile Time Option

[Russ Allbery]

Bernd Zeimetz  writes:
> On 11/30/19 8:58 AM, Thibaut Paumard wrote:

>> I think the right fix would be to compile the package twice as "foo"
>> (for the systemd version) and "foo-non-systemd".

>> Another option would be to ship both versions in package "foo" and
>> decide at runtime which one to run, if technically feasible.

>> My understanding of D.7 is that, If someone provides a patch that
>> implements either of this in a maintainable fashion, this patch should
>> be accepted.

> I'm wondering what the security team says to this approach. Who is
> actually going to review these changes, given the fact that most of the
> features in systemd that need patches in packages are somehow security
> relevant.

In the Kerberos world, we've shipped two binary packages build from the
same source package against MIT Kerberos and Heimdal for some time in
places where that makes sense.  It hasn't been much of a problem in
practice, although obviously it's extra packaging work.

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Adam Borowski  writes:

> * request a list of non-systemd-hostile policies to be changed[4], initial
>   contents being:
>   • an unrelated package forcing an init switch on a straightforward apt
> invocation is RC-buggy (usually caused by an unthoughtful deps ordering)

For the record, I suspect we can get regular Policy consensus for this
rule, since having one's init system changed by installing some unrelated
package is clearly buggy.

>   • requesting a redundant .service file when an init script exists, without
> a good reason (doubles work and reduces test coverage)

Note that the next revision of Policy will recommend that all packages
that want to start a daemon have systemd units because the generator that
handles init scripts has various undesirable edge cases.  The systemd
behavior is generally better and more consistent if every service has a
unit file.

There were no objections during the Policy discussion process for this
change, for the record.

>   • allowing unrelated packages to be unbuildable when a specific daemon/etc
> is installed (ie, should B-Dep/library-Dep on not-yet-existing
> systemd-dev instead of systemd, but the problem is not restricted to
> systemd)

Could you provide some more information about what your concern is here?
libsystemd-dev depends only on libsystemd0, which has a pretty tiny list
of dependencies and shouldn't require that systemd be running so far as I
know.  Are you thinking of test suites that assume systemd is available?

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

Re: Proposal: Focus on systemd

[Jeremy Bicha]

> I'd like submit the following proposal:
> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

Seconded.

Thanks,
Jeremy Bicha


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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Adam Borowski]

[I purposefully abstained in participating in this discussion so far, as I
have quite strong views, and I hoped it will stay mostly civilised.  But
alas, last developments seem to fails these hopes.  Thus, let's help Guillem
improve his proposal.]

On Sat, Nov 30, 2019 at 02:11:56PM -0500, Sam Hartman wrote:
> > "Bdale" == Bdale Garbee  writes:
> Bdale> I find this really appealing as a higher-level statement of
> Bdale> values and intent, but unfortunately, I don't think the text
> Bdale> does anything to help resolve the problems that Sam set out
> Bdale> to try and tackle with this GR.
> 
> I concur with Bdale and Russ.  If this option wins I find that I
> wouldn't know how to go forward. [...]
> This issue gives no guidance on the sorts of issues that I and the
> policy editors are facing.  This option provides no guidance on how to
> approach the patterns of behavior that Ian and I have seen on our lists.

I agree.  There are statements but no clear guidance.  Thus, I'll list
problems in the current state of Debian in regard of systemd in particular:

* there's a lot of use cases where systemd fails[1].  This makes it unfit
  for being the sole init+rc of an universal operating system.
* patches fixing non-systemd regressions are routinely ignored[2]
* changes I view as done with spite, which bring no or negligible benefit to
  systemd yet large detriment to other rc systems[3]

On the other hand, you cannot require contributors to implement something
they don't care about nor have required hardware/etc for.  Thus, let's use
the approach already in place for porting to architectures:

1. no regressions (enforced by testing migration process)
2. porter patches are privileged:

# devref §5.10.2.2. source NMUs for porters
#
# [...] It also varies whether the architecture is a candidate for
# inclusion into the next stable release [...]
#
# If you are a porter doing an NMU for "unstable", the above guidelines
# for porting should be followed, with two variations. Firstly, the
# acceptable waiting period — the time between when the bug is submitted
# to the BTS and when it is OK to do an NMU — is seven days for porters
# working on the "unstable" distribution. This period can be shortened
# if the problem is critical and imposes hardship on the porting effort,
# at the discretion of the porter group.


I propose to extend these rules to more technologies, starting with init/rc
systems.  This will give us an actionable guidance Bdale and Russ requested.

Thus: Guillem, would you consider amending your proposal to:
* extend the above rules to a list of technologies, with the list's initial
  contents being:
  • sysv-rc, at severity equivalent to a release arch
  • openrc, at severity equivalent to a -ports arch
  • non-yet-packaged new rc systems, equivalent to an out-of-archive arch
  (sysv-rc and openrc share most of the efforts)
  Alternatively, you can say just "init scripts" without going into details.
* request a list of non-systemd-hostile policies to be changed[4], initial
  contents being:
  • an unrelated package forcing an init switch on a straightforward apt
invocation is RC-buggy (usually caused by an unthoughtful deps ordering)
  • requesting a redundant .service file when an init script exists, without
a good reason (doubles work and reduces test coverage)
  • allowing unrelated packages to be unbuildable when a specific daemon/etc
is installed (ie, should B-Dep/library-Dep on not-yet-existing
systemd-dev instead of systemd, but the problem is not restricted to
systemd)

(Some more terse wording would be nice.)


Meow!

[1]. Such as, it doesn't boot on my new main desktop.  Or, it breaks schemes
  that rely on mount --bind (which it randomly sometimes converts to --rbind
  after a raceable delay, sometimes it doesn't).  Or, it not only refuses to
  mount degraded btrfs RAID but even unmounts if mounted manually.  Or,
  sometimes causes data loss of mails sent from cronjobs/exiting daemons.
  My list is short only because for obvious reasons I avoid prolonged
  exposure to systemd.

[2]. The worst case being patches for compiling policykit both for systemd
  and consolekit (initially) then elogind (later), despite a tested
  solution being proposed and available since Jan 2018. This led to
  Buster being mostly unusable with a modern GUI.  Reactions we met with
  were: 1. stonewalling (no one but smcv graced us with a response), then
  2. stalling (long delays when responding to bugs), and 3. last-minute
  demand of large-scale rewrite (a request to make libelogind0
  ABI-compatible and replacing libsystemd0, instead of both being
  coinstallable).

[3]:
  * dependencies on "systemd | other" rather than "other | systemd"; this is
a no-op on a systemd system (installed by debootstrap before any
non-base packages) but causes apt to force an init+rc switch elsewhere
  * changing "service" (the rc-agnostic wrapper) to "systemctl"
  * (dubious due to m

Re: Withdrawing Proposal C; Option Ordering; CFV Timing

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 05:34:09PM -0500, Sam Hartman wrote:
> > "Kurt" == Kurt Roeckx  writes:
> 
> Kurt> On Sat, Nov 30, 2019 at 05:15:25PM -0500, Sam Hartman wrote:
> >> > "Kurt" == Kurt Roeckx  writes:
> >> 
> Kurt> Anyway, I'm not sure what the "I'd like" means. Is that just
> Kurt> an intention to do it, or did you do it?
> >> 
> >> I withdraw Proposal C.
> 
> Kurt> I have removed the proposal from the page. I'm not sure that
> Kurt> is the best thing to do.
> 
> Are you saying you wish I had not withdrawn it, or are you saying that
> you're not sure how best to mark it?

It was about the marking. I think I if I leave it there that it
might confuse people.


Kurt

Re: Withdrawing Proposal C; Option Ordering; CFV Timing

[Sam Hartman]

> "Kurt" == Kurt Roeckx  writes:

Kurt> On Sat, Nov 30, 2019 at 05:15:25PM -0500, Sam Hartman wrote:
>> > "Kurt" == Kurt Roeckx  writes:
>> 
Kurt> Anyway, I'm not sure what the "I'd like" means. Is that just
Kurt> an intention to do it, or did you do it?
>> 
>> I withdraw Proposal C.

Kurt> I have removed the proposal from the page. I'm not sure that
Kurt> is the best thing to do.

Are you saying you wish I had not withdrawn it, or are you saying that
you're not sure how best to mark it?

Re: Withdrawing Proposal C; Option Ordering; CFV Timing

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 05:15:25PM -0500, Sam Hartman wrote:
> > "Kurt" == Kurt Roeckx  writes:
> 
> Kurt> Anyway, I'm not sure what the "I'd like" means. Is that just
> Kurt> an intention to do it, or did you do it?
> 
> I withdraw Proposal C.

I have removed the proposal from the page. I'm not sure that is the
best thing to do.


Kurt

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Paul Tagliamonte]

On Sat, Nov 30, 2019, 4:41 PM Bernd Zeimetz  wrote:

> Hi,
>
> > X<
> > Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> ... so how does this help the project? We are all wasting lots of time
> in discussing policy and if we want to support init and friends and if
> bugs are RC or not. You are basically saying that this needs to continue.
>
> I really hope that people vote this far below FD and I fail to
> understand why fellow developers actually second this.
>

I strongly agree. This proposal sounds nice as an aspirational set of
values to write proposals off of, but is deeply unhelpful in helping
resolve the rats nest we find ourselves in. I will be putting this option
below FD.

Paul

Re: Withdrawing Proposal C; Option Ordering; CFV Timing

[Sam Hartman]

> "Kurt" == Kurt Roeckx  writes:

Kurt> Anyway, I'm not sure what the "I'd like" means. Is that just
Kurt> an intention to do it, or did you do it?

I withdraw Proposal C.


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 06:46:27PM +0100, Guillem Jover wrote:
> 
> I'm thus proposing the following:

That is now on the website.


Kurt

Re: Withdrawing Proposal C; Option Ordering; CFV Timing

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 03:47:40PM -0500, Sam Hartman wrote:
> 
> First, if it does not reset the minimum discussion period, I'd like to
> withdraw proposal C.

I don't think that withdrawing an option changes the minimum
discussion period.

In A.2 it says:
4. The minimum discussion period is counted from the time the last
   formal amendment was accepted, or since the whole resolution was
   proposed if no amendments have been proposed and accepted.

To confuse people, in A.1 it says:
6. The proposer of a resolution may make changes to correct minor
   errors (for example, typographical errors or inconsistencies) or
   changes which do not alter the meaning, providing noone objects
   within 24 hours. In this case the minimum discussion period is not
   restarted.

Which seems to imply that maybe other options under A.1 might have
that effect, other than A.1.2.

Withdrawing is under A.4, which doesn't say anything about the
discussion period.

Anyway, I'm not sure what the "I'd like" means. Is that just an
intention to do it, or did you do it?

> I think the overlap between Proposal C and F is significant and we have
> not identified differences that appear to be important to our community.
> 
> I don't plan to make aCFV before Tuesday.  Whether even that makes sense
> depends on what happens between now and then.  I continue to believe it
> is very important to start voting by December 8.  based on feedback
> received so far, I do plan to ask to extend the voting period to three
> weeks.
> 
> Obviously others could choose to make a CFV sooner.
> 
> At this point, speaking as an interested party, but not the DPL, I'd
> request that we not reorder the options.
> I've found that I need to talk in mails, IRC, notes to myself about the
> specific proposals by letter.
> I have seen others do the same.
> I think that the cost of confusion is high enough at this point that I'd
> rather not see us reorder.
> If you do reorder, please please don't change the web links like
> https://www.debian.org/vote/2019/vote_002#textf (the link to Proposal
> F's text).

The reason I didn't reorder it yet, is because it's talked about
like that. But I guess I can just reorder it on the page, keep the
letter but change the number.

In any case, at the time of the vote I want the order on the page
to be the same as the option on the ballot.


Kurt

Re: Question Under Proposal D: Compile Time Option

[Bernd Zeimetz]

On 11/30/19 8:58 AM, Thibaut Paumard wrote:
> I think the right fix would be to compile the package twice as "foo"
> (for the systemd version) and "foo-non-systemd".
> 
> Another option would be to ship both versions in package "foo" and
> decide at runtime which one to run, if technically feasible.
> 
> My understanding of D.7 is that, If someone provides a patch that
> implements either of this in a maintainable fashion, this patch should
> be accepted.


I'm wondering what the security team says to this approach. Who is
actually going to review these changes, given the fact that most of the
features in systemd that need patches in packages are somehow security
relevant.

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Bernd Zeimetz]

Hi,

> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations

... so how does this help the project? We are all wasting lots of time
in discussing policy and if we want to support init and friends and if
bugs are RC or not. You are basically saying that this needs to continue.

I really hope that people vote this far below FD and I fail to
understand why fellow developers actually second this.


Bernd


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



signature.asc
Description: OpenPGP digital signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 08:43:38PM +, Mike Gabriel wrote:
> Seconded.

Your message wasn't signed.


Kurt

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Alberto Gonzalez Iniesta]

On Sat, Nov 30, 2019 at 06:46:27PM +0100, Guillem Jover wrote:
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55


signature.asc
Description: PGP signature

Withdrawing Proposal C; Option Ordering; CFV Timing

[Sam Hartman]

First, if it does not reset the minimum discussion period, I'd like to
withdraw proposal C.
I think the overlap between Proposal C and F is significant and we have
not identified differences that appear to be important to our community.

I don't plan to make aCFV before Tuesday.  Whether even that makes sense
depends on what happens between now and then.  I continue to believe it
is very important to start voting by December 8.  based on feedback
received so far, I do plan to ask to extend the voting period to three
weeks.

Obviously others could choose to make a CFV sooner.

At this point, speaking as an interested party, but not the DPL, I'd
request that we not reorder the options.
I've found that I need to talk in mails, IRC, notes to myself about the
specific proposals by letter.
I have seen others do the same.
I think that the cost of confusion is high enough at this point that I'd
rather not see us reorder.
If you do reorder, please please don't change the web links like
https://www.debian.org/vote/2019/vote_002#textf (the link to Proposal
F's text).

I do agree that reordering would have been nice.


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Mike Gabriel]

Hi,

Am Samstag, 30. November 2019 schrieb Guillem Jover:
> Hi!
> 
> I think the current GR is incorrectly framing the problem at hand,
> as if it was just an init system selection. It seems to me, that an
> init system is in principle just one of the many technologies we ship
> and integrate. But at least when it comes to systemd, choosing that in
> detriment to anything else, has a cascading effect of deciding on and
> closing doors on a wide range of technologies which have been declared
> incompatible by systemd upstream or by those other technologies.
> 
> For example the claims on "cross-distribution standards and
> cooperation", are pretty much restricted to GNU/Linux (glibc-based),
> not even say musl-based systems, or many other variations. systemd
> provides many nice features, but at the same time, as with any
> software, not all of them fit or are sufficient for all use cases or
> requirements, and people do want or have to use alternatives for many
> valid reasons.
> 
> 
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<
> 
> Thanks,
> Guillem
>

Seconded.

Mike
-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Re: Review of proposals

[Sean Whitton]

Hello,

On Fri 29 Nov 2019 at 10:00PM -08, Russ Allbery wrote:

> Speaking as one of the Policy editors, personally I'd rather have the
> explicit time frame so that we don't have to argue about what "enough
> time" means.  I like Ian's explicit list, which preempts a lot of the
> expected arguments.

Speaking as the other Policy Editor, I concur.  Ian's proposal is a
powerful compromise because of its preemption of certain points of
disagreement.

For similar reasons, I don't think that Guillem's new proposal is
sufficient to answer the project's current needs.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Sam Hartman]

> "Bdale" == Bdale Garbee  writes:

Bdale> Guillem Jover  writes:
>> I think the current GR is incorrectly framing the problem at
>> hand, as if it was just an init system selection.

Bdale> This resonates with me, but...

>> I'm thus proposing the following:

Bdale> I find this really appealing as a higher-level statement of
Bdale> values and intent, but unfortunately, I don't think the text
Bdale> does anything to help resolve the problems that Sam set out
Bdale> to try and tackle with this GR.

Bdale> I therefore find myself unwilling to second it, even though
Bdale> on some level I would really like to.

I concur with Bdale and Russ.  If this option wins I find that I
wouldn't know how to go forward.  I started this process because there
were issues coming before me as DPL that I didn't know how to address
because I didn't understand the direction of the project.
This issue gives no guidance on the sorts of issues that I and the
policy editors are facing.  This option provides no guidance on how to
approach the patterns of behavior that Ian and I have seen on our lists.

--Sam

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Bdale Garbee]

Guillem Jover  writes:

> I think the current GR is incorrectly framing the problem at hand,
> as if it was just an init system selection.

This resonates with me, but...

> I'm thus proposing the following:

I find this really appealing as a higher-level statement of values and
intent, but unfortunately, I don't think the text does anything to help
resolve the problems that Sam set out to try and tackle with this GR.

I therefore find myself unwilling to second it, even though on some
level I would really like to.

Bdale


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Russ Allbery]

Guillem Jover  writes:

> I'm thus proposing the following:

> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations

Should this be on the ballot, I will vote it below FD because it provides
essentially no guidance to how to resolve the concrete Policy problems
that are my primary concern in this GR.

This resolution would make Policy's job even more difficult than it
already is.  It says a lot of wonderful-sounding things, but it makes all
of the practical and community problems facing Debian even worse by
refusing to provide any clarity.  It's essentially equivalent to just
voting for Further Discussion, except that it adds a very vague position
statement for all sides to beat each other over the head with ("you're not
welcoming the integration of diverse technologies" vs. "you're not willing
to put in the effort required").

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

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Steve Kostecke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Guillem Jover said:

>X<
>Title: Reaffirm our commitment to support portability and multiple 
>implementations

>The Debian project reaffirms its commitment to be the glue that binds
>and integrates different software that provides similar or equivalent
>functionality, with their various users, be them humans or other software,
>which is one of the core defining traits of a distribution.
>
>We consider portability to different hardware platforms and software
>stacks an important aspect of the work we do as a distribution, which
>makes software architecturally better, more robust and more future-proof.
>
>We acknowledge that different upstream projects have different views on
>software development, use cases, portability and technology in general.
>And that users of these projects weight tradeoffs differently, and have
>at the same time different and valid requirements and/or needs fulfilled
>by these diverse views.
>
>Following our historic tradition, we will welcome the integration of
>these diverse technologies which might sometimes have conflicting
>world-views, to allow them to coexist in harmony within our distribution,
>by reconciling these conflicts via technical means, as long as there
>are people willing to put in the effort.
>
>This enables us to keep serving a wide range of usages of our distribution
>(some of which might be even unforeseen by us). From servers, to desktops
>or deeply embedded; from general purpose to very specifically tailored
>usages. Be those projects hardware related or software based, libraries,
>daemons, entire desktop environments, or other parts of the software
>stack.
>X<

Seconded

- -- 
Steve Kostecke 

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEGH2sJVLoH0wvM1tGQgpClenb3bwFAl3itPEACgkQQgpClenb
3bz2Ow//X3604SG61vxZpW1rgInfqKiarDMmCiHPBno/ZLecPGecvdhrzGPlfT3F
O3BZ2UPdhrkhrz1Bhl/ElRV+032Nhu1ZF5j82N1Lm5YiN6HmWU9RyDhGLxrCVCSK
p4lPOrDx0Eb52c3lIo2R1tpNATs6cG5JfuxyR4nYvuoCnRZyROUhnwihurjdmL2r
mCxwQHdZ/DV90H+ceqKnTqbeqgZthzBL0jZ+3bhon4EctUDK/HLyGmyChrkrE2Fu
n+IzmnnxeB8PSR3SqqXvmYb+LYz9TVrlrj/xO7IHCanADCMghhcPzZ6l+l3DvU9/
WBdGwYzwP3chNymt2tSkD0ogdgyAm4lbmpszr26wfXF+46+9cZhuOHiAx7asmmaz
3GqVWioj3gXTAEDiIkXnGtbA99CIpVhPEtA7fBwU+mtRH2isYBzQxWSpVo4Nbk3J
3rkVKv+sb+Oso/bzdF4C0zEAuglpu7eVDnyFN1Mp5z4U+iEyNWHHYwynJ0DWvGt0
//IJSb15QB980ErD9VstHSxuky54fBDc2hzb5iqgxM9HSrWFCg4NHqtOkgJEi3lc
2PYMwhNDXg6oi4MfRFAEjy7vt9TeS4HzyGOAieP2HEGO+rCjwbu+9e/JqQmT1aMt
kou751bqIkZAIbfvLxXzKW0vJZvUsGW9Bq7t3jtI+xBrUgVj1Dk=
=Gd1A
-END PGP SIGNATURE-

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Mathias Behrle]

* Guillem Jover: " Proposal: Reaffirm our commitment to support portability and
  multiple implementations" (Sat, 30 Nov 2019 18:46:27 +0100):


> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

Cheers
Mathias

-- 

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


pgpppRCShTFTa.pgp
Description: Digitale Signatur von OpenPGP

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ricardo Mones]

On Sat, 30 Nov 2019 18:46:27 +0100
Guillem Jover  wrote:
[...]
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other
> software, which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more
> future-proof.
> 
> We acknowledge that different upstream projects have different views
> on software development, use cases, portability and technology in
> general.  And that users of these projects weight tradeoffs
> differently, and have at the same time different and valid
> requirements and/or needs fulfilled by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our
> distribution, by reconciling these conflicts via technical means, as
> long as there are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our
> distribution (some of which might be even unforeseen by us). From
> servers, to desktops or deeply embedded; from general purpose to very
> specifically tailored usages. Be those projects hardware related or
> software based, libraries, daemons, entire desktop environments, or
> other parts of the software stack.
> X<

Seconded.

best regards,
-- 
  Ricardo Mones 
  ~
  bash: ./signature: No such file or directory  /bin/bash



signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Guilhem Moulin]

On Sat, 30 Nov 2019 at 18:46:27 +0100, Guillem Jover wrote:
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

-- 
Guilhem.


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Jonas Smedegaard]

Quoting Guillem Jover (2019-11-30 18:46:27)
> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded

 - Jonas

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

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


signature.asc
Description: signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[gregor herrmann]

On Sat, 30 Nov 2019 18:46:27 +0100, Guillem Jover wrote:

> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bob Dylan: I Want You


signature.asc
Description: Digital Signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon Richter]

On 30.11.19 18:46, Guillem Jover wrote:

> I'm thus proposing the following:
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple 
> implementations
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight tradeoffs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> X<

Seconded.

   Simon



signature.asc
Description: OpenPGP digital signature

Proposal: Reaffirm our commitment to support portability and multiple implementations

[Guillem Jover]

Hi!

I think the current GR is incorrectly framing the problem at hand,
as if it was just an init system selection. It seems to me, that an
init system is in principle just one of the many technologies we ship
and integrate. But at least when it comes to systemd, choosing that in
detriment to anything else, has a cascading effect of deciding on and
closing doors on a wide range of technologies which have been declared
incompatible by systemd upstream or by those other technologies.

For example the claims on "cross-distribution standards and
cooperation", are pretty much restricted to GNU/Linux (glibc-based),
not even say musl-based systems, or many other variations. systemd
provides many nice features, but at the same time, as with any
software, not all of them fit or are sufficient for all use cases or
requirements, and people do want or have to use alternatives for many
valid reasons.


I'm thus proposing the following:

X<
Title: Reaffirm our commitment to support portability and multiple 
implementations

The Debian project reaffirms its commitment to be the glue that binds
and integrates different software that provides similar or equivalent
functionality, with their various users, be them humans or other software,
which is one of the core defining traits of a distribution.

We consider portability to different hardware platforms and software
stacks an important aspect of the work we do as a distribution, which
makes software architecturally better, more robust and more future-proof.

We acknowledge that different upstream projects have different views on
software development, use cases, portability and technology in general.
And that users of these projects weight tradeoffs differently, and have
at the same time different and valid requirements and/or needs fulfilled
by these diverse views.

Following our historic tradition, we will welcome the integration of
these diverse technologies which might sometimes have conflicting
world-views, to allow them to coexist in harmony within our distribution,
by reconciling these conflicts via technical means, as long as there
are people willing to put in the effort.

This enables us to keep serving a wide range of usages of our distribution
(some of which might be even unforeseen by us). From servers, to desktops
or deeply embedded; from general purpose to very specifically tailored
usages. Be those projects hardware related or software based, libraries,
daemons, entire desktop environments, or other parts of the software
stack.
X<

Thanks,
Guillem


signature.asc
Description: PGP signature

Re: Proposal: Focus on systemd

[Simon Richter]

Hi,

On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote:

> I'd like submit the following proposal:

I guess my second is not really needed anymore for this, but it's good to
have it on the ballot.

> Proposal: Focus on systemd to promote standardization and cross-distribution 
> cooperation

Standardization and cross-distribution cooperation are kind of conflicting
goals, because the only distributions you can effectively cooperate with
are the ones following the same standards, so this narrows down the options
for cross-distribution cooperation rather than opening them up.

So this is effectively a decision to join a crowded bubble, and when Debian
does so, we also need a clear picture of what makes us unique or
interesting inside that bubble, so we can continue to attract volunteers.

 - What differentiates us from Ubuntu?

Ubuntu took that leap a few years ago, and they have a reputation of being
a strong desktop distribution, some people seem to be using them for
servers as well, and they are virtually nonexistant outside of that. Can we
provide equally strong support to desktop users, and can we keep those
users whose use cases we demote in priority?

 - What are the skills we require from maintainers?

Do we still require maintainers to be proficient in shell scripting, in
addition to systemd incantations, or should we take advantage of the
"flattened" learning curve?

> Cross-distribution standards and cooperation are important factors in
> the choice of core Debian technologies.  It is important to recognize
> that the Linux ecosystem has widely adopted systemd and that the level
> of integration of systemd technologies in Linux systems will increase
> with time.

I share this observation, and this puts Debian with its long release cycle
into an awkward position, as we need to find a balance between a stable
core system and providing the necessary capabilities for add-on software.

Of course that happens however we decide on this GR, but the next question,
should this option win, would be a backports policy: do we want to
encourage writing compatibility code for systemd features not yet in a
stable release, or do we want users to upgrade systemd instead, and if the
former, can this be coordinated with distributions that have the same
problem?

   Simon

Re: Proposal: Focus on systemd

[Moritz Mühlenhoff]

Sean Whitton  schrieb:
> I would be grateful for an informal summary of why proposal F is thought
> to be needed on the ballot in addition to proposal C.  What is thought
> not captured well by Sam's text, but is thought to be captured well by
> Martin's text?

>From my PoV:
- Less ambigious, C only talks about service units and preferring other
facilities "if they have clear and obvious advantages" (but we have no
good method to clarify whether e.g. systemd-sysusers fulfills that over
adduser), while F actively endorses tight integration.
- F is more expressive in terms of why to focus on systemd (like to
collaborate with the 99% of the FLOSS world who settled on systemd) than
C.

Cheers,
Moritz

Re: Proposal: Focus on systemd

[Kurt Roeckx]

On Sat, Nov 30, 2019 at 01:44:08AM +0100, gregor herrmann wrote:
> On Fri, 29 Nov 2019 18:12:48 -0500, Sam Hartman wrote:
> 
> > I'm trying to figure out if the new proposal is redundant with proposal
> > C.  The text is obviously very different, but I'm trying to figure out
> > if there are any practical differences.  Understand this is not a
> > criticism of this proposal, but if there are no significant practical
> > differences I am enclined to withdraw Proposal C.
> 
> Without having thought this through, I have a gut feeling that you
> could withdraw all of your original proposals, because we now have 3
> clear proposals, worded by the respective proponents, for the 3
> general directions: Dmitry's pro multiple init systems variant, Ian's
> compromise proposal, and now tbm's clear pro systemd text.

I think from a constitutional point of view, proposal A can not be
withdrawn, it would stop the whole GR, but he should instead accept
one of the others to replace it.


Kurt