Re: [RFC] General Resolution to deploy tag2upload

[Didier 'OdyX' Raboud]

(dropping all CC, focusing on the content)

Le vendredi, 28 juin 2024, 08.32:43 h CEST Ansgar  a écrit :
> I'll expand on the here slightly for your benefit:
> 
> $ git clone https://salsa.debian.org/rra/tf5.git
> [...]
> $ apt-get source tf5
> [...]
> $ rm -rf tf5/.git tf5-5.0beta8/.pc
> $ diff -Nur tf5 tf5-5.0beta8; echo $?
> 0
> 
> If one is really bored:
> $ (cd tf5; sha256sum $(find . -type f | sort) | sha256sum -)
> 8d7820471fb44382a0c752319906064a1276ff18873fb4730dec1319aaf7b459  -
> $ (cd tf5-5.0beta8; sha256sum $(find . -type f | sort) | sha256sum -)
> 8d7820471fb44382a0c752319906064a1276ff18873fb4730dec1319aaf7b459  -
> 
> I will leave it as an exercise to you to compare the output and to
> reason about results of different ways to compare both trees.

It looks to me that you have taken (by choice, or by chance) an example that 
too conveniently fits what you want to demonstrate: in which the git 
repository and the .dsc are treesame. They are often the case, but not always, 
as documented in the various git workflows' documentation provided by dgit. 
The salsa repo can be patches-applied and not have the debian/patches files, 
they'd be created at dgit push-source time.

If I understand your position correctly (please correct me if needed): you 
(with a ftpmaster hat) would like all uploads to come with a signed artefact 
of hashes corresponding to the set of files as represented by the current 
Debian source package format, as accepted by the archive today. And you would 
like this artefact's signature be a signature by the human uploader. Did I get 
this right?

If I understand dgit and tag2upload correctly, in the cases where the git 
repository is treesame to the source package (patches-applied, with debian/
patches file stored in git, as pointed by a tag), this artefact has the exact 
same cryptographic value as the git tag, pointing to the git tree, pointing to 
the git objects (modulo the SHA-1 vs SHA-256 hash functions choice, which was 
clarified elsewhere). One such example is the tf5 source that you used as 
example. In that case, would you still want a outside-of-git hash, signed by 
the human uploader?

In the cases where the git repository is _not_ treesame to the source package 
(patches-applied, but debian/patches not stored in git), uploads are already 
possible via dgit push-source (and the human upload signature covers the 
source package as it goes in the archive, not the git tree). In that other 
case, would you still want a signed artifact of hashes, signed by the human 
uploader? And do we both understand that this means that some git repository 
layouts would hence not be possible to be uploaded via tag2upload (because it 
needs a much heavier git tag client, that builds the final source package, 
hashes its contents, and creates the git tag)?

(I have refrained from formulating the questions as explicit to the ftpmaster 
delegates "as a team", I merely want to understand Ansgar's position first ).

-- 
OdyX

Re: General Resolution to deploy tag2upload

[Didier 'OdyX' Raboud]

Le jeudi, 27 juin 2024, 09.15:42 h CEST Sean Whitton a écrit :
> =
> BEGIN FORMAL RESOLUTION TEXT
> 
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.
> 
> 1. tag2upload, in the form designed and implemented by Sean Whitton and
>Ian Jackson, and design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2upload service.
> 
> 3. Future changes to tag2upload should follow normal Debian processes.
> 
> 4. Nothing in this resolution should be taken as requiring maintainers
>to use any particular git or salsa workflows.
> 
> END FORMAL RESOLUTION TEXT
> =

Seconded, thanks for the extensive discussion and work towards that goal.

I'm of course worried by the potential disruptions on motivation and morale 
for the FTP team, but I (currently) feel that the potential benefits from a 
working tag2upload are worth at least having that vote.

I wonder if certain amendments would make sense and better the ballot (such as 
weakening the "should be deployed" towards a "ftpmaster are encouraged to 
consider deploying", or so), but I don't have the mental space or bandwidth to 
think of a good one.

-- 
OdyX

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

Re: Summary of the current state of the tag2upload discussion

[Didier 'OdyX' Raboud]

Le mardi, 25 juin 2024, 22.13:53 h CEST Philip Hands a écrit :
> Aigars Mahinovs  writes:
> > Do you actually check that the contents of the source *package* (after all
> > operations done by dpkg-source and possibly other tools) actually match
> > what you were looking at before in your source work tree folder?
> 
> Until this thread, the idea that doing so might be prudent had not even
> occured to me TBH.
> 
> Now that it has, it also occurs to me that if I actually were subject to
> an attack that was attempting to sneak something in at this point, my
> system might well have been tampered with to render it unable to detect
> the change (by replacing diff with a version blind to the changes etc.)

Following on the red team idea from Russ; if dpkg-source added a "# report a 
bug to dpkg-source if you see me" comment in debian/rules at build time 
(hidden in the .debian.tar, but not present in the local directory), I would 
not be surprised if this was only detected by casual readers of 
sources.debian.org, or NMUers, but not by any uploaders. And I'd bet that this 
would span several hundreds of uploads before being detected (and of course, 
this would affect tag2upload similarly).

But if this is done not as an attack on the dpkg-source package, but just as a 
local compromise of $PATH on a DD's laptop, who would detect it? I certainly 
wouldn't have.

-- 
OdyX

Re: Summary of the current state of the tag2upload discussion

[Didier 'OdyX' Raboud]

Le mardi, 25 juin 2024, 19.14:53 h CEST Russ Allbery a écrit :
> tho...@goirand.fr writes:
> > Watch the Kosovo lightning talk where Didier shows what he did. It is a
> > proven concept.
> 
> If this is the proof of concept where the *.dsc file is encoded in a Git
> tag (sorry, there have been several proofs of concept and I lose track of
> which person was associated with which one), I understand it and have
> already said why I don't think it will work reliably enough in its current
> form.  (Summary: It relies on the reproducibility of tar and compression
> programs.)  We should measure reproducible source packages by comparing
> the unpacked source packages.  It's a lot more robust.

For the record: I agree with Russ.

My PoC was written out of the desire to let Salsa CI upload _after successful 
tests_, and I took the "inline the source package as built locally in a git 
object" route for that. It inlines the .dsc and the _source.changes. As Russ 
(and others) have demonstrated, this kind of concept is going to be very 
fragile and very susceptible to breakage (with origins in varying versions of 
dpkg, tar, git-archive, pristine-tar, source building workflows, etc etc): in 
other words, it relies on the reproduciblity of _source packages_, 
reproducibility of the conversion from a git repository to a source package 
(which is out of scope of the reproducible builds' team, last I checked).

It also falls short on its original promise: given that (a modified, inlined 
version of) the signed source package is pushed to Salsa, the uploader has 
already vouched for the upload to Debian, even before the "required" tests 
have ran.

The workflow I proposed was to delegate the actual upload to a CI job, but it 
has no additional git-centric or security-centric properties than an uploader 
pushing a git tag and uploading to DELAYED/1 simultaneously, and then 
promoting, or cancelling depending on the CI test results (besides a bit less 
manual work).

Another caveat with that approach, is that it clearly needs a Debian-specific 
tool to build the inline data and add it to git (and then another to unpack it 
and upload). As I wanted something auditable, I inlined text signatures and 
refused to inline things out of the source tree, but it would be easy to 
commit the actual signed source binaries to git and get the same process (and 
effect). But then there's no point in using git, just upload it!

I think the tag2upload is a much better and stronger approach than my PoC for 
these reasons:
- the dgit tools cover way more ground in terms of supported git workflows, to 
get closer to reproducible source package building from git
- the PoC's promise to "only upload after successful CI" is nice, and not 
covered by tag2upload (yet?), but is not really important in the big picture; 
it's not such a fundamental property for a git workflow that it is worth 
blocking the tag2upload proposal for. (and it's likely quite simple to get 
that with tag2upload)
- tag2upload (especially with multiple, parallel instances of it) would test 
reproducibility of the git-to-source process that is currently absolutely 
untested. I totally concur with the impression that almost nobody is actually 
dissecting source packages (as signed, I really mean the orig tar and 
.debian.tar files) before upload; as well as the fact that even those doing so 
are very likely to miss anything unusual in there, making the check mostly 
useless.

OdyX

Re: [RFC] General Resolution to deploy tag2upload

[Didier 'OdyX' Raboud]

Le jeudi, 13 juin 2024, 08.23:45 h CEST Thomas Goirand a écrit :
> One thing I really dislike, is having a single gpg key to upoload them
> all. I very much preferred the design that Didier explained during
> Debconf Kosovo, where the .changes signature is uploaded together with
> the tagged commit.

Thomas is referring to my very rough proof-of-concept with specially-crafted 
tags I had quickly presented at DebConf22: first lightning talk, video'ed 
here: https://debconf22.debconf.org/talks/41-lightning-talks/

I had called this "dtag": the idea was to store an inline representation of 
the .dsc and .changes you would produce locally in `git notes` that get 
attached to git tags (to avoid storing very large amounts of signatures in a 
git tag); the uploader pushes the tag, and a job in Salsa CI (or whatever 
tool) then takes the tag, reconstructs the .dsc and .changes, and then (as 
they're validly signed), directly uploads them.

Source is there:
  https://salsa.debian.org/odyx/dtag

A "signing job" is there:
  https://salsa.debian.org/debian/libopenaptx/-/jobs/3020729

I never progressed further than the hacked-around scripts I had done towards 
that lightning talk, mostly for these reasons:

* it's fragile: it depends on bit-by-bit reproducibility of source _and_ 
changes files between what the uploader would do on their machine, and what 
the git tag notes processor does. As the dgit & tag2upload teams have 
demonstrated, there are _many ways_ this can (and will) break.
* while I like the "only upload if the CI passes" feature, I'm not very happy 
with the fact that as uploader, I already granted the right to upload (as all 
the material to generate a signed source package is pushed) before the CI ran 
successfully: an evil bypasser could use my git tag+notes and upload anyway, 
as signed with my key. I don't think its unique to that implementation though: 
all signed processes around git tags have the same issue.
* Debian has fallen behind in my priorities, so I'm uploading less, and 
polishing this has not been on my todo list.
* generating the special git notes is bulky, and requires local software, that 
is not-pretty python3.

By no means do I claim ownership of the idea or the design, or even on the 
proof-of-concept code; if that is seen as worthwhile, I'd be honoured to see 
anyone building on top of this idea, design, or code!

-- 
OdyX

Re: Debian Project Leader election 2023: First call for votes

[Didier 'OdyX' Raboud]

Le samedi, 1 avril 2023, 16.24:51 h CEST Luna Jernberg a écrit :
> Not really any point to vote as highvoltage is the only one to vote on
> congrats to being the Debian Project Leader for another year

With Q being about 16, and quorum being 3Q, at least 48 developers need to 
vote highvoltage above NOTA for him to be elected (see constitution article 
4.2 and past votes); otherwise we have to take another vote (5.2.6).

There's almost always a point to go out and vote!

-- 
OdyX

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

Re: new proposal: free and and non-free installers with SC change

[Didier 'OdyX' Raboud]

Le mercredi, 14 septembre 2022, 17.00:26 h CEST Holger Levsen a écrit :
> -
> Proposal F
> 
> This ballot option supersedes the Debian Social Contract (a foundation
> document) under point 4.1.5 of the constitution and thus requires a 3:1
> majority.
> 
> The Debian Social Contract is replaced with a new version that is identical
> to the current version in all respects except that it adds the following
> sentence to the end of point 5:
> 
> The Debian official media may include firmware that is otherwise not
> part of the Debian system to enable use of Debian with hardware that
> requires such firmware.
> 
> The Debian Project also makes the following statement on an issue of the
> day:
> 
> We will include non-free firmware packages from the "non-free-firmware"
> section of the Debian archive on our official media (installer images and
> live images). The included firmware binaries will normally be enabled by
> default where the system determines that they are required, but where
> possible we will include ways for users to disable this at boot (boot menu
> option, kernel command line etc.).
> 
> When the installer/live system is running we will provide information to the
> user about what firmware has been loaded (both free and non-free), and we
> will also store that information on the target system such that users will
> be able to find it later. Where non-free firmware is found to be necessary,
> the target system will also be configured to use the non-free-firmware
> component by default in the apt sources.list file. Our users should receive
> security updates and important fixes to firmware binaries just like any
> other installed software.
> 
> We will publish these images as official Debian media, alongside the current
> media sets that do not include non-free firmware packages.
> 
> ---

Seconded; thanks Holger!

-- 
OdyX

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

Re: Possible draft non-free firmware option with SC change

[Didier 'OdyX' Raboud]

Le jeudi, 8 septembre 2022, 07.14:09 h CEST Russ Allbery a écrit :
> Didier 'OdyX' Raboud  writes:
> > Thanks for that proposal Russ!
> > 
> > While we're at updating the Social Contract's article 5, what about a
> > more invasive cleanup, to reflect reality ?
> 
> [...]
> 
> > What about this (which adds the non-free-firmware area, replaces "CD
> > manufacturers" with "installation media providers", replaces "on their
> > 
> > CD" with "on their installation media":
> >> The Debian Social Contract is replaced with a new version that is
> >> identical to the current version in all respects except that the point 5
> >> 
> >> reads as follows:
> >> 5. Works that do not meet our free software standards
> >> We acknowledge that some of our users require the use of works that
> >> do
> >> not conform to the Debian Free Software Guidelines. We have created
> >> "contrib", "non-free" and "non-free-firmware" areas in our archive
> >> for
> >> these works. The packages in these areas are not part of the Debian
> >> system, although they have been configured for use with Debian. We
> >> encourage installation media providers to read the licenses of the
> >> packages in these areas and determine if they can distribute the
> >> packages on their installation medias. Thus, although non-free works
> >> are
> >> not a part of Debian, we support their use and provide infrastructure
> >> for non-free packages (such as our bug tracking system and mailing
> >> lists). The Debian official media may include firmware that is
> >> otherwise
> >> not part of the Debian system to enable use of Debian with hardware
> >> tha
> >> requires such firmware.
> 
> With Steve's change and a few other tweaks to try to make this a bit more
> concise:
> 
>  5. Works that do not meet our free software standards
> 
>  We acknowledge that some of our users require the use of works that
>  do not conform to the Debian Free Software Guidelines. We have
>  created areas in our archive for these works. The packages in these
>  areas are not part of the Debian system, although they have been
>  configured for use with Debian. We encourage distributors of Debian
>  to read the licenses of the packages in these areas and determine if
>  they can distribute the packages on their media. Thus, although
>  non-free works are not a part of Debian, we support their use and
>  provide infrastructure for non-free packages (such as our bug
>  tracking system and mailing lists). The Debian official media may
>  include firmware that is otherwise not part of the Debian system to
>  enable use of Debian with hardware tha requires such firmware.
> 
> I do think this sounds more up-to-date, and getting rid of "CDs" does feel
> like an overdue edit.  This would also resolve how to phrase the ballot
> option (although someone's going to ask for a diff).  What does everyone
> else think about this?

Yes. Yes. Yes.

(Missing a "t" at the end of "tha*T* requires such firmware")

> Going *way* out on a limb (and to be honest I'm leaning hard against
> proposing this because I think this level of change would require more
> than a week's worth of discussion), I think something like this that
> reorders and trims the section down would be even better:
> 
>  5. Works that do not meet our free software standards
> 
>  We acknowledge that some of our users require the use of works that
>  do not conform to the Debian Free Software Guidelines. We have
>  created areas in our archive for these works. These packages have
>  been configured for use with Debian and we provide some
>  infrastructure for them (such as our bug tracking system and mailing
>  lists), but they are not part of the Debian system. We encourage
>  distributors of Debian to read the licenses of the packages in these
>  areas and determine if they can distribute these packages on their
>  media. The Debian official media may include firmware from these
>  areas that is otherwise not part of the Debian system to enable use
>  of Debian with hardware that requires such firmware.

As-is (that is: "changing only SC5 with a 3:1 majority") seems to be one very 
simple way to express the change we (some of us) want. The "statement of the 
day" is a nice addition, but can risk being nitpicked-upon. I'd definitely 
second a ballot option that wo

Re: Possible draft non-free firmware option with SC change

[Didier 'OdyX' Raboud]

Thanks for that proposal Russ!

While we're at updating the Social Contract's article 5, what about a more 
invasive cleanup, to reflect reality ?

Le mercredi, 7 septembre 2022, 19.48:36 h CEST Russ Allbery a écrit :
> --
> 
> This ballot option supersedes the Debian Social Contract (a foundation
> document) under point 4.1.5 of the constitution and thus requires a 3:1
> majority.


Instead of this:
> The Debian Social Contract is replaced with a new version that is
> identical to the current version in all respects except that it adds the
> following sentence to the end of point 5:
> 
> The Debian official media may include firmware that is otherwise not
> part of the Debian system to enable use of Debian with hardware that
> requires such firmware.

What about this (which adds the non-free-firmware area, replaces 
"CD manufacturers" with "installation media providers", replaces "on their CD" 
with "on their installation media":

> The Debian Social Contract is replaced with a new version that is
> identical to the current version in all respects except that the point 5 
> reads as follows:
> 
> 5. Works that do not meet our free software standards
> We acknowledge that some of our users require the use of works that do 
> not conform to the Debian Free Software Guidelines. We have created 
> "contrib", "non-free" and "non-free-firmware" areas in our archive for
> these works. The packages in these areas are not part of the Debian
> system, although they have been configured for use with Debian. We
> encourage installation media providers to read the licenses of the
> packages in these areas and determine if they can distribute the 
> packages on their installation medias. Thus, although non-free works are
> not a part of Debian, we support their use and provide infrastructure
> for non-free packages (such as our bug tracking system and mailing
> lists). The Debian official media may include firmware that is otherwise
> not part of the Debian system to enable use of Debian with hardware tha
> requires such firmware.

The rest of your proposed draft reads excellent to me.
-- 
OdyX

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

Re: Making the RMS resolution a Secret Ballot

[Didier 'OdyX' Raboud]

Le dimanche, 11 avril 2021, 23.10:53 h CEST Jonathan Wiltshire a écrit :
> So I suggest the DPL directs under s5.1 something like:
> 
> "The secretary shall delay publication of the the association between
> identify and ballot on the tally sheet, for a period of not more than 90
> days, unless directed otherwise by a General Resolution of the Developers."
> 
> A GR about future secret ballots should make provision for how to apply it
> retrospectively to this one. This preserves the 3:1 requirement that there
> would have been were it being decided in advance.

That's a quite interesting approach, thank you for it.

My only concern is that deciding on the privacy of vote ballots *given the 
aggregated results*, is bound to be influenced by these results.  I wouldn't 
be surprised by voters wanting to see the list of names _more_, depending on 
the results.

-- 
OdyX

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

Re: Making the RMS resolution a Secret Ballot

[Didier 'OdyX' Raboud]

Le dimanche, 11 avril 2021, 01.02:18 h CEST Eduard Bloch a écrit :
> Those who insist on making the personal views on this (non-technical!!!)
> GR public should be ashamed of dragging their fellows into denuding
> themselves for no good reason.

Just clarifying one thing here, to make sure there's no misunderstanding.

All non-election Debian GRs have had the tally sheet of nominal votes 
published, thereby making the personal views of all voters public. [0]

( Looking at the last GR; https://www.debian.org/vote/2019/vote_002.en.html 
  links to https://www.debian.org/vote/2019/vote_002_tally.txt, which has your  
  vote: "V: 67512348 blade Eduard Bloch". )

For what I'm concerned, I don't "insist on making the personal views on this 
GR public", because it was always clear (to me) that all voters' personal 
views on this GR would end up being made public by the secretary on our 
website; this is how we have all experienced the publication of GR results for 
at least a decade. I insist on "not changing how we collectively run through 
the GR experience in the middle of a sensitive GR". This is not "dragging my 
fellows into denuding themselves", because my expectation is that every voter 
is well aware that their vote would be published, in this GR as in any GR. [1]

If you don't want to (or cannot afford to) see your personal views on this
GR to be made public, then don't vote.

Don't misread me; it is a very very serious concern that external factors 
(threats, pression, etc) make it so that some of our voters will not vote in 
fear of retaliation. But I think that if we, as a project, accept to bend our 
traditional and constitutional procedures under that external pressure through 
emergency exceptional measures, we also make the project more vulnerable to 
future external pressure; we also weaken this GR's results too.

We must protect our members from harassment; we must defend the project from 
external influence; and we must call out external pressures in the strongest 
terms possible. Threats against Debian project members because of their public 
opinions in the project are *not acceptable*, ever [1], and we must stand, as 
a project, against those threatening our members and our community. The 
problem we face here is the pressure and the threats against project members, 
not the publication of the GR votes. Let's not forget that.

-- 
OdyX

[0] For as long as I remember at least, but certainly since I gained voting 
rights in 2011. I just checked, the 1999 vote about logo licenses already
had a public tally sheet; https://www.debian.org/vote/1999/result_0002
[1] From https://lists.debian.org/debian-devel-announce/2021/04/msg1.html
> VOTING SECRECY
> This is a non-secret vote. After the voting period is over the details on
> who voted what will be published.
[2] Critics against one's opinion of course are.

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

Re: Making the RMS resolution a Secret Ballot

[Didier 'OdyX' Raboud]

Le vendredi, 9 avril 2021, 19.12:26 h CEST Sam Hartman a écrit :
> On another list, there was discussion of the DPL encouraging the
> secretary to make the vote on the rms GR secret.

For what is worth; let me bring a slightly dissonant voice in that discussion. 
While abundantly aware of the concerns around making project member votes 
public after this GR, I'd rather let our usual processes finish their course; 
I'd rather let the secretary proceed with publishing the tally sheet as usual 
after the vote has ended.

I am of course highly concerned by reports of members declining to vote in 
fear of retaliation by individuals or organizations external to the project. 
By no means do I intend to neglect the gravity of what these external menaces 
on our project members' sanity and health are.

But I'm quite concerned by the prospect of making this vote a special case in 
our grand scheme of things. Looking at past GRs (specifically, the systemd 
ones), some have been quite divisive, and also had important external 
pressures, including on individual project members. I don't feel we're in a 
_much_ different situation now, for this GR.

I don't think changing our 25+ years worth of GR practice (and GR tradition) 
*right in the middle of a vote* will do any good; not internally, and not 
externally.

Do I think we should have procedures to decide _before a vote is called_ 
whether individual votes will be published after the vote? Absolutely; very 
clearly. But do I thing we should do this change for that very vote, while 
some votes have already been tallied, by "consensus" decision and/or pressure 
on the secretary? No. Clearly not.

One other important point I think really matters: I am sad to acknowledge that 
I don't think I can trust *all* the project members to keep a privately shared 
tally sheet private. We're a _huge_ crowd of voters, and the vote is likely to 
be going to draw strong divide lines; I wouldn't be surprised by fleets of 
resignations after the (aggregated, public) results are published. (Clearly, 
if some of the options win, I would resign myself). Where I'm going at it that 
emotions are high currently, and I wouldn't be surprised (but very sad) if a 
privately shared tally would be leaked, either publically, or privately to 
external, potentially hostile actors. If we do make the votes private for the 
larger public, I don't see a viable way to make them private to ourselves 
only, while keeping our members sufficiently safe from external harassment. 

Finally, dear Kurt, as project secretary; I know I wouldn't enjoy filling this 
role in these moments, and I send you all the positive vibes I can to 
hopefully make these decisions easier to take for you. You have all my trust.

Best regards,
OdyX

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

Printing from Linux (was: Re: Nuance Regarding RMS)

[Didier 'OdyX' Raboud]

I'm well aware the discussion period is over, but I can't let that one pass, 
so bear with me.

Le vendredi, 2 avril 2021, 18.19:02 h CEST Barak A. Pearlmutter a écrit :
> Fifty years ago a laserprinter didn't work right because of some
> software issue and he couldn't fix it because the software in that
> car-sized prototype Xerox laserprinter was proprietary and it pissed
> him off and he vowed that one day *nobody* will be in that position.
> He's holding fast to that vow. He still works tirelessly, every day,
> to bring us that vision.
> 
> I've got a stupid Dell laserprinter 80cm from me and it doesn't work
> right because of some stupid software issue and I can't fix it because
> I don't have the source code. Nobody cares. Well, except RMS. He
> cares.

As Debian Printing Team member, when you state that "Nobody cares" (about 
printing from Linux systems), I don't receive it particularily well [0]. Not 
for our work specifically (we're "just" maintainers), but for the tireless 
work from upstreams who brought the ecosystem up to a point at which I'm not 
afraid to claim that Debian Bullseye will ship with the best (Linux) printing 
user experience _ever_. Of course, this is not due to the release of FLOSS 
printer firmware [1], but rather to standardization of network (and wire) 
protocols, lots of software architecturing and writing, as well as intense 
lobbying to reach a point where virtually all newly sold printers support open 
standards, that are now supported "driverless", directly from standard Debian 
installs [2]. (Debian's not unique in that regard, it's all free software).

Although the initial trigger for the launch of the Free Sofware Foundation 
(and movement) might indeed have been a frustration with printers [3], from 
where I stand, I can reasonably state that OpenPrinting [4] _does_ care. 
Specifically, Till Kamppeter and Michael Sweet (among countless others) _do_ 
care. And their work has brought _immense_ progress for the specific question 
of "freedom to use printers in ways we see fit". I'm certainly not an expert 
on the history of these organizations, but it seems (to me) that we're at this 
point thanks to tireless efforts and industrial pragmatism from OpenPrinting 
(hence the Linux Foundation), the IEEE-ISTO Printer Working Group, Apple [5] 
and certainly others; but not particularily thanks to the FSF (or RMS) 
(notwithstanding the FSF's contribution to the principles of Free Software, of 
course).

RMS and the FSF certainly care for Free Software, but I'd refrain from using 
the "printers are bad proprietary machines, and printing from Linux sucks" 
example to illustrate that point: this particular problem was (mostly) solved 
by others; by turning this problem into "(recent) printers are bad proprietary 
machines that (mostly) follow open standards, hence printing from all OS' 
using (free) software implementing these standards is (mostly) flawless".

--
OdyX


[0] But I also took no offense, as I also read it as a hyperbole of sorts.
[1] But in an era where most electronics from dishwashers to wireless routers
to computer phones are essentially closed boxes of non-FLOSS
software+firmware+hardware combinations, insisting for the release of
FLOSS printer _firmware_ is not an effective way to reach our goals.
[2] https://wiki.debian.org/DriverlessPrinting
[3] 
https://www.fsf.org/blogs/community/201cthe-printer-story201d-redux-a-testimonial-about-the-injustice-of-proprietary-firmware
[4] Currently a free software organization under The Linux Foundation.
[5] Yes, Apple acquired and then maintained CUPS under a FLOSS license for
quite some time!

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

Re: Secret ballot and RMS Resolution

[Didier 'OdyX' Raboud]

1 avril 2021 17:01 "Kurt Roeckx"  a écrit:
> On Thu, Apr 01, 2021 at 04:40:59PM +0200, Stefano Zacchiroli wrote: 
>> On Thu, Apr 01, 2021 at 12:42:01PM +, Jean Duprat (Avignon) wrote:
>> Votes in leadership elections are kept secret even after the end of
>> the voting period for obvious reasons: by knowing that the ballot is
>> secret, voters can feel free to express their opinion as they see
>> fit. This constitutional guarantee sadly does not apply to General
>> Resolutions.
>> 
>> I think we're at opposite ends of the voting spectrum here on this
>> matter, but I share your concern.
>> 
>> In fact, I think that *any* position taken in this vote could result in
>> targeted harassment of the voters.
>> 
>> As this is a vote on a person (even if an indirect one, in the sense
>> that is not an election), most democratic systems will treat it as a
>> vote where ballots should be secret. But I fear that the Debian
>> Constitution ties the hands of the secretary here, or am I missing
>> something here Kurt?
> 
> This would be a vote I would also like to see as secret. The
> constitution says:
> 3. Votes are taken by the Project Secretary. Votes, tallies, and
> results are not revealed during the voting period; after the vote
> the Project Secretary lists all the votes cast. The voting period
> is 2 weeks, but may be varied by up to 1 week by the Project
> Leader.
> 
> While for DPL election it says:
> 5. The next two weeks are the polling period during which Developers
> may cast their votes. Votes in leadership elections are kept
> secret, even after the election is finished.
> 
> You could say that "all the votes cast" could mean what was voted,
> now who voted what, but I think that conflicts with the intention
> of the text.

Could we get a Constitution Amendment GR passed along the lines of the
following?

Provided that 2*Q developers demand it, votes are kept secret after
the vote ended.

(en_* advice welcome)

--
  OdyX

Re: How to leverage money to accomplish high impact Debian projects

[Didier 'OdyX' Raboud]

Le vendredi, 19 mars 2021, 17.49:54 h CET Louis-Philippe Véronneau a écrit :
> On 2021-03-19 08 h 02, Raphael Hertzog wrote:
> >> I've been telling a few people last month that I would really liked to
> >> have an Enterprise Edition Online MiniDebConf, unfortunately I don't
> >> have any time/energy to instigate that currently.
> > 
> > Something for a Debian fellow that we could hire ;-)
> 
> I for one would be less motivated to help with videoteam tasks if I knew
> someone was paid to organise a miniconf.

Would your motivation also be affected if an individual was paid only for a 
specific task that noone in the team found particularily interesting to do?

(I don't know much about how the videoteam works, so I don't know if that's a 
good example, but let's see…) For example, what if someone (paid) handled the 
storage and timely shipping of all the hardware, as well as the actual 
ordering of new hardware, leaving the (what I assume is the more interesting 
part) configuring, design and conception of the system to volunteers?

OdyX


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

Re: How can we make Debian packaging more standardised?

[Didier 'OdyX' Raboud]

Le lundi, 22 mars 2021, 21.09:05 h CET Jonas Meurer a écrit :
> Why not have an officially delegated Debian Project Board that meets
> once a week (or every two weeks) and discusses and tackles painpoints in
> the project at large?

Or an elected one.

-- 
OdyX

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

Re: Should the project hire one or two persons to help the DPL?

[Didier 'OdyX' Raboud]

Le vendredi, 19 mars 2021, 10.38:08 h CET Raphael Hertzog a écrit :
> There are quite a few software projects that have hired staff to help
> smooth the internal working of organizations, I know at least of Django
> with its fellowship program:
> https://www.djangoproject.com/fundraising/#fellowship-program
> 
> The current resources of Debian means that we can confidently hire at least
> one or two fellows that would work under the direction of the DPL
> and not be in troubles for many years.

Thank you for bringing this topic on the table, I consider it very important 
for the long-term sustainability of the project!

> To the other DD, would you second a GR to allow the DPL to hire one
> or two persons to help him lead the project? What kind of safeguards would
> be needed?

Yes, definitely. (tl; dr: in fact it turns out I rather disagree)

But I liked last year's focus put by Brian about this idea; I don't see the 
whole solution being only "having staff on a payroll", but it's rather a 
larger structural question.

So, to take a (hopefully small) step back, for me the question we shall ask 
ourselves is: what organizational structure, with what roles accountable for 
which areas of responsibility, with what material support or financial 
compensation is best suited to serve our larger organization's purpose and 
long- (and mid-)term goals?

Our constitution has established a "large body of peers, with one elected 
leader delegating power, no financial compensations" structure, which I think 
served us moderately well until some years ago, but not sufficiently well 
anymore.

From other non-IT/non-Debian experience, I have also witnessed (in my very 
privileged socio-cultural environment, so take that with a grain of salt) that 
the way people spend their volunteer time has also evolved quite a lot in the 
past 10 years: people don't engage in their communities the same way they did 
a decade ago. They don't necessarily spend less time overall, but it's much 
more cluttered, spread among more organizations, causes and concerns. And 
volunteers have different expectations in terms of recognition, of 
compensation, and of commitment. Applying this to our organization, I feel 
that volunteering to be the DPL for a year doesn't have the same meaning as it 
had 10 years ago; the responsibilites, exposure and expected commitment have 
changed, but the "job description" hasn't.

Now, notwithstanding the discussion about making Debian a legal entity world-
wide, I think it's about time for Debian to adopt a "more than just one 
perfect elected individual" leadership structure (I'm well aware it took all 
sorts of names over the years, ranging from DPL Board to DPL advisory 
committee, etc etc). It's really not uncommon for organizations to have 
Boards, with only elected roles, and that's the direction I'd lean into; we 
need a larger body of elected roles to take on the set of tasks currently 
given to the DPL (probably a larger one too). So I think we need to start 
talking concretely about the number of roles, their purpose and 
accountabilities, their names, the length of their mandates, etc etc. THEN, 
with such a body in place, with elected roles filled by volunteers, I think we 
can start talking about hiring.

(OK, that turned out to be a larger step back than I expected, sorry).

If, and when, Debian (likely through the DPL, or directly) opens a paid 
position for a specific role, we need to be abundantly clear about the job 
description, the limits of the role, the reporting expectations, etc etc. I 
would definitely not "allow the DPL to hire to help them lead the project", 
but I would rather "allow the DPL to hire somebody to fill a specific 
(eventually wide) non-leadership support role". In other terms; I don't think 
we want to have paid staff with actual decision powers. I do think we might 
agree to having paid staff *without* actual decision power, but providing 
administrative support for example.

Regarding Ganneff and gregoa's concerns (which I share to some extent); I know 
of many non-IT organizations which have these types of structures, and it 
works usually quite well, because the formal decision powers reside in elected 
volunteers, while loads of administrative, directed, support work is done by 
paid staff. Of course, paid staff ends up spending quite some more time on 
some topics, and gain deeper knowledge, reputation, and can end up 
overshadowing the elected volunteers who can't manage / afford to dive as deep 
in some subjects; so that's exactly why we ought to define the paid staff's 
mandate precisely, with these caveats in mind.

Anyway; in short; I think a project the size of Debian needs reliable and  
accessible administrative support paid staff, to free the leadership (and lots 
of non-leadership) roles from this burden, and to help all volunteers focus on 
what they do best instead of being drowned in administrativia and accounting 
loopholes.

-- 
OdyX

Re: Discussion on eventual transition away from source packages

[Didier 'OdyX' Raboud]

Le vendredi, 22 mars 2019, 09.32:55 h CEST Lucas Nussbaum a écrit :
> I'm probably missing something, but it doesn't sound like a lot of work
> to me? It's "just" a service that:
> - gets notified of the existence of a git repo + tag to upload
> - fetches that git repo + tag
> - checks signature / confirm that the GPG key owner is allowed to upload
>   that package
> - build a Debian source package
> - uses a slightly different path to accept the source package (because
>   the .dsc and .changes wouldn't be signed)
> 
> This could exist in parallel to the current upload scheme.
> 
> And it's a terrible idea, but it could even be implemented as a
> third-party service, run by a DD that would do that and sign+upload the
> source package using the DD's own GPG key.

Eh. I have fond memories of DebConf11 discussions bout pretty much this idea. 
The point so far has been that no DD wanted to "risk" their GPG key for that 
(and/or risk getting hit by social blame triggered by automated/wrong 
uploads).

Times have changed, maybe it could be done now afterall. :-)

-- 
OdyX

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

Re: Q: NEW process licence requirements

[Didier 'OdyX' Raboud]

Le dimanche, 1 avril 2018, 00.11:58 h CEST Adrian Bunk a écrit :
> Sat, Mar 31, 2018 at 11:03:00PM +0200, Joerg Jaspert wrote:
> > Like it or not, but there *is* a big difference in the project making
> > something available for the big wide world (which a public NEW would
> > be), or a user putting it somewhere readable for everyone even though
> > the latter might be using project resources too.
> 
> What is the big (legal) difference between distributing something
> from the Debian group on the Debian machine salsa.debian.org, and
> distributing the same from a different Debian machine?

People are mirroring the Debian pool under a set of well-understood norms, as 
that's what the Debian project "produces" (think of the mirror network, people 
pressing CDs, etc). A .deb in a Debian suite in the Debian pool isn't 
comparable to a random .deb, as only the former has the Debian-seal-of-
approval (DFSG & fulfills releasability criterias).

Salsa is not meant to be mirrored by third-parties, and really shouldn't.

Cheers,
OdyX

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

Re: Iain Lane's proposal

[Didier 'OdyX' Raboud]

Le mercredi, 21 septembre 2016, 21.17:19 h CEST Steve M. Robbins a écrit :
> 
> 
> Title: debian-private shall remain private
> 
> The text of the GR is replaced with the following.
> 
>   1. The 2005 General Resolution titled "Declassification of
>  debian-private list archives" is repealed.
>   2. There shall be no declassification of any portion of the
>  debian-private archives, except in the following circumstances.
>  2a. Participants may declassify their own material.
>  2b. Participants may declassify the material of others where
>  consent has explicitly been given by the authors of all of the
>  material being declassified.
>   3. Participants are reminded to use -private only when necessary.
> 
> 

I second this proposal as well. This seconding doesn't imply retracting of my 
previous seconding, nor infers any clue about my ranking of these options, I 
just want them on the ballot.

-- 
Cheers,
OdyX

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

Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list

[Didier 'OdyX' Raboud]

Le jeudi, 1 septembre 2016, 23.15:05 h CEST Gunnar Wolf a écrit :
> === BEGIN GR TEXT ===
> 
> Title: Acknowledge that the debian-private list will remain private.
> 
> 1. The 2005 General Resolution titled "Declassification of debian-private
>list archives" is repealed.
> 2. In keeping with paragraph 3 of the Debian Social Contract, Debian
>Developers are strongly encouraged to use the debian-private mailing
>list only for discussions that should not be disclosed.
> 
> === END GR TEXT ===

Seconded.


-- 
Cheers,
OdyX

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

Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list

[Didier 'OdyX' Raboud]

Le dimanche, 11 septembre 2016, 11.01:09 h CEST Anthony Towns a écrit :
> In that sense, my reading of the original version of the GR that just
> failed was pretty much "eh, we don't care that much about transparency
> when it comes to ourselves and it's time we admit that". Which is fine,

I supported the previous GR, and will second Gunnar's, not because I think "we 
don't care much about transparency", but rather because I think time has now 
shown that the process as decided in 2005 was unrealistic and impractical.

I now also tend to think that we, as a collection of individuals, also need 
some sort of "safe space" to discuss certain things, that can't be public. 
Some of these things can't immediately be public, and some other things can't 
ever. Separating both is a herculean task, which is why I'm not suprised noone 
has really started, especially not within the 2005 GR canvas. d-private can 
only be a good safe-space if its privacy promise will hold forever.

In short, I see value in having the projet say "d-private is our internal 
communication channel; it's an explicit step away from our transparency 
promise, but we value its importance as a safe-space for our members, and as a 
medium to discuss sensitive and/or private topics. We promise (and have all 
members as testimonials) to restrict it's usage to topics that really need to 
be private"

-- 
Cheers,
OdyX

Re: more GRs to come (Re: Current GRs clarification)

[Didier 'OdyX' Raboud]

Hi Holger,

Le lundi, 8 août 2016, 13.34:07 h CEST Holger Levsen a écrit :
> So, I hereby announce that I'll propose another GR to "depeal the GR
> of 2005 and burry the idea of systematically declassifying debian-private"
> if *this* GR turns out to result in "further discussion".

Here we are. :) Are you still interested in proposing this new GR?

-- 
Cheers,
OdyX


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

Re: Amendment to Proposed GR: Declassifying parts of -private of historical interest

[Didier 'OdyX' Raboud]

Le mardi, 9 août 2016, 00.14:49 h CEST Nick Phillips a écrit :
> To be clear - I do not believe that it would be acceptable for any message
> to be made public without explicit approval of the author. A mere lack of
> objection is not enough - however it does seem to me that this is a road
> that some are keen to travel down.

Please note that the current process, as decided by GR 2005/002 [0] is as 
follows (emphasis and ellipsis mine):

> The team will *automatically* declassify and publish posts made to that list
> that are three or more years old, with the following exceptions:
> - the author (…) in messages being reviewed will be contacted, and allowed
>   between four and eight weeks to comment;
> (…)
> - requests by the author of a post for that post not to be published will be
>   honored;

So you do not believe "it would be acceptable for any message to be made 
public without explicit approval of the author", but the project has _not_ 
decided to make past messages' declassification dependent on explicit approval; 
only on "4-8 weeks time, no objection raised".

The current process _allows_ declassification of posts from unreachable, 
incapacitated or dead participants.

-- 
Cheers,
OdyX

[0] https://www.debian.org/vote/2005/vote_002.en.html


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

Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution

[Didier 'OdyX' Raboud]

Le vendredi, 22 juillet 2016, 12.28:38 h CEST Jakub Wilk a écrit :
> Luckily there's an awesome non-gendered and non-furnitured alternative:
> 
> President

Point is, the TC  is constitutionally only about half-surrogating 
MIA DPLs and breaking ties. The non-constitutional part of the duty is much 
more about making meetings happen, running the administrativia, etc. In short, 
it's much more of a 'Secretary' role, rather than a 'President' role.

But we already have a secretary role in the project.

So we fall back (can we say "sit"?) on furnitured 'Chair'.

-- 
Cheers,
OdyX

Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution

[Didier 'OdyX' Raboud]

Le vendredi, 8 juillet 2016, 15.27:56 Margarita Manterola a écrit :
> === BEGIN GR TEXT ===
> 
> Title: Replace "Chairman" with "Chair" throughout the Debian
> Constitution
> 
> All appearances of the word Chairman shall be replaced with the word
> Chair.
> 
> === END GR TEXT ===

Seconded; thanks!

-- 
Cheers,
OdyX

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

Re: Proposed GR: Acknowledge that the debian-private list will remain private

[Didier 'OdyX' Raboud]

Le jeudi, 7 juillet 2016, 12.31:40 Don Armstrong a écrit :
> That puts a whole lot of stop energy in front of anyone who actually
> is interested in trying to declassify -private, though; they'd have
> to come up with a method, bikeshed the method, and then propose a
> vote which still might not succeed.

The previous GR apparently hasn't removed enough of the stop-energy 
either; it is time for us to acknowledge that it is not workable.

I also kinda disagree that in the absence of a GR (aka before the 05-002 
GR, or after we'd have repeal'ed it) there are real active blockers 
against declassification.

Afterall, "technically", our promise of privacy for d-private is only 
regulated by the developers-reference that says, in §4.1.3:
>  is a special mailing list for
> private discussions amongst Debian developers. It is meant to be used
> for posts which for whatever reason should not be published publicly.
> As such, it is a low volume list, and users are urged not to use
>  unless it is really necessary.
> Moreover, do _not_ forward email from that list to anyone.

I'd argue that, barring any specific GR, the declassification of d-
private is technically something of the jurisdiction of the listmasters.
I trust their ability to come up with a declassification procedure that 
respects the best interests of the back-then writers and those of the 
project.

We should now acknowledge that the work to declassify d-private archives 
would be very sensitive, complex and would need quite a load of good 
judgment calls. Given the assumption that the most interesting part is 
the early days (aka pre-2005 GR), we have no process anyhow.

In short, I think that no matter the process, declassification would not 
happen, as it's a too complex problem. I'm fine with us taking that 
position.

-- 
Cheers,
OdyX

Re: Proposed GR: Acknowledge that the debian-private list will remain private

[Didier 'OdyX' Raboud]

Le jeudi, 7 juillet 2016, 14.39:21 Holger Levsen a écrit :
> (should the text be reworded, I'd like to propose s#Debian
> Developers#Debian members#g.)

Point is; only "Developers" (the term our constitution uses) are 
supposed to ever have been subscribed to d-private.

That said, we could amend the constitution in a separate GR.

-- 
Cheers,
OdyX

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

Re: Proposed GR: Acknowledge that the debian-private list will remain private

[Didier 'OdyX' Raboud]

Le jeudi, 7 juillet 2016, 15.37:08 Nicolas Dandrimont a écrit :
> === BEGIN GR TEXT ===
> 
> Title: Acknowledge that the debian-private list will remain private.
> 
> 1. The 2005 General Resolution titled "Declassification of
>debian-private list archives" is repealed.
> 2. In keeping with paragraph 3 of the Debian Social Contract, Debian
>Developers are strongly encouraged to use the debian-private
>mailing list only for discussions that should not be disclosed.
> 
> === END GR TEXT ===

Seconded.

Thank you for all the people at DebConf16 (more precisely so, in the 
pub) that helped review this text.

-- 
Cheers,
OdyX

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

Re: Results for Update Standard Resolution Procedure

[Didier 'OdyX' Raboud]

Le jeudi, 17 décembre 2015, 09.43:20 Didier 'OdyX' Raboud a écrit :
> Dear Secretary,
> (CC'ing the TC chair, as per §7.2)
> 
> Le dimanche, 13 décembre 2015, 00.00:05 devotee a écrit :
> > This message is an automated, unofficial publication of vote
> > results.
> > 
> > Official results shall follow, sent in by the vote taker, namely
> > Debian Project Secretary
> > 
> > This email is just a convenience for the impatient.
> 
> Is there anything one could do to help getting the official
> publication of the vote results here?

Thanks for the mails to debian-devel-announce [0,1].

The doc-debian as well as the web version of the constitution should be 
amended now. Can any DD do that, or does it need to be the secretary?

-- 
Cheers,
OdyX

[0] https://lists.debian.org/20151226213203.ga1...@roeckx.be
[1] https://lists.debian.org/20151226233514.ga8...@roeckx.be 

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

Re: Results for Update Standard Resolution Procedure

[Didier 'OdyX' Raboud]

Dear Secretary,
(CC'ing the TC chair, as per §7.2)

Le dimanche, 13 décembre 2015, 00.00:05 devotee a écrit :
>   This message is an automated, unofficial publication of vote results.
> Official results shall follow, sent in by the vote taker, namely
> Debian Project Secretary
> 
>   This email is just a convenience for the impatient.

Is there anything one could do to help getting the official publication 
of the vote results here?

Cheers, OdyX

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

Re: General Resolution: Fix Minor Bugs in Constitution

[Didier 'OdyX' Raboud]

Hi Sam,

thanks for this relaunch.

Le lundi, 26 octobre 2015, 21.22:46 Sam Hartman a écrit :
>- GENERAL RESOLUTION STARTS -
>
>
>Constitutional Amendment: TC Supermajority Fix
>
>Prior to the Clone Proof SSD GR in June 2003, the Technical
>Committee could overrule a Developer with a supermajority of 3:1.
>
>Unfortunately, the definition of supermajorities in the SSD GR has
>an off-by-one error.  In the new text a supermajority requirement is
>met only if the ratio of votes in favour to votes against is strictly
>greater than the supermajority ratio.
>
>In the context of the Technical Committee voting to overrule a
>developer that means that it takes 4 votes to overcome a single
>dissenter.  And with a maximum committee size of 8, previously two
>dissenters could be outvoted by all 6 remaining members; now that
>is no longer possible.
>
>This change was unintentional, was contrary to the original intent
>of the Constitution, and is unhelpful.
>
>For the avoidance of any doubt, this change does not affect any
>votes (whether General Resolutions or votes in the Technical
>Committee) in progress at the time the change is made.
> 
>Therefore, amend the Debian Constitution as follows:
> Index: doc/constitution.wml
> ===
> --- doc/constitution.wml(revision 10982)
> +++ doc/constitution.wml(working copy)
> @@ -913,7 +913,7 @@
> 
>   
>   
>   
>An option A defeats the default option D by a
>majority
> 
> -  ratio N, if V(A,D) is strictly greater than N * V(D,A).
> +  ratio N, if V(A,D) is greater or equal to N * V(D,A) and 
> V(A,D) is strictly greater than V(D,A).
>   
>   
>   
>If a supermajority of S:1 is required for A, its
>majority ratio
>
>Constitutional Amendment: Fix duplicate section numbering.
>
>The current Debian Constitution has two sections numbered A.1.
>This does not currently give rise to any ambiguity but it is
>undesirable.
>
>Fix this with the following semantically neutral amendment:
> - Renumber the first section A.1 to A.0.
>
>- GENERAL RESOLUTION ENDS -

Seconded.

Cheers,
OdyX

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

Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering

[Didier 'OdyX' Raboud]

Le mardi, 1 septembre 2015, 12.20:05 Ian Jackson a écrit :
> Kurt Roeckx writes ("Re: GR: Constitutional Amendment to fix an off-
by-one error and duplicate section numbering"):
> > On Wed, Aug 26, 2015 at 10:12:41PM +0200, Andreas Barth wrote:
> > >(i) Delete most of A.6(3) (which implemented the supermajority
> > >
> > >by dropping options at an early stage).  Specifically:
> > >   - Move A.6(3)(1) (the definition of V(A,B)) to a new
> > >   subparagraph
> > >   
> > > A.6(3)(0) before A.6(3)(1).
> > >   
> > >   - Remove the rest of A.6(3) entirely, leaving A.6(2) to be
> > >   
> > > followed by A.6(4).
> 
> As the original author of this wording, this is my fault.  Sorry.
> 
> > Those 2 things conflict.  First you create a A.6(3)(0), then you
> > say there is no A.6(3) left.  Please clarify what you mean.
> 
> I think this is a numbering problem:
> 
>   (i) Delete most of A.6(3) (which implemented the supermajority
>   by dropping options at an early stage).  Specifically:
>- Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph
>  A.6(3)(0) before A.6(3)(1).
>^
> 
> I think I intended that this should read A.6(4)(0).
> ^^^
> That puts the definition of V(A,B) immediately before its first use in
> A.6(4)(1).

So would the attached diff match your intent [0]?

It'd be good if you (as well as Andreas, as GR proposer) could comment 
on the full series of commits in that repository, to make sure we all 
agree on a constitution diff.

Cheers,
OdyX

[0] 
http://anonscm.debian.org/cgit/users/odyx/supermajority-GR.git/commit/?id=0480d88e4ec36350541339239255261e341865cd>From 0480d88e4ec36350541339239255261e341865cd Mon Sep 17 00:00:00 2001
From: Didier Raboud 
Date: Thu, 27 Aug 2015 11:28:09 +0200
Subject: Delete most of A.6(3) (which implemented the supermajority by
 dropping options at an early stage).  Specifically:

- Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph
  A.6(3)(0) before A.6(3)(1).
- Remove the rest of A.6(3) entirely, leaving A.6(2) to be
  followed by A.6(4).
---
 constitution.txt | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/constitution.txt b/constitution.txt
index bb8535d..26ac4db 100644
--- a/constitution.txt
+++ b/constitution.txt
@@ -573,14 +573,8 @@ A. Standard Resolution Procedure
 2. If the ballot has a quorum requirement R any options other than the
default option which do not receive at least R votes ranking that
option above the default option are dropped from consideration.
-3. Any (non-default) option which does not defeat the default option
-   by its required majority ratio is dropped from consideration.
- 1. Given two options A and B, V(A,B) is the number of voters who
-prefer option A over option B.
- 2. An option A defeats the default option D by a majority ratio
-N, if V(A,D) is strictly greater than N * V(D,A).
- 3. If a supermajority of S:1 is required for A, its majority
-ratio is S; otherwise, its majority ratio is 1.
+3. Given two options A and B, V(A,B) is the number of voters who
+   prefer option A over option B.
 4. From the list of undropped options, we generate a list of pairwise
defeats.
  1. An option A defeats an option B, if V(A,B) is strictly greater
-- 
cgit v0.11.2

Re: General resolution: Changes to the Standard Resolution Procedure

[Didier 'OdyX' Raboud]

Hi Axel,

(CC'ing aba, as GR proposer).

Le lundi, 31 août 2015, 10.26:18 Axel Beckert a écrit :
> Kurt Roeckx - Debian Project Secretary wrote:
> > https://www.debian.org/vote/2015/vote_002
> 
> Please either do not use the word combination "fencepost bug" at all
> or explain its meaning.

These words are in the original GR proposal [0], so this would need to 
be amended for clarity.

> As far as I could find out it refers to a political joke (!) in the
> USA comparing a "fencepost turtle" to e.g. George W. Bush or Sarah
> Palin. I don't think such a term is suitable for being used in a
> Debian GR.
> 
> (In case I'm wrong with my interpretation of that term, it proves my
> point even more: Please either don't use it or explain it because the
> term is obviously unclear.)

I understand this "fencepost bug" to refer to the fencepost error [1], 
quoting Wikipedia:

> A fencepost error (occasionally called a telegraph pole or lamp-post
> error) is a specific type of off-by-one error. The following problem
> illustrates the error:
>
> > If you build a straight fence 30 meters long with posts spaced 3
> > meters apart, how many posts do you need?
> 
> The intuitive answer 10 is wrong. The fence has 10 sections, but 11
> posts.

Is it clearer, and enough for you, or would you like to propose a GR 
amendment?

Cheers, OdyX

[0] https://lists.debian.org/20150826201241.gf9...@mails.so.argh.org
[1] https://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error

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

Re: General resolution: Changes to the Standard Resolution Procedure

[Didier 'OdyX' Raboud]

Andreas: GR amendment proposal below.

Le lundi, 31 août 2015, 11.04:59 Axel Beckert a écrit :
> I would have preferred if "off-by-one" would have been used instead of
> "fencepost" as in the subject of the original GR proposal. That term
> is later missing in the announcement by Kurt as well as on
> https://www.debian.org/vote/2015/vote_002
> 
> "off-by-one" is very common, self-descriptive and well-known even
> among non-native speakers. "fencepost" is not. (…)
> 
> > or would you like to propose a GR amendment?
> 
> As far as I understand this would mean proposing an alternative choice
> for the voter. In that case, the damage is already done and cannot be
> undone. This IMHO only makes sense if I'd propose different
> semantics.

The GR proposer can accept formal wording changes directly on his 
amendment proposal (§A.1.5).

I think the change would clarify the GR for more voters than only you, 
so I'm hereby asking Andreas whether he'd accept a wording change on his 
GR proposal as follows (%s/fencepost/off-by-one/g), under §A.1.5:

--- a/vote_002
+++ b/vote_002
@@ -7,7 +7,7 @@
   Committee could overrule a Developer with a supermajority of 3:1.

   Unfortunately, the definition of supermajorities in the SSD GR has a
   [-fencepost-]{+off-by-one+} error.  In the new text a supermajority
   requirement is met only if the ratio of votes in favour to votes
   against is strictly greater than the supermajority ratio.

@@ -78,9 +78,9 @@
   votes (whether General Resolutions or votes in the Technical
   Committee) in progress at the time the change is made.

   The effect is to fix the [-fencepost-]{+off-by-one+} bug, and
   arrange that failing asupermajority voids the whole decision (or
   makes it advisory), rather than promoting another option.  The
   [-fencepost-]{+off-by-one+} bugfix will also have a (negligible)
   effect on any General Resolutions requiring supermajorities.  And
   after this change the TC chair can choose a non-default option even
   if it is tied with a default

Cheers,
OdyX

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

Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering

[Didier 'OdyX' Raboud]

Le jeudi, 27 août 2015, 10.04:50 Stefano Zacchiroli a écrit :
 On Wed, Aug 26, 2015 at 10:12:41PM +0200, Andreas Barth wrote:
  we (as the Technical Committee) have encountered two bugs in the
  constitution which we like to fix. For this reason, I propose the
  following General Resolution to change the constitution.
 
 Can we have a diff and a word-diff please? That would help a lot in
 better reviewing the proposal.

They're hereby attached, I've pushed the git repository that I've used 
for creating these there too:

http://anonscm.debian.org/cgit/users/odyx/supermajority-GR.git/

Andreas, it would make sense to confirm that this is your understanding 
of the GR proposal. In particular, I was puzzled when trying to 
interpret:

(i) Delete most of A.6(3) (which implemented the supermajority
by dropping options at an early stage).  Specifically:
- Move A.6(3)(1) (the definition of V(A,B)) to a new subparagraph
  A.6(3)(0) before A.6(3)(1).
- Remove the rest of A.6(3) entirely, leaving A.6(2) to be
  followed by A.6(4).

Cheers,
OdyXdiff --git a/constitution.txt b/constitution.txt
index 6204fbe..4b9b499 100644
--- a/constitution.txt
+++ b/constitution.txt
@@ -86,7 +86,9 @@
 3. Make or override any decision authorised by the powers of the
Project Leader or a Delegate.
 4. Make or override any decision authorised by the powers of the
-   Technical Committee, provided they agree with a 2:1 majority.
+   Technical Committee, provided they agree with a 2:1 majority;
+   failing that, the prospective winning resolution text becomes a
+   non-binding statement of opinion.
 5. Issue, supersede and withdraw nontechnical policy documents and
statements.
These include documents describing the goals of the project, its
@@ -260,10 +262,11 @@
 4. Overrule a Developer (requires a 3:1 majority).
The Technical Committee may ask a Developer to take a particular
technical course of action even if the Developer does not wish to;
-   this requires a 3:1 majority. For example, the Committee may
-   determine that a complaint made by the submitter of a bug is
-   justified and that the submitter's proposed solution should be
-   implemented.
+   this requires a 3:1 majority; failing that, the prospective winning
+   resolution text becomes a non-binding statement of opinion. For
+   example, the Committee may determine that a complaint made by the
+   submitter of a bug is a justified and that the submitter's proposed
+   solution should be implemented.
 5. Offer advice.
The Technical Committee may make formal announcements about its
views on any matter. Individual members may of course make informal
@@ -477,7 +480,7 @@ A. Standard Resolution Procedure
These rules apply to communal decision-making by committees and
plebiscites, where stated above.
 
-  A.1. Proposal
+  A.0. Proposal
 
The formal procedure begins when a draft resolution is proposed and
sponsored, as required.
@@ -531,8 +534,6 @@ A. Standard Resolution Procedure
ballot that includes an option for the original resolution, each
amendment, and the default option (where applicable).
 2. The default option must not have any supermajority requirements.
-   Options which do not have an explicit supermajority requirement
-   have a 1:1 majority requirement.
 3. The votes are counted according to the rules in A.6. The default
option is Further Discussion, unless specified otherwise.
 4. In cases of doubt the Project Secretary shall decide on matters of
@@ -573,14 +574,8 @@ A. Standard Resolution Procedure
 2. If the ballot has a quorum requirement R any options other than the
default option which do not receive at least R votes ranking that
option above the default option are dropped from consideration.
-3. Any (non-default) option which does not defeat the default option
-   by its required majority ratio is dropped from consideration.
- 1. Given two options A and B, V(A,B) is the number of voters who
-prefer option A over option B.
- 2. An option A defeats the default option D by a majority ratio
-N, if V(A,D) is strictly greater than N * V(D,A).
- 3. If a supermajority of S:1 is required for A, its majority
-ratio is S; otherwise, its majority ratio is 1.
+3. Given two options A and B, V(A,B) is the number of voters who
+   prefer option A over option B.
 4. From the list of undropped options, we generate a list of pairwise
defeats.
  1. An option A defeats an option B, if V(A,B) is strictly greater
@@ -602,10 +597,22 @@ A. Standard Resolution Procedure
 equal to V(B,Y) and V(X,A) is greater than V(Y,B).
  2. A weakest defeat is a defeat that has no other defeat weaker
 than it. There may be more than one such 

Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering

[Didier 'OdyX' Raboud]

Le mercredi, 26 août 2015, 22.12:41 Andreas Barth a écrit :
- GENERAL RESOLUTION STARTS -
 
Constitutional Amendment: TC Supermajority Fix
 
Prior to the Clone Proof SSD GR in June 2003, the Technical
Committee could overrule a Developer with a supermajority of 3:1.
 
Unfortunately, the definition of supermajorities in the SSD GR has
a fencepost error.  In the new text a supermajority requirement is
met only if the ratio of votes in favour to votes against is
strictly greater than the supermajority ratio.
 
In the context of the Technical Committee voting to overrule a
developer that means that it takes 4 votes to overcome a single
dissenter.  And with a maximum committee size of 8, previously two
dissenters could be outvoted by all 6 remaining members; now that
is no longer possible.
 
This change was unintentional, was contrary to the original intent
of the Constitution, and is unhelpful.
 
Additionally, following discussion of the supermajority mechanism
within the project, it was realised that certain situations could
cause anomalous results:
 
* The existing rules might result in a GR or TC resolution passing
  which was actually the diametric opposite of the majority view.
 
* The existing rules unintentionally privilege the default option
  in evenly contested TC votes where no supermajority is required,
  possibly encouraging tactical voting.
 
Therefore, amend the Debian Constitution as follows:
 
(i) Delete most of A.6(3) (which implemented the supermajority
by dropping options at an early stage).  Specifically:
   - Move A.6(3)(1) (the definition of V(A,B)) to a new
 subparagraph A.6(3)(0) before A.6(3)(1).
   - Remove the rest of A.6(3) entirely, leaving A.6(2) to be
 followed by A.6(4).
 
(ii) In A.6(8) replace all occurrences of winner with
prospective winner.  Replace wins in which of those options
wins with is the prospective winner.
 
(iii) In A.6(8) add a new sentence at the end:
  + If there is no elector with a casting vote, the default option
  + wins.
 
(iv) Add a new section A.6(9) after A.6(8):
  + 9. 1. If the prospective winner W has no majority requirement,
  +   or defeats the default option D by its majority
  +   requirement, the prospective winner is the actual winner.
  +2. Otherwise, the motion has failed its supermajority with
  +   the consequences set out alongside the majority
  +   requirement (or, if unspecified, the default option
  +   wins).
  +3. An option A defeats the default option D by a
  +   majority of N:M if M * V(A,D) is greater than or equal to
  +   N * V(D,A).
 
(v) In
* 6.1(4) (Technical Commitee power to overrule a Developer)
* 4.1(4) (Developers' use of TC powers by GR) (if another
constitutional amendment has not abolished that
supermajority requirement)
in each case after the N:M majority add
+   ; failing that, the prospective winning resolution text becomes
+   a non-binding statement of opinion.
 
(vi) In A.3(2) delete as follows:
2. The default option must not have any supermajority requirements.
-  Options which do not have an explicit supermajority requirement
-  have a 1:1 majority requirement.
 
For the avoidance of any doubt, this change does not affect any
votes (whether General Resolutions or votes in the Technical
Committee) in progress at the time the change is made.
 
The effect is to fix the fencepost bug, and arrange that failing a
supermajority voids the whole decision (or makes it advisory),
rather than promoting another option.  The fencepost bugfix will
also have a (negligible) effect on any General Resolutions
requiring supermajorities.  And after this change the TC chair can
choose a non-default option even if it is tied with a default
option.
 
Constitutional Amendment: Fix duplicate section numbering.
 
The current Debian Constitution has two sections numbered A.1.
This does not currently give rise to any ambiguity but it is
undesirable.
 
Fix this with the following semantically neutral amendment:
 
 - Renumber the first section A.1 to A.0.
 
- GENERAL RESOLUTION ENDS -

Seconded.

OdyX

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

Re: Q to Neil: PPA

[Didier 'OdyX' Raboud]

Le vendredi, 20 mars 2015, 19.15:24 Neil McGovern a écrit :
 On Sun, Mar 15, 2015 at 09:57:28AM +0100, martin f krafft wrote:
  in your platform, you advocate PPAs and modernising our build and
  infrastructure.
  
  What's the DPL's role in this? Or, put differently, couldn't you
  just start working on this without the DPL hat? Why not? What's the
  difference here?
 
 (…)
 Secondly, the DPL position holds the ability to influence external
 parties more than others. The conversations we can have to try and get
 external interest in getting this (finally) off the ground is much
 easier as DPL than not.

Could you clarify which external parties you intend to influence as DPL 
to push the PPAs and the general modernization of our infrastructure?

I'm genuinely curious about how the PPAs need more a DPL influencing 
external parties rather us getting to work.

Cheers, OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2175679.hYrCcmalrQ@gyllingar

Re: Q to all candidates: dropping SC §5

[Didier 'OdyX' Raboud]

Le mardi, 17 mars 2015, 14.16:09 Paul Wise a écrit :
 Add an extra component that d-i could add to sources.list when
 non-free firmware is needed, instead of adding all of non-free.

I'd very much welcome a solution along these lines: not every package in 
non-free is the same kind of evil for me, and being able to have main + 
non-free/firmware would be a net benefit over being somewhat forced to 
allow the full non-free repository.

Cheers,
OdyX

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

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Didier 'OdyX' Raboud]

Le lundi, 1 décembre 2014, 12.20:25 Stefano Zacchiroli a écrit :
 I'm hereby formally submitting the GR proposal included below between
 dashed double lines, and calling for seconds.  With respect to past
 discussions on the -vote mailing list, this is the proposal code-named
 2-S; see [1,2] for (the last known versions of) alternative proposals.
 
 [1]: https://people.debian.org/~zack/gr-ctte-term-limit/
 [2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
 
 ===
 The Constitution is amended as follows:
 
 ---
 --- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
 +++ constitution.2-S.txt2014-11-21 16:56:47.328071287 +0100
 @@ -299,8 +299,20 @@
 Project Leader may appoint new member(s) until the number of
 members reaches 6, at intervals of at least one week per
 appointment.
 -5. If the Technical Committee and the Project Leader agree they may
 +5. A Developer is not eligible to be (re)appointed to the Technical
 +   Committee if they have been a member within the previous 12 months.
 +6. If the Technical Committee and the Project Leader agree they may
 remove or replace an existing member of the Technical Committee.
 +7. Term limit:
 + 1. On January 1st of each year the term of any Committee member
 +who has served more than 42 months (3.5 years) and who is one
 +of the two most senior members is set to expire on December
 +31st of that year.
 + 2. A member of the Technical Committee is said to be more senior
 +than another if they were appointed earlier, or were appointed
 +at the same time and have been a member of the Debian Project
 +longer. In the event that a member has been appointed more
 +than once, only the most recent appointment is relevant.
  
6.3. Procedure
  
 ---
 
 As a transitional measure, if this GR is passed after January 1st, 2015,
 then the provision of section §6.2.7.1 is taken to have occurred on January
 1st, 2015.
 ===

Seconded.

OdyX

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

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Didier 'OdyX' Raboud]

Le lundi, 1 décembre 2014, 14.37:30 Lucas Nussbaum a écrit :
 I am hereby formally submitting an alternative proposal, between
 double-dashed lines below (formally it's an amendment, but I don't
 expect Stefano to accept it, as we discussed it before). I am also
 calling for seconds (see below).
 
 
 ===
 The Constitution is amended as follows:
 
 ---
 --- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
 +++ constitution.2-R.txt2014-11-24 10:24:42.109426386 +0100
 @@ -299,8 +299,22 @@
 Project Leader may appoint new member(s) until the number of
 members reaches 6, at intervals of at least one week per
 appointment.
 -5. If the Technical Committee and the Project Leader agree they may
 +5. A Developer is not eligible to be (re)appointed to the Technical
 +   Committee if they have been a member within the previous 12 months.
 +6. If the Technical Committee and the Project Leader agree they may
 remove or replace an existing member of the Technical Committee.
 +7. Term limit:
 + 1. On January 1st of each year the term of any Committee member
 +who has served more than 54 months (4.5 years) and who is one
 +of the N most senior members automatically expires. N is
 +defined as 2-R (if R  2) or 0 (if R = 2). R is the number of
 +former members of the Technical Committee who have resigned,
 +or been removed or replaced within the previous 12 months.
 + 2. A member of the Technical Committee is said to be more senior
 +than another if they were appointed earlier, or were appointed
 +at the same time and have been a member of the Debian Project
 +longer. In the event that a member has been appointed more
 +than once, only the most recent appointment is relevant.
  
6.3. Procedure
  
 ---
 ===

Seconded.

OdyX

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

Re: [DRAFT] Maximum term for tech ctte members

[Didier 'OdyX' Raboud]

Le mercredi, 19 novembre 2014, 10.13:45 Lucas Nussbaum a écrit :
 The '2-R' schema could even result in an internal TC discussion: OK,
 the Project wants us to change two members. Are there people that feel
 like resigning now? Or should we just fallback to the default of
 expiring the two most senior members?
 I think that if this happened, it would be very healthy for the TC.

I quite like the idea. I was also thinking of something along the lines 
of automatic resignation unless self-extended, similar to what we have 
(although mildly working) for DMs. This would be equivalent to saying 
that the TC terms are of one year, renewed manually by stating so, up 
to 5 times.

This would allow automatic expiry of members becoming inactive for some 
reason, without implying a TC+DPL decision (§6.2.5). This would also put 
the should I continue be part of the TC for a new one-year term 
question explicitly and annually on the table.

OdyX

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

Re: [DRAFT] Maximum term for tech ctte members

[Didier 'OdyX' Raboud]

Hi zack@,

Thanks for pushing this subject forward, it's a constitutional change I 
would likely second.

Le mardi, 18 novembre 2014, 14.15:25 Stefano Zacchiroli a écrit :
  provided /they/ were appointed reads to me like it might mean that
  if only one of them was appointed that long ago, maybe neither of
  them expire. I'm not sure I can think of anything better; maybe
  something like At this time, the terms of members who were
  appointed at least 54 months ago automatically expire. Expiry
  occurs in order of seniority, and is limited to at most the two
  most senior members. would be better? But I'm not sure this is
  worth fixing.
 
 This is still pending, and noted in BUGS. I agree this is as a
 potential problem, at least if you look at it from a paranoid angle.
 I find your suggested wording not immediate, though, and I wonder if
 a/ someone else has better suggestion, and b/ whether this is worth
 fixing.

What about something along the lines of At this time, the terms of 
members who have been members for more than 54 months automatically 
expire. ?

Another point though:
 5. A Developer is not eligible to be (re)appointed to the Technical
Committee if they have been a member within the previous 12 months.

Provided that the expiration happens on January first, does this imply 
that if A was expired on 01.01.2015, she becomes eligible again on 
01.01.2016? As I read the two new clauses, given someone the project 
really wants on the TC, she can stay 5 years, break for a year and be 
re-appointed, right?

All-in-all, I feel the change goes in the right direction, but I also 
feel it only goes halfway through (probably the half we can collectively 
agree on though). The two issues I'd like to see fixed on a longer term 
are quite long mandates (although the fix helps here) and imperfect 
representativity of the diversity of the project caused by self-
appointment, which I'd like to get fixed through some sort of election 
through the project. Sorry, I digressed; let's keep that for a later 
discussion.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2993924.FIlfxOZmI7@gyllingar

Re: increasing maximum ctte size

[Didier 'OdyX' Raboud]

Le mercredi, 19 novembre 2014, 00.12:27 Neil McGovern a écrit :
  Even if it were as ready, I wonder if it wouldn't be better to have
  a
  separate GR. Voting once instead of twice is nice for everyone, but
  conflating two separate decisions in a single GR has been proven to
  be unwise in the past. And I'm especially wary of doing so with a
  constitutional change. Secretary: can you share your thoughts on
  this last point with us, what would be best from the ballot
  preparation POV?
 If you think you want this as a separate option, I would suggest an
 amendment to your original text and not accepting it. This way people
 could (with condorcet) choose between the two.

That doesn't work if people want to vote on change A and change B 
independently, unless the ballot becomes:

* only A
* only B
* B  A

… at which point two votes in sequence make more sense, IMHO.

OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5661362.pdqW3v9eEL@gyllingar

Re: REISSUED CfV: General Resolution: Init system coupling

[Didier 'OdyX' Raboud]

Hi Neil, (CC'ing secretary@)

Le mardi, 4 novembre 2014, 23.53:43 Neil McGovern a écrit :
 The responses to a valid vote shall be signed by the vote key created
 for this vote. The public key for the vote, signed by the Project
 secretary, is appended below.

From what I can see [0], the public key as appended in the CfV is signed 
by the assistant secretary, and not by the secretary himself. Although 
§7.1.4 allows the secretary to delegate his authority, I think the above 
formulation (probably out of a template) was factually wrong. It would 
be good if the secretary could also sign this key and send the signature 
to the list…

(For the avoidance of doubt: I have no trust issues with the secretary 
or his assistant, at all).

Cheers,
OdyX

[0] gpg --list-sigs B4AD3EC3 | grep '^sig' | grep -v gr_initcoupling
sig  A40F862E 2014-11-03  Neil McGovern n...@halon.org.uk


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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Didier 'OdyX' Raboud]

(Dropping -project)

Le mardi, 28 octobre 2014, 17.26:32 Ian Jackson a écrit :
 Thanks to Steve for his perceptive and well-reasoned article.
 
 Steve Langasek writes:
  There are also a lot of Debian users who are afraid of what the
  future holds for an OS that they love very much; and they deserve
  to have that cloud of fear removed from over their heads, to be
  given closure, even if that closure brings the certainty that they
  will part ways with Debian rather than being reconciled to it.
 
 There is a big point I wanted to make apropos, roughly, of this:
 
 If this vote goes against the users and derivatives who don't want to
 use systemd, those people will have nowhere to go.

It would be nice (and, I think, more honest) if you refrained from 
framing this GR as a vote in favour or against the (people) who don't 
want to use systemd: your amendment doesn't say anything in this 
regard, and none of the others say so either. By framing the GR in this 
light, it seems to me that you're trying to paint anyone not voting your 
proposal first as against non-systemd users, which I feel as unfair 
and dishonest.

Several amendments in this GR are indeed saying whoever doesn't want to 
use systemd in Debian should be putting up the work to make it happen, 
but none of that is voting against the (people) who don't want to use 
systemd.

OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4664676.peOt7Kkscx@gyllingar

Re: Tentative summary of the amendments

[Didier 'OdyX' Raboud]

Ian,

Le mercredi, 22 octobre 2014, 13.34:27 Ian Jackson a écrit :
 Jonas Smedegaard writes (Re: Tentative summary of the amendments):
  I too find it wrong to interpret Ian's text as a war between systemd
  and sysvinit - that's anything but basically fine!
 
 It's only a war between systemd and sysvinit insofar as some of
 systemd's proponents are trying to abolish everything except systemd,
 which encompasses abolishing sysvinit.

Can you _please_ point to such attempts or retract your unfounded FUD?

As far as I have read so far, most systemd's proponents only want the 
software they maintain be _allowed_ to use the systemd features in a 
Debian context, something which is totally unrelated to abolishing 
sysvinit. I'll go even further by pointing out that the systemd 
maintainers have pointed [0] their intend to _ensure_ that sysvinit 
would _stay_ at the users' disposal even through upgrades migrating to 
having systemd as pid1.

I will also note that so far only Jonas and you have used the term war 
in the context of this GR discussion period. I thought the discussion 
period was supposed to be rather a democratic exercise than a call to 
arms.

OdyX

[0] https://lists.debian.org/871tq1fihn@xoog.err.no


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1564256.lJdt0hsHAp@gyllingar

Re: GR option text on ballots

[Didier 'OdyX' Raboud]

Le lundi, 20 octobre 2014, 12.17:14 Neil McGovern a écrit :
   Ian's: make each package support all alternative init systems
  
  This is actively misleading in a least four ways:
 Yup, I wouldn't count that as neutral either. How about:

Your two proposals don't seem to match Ian's to which you're 
responding:

   Packages should continue to run under sysvinit unless technically
   unfeasible

Ian's doesn't mention sysvinit at all; this would be highly misleading.

   Packages may require a specific init system if technically required

That's not at all the core of Ian's proposal in my reading.

What about
  In general, software may not require one specific init system to be
  pid 1

?

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3165381.DVHk3vBgWs@gyllingar

Re: [Call for seconds] The “no GR, please“ amendement.

[Didier 'OdyX' Raboud]

Le dimanche, 19 octobre 2014, 23.29:21 Charles Plessy a écrit :
 --
 
 The Debian project asks its members to be considerate when proposing
 General Resolutions, as the GR process may be disruptive regardless
 of the outcome of the vote.
 
 Regarding the subject of this ballot, the Project affirms that the
 question has already been resolved and thus does not require a
 General Resolution.
 
 --

Seconded, for much the same reasons as Holger's.

Cheers,
OdyX

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

Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain

[Didier 'OdyX' Raboud]

Le lundi, 20 octobre 2014, 14.14:58 Joey Hess a écrit :
 The tech committe made a separate ruling on this question, and
 decided:
  For the record, the TC expects maintainers to continue to
  support the multiple available init systems in Debian.  That
  includes merging reasonable contributions, and not reverting
  existing support without a compelling reason.
 http://bugs.debian.org/746715

I didn't understand this as a technically binding ruling, rather as a 
forewarning to maintainers, from the TC; this is underlined by the the 
TC expects rather than explicitly using one of the TC powers (§6.1).

 So, your proposal actually overrules this decision of the tech
 committee.

I don't see it that way; the developers' body would be exercising one TC 
power without overriding a previous decision. Let's see what the 
secretary@ (CC'ed) thinks…

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/11496916.5mCyfBQSlK@gyllingar

Re: Re-Proposal - preserve freedom of choice of init systems

[Didier 'OdyX' Raboud]

Le vendredi, 17 octobre 2014, 10.00:59 Ean Schuessler a écrit :
 - Holger Levsen hol...@layer-acht.org wrote:
  If you don't like upstreams choices, *you* should write patches. Not
  GRs telling other people to do so.
 
 Very well stated. Perhaps a sensible response to this GR is for all of
 the maintainers who truly disagree with it to state their intent of
 putting their packages up for adoption upon its ratification.

This would only make Debian worse, not better.

Amongst the other problems of this GR, I think this one is the worst 
part: this GR text [0] creates artificial new conditions [1] for 
software acceptable in Debian, both for new software _and_ for existing 
ones. This implies that the best ${insert-your-tech-here} since slice 
bread only working with one init system [2] would _not_ be acceptable in 
Debian until someone does the work to make it non-init specific, even 
if no one would ever imagine using said ${insert-your-tech-here} in that 
context. We'd be severely moving away from a patches welcome culture, 
which I feel, does quite essentially define our mode of collaboration. 
We'd be moving to a culture where perfect(ly init-agnostic) would be the 
enemy of good and where we put the burden of making sure corner-cases 
work not on the ones experiencing the corner-cases, but on the 
maintainers. I'm unhappy about that and will not vote in favour of this 
proposal.

Cheers,
OdyX

[0] 21567.57029.724173.958...@chiark.greenend.org.uk
[1] On top of our usual set: DFSG, maintainability, security, etc.
[2] Which might happen to be why it's so much better: better integration 
across the stack.


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/56544976.cMIKFiWbv4@gyllingar

Re: Re-Proposal - preserve freedom of choice of init systems

[Didier 'OdyX' Raboud]

Le vendredi, 17 octobre 2014, 19.50:22 Jonas Smedegaard a écrit :
 We need the GR to ensure situation stays good.  No big deal.

That's the fundamental crux of the disagreement I think: A GR will _not_ 
automagically generate upstream attention for non-systemd support. 
Point.

If your good situation is a situation where non-systemd setups 
continue to work, what's needed to ensure it stays so is people putting 
up the work everywhere needed, _not_ a GR (which is people have stated 
a collective opinion).

Post-Jessie, trying to coerce sysvinit maintenance burden on maintainers 
is directly against §2.1.1 of our constitution; trying to coerce 
sysvinit maintenance burden on upstreams will simply not happen, no 
matter how many GRs we might pass in that hope.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/11311148.CxcO47Piez@gyllingar

Re: GR: Selecting the default init system for Debian

[Didier 'OdyX' Raboud]

Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit :
 Russ Allbery writes (Re: GR: Selecting the default init system for 
Debian):
  As a TC member, I dislike the supermajority requirement for the
  project to overturn a TC decision by GR, particularly in this case.
   I think we would all be extremely unhappy if the TC voted one way
  on the default init system and the project then voted a different
  way by a 60% majority.
 
 I agree.  I think that would be quite bad.  We could explicitly state
 in our TC resolution that the TC decision can be vacated by General
 Resolution on a simple majority.

I don't think our constitution allows a resolution of the TC to change 
how §4.1.4 has to be interpreted for a GR overriding it[0]. It would 
certainly need to be checked with the secretary (CC'ed, just in case).

Cheers,
OdyX

[0] If §4.1.4 stood with something along the lines of unless the TC 
explicitly lowered that requirement, that would be different, of 
course.

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

Re: not being elected?

[Didier 'OdyX' Raboud]

Hi Moray,

Le dimanche, 17 mars 2013 16.42:34, Moray Allan a écrit :
  Will not being elected de-motivate you?
 
 In many ways, not being elected would be a relief.  I'd have more time
 to put into non-Debian parts of my life.
 
 However, if I am not elected, I would see that as a lack of agreement
 with my proposals, or at least a lack of interest in them, and I would
 be de-motivated from pushing those topics further against the apparent
 view of the project.

Given that a) you nominated yourself and b) there are two other serious 
candidates¹, I must say I am quite surprised to read that you would see a non-
election as a lack of agreement or interest in your proposals.

As far as I'm concerned, I'm not voting between three distinct sets of 
proposals: as it's been apparent in other threads, there's quite a lot of 
overlap between the candidate platforms and their specific proposals. We are 
electing someone to stand in the DPL shoes: debating eachothers' proposals, 
views and stuff is obviously useful to decide, but at the end of the day, we 
can't all vote the three candidates equally. We're voting for concurrent 
persons, not concurrent proposals.

So unless you end up being ranked below NOTA (which I certainly don't see 
happening for any of the three very good candidates), I wouldn't take not 
being ranked first as a dismissal of your ideas or proposals; and I'm 
surprised that you see it as such.

Cheers,
OdyX

¹ Which implies that you start with both a ⅓ chance of being elected and a ⅔
  chance of not being elected.


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

Re: [all candidates] DPL salary

[Didier 'OdyX' Raboud]

Hi Russ,

while I do agree with the rest of your post, there's one part which I'm not 
sure to understand correctly:

Le mercredi, 13 mars 2013 18.03:36, Russ Allbery a écrit :
 For example, I live in the SF Bay Area.  Fair market compensation here for
 the sort of senior IT person that we would elect DPL is *at least*
 $100,000 US per year, and at $100,000, people would generally be taking a
 substantial pay cut because they believed in the organization.

the sort of senior IT person that we would elect DPL is the part that 
puzzles me: with both the extension of the DD status and the diversity 
statement, we made it clear that we welcome all sorts of contributions from 
all sorts of contributors: I, for one, would be very happy to elect a DPL who 
is not necessarily that senior IT person. I'm not hereby saying that senior 
IT persons become bad DPLs or that other professions have lower costs than 
the above figures, just that I think it's very important to keep the 
potential DPLs set wide enough.

Cheers,

OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303141243.19633.o...@debian.org

Re: [all candidates] DPL term duration

[Didier 'OdyX' Raboud]

Hi Moray, hi all,

Le mardi, 12 mars 2013 21.24:15, Moray Allan a écrit :
 In my view, if we want to lengthen the term of office for our
 leadership roles, which could have beneficial aspects, we should do that
 as part of a wider reform that reduces the concentration of roles/power
 in a single person.

As I see it, one way to do that (which has certainly been proposed already) 
would be to have a sort-of DPL guild⁰. It would have these properties¹:

- enough members
  (start with 3 for example, but a fixed number set in the constitution)
- fixed-length terms (18 months for example)
- renewable terms
- overlapping terms (more by coincidence than by enforcement)
- resignation is possible per-member, at any time
  (so if one member resigns, a new one is elected ASATCP²)
- leadership/chairman role (if needed) rotated between the elected members on
  a regular basis³

What do the candidates think of such a system; would it be something you would 
push, not push, why?

Thanks in advance, cheers,
 
OdyX

⁰ Team / Board / Committee / Whateva, the name isn't the core of the idea.
¹ Which are quite alike those of the swiss federal government
² As Soon As The Constitution Permits
³ Could also be done by decision of the guild, for example; or not at all.


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

Re: [all candidates] DPL term duration

[Didier 'OdyX' Raboud]

Le jeudi, 14 mars 2013 13.00:09, Didier 'OdyX' Raboud a écrit :
 As I see it, one way to do that (which has certainly been proposed already)
 would be to have a sort-of DPL guild⁰. It would have these properties¹:
 (…)

Damn, I just realised all candidates already addressed the wider board idea 
in the thread starting at 20130311235436.gb18...@ftbfs.de ⁰.

OdyX

⁰ http://lists.debian.org/debian-vote/2013/03/msg00045.html


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201303141751.13265.o...@debian.org

Re: Standardization, large scale changes, innovations

[Didier 'OdyX' Raboud]

On Wed, Mar 31 2010, Josselin Mouette wrote:
 However a newcomer not aware of your fanatic rejection of any kind of
 standard tools would absolutely not understand what this is about. And
 the same goes about everything else in the package.

Manoj Srivastava wrote:
 I just update code in one place, test it, and then run a script
  that does a git pull for all my packages. The next time I build the
  package, it will pull in the change.

So you are indeed using package helpers. Those are just yours and not 
anyone else's…

 Personally, I find a small shell snippet to be clearer than a
 reference to a external program, and when finding myself stuck in RHEL-
 land, my packages build, and would have caused more pain were they
 dependent on helper packages.

Hmm… So a shell snippet is clearer than a manpage [debhelper's not a GUI…] ?

Are those helpers not installable/available on RHEL ? Maybe they should…

OdyX


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hovf0u$1v...@dough.gmane.org