Re: Summary of the current state of the tag2upload discussion
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.) Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Summary of the current state of the tag2upload discussion
Scott Kitterman writes: > Do you have any examples of problems that this would have avoided > (xz-utils isn't one - due to the way it's releases are done, it > wouldn't be suitable for tag2upload)? I'm somehow reminded of Ignaz Semmelweis's attempts to improve medical hygiene by getting doctors to emulate the local midwives, who scrubbed their hands between patients, whereas the doctors generally didn't, and would alternate between performing autopsies and attending deliveries. I'd guess someone may well have pushed back against that, thus: Can you to name a single patient who has suffered as a result of existing practice? If I stretch that metaphor (possibly beyond breaking point), then one might think of our developers' laptops as the (potentially infected) cadavers, the newly uploaded source packages as the live births, and our tooling as the doctors' hands that may carry the infectious material from one to the other. I hope that we've been lucky enough to not actually have any of the relevant "infections" in the population of laptops that produce our packages, but would it not be wise to make it more difficult for such an infection to be silently transmitted? People state that a compromised machine can as easily commit malicious code to git as it could insert it into a source package, but the difference is that the malicious commit then needs to be pushed in order to work, exposing it to examination. In our metaphor perhaps the git commit step would equate to requiring doctors to touch a new Petri dish before each patient, which would at least record what was going on, and might give the opportunity to deal with the situation before real harm is done. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
Russ Allbery writes: ... > At the risk of trying to argue by analogy, it feels akin to saying "okay, > you can have a binary buildd, but only if it doesn't use a compiler and > only copies files around." Yes, that's a compromise compared to no binary > buildds, but in a way that makes the whole picture more complicated and > doesn't achieve the point of the design. Also, packages change over time. If one had that restriction, and got used to being allowed to use that sort of restricted buildd, what happens when upstream adds something that needs compilation? Similarly, if one has a package that could be dealt with by a limited tag2upload, and then upstream changed something that nudged you into the problematic territory, you'll be confronted with having to abandon tag2upload, or perhaps having to start doing trickery to live within the limitations (e.g. performing the problematic steps and then committing the results of that to git, say, which will just make the package horrible). If that's the choice available, I'll be sticking with local dgit from the start, because at least that's going to be able to deal with tomorrow's version from upstream. If that's the rational choice which any well-informed uploader will adopt, then such a limited tag2upload really serves no purpose. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
Russ Allbery writes: > Marco d'Itri writes: >> r...@debian.org wrote: > >>> My understanding is that the problem with this design from their >>> perspective is that it requires a fat client on the uploader's system, >>> and whole point of tag2upload is to stop requiring a fat client on the >>> uploader's system. In particular, it requires all the code to >>> reconstruct the source package from a Git tree be installed locally, >>> which is basically a full dgit implementation. > >> Does it? What if both the tag2upload client and server implemented >> instead some very simple serialization and canonicalization algorithm >> over the source package? > > The serialization isn't the problem, constructing the source package is. > Once you have a source package, there are lots of things you can do, but > the problem is precisely that going from a Git tree to a source package is > non-trivial and involves a whole bunch of Debian-specific code. We seem to be very focused on how one might reproduce the source package, to make sure that it can be bit-for-bit generated from the signed tag, which is clearly a hard thing to do. Do we actually need to do that at all? Would it not be sufficient to check that the resulting source package is a reasonable representation of the content pointed at by the signed tag. Given that we already have the source package at the point when we need to do this check, that really ought to be a lot easier than building the source package in the first place. If we had a tool that did that check, such that you could feed it a source package and a tag, and it would tell you if the source package was correctly generated from the tag, would that be enough to satisfy the FTP masters? If so, is there anything that makes it difficult to create such a tool? (my naive perception is that it's a lot easier to untar a tarball, and check that the contents match a git checkout than it is to make sure that git-archive is reproducible, and that this situation seems somehow analogous to that) Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
A thought experiment regarding tag2upload and trust
Sean Whitton writes: ... > The ftpmaster team have refused to trust uploads coming from the > tag2upload service. This GR is to override that decision. Full disclosure: I'm a happy dgit user. The support I've had from Ian for dgit (when I messed things up, generally) has been outstandingly good, and has generally resulted in a change to dgit that prevents me (and others) from messing up in a similar manner. It strikes me that tag2upload is another stride in the same direction, so I'd like to have the chance to use it, because I suspect that it will also make contributing to Debian easier, less error-prone, and just more pleasant. [Note: in the following, I am NOT trying to suggest a technical fix, so please don't start nitpicking the details -- it's just a thought experiment that I hope might shed some light on the situation] If it were easy to deploy an instance of tag2upload in my house, populated with a sub-key of my GPG key, I would probably set that up (and then start worrying about the security of the sub-key ;-) ). If I did that, I believe the FTP masters would still accept my uploads. Should they? or is it perhaps the case that they are objecting to the idea that tag2upload is capable of reliably generating a source package from a git tag. (I personally trust Ian when he says that it is capable) If Ian were to offer a hosting service for such personal tag2upload instances, in a way that he assured me could not be used to sign packages unless I had signed a matching git-tag, I would be willing to trust his assurances, and may well take him up on the offer. It seems to me that such a centralised service is more likely to do things like keep the keys in an HSM, and have effective separation of the components, than something set up by a random developer at home, so one could argue that it's going to be more secure than the self-hosted version. Would the FTP masters still be OK with that? If not, what's changed? If that's OK, but tag2upload as proposed is not, are we really drawing a line based on what name is on the signing key? Would it make any difference to the FTP masters if there was some way for me to assert that I trust the tag2upload service/key to build/sign source packages for me? For instance, if one had to sign something with a GPG key that matches the one that later signs a gpg tag, before tag2upload would be willing to process one's signed tags, would that make the FTP masters happier? Personally, I'm not convinced that would really add anything, since if one has sufficient control of the key to push a signed tag, then one's also going to be able to sign a statement that you want tag2upload to act on that tag, but I thought that describing the options might help narrow down what the perceived problem is. Of course, without something describing exactly what the problem is from the FTP master's point of view, it's very hard to judge the merits of their position. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Lisandro Damián Nicanor Pérez Meyer writes: ... > Just to be clear: I also do agree with the main intention of the > proposal, what I do not like is that the current draft wording might > backfire on us. I'd expect the multinationals, who have large legal teams, and are used to interacting with the EU, to find various ways of ensuring that they can continue to avoid responsibility for their (often-shoddy) wares. They seem to treat legal fees and fines as costs of doing business, so won't be significantly inconvenienced. Meanwhile, one could imagine something like the BSA going around looking to see if vendors of Free Software based systems have sold anything into the EU, and encouraging the EU authorities to audit them, just to crap on the competition. I remember MS signing-up UK schools to per-processor site licenses where if one offered to give a school 100 refurbished laptops running Debian, they'd often end up saying no because they couldn't afford the extra Windows/Word licenses that they'd have to pay for if they allowed those CPUs on site. I'm sure there are still people being paid by incumbents to come up with ways of maintaining market share by whatever means, who are perfectly capable of weaponising this legislation against new entrants -- and that seems very likely to include people associated with Free Software. Do we really want the likes of Purism to refuse to ship into the EU in future? I think that seems quite likely to be a rational response on the part of small enterprises where the bulk of their market lies elsewhere. I'd love for the vendors of crappy software to be held accountable for the endless plague of viruses, and the Internet of Shit, they're inflicting on the world, but I suspect that it won't work out that way. Instead, I worry that it will only touch people that are trying much harder to do a good job, but cannot afford a full-time lobbying team in Brussels. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Re: General Resolution: non-free firmware: results
Ian Jackson writes:
> Russ Allbery writes ("Re: General Resolution: non-free firmware: results"):
>> I don't think you can draw any meaningful conclusions from this ranking
>> because of the concern that the latter option may have been ruled invalid
>> by the Project Secretary. I prefer one installer (to focus our resources
>> and UX efforts), but voted "recommend installer" above "only one
>> installer" because of the constitutional concerns.
>
> You make a very good point.
I think interpreting other people's votes is very often problematic.
I voted the winning option first, despite a personal preference for
keeping the fully-free installer available.
The reason being that I didn't want to inflict work on the debian-cd
team, and I assume that nobody will object if volunteers turn up to help
build/test the free images. If they're built and tested, I'm pretty sure
they'll be published.
If someone builds them, I will certainly help test them with openQA.
If one of the options that forced the debian-cd team to publish free CDs
had won, then the potential volunteers for building them would not be
nearly so motivated to do the work, because they can just sit back and
let the debian-cd team do what they're told.
As it is, we either get more people to work on the CDs, or perhaps
it's not that important to people after all -- I'm sure we'll find out.
Anyway, I suspect the above isn't the first interpretation that comes to
mind of someone that voted the winning option top.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: Possible draft non-free firmware option with SC change
Bill Allombert writes: > Le Wed, Sep 14, 2022 at 12:37:08PM +0200, Philip Hands a écrit : >> Simon Josefsson writes: >> >> ... >> > I agree it doesn't make sense for either organization to change >> > approach. I do believe that what we are seeing in this vote, however, >> > is that Debian _is_ changing tactics: rather than providing a 100% free >> > Debian (guided by the DSC/DFSG) and using that as a tactic to change the >> > world, Debian will (under A/E) provide a 99% free Debian. >> >> Stretching that metaphor a little: making non-free firmware available >> in the installer strikes me as equivalent to offering Wellington boots >> to new arrivals at the beach, so that they can wade across the muddy >> patch to get to the nice dry, sandy bit of beach where we play barefoot. > > Yes, but this is not the question at hand. Nobody is suggesting that the > non-free installer should not exist, but whether it should be considered > part of Debian or part of non-free. Exactly "Nobody is suggesting that the non-free installer should not exist" ... including me just then. I'm afraid you seem to have so completely misunderstood the point that I was attempting to make that I don't know where to begin to explain it better. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
Simon Josefsson writes: ... > I agree it doesn't make sense for either organization to change > approach. I do believe that what we are seeing in this vote, however, > is that Debian _is_ changing tactics: rather than providing a 100% free > Debian (guided by the DSC/DFSG) and using that as a tactic to change the > world, Debian will (under A/E) provide a 99% free Debian. Back in the days when I was involved in producing CD images, people used to use them to make CDs (shocking, I know ;-) ). As such, I have always thought of the installer images as being outside Debian, since in order for them to be useful they needed to be instantiated in a physical form that was encrusted with layer upon layer of patent, trademark, licensing and other legal constraints regarding the form of both the media and the devices used for reading the media. Of course, in the mean time the physical representation has changed, but still, SD cards are inherently non-free in many ways, even if the data on them is purely free. I'd suggest that there's always been a fuzzy tide-mark showing where you should stop worrying too much about the freeness we can achieve. Stretching that metaphor a little: making non-free firmware available in the installer strikes me as equivalent to offering Wellington boots to new arrivals at the beach, so that they can wade across the muddy patch to get to the nice dry, sandy bit of beach where we play barefoot. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
Didier 'OdyX' Raboud writes: ... >> But as mentioned, I think this is probably too big of a change for this >> point in the process. (I'll still throw it out there, though, in case >> there's overwhelming sentiment the other way.) > > I disagree; this looks precisely like the change I think we should be making. Likewise -- I think dropping the "we support ..." language makes the meaning that we were always trying to convey much more obvious. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Tiago Bortoletto Vaz writes:
...
> I'm wondering how the d-i team feels about that (having the image with
> non-free
> bits called unofficial). Or whether it makes any sense at all, say, having
> such
> an essential component developed by fellow Debian members, using official
> Debian resources, and still being named 'unofficial', just for our
> convenience (?)
IIRC the "official" thing came in because someone produced a CD for a
magazine cover for some early release (1.2 maybe?) that was actually
slightly pre-release, because their publication date was set to coincide
with the actual release, but there was a significant bug with that CD
image, so we were forced to call the actual release CDs 1.2.1 (or
whatever) in order to distinguish between the other (widely distributed,
buggy) version and the actual release.
I seem to remember that is was quite annoying at the time.
Calling certain images "official" was an attempt to stop that sort of
thing happening again.
Does anyone still mass-produce CDs?
I think we could simply forget about the term "official" now, and just
let people download whatever's current, in whichever variant suits their
purpose best ("free" vs. "free+firmware").
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: Changing how we handle non-free firmware
Steve McIntyre writes: .. > On Tue, Aug 23, 2022 at 12:51:10PM +0200, Philip Hands wrote: >>Debian with the non-free drivers... > > We're talking about non-free **firmware, not non-free > **drivers**. Sorry to play the pedant card here (and I know you know > the difference!), but this is a common mistake and a lot of users > really get the two confused. Oops! Sorry, that was a slip-of-the-keyboard -- I stand appropriately admonished. Thanks for the correction. :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Simon Josefsson writes: > "Andrew M.A. Cater" writes: > >> In practice, the free installer is useless on its own. > > That is not my experience -- I'm using Debian through its installer on a > number of laptops, desktops and servers, and for my purposes it works > fine and in general I have not needed to enable non-free/contrib for > hardware support. You may have other purposes for which it does not > work, but that doesn't make it useless for everyone, and there are > alternatives available to solve your use-case (unofficial non-free > installer) that doesn't entail the cost of abandoning the free software > ideals of the Debian project. I would suggest that "abandoning the free software ideals of the Debian project" is significantly mis-characterising what's going on here. Debian has always been pretty pragmatic about enabling the use of non-free software by our users, even while maintaining the strict separation of non-free from main. That is after-all what's kept the FSF mildly upset with us all these years. I don't suppose that including non-free-firmware on our ISOs will help with that, but it also doesn't really make things any worse. By not having the non-free-firmware on our media, we really do lose new users, all the time. In particular, people that don't have any choice regarding their hardware often fail to install anything useful with our 100% pure ISOs. Those people are likely to have obtained some old hardware either as a gift or very cheaply, and do not have a budget for an RFY wifi stick. Debian with the non-free drivers often runs really well on such hardware, giving people that would otherwise be digitally excluded a viable option. Encouraging such people to waste their efforts downloading an ISO that we know is quite likely to fail for them, while hiding the image we know they really need strikes me as a form of abuse. A lot of people will abandon the attempt after a single failure. Every one of these lost users is a potential Debian contributor. Driving them away is an act of self-harm, and does more damage to Free Software than could possibly be done by admitting the truth that for many (newbies in particular) the tainted ISOs are what people really want. There will be plenty of time to explain that their they should choose a better wifi card if they get the chance once they have managed their first install, but if we continue to set up obstacles at the start then they won't even be around to listen. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Jonas Smedegaard writes: > Quoting Tobias Frost (2022-08-22 15:57:01) >> On Mon, Aug 22, 2022 at 07:39:21AM +0200, Simon Josefsson wrote: >> > Ansgar writes: >> > >> > > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: >> > >> Do we need to update the Debian Social Contract for that? >> > >> Specifically paragraph 1, which currently reads >> > >> >> > >> Debian will remain 100% free >> > > >> > > No. Just like we don't need to update the Debian Social Contract for >> > > having https://deb.debian.org/debian/pool/non-free/: we just ship >> > > additional files that might be useful for people having specific >> > > hardware. >> > >> > I disagree -- what is being proposed here is to replace our current >> > DSC-compatible free software installer images with non-free. That goes >> > significantly further than what the spirit of DSC§5 suggests. >> >> It not being replaced; there are just additional bits in there which >> help people to actually be able to install Debian on some modern machines. >> >> The guarantee in SC1 that we will never *require* those non-free bits, as >> writen >> out in "We will never make the system require the use of a non-free >> component." >> This GR does not violate this promise. > > I understand how we will not require non-free bits getting *installed*. > > The way I see it, with this change we will require non-free bits for > *distribution* of our system, because our official installer will now > include non-gree bits. Would those arguing for the availability of the 100%-free installer find it acceptable if there was a way of cleansing the non-free bits from the includes-nonfree-firmware installer images? I'd guess that one could put the non-free bits on the end of the image, as an additional session, or perhaps just mark them in the image, and then reasonably trivially trim them off, or blank them out. We could then generate the firmware-included images, but make the cleansed ones available on-line by having a server-side script trim out the non-free bits on the fly. If that still makes you feel dirty, because the free bits were once next-door to some non-free bits, would it make any difference if the resulting images could be built reproducibly without access to any of the non-free components? I'm mostly asking this to find out where people's lines are, but also in the hope that we could come up with a compromise that allows us to get away from the enthusiasm sapping situation where the debian-cd team is required to make images that they know are sub-optimal for many of our users. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Steve McIntyre <93...@debian.org> writes: > Hi a11! > > I'm proposing to change how we handle non-free firmware in > Debian. I've written about this a few times already this year [1, 2] > and I ran a session on the subject at DebConf [3]. > > TL;DR: The way we deal with (non-free) firmware in Debian isn't > great. For a long time we've got away without supporting and including > (non-free) firmware on Debian systems. We don't *want* to have to > provide (non-free) firmware to our users, and in an ideal world we > wouldn't need to. However, it's no longer a sensible path when trying > to support lots of common current hardware. Increasingly, modern > computers don't function fully without these firmware blobs. > > Since I started talking about this, Ansgar has already added dak > support for a new, separate non-free-firmware component - see > [4]. This makes part of my original proposal moot! More work is needed > yet to make use of this support, but it's started! :-) > > I believe that there is reasonably wide support for changing what we > do with non-free firmware. I see several possible paths forward, but > as I've stated previously I don't want to be making the decision > alone. I believe that the Debian project as a whole needs to make the > decision on which path is the correct one. > > I'm *not* going to propose full text for all the possible choices > here; as eloquently suggested by Russ [5], it's probably better to > leave it for other people to come up with the text of options that > they feel should also be on the ballot. > > So, I propose the following: > > = > > 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. 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, replacing the > current media sets that do not include non-free firmware packages. > > = > > A reason for defaulting to installing non-free firmware *by default* > is accessibility. A blind user running the installer in text-to-speech > mode may need audio firmware loaded to be able to drive the installer > at all. It's going to be very difficult for them to change this. Other > people should be able to drive the system (boot menus, etc.) to *not* > install the non-free firmware packages if desired. > > We will *only* include the non-free-firmware component on our media > and on installed systems by default. As a general policy, we still do > not want to see other non-free software in use. Users may still enable > the existing non-free component if they need it. > > We also need to do the work to make this happen: > > * in d-i, live-boot and elsewhere to make information about firmware >available. > > * add support for the non-free-firmware section in more places: >ftpsync, debian-cd and more. > > and I plan to start on some of those soon. > > [1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do > [2] https://lists.debian.org/debian-devel/2022/04/msg00130.html > [3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/ > [4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable > [5] https://lists.debian.org/debian-devel/2022/04/msg00214.html > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > You raise the blade, you make the change... You re-arrange me 'til I'm sane... Seconded. Thanks Steve. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: General resolution: Condemn Russian invasion of the Ukraine
Julian Andres Klode writes: > On Thu, Mar 31, 2022 at 03:46:46PM +, Andrew M.A. Cater wrote: >> On Thu, Mar 31, 2022 at 04:17:42PM +0300, Adrian Bunk wrote: >> > On Thu, Mar 31, 2022 at 12:31:18PM +0200, Julian Andres Klode wrote: >> > > Under 4.1.5 of the Constitution, the developers by way of GR are the >> > > body who has the power to issue nontechnical statements. >> > > >> > > This is a proposal for Debian to issue a statement on an >> > > issue of the day as given as an example, the recent invasion >> > > of Ukraine. >> > > >> > > Text of GR >> > > >> > > The Debian project issues the following statement: >> > > >> > > The Debian project strongly condemns the invasion of Ukraine by >> > > Russia. The Debian projects affirms that Ukrain is a souvereign >> > > nation which includes the Donbas regions of Luhansk, as well as >> > > Crimea, which has already been illegaly annexed by Russia. >> > >> > I do not believe that Debian starting issuing such statements for >> > political issues of the day would be a good idea. >> > >> >> I think this is a good position, especially in this case. >> >> We have Debian developers and users in Ukraine and Russia: hostilities >> continue. >> If the project were to endorse this, you might put people in a dangerous >> situation - in an area subject to Russian control, anybody involved with >> Debian, even peripherally, would be breaking Russian law if the above >> passed and might be subject to 15 years imprisonment. >> [A factual statement with no further judgment]. > > Can you provide a source? If you've not noticed that the whole of Russia's independent media has given up publishing over the last month, largely because of this new law that imposes maximum penalties of 15 years in prison for spreading "false" news, such as referring to what the Kremlin calls a "Special Military Operation" as a "war" or "invasion", then you've really not been paying attention ... in which case, you don't know enough about it to propose a GR (even if such a thing was a good idea, which it isn't). Given that Putin's not going to suddenly come to his senses upon hearing that Debian doesn't like his war, the only effect such a GR is likely to have would be to sow division within the project where none needs to exist. It also has the potential to give the false impression that Debian supports Putin if enough people are against such statements (regardless of their content), and vote NotA first to show that. BTW I note that you are missing the 'e' from Ukraine in your GR, among other typos, which reinforces the impression that you didn't really devote much concentration to this GR. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Results for Voting secrecy
Russ Allbery writes: > Philip Hands writes: > >> The blurb that's sent out with the votes says: > >> To vote "no, no matter what", rank "None of the above" as more >> desirable than the unacceptable choices, or you may rank the "None of >> the above" choice and leave choices you consider unacceptable blank. > >> which to me suggests that if one ranks something as equal to NotA then >> one is not marking it as unacceptable, so presumably it is counted as >> acceptable -- is that how such votes are calculated? > > The relevant provision of the constitution is: > > A.5.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 greater or equal to N * V(D,A) and V(A,D) is > strictly greater than 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. > > My understanding of the implications of this process (and Kurt is > authoritative here, of course) is that if you rank NOTA equally with an > option, that vote is not part of V(A,D) or V(D,A) since neither option is > preferred over the other, and therefore has no effect either way on > whether an option is discarded because it doesn't meet majority. Ah, right -- it seems that I had a typo in the grep pattern I was pointing at the tally file, which was confusing me. Having fixed that, I can now see that it is exactly as you describe. Thanks :-) In that case, a vote of '--1-' does make sense, if one doesn't actually want to block a sufficiently large vote for options 1 or 2. In fact it's probably what I should have voted rather than '--12' in order to reflect my actual view. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Results for Voting secrecy
Kurt Roeckx writes: > On Mon, Mar 28, 2022 at 12:26:51PM -0600, Sam Hartman wrote: >> >>>>> "Kurt" == Kurt Roeckx writes: >> >> >> >> It inadvertently weakened the constitutional protection against >> >> changes to the constitution. >> >> Kurt> I currently fail to see how it does. >> >> I think Felix's point is that if we had choice 1, 2 and Nota, >> >> People who preferred option 3 would vote N>2=1 or some such. >> >> Because choice 3 was on the ballot, people had options that reflected >> their preferences and so some of those people voted 3>2>N. > > So the only thing I see is that they now had the option to express there > preferences, while they were limited in how to express their preference > without option 3. > > One way of interpreting the NOTA option is to look say what you think is > acceptable or not. Without option 3 on the ballot, you can not say you > think option 1 and 2 are acceptable but prefer option 3. You need to say > option 1 and 2 are not acceptable, while you actually think they are > acceptable. With option 3 on the ballot you can really talk about it > being acceptable or not. > > Without option 3, it's probably beter to talk about preference rather > than being acceptable. If you prefer no change, you just mark it below > the NOTA option, even when you think option 1 or 2 is acceptable. > > Option 3 being on the ballot can make it more likely for option 1 and > 2 to pass, but that's because people can actually express their opinion. > > Our voting system works best when all option are on the ballot. Adding > more options is not a problem, it has clone independence. > >> Felix's point is that the voters who preferred option 3 actually had the >> power to make it win, provided they were willing to say that they found >> option 2 unacceptable. >> Felix's assumption is that if they realized they had that power, they >> would have exercised it. > > But option 2 won, so even if there were people who voted strategically, > it's not a problem in this vote. I don't actually mind the outcome (despite my '--12' vote, which was tactical in the way described above I'm afraid -- probably as a result of growing up under the UK's first-past-the-post system, which pretty-much forces people to vote tactically, so I tend to do it out of habit). However, I'm failing to understand how the votes are calculated and/or what certain votes were expected to achieve by the people casting them. The blurb that's sent out with the votes says: To vote "no, no matter what", rank "None of the above" as more desirable than the unacceptable choices, or you may rank the "None of the above" choice and leave choices you consider unacceptable blank. which to me suggests that if one ranks something as equal to NotA then one is not marking it as unacceptable, so presumably it is counted as acceptable -- is that how such votes are calculated? It seems 8 people voted '--1-' and 3 voted '1---'. Did those all contribute to option 2 getting its 3:1 majority? If so, do we think that someone casting either of those votes was expecting their vote to be interpreted thus? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Reaffirm public voting
Holger Levsen writes: > On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote: >> On Fri, Mar 04, 2022 at 10:42:51AM +, Holger Levsen wrote: >> > Reaffirm public voting >> > == >> > >> > Since we can either have secret and intransparent voting, or we can have >> > open and transparent voting, the project resolves to leave our voting >> > system as it is. >> > >> > Rationale: >> > >> > The GR proposal for secret voting is silent on implenentation details, >> > probably because secret and transparent voting is, well, impossible to >> > achieve fully, so this GR is bound to a similar fate as the 'publish >> > debian-private' vote, which was voted for and then was never implemented. >> > >> > A voting system which is transparent only to some, is undemocratic and >> > will lead to few people in the know, which is diagonal to Debians goals >> > of openness and transparency. >> > >> > And then, early 2022 is not the time for rushed changes like this, which >> > is also why I explicitly want to see "keep the status quo" on the ballot, >> > and not only as "NOTA", but as a real option. >> > >> > I'm seeking sponsors for this amendment to the current GR. >> Assuming you meant this as "this ballot" instead of "this amendment" >> (following the new GR flow), I sponsor this. > > yes, that's what I ment, thanks. Do I need to resent my mail now with this > change? :) I sponsor this. While I may not end up voting for it as my first option, I think it deserves to be an explicit option, because I can imagine that no super-majority emerges in this vote, and if that happens then we will be able to draw rather different conclusions about the project consensus depending upon whether this option comes above or below NotA (and by how much). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: GR Ballot Option: Allow, but do not require, secret voting
Harlan Lieberman-Berg writes: > On 3/1/22 23:13, Harlan Lieberman-Berg wrote: >> Hello everyone, >> >> I propose the following ballot option for the current GR: >> >> Rationale >> >> While I agree that there are some votes which, due to their nature, >> may be so controversial that the potential for a person's votes to be >> publicly revealed may cause them to change their vote (or opt out of >> the election), even among divisive GRs, few rise to that level of >> controversy: the RMS GR and the systemd GR being two recent examples >> which have provoked ire. >> >> There is something which fundamentally distinguishes the kind of >> voting that Debian does from that of a private institution or group, >> where minutes and votes are typically kept out of public view: Debian >> serves a larger community than the members of the institution. In >> that sense, we are more similar to a public body than a private >> membership. >> >> Our Social Contract makes this distinction clear: when it says that we >> will not hide problems, it immediately emphasizes that the bug >> database will be open for public view at all times. Taking the step >> to make a particular vote secret should require us to stop and >> carefully weigh the costs to the larger community. >> >> I hope this option better strikes the balance between the aspirations >> of public visibility and the occasional, pragmatic need for secrecy. >> >> Ballot Option >> == >> The changes are available at: >> https://salsa.debian.org/hlieberman/webwml/-/commit/82729d07aba7dd7ac641f7e4a87178f34b23efca >> >> A diff follows (the word diff is very confusing, so I've omitted it): >> >> diff --git a/english/devel/constitution.wml >> b/english/devel/constitution.wml >> index 41cb9dfbd80..7924992d3a7 100644 >> --- a/english/devel/constitution.wml >> +++ b/english/devel/constitution.wml >> @@ -226,12 +226,15 @@ earlier can overrule everyone listed >> later. >> >> >> >> - 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. >> + Votes, tallies, and results are not revealed during the voting >> period. >> + After the vote, the Project Secretary lists all the votes >> cast, unless >> + either one of the following is true: >> >> + >> + The vote is for a leadership election as defined in >> §5.2. >> + At least 4K Developers have sponsored any single ballot >> option >> + which says the votes will be kept secret. Does this not force people that would like to keep their vote secret to publish that fact in order for it to happen (which might well hint strongly at how they are likely to vote)? In reaction to that flaw I suspect you'd then end up with a bunch of public-spirited folk suggesting that option for every vote, in order to cater to a presumed need for privacy by others. If that's the case we could save everyone the effort by just making all votes secret. How about people being able to request a secret ballot in private, by asking the secretary, who would keep a tally of requests and announce whether the vote was to be secret before voting started? BTW I had been persuaded that the published-only-internally option was not really good enough by subsequent discussion, which is why I've not proposed such an amendment, but perhaps the combination of published-only-internally with option-to-go-secret would actually be worth having as a ballot option. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Russ Allbery writes: > Philip Hands writes: > >> I was wondering if we could allow expressions of disdain >> (anti-seconds?), such that a second would get cancelled out for every >> two DDs (or maybe a larger multiple?) that respond to a call for seconds >> with an anti-second. A proposal would then need to stay at above 6 >> seconds for some short period after the latest anti-second landed to be >> considered to have a properly seconded proposal. > > This is a vote, though, just a kind of awkward one. If we're going to > hold a vote, I think we should do it with decent software designed to > handle a vote, rather than asking some poor person to manually verify and > count mailing list messages. That mail was a bit stream-of-consciousness, and I had hoped that by the end of it it was clear that I too thought the "anti-second" idea was not actually that great ... oh well, never mind. Sorry for not re-editing it. The bit that was supposed to be the conclusion of that was that it might be good if we had some mechanism for collecting opinions related to mailing-list mails/threads that was private, and didn't involve making (often already long) mailing list threads longer in order to express an opinion, but I think that's going OT so should be discussed elsewhere, probably after setting up a prototype. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Felix Lechner writes: > Hi, > > On Tue, Feb 15, 2022 at 12:31 PM Russ Allbery wrote: >> >> Trying to be generous to one another and only tackle divisions when they >> are of central importance to the project is a good principle, but I think >> there are some divisions of central importance to the project, not >> everyone is going to agree on which divisions are of central importance, >> and six DDs have a right under the constitution to bring a GR to a vote. >> I'm also leery of getting into another situation where a vote is going to >> be worrisome but we have no framework to mitigate the effects because >> we've been overly hopeful that we could avoid any such vote. > > Six DDs can force a vote, but not necessarily a decision. Would a > higher quorum help to ensure that divisive issues remain moot unless > there is broader interest? I was wondering if we could allow expressions of disdain (anti-seconds?), such that a second would get cancelled out for every two DDs (or maybe a larger multiple?) that respond to a call for seconds with an anti-second. A proposal would then need to stay at above 6 seconds for some short period after the latest anti-second landed to be considered to have a properly seconded proposal. I'm not sure what one would want to do if a hundred anti-seconds landed just too late. That might of course be somewhat divisive too, since people may feel like they didn't get a fair hearing, but would allow the project to express a "Let's not go there" without having to discuss it for ages. Also, if the declarations of disdain needed to be public, that would disenfranchise anyone that's only going to vote in secret ballots. I suppose one could do the anti-seconding in secret, but in that case one would also need to allow at least some of the seconds to be secret as well, to have an even playing field, which all seems a bit complicated. Alternatively, we could just have this as an informal thing, where people get to somehow declare their reaction to a GR discussion, in a secret, rolling, self-selecting poll, with simple options like "please make this stop" or "feel free to continue" ... and the numbers get published. The proposer of something that's obviously unpopular then gets to decide if they're willing to continue pushing their idea anyway, regardless of the fact that it's got no chance of success, and is only going to get them a reputation for wasting everyone's time. They would of course also have the chance at that point of persuading a silent majority (on who's behalf they may think they speak) to express support in the poll, which may make the opposition realise that there is a wider spectrum of opinion than they thought, which may lead to better debate. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Russ Allbery writes: > Don Armstrong writes: > >> I'm likely biased because I'm in a privileged position and rarely have >> to deal with concerted harassment directed specifically at me, so I >> might be minimizing the real fear people have because I personally >> haven't experienced it. > > This is almost exactly my concern. > > I'm not particularly worried about making all of my Debian votes public. > I've been on the Internet for a long time, have the resources to defend > myself against the sorts of reactions I think are likely, and am not the > sort of person who tends to draw the most attention anyway. Maybe I'm too > optimistic since things seem to be getting worse, but I'm not very worried > for myself. > > However, I think there's a bias implicit in that sort of analysis, and I > don't want only the Debian Developers who are similarly situated to be > able to vote. If someone is more socially vulnerable than I am, I don't > want them to have to do this calculus in order to vote their conscience. This sums up my position as well, but I suppose I was concerned that we might stumble into doing something to protect the vulnerable based on several privileged people's imaginings of what it might be like to be vulnerable. Of course, one cannot really expect someone who feels vulnerable to say so in public. I've had one person point out in private that they did feel vulnerable, but in the end, steeled themselves to vote anyway -- I would hope that we could arrive at a place where people don't have to go through that. > I agree with Sam's analysis that the point of Debian votes is to vote as > individuals, not to vote as trustees on behalf of a constituency, and > while I too have gotten valuable understanding and course correction from > seeing people I respect in the project vote differently than me, I don't > think public voting is a core project value. I therefore find it hard to > argue against people's perceived safety (even if it is only a perception). I find the idea that someone might be forced to reveal their previously undeclared political views in order to vote particularly persuasive as a reason to have as-secret-as-possible votes on at least those subjects. Alternatively, we could just reach a consensus not to even attempt these sorts of position statements in future, since all they do is highlight divisions. Given that we generally want DDs to be drawn from as diverse a population as possible, we should expect our views on pretty-much any subject other than Free Software to represent the full spectrum of opinion, so drawing an arbitrary line somewhere and then getting the project to divide on which side we should stand as a group is not likely to give a useful result, but will give people reasons to be upset with one another. I don't really see that the secrecy of the ballot helps in such a case, since most of the damage is done in the pre-vote discussion. Perhaps we need a mechanism for people to express a view that a proposed GR is something that we shouldn't be deciding, to quickly kill the discussion if a (perhaps super) majority would rather just leave it alone. >> Perhaps the compromise position is to default to secret ballots, but >> allow people to automatically unmask their preference at the appropriate >> time. [Totally not supported by devotee currently, but certainly >> possible to enable.] > > That's an interesting thought. My immediate reaction is that the social > signaling of who reveals their votes and who doesn't is a bit complicated > and I'm not sure what effect it would have. In a divisive argument, one grouping might well be able to expose their opposition's votes by revealing their own. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Stefano Rivera writes: > Hi Philip (2022.02.14_13:55:45_+) >> Under what circumstances are we expecting people to think that letting >> other DDs know how they voted is going to be against their interests? > > From the discussions around recent GRs, I saw that there were community > members who were uncomfortable making their views on an particular > decisions public. Not because of fear of attack from a single toxic > person, but rather that there'd be many people who disagreed with their > vote. > > I can imagine this if you are voting for the unpopular option, or an > option perceived as not being politically correct. I can imagine being fearful of that too, but what I'm interested in is whether we have any evidence of that fear being justified. If it is actually the case that any of our votes have been followed by people giving one-another grief over their vote, that is one thing, and I think we need to ensure that we have mechanisms for dealing with such an eventuality. On the other hand, if that does not actually happen, then I'd suggest that it's better to establish that as a well known fact than to allow people to continue being fearful that it might be something they should expect. I think going to a lot of effort to decide that ballots should be secret strongly implies that we currently have such a problem, whether we do or not, which seems only likely to amplify those fears regardless of whether they are well founded. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Antonio Terceiro writes: > On Mon, Feb 14, 2022 at 12:01:43PM +0100, Thomas Goirand wrote: >> On 2/14/22 10:36, Philip Hands wrote: >> > I don't actually care if our votes are readable by the general public, >> > so would one way of addressing the concerns of attracting abuse would be >> > to make the tally sheet only available to DDs behind authentication? >> >> I very much agree with the above. >> I don't see why I would want to hide my opinion from the other DDs. > > Making the ballot secret makes it possible for one to not do so if they > feel that is against their best interests, but does not stop you from > stating your opiniion publicly. Under what circumstances are we expecting people to think that letting other DDs know how they voted is going to be against their interests? If we are assuming that some DDs might start attacking people based on the way they voted, then I'd suggest that it's more important to eject such toxic people from Debian than it is to try to mitigate their toxicity using measures that have negative side-effects. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Sam Hartman writes: > Rationale > = > > During the vote for GR_2021_002o, several developers said they were > uncomfortable voting because under the process at that time, their name > and ballot ranking would be public. I know that was said in the discussion at the time, but I wonder to what extent people either subsequently received any abuse about it, or modified their voting behaviour in response to that fear. Do we have any evidence that either thing happened? Also, it seems to me that the problem we're considering is that toxic people who are not really interested in Debian at all, might stumble across Debian voting results, and then use what they find as a reason to persecute some of us on-line. Is that about right? I have used the results of votes in the past to start conversations with people that I disagree with in some issue in order to better understand how they came to the other view. One can generally find someone on the other side of the argument who you already know and respect, which makes it much harder to dismiss them as an idiot. I'd miss that in a properly secret ballot. I don't actually care if our votes are readable by the general public, so would one way of addressing the concerns of attracting abuse would be to make the tally sheet only available to DDs behind authentication? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Secret Ballots: Handling Disagreement with the Secretary
Holger Levsen writes: > On Sun, Jan 30, 2022 at 03:58:50PM +, Holger Levsen roughly wrote: >> On Sat, Jan 29, 2022 at 03:22:24PM -0700, Sam Hartman wrote: >> > In my proposal all ballots would be secret, and the secretary would not >> > make a determination about that. >> what's the definition of 'secret' here? > > I'd still like to hear an answer to this question and thus I hope > it will be addressed in the upcoming proposal. I too would also like an answer to that. My reason (and maybe Holger's too) is I'd say that there is no possibility of guaranteeing real permanent absolute secrecy in a vote that we can practically conduct over the Internet (at least, not one where the results are also trustworthy), so there is going to be some sort of compromise, and it is essential to understand the nature of that compromise in order to come to any conclusion about whether it might be a good idea to do the the thing that we're really talking about. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: General Resolution: Change the resolution process: results
Felix Lechner writes: > Hi, > > On Mon, Jan 31, 2022 at 6:37 AM Bernd Zeimetz wrote: >> >> I'm wondering if there is anything we can do to motivate more >> people to vote. > >>From Wikipedia's page on 'Get Out the Vote': [1] > > "GOTV is often most effective when potential voters are told to do > so "because others will ask." Voters will then go to the polls as a > means of fulfilling perceived societal expectations. Paradoxically, > informing voters that turnout is expecting to be high was found to > increase actual voter turnout, while predicting lower turnouts > actually resulted in less voters. > > The red bar chart in the same article indicates something similar. > Perhaps we should publish a list of actual voters afterwards, without > their choices, or award badges on Salsa? Something like this, perhaps? https://www.debian.org/vote/2021/vote_003_tally.txt Personally, I think it's totally fine for decisions to be made by those of us that feel like we have an opinion, and for those that don't feel the need to vote to trust that the outcome from that will be reasonable. I don't see how encouraging people to vote who lack either an opinion on the subject in hand, or the motivation to vote, is supposed to improve the outcome. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
Russ Allbery writes: > This constitutional change attempts to address those issues by > > * separating the Technical Committee process from the General Resolution > process since they have different needs; > * requiring (passive) consensus among TC members that a resolution is > ready to proceed to a vote; > * setting a maximum discussion period for a TC resolution and then > triggering a vote; > * setting a maximum discussion period for a GR so that the timing of the > vote is predictable; > * extending the GR discussion period automatically if the ballot changes; > * modifying the GR process to treat all ballot options equally, with a > clearer process for addition, withdrawal, and amendment; > * changing the default option for a GR to "none of the above"; and > * clarifying the discretion extended to the Project Secretary. Seconded. Although, I think you should fix A.2.3 which currently says: > ... sponsors stepping forward, it removed from the draft ballot. ^ which I'd suggest needs an 'is', or perhaps 'will be', between 'it' & 'removed' Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Adrian Bunk writes: > On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote: >>... >> * The length of the discussion period is ill-defined in multiple ways, >> which has repeatedly caused conflicts. It only resets on accepted >> amendments but not new ballot options, which makes little logical sense >> and constantly confuses people. There's no maximum discussion period >> defined, which means fixes for that risk introducing a filibuster. >> >> * Calling for votes is defined as a separate action from the end of the >> discussion period, but in practice the constitution allows any developer >> to call for a GR vote via an abuse of process that probably wasn't >> intended, and even apart from that, the set of people who can call for a >> vote is strange and not very defensible. >>... > > The process to shorten the discussion period is also suboptimal. > > In the latest GR the way the discussion period was shortened was > perceived by many as an anti-democratic attempt to suppress discussions > about the contents and alternative ballot options. > > And there was plenty left to discuss (including wording of ballot > options and secrecy of the vote) when the minimum discussion period > ended and the vote was called. > > I would suggest to replace the option of shortening the discussion > period with the possibility of early calling for a vote after a week > that can be vetoed by any developer within 24 hours. This would ensure > that shorter discussion periods would only happen when there is > consensus that nothing is left to be discussed. Would you expect a different result if that had been done in this case? There were certainly people objecting to things, but it seems to me that their views were correctly reflected in the vote results, in which case I'm wondering what would have been added by discussing it further. It's possible that there were people who were on holiday or some such, and thus missed the whole thing, but on the other hand it's also pretty clear that some people were at the end of their endurance ... perhaps they would have been driven to ignore the continuing discussion if it had gone on longer, and thus been disenfranchised. I don't think that one can automatically assume that more discussion is better. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Felix Lechner writes: > Hi, > > On Mon, Apr 19, 2021 at 2:40 PM Pierre-Elliott Bécue wrote: >> >> I don't understand how you semantically see 7 and 8 as comparable. > > Aside from Bdale's reason for ranking unwanted options below FD—which > were motivated by the voting system—I do: GRs do not decide a matter > with prejudice, even though the weight to bring them again may be > substantial. Therefore, doing nothing is very similar to doing nothing > but talking more. While I see what you're saying, I think it is missing a very important point, which is that the bulk of the voters apparently disagree. FD came quite close to the bottom of the ranking, whereas not issuing a statement came top -- if the voters as a group have distinguished between these two options so significantly it seems quite odd to pretend that they are equivalent. The two things also send quite different messages in the result. If the FSF have paid attention to this vote (which I'd hope they did) they'll have seen that deciding not to issue a statement won by a single vote. All other options that achieved majority were critical of the FSF. I think they would have (rightly) interpreted FD winning as a completely different result. > As we all heal from this divisive issue, I furthermore find it > meaningful that proponents of a shortened discussion, who were at > times accused of pushing the resolution, were actually aligned with > voters: By a narrow margin, people did not want to discuss the matter > at all. or (given how low down the order FD came) by a wide margin they didn't want to talk about it any more -- either way, I agree with you on that. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Adrian Bunk writes: > On Sun, Apr 18, 2021 at 06:58:49PM +0100, Barak A. Pearlmutter wrote: >>... >>... >> If that arrow had been reversed (which >> could be done by switching the order of two adjacent options on TWO >> BALLOTS) >>... > > On one ballot. > > Which brings us back to my suggestion that we should make ranking all > options mandatory I'm really struggling to understand how you can think that it's important enough to try to start a discussion now about forcing everyone to rank everything when you didn't bother to rank 4 of the options in the GR ballot. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What does FD Mean
Adam Borowski writes: > On Tue, Apr 13, 2021 at 08:40:03AM +0200, Philip Hands wrote: >> Adam Borowski writes: >> > Here's how this works in the real world: >> > https://en.wikipedia.org/wiki/Donkey_vote >> > >> > As our ballots routinely get sorted (systemd was FBADHEG$) according to the >> > vote's spectrum, it would be nice to get resistant to such votes. Thus, >> > what about sorting ballots randomly instead? >> >> Do you have any evidence at all that this occurs in Debian votes? >> >> If you have read the article to which you refer, you'll have seen: >> >> Donkey votes are most common where preference voting is combined with >> compulsory voting, such as in Australia, particularly where all >> candidates must be ranked on the ballot paper. >> >> Our elections are not compulsory > > That's why we don't get pure donkey votes (12345678). > >> and there is no insistence that one ranks all options > > This has been suggested in this very thread. I'm struggling to understand the point you're making here now. Are you saying that you originally raised the spectre of Donkey Votes as an argument against the idea of having to rank all choices? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What does FD Mean
Adam Borowski writes: > On Sun, Apr 11, 2021 at 11:27:28PM +0200, Timo Röhling wrote: >> * Adrian Bunk [2021-04-11 20:53]: >> > I am not saying people were stupid. >> Okay, that was hyperbolic. But you have to admit that you don't seem to >> put much confidence in people's ability (or willingness) to read the >> explanations that come with each ballot. I am by no means a voting >> system nerd and found them quite understandable. > > Here's how this works in the real world: > https://en.wikipedia.org/wiki/Donkey_vote > > As our ballots routinely get sorted (systemd was FBADHEG$) according to the > vote's spectrum, it would be nice to get resistant to such votes. Thus, > what about sorting ballots randomly instead? Do you have any evidence at all that this occurs in Debian votes? If you have read the article to which you refer, you'll have seen: Donkey votes are most common where preference voting is combined with compulsory voting, such as in Australia, particularly where all candidates must be ranked on the ballot paper. Our elections are not compulsory, and there is no insistence that one ranks all options, so I seriously doubt that people who are going to the trouble of filling in all the numbers would bother if they had no interest in the actual outcome, which is what you are trying to imply. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Making the RMS resolution a Secret Ballot
Martin Pitt writes: > Hello all, > > Pierre-Elliott Bécue [2021-04-10 18:16 +0200]: >> After a careful thinking, I agree with Elena's opinion and would rather >> not make the vote private while it already has started. > > Ulrike Uhlig [2021-04-10 18:20 +0200]: >> On 10.04.21 15:33, Didier 'OdyX' Raboud wrote: >> > Le vendredi, 9 avril 2021, 19.12:26 h CEST Sam Hartman a écrit : >> >> > 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 >> Reading Odyx' arguments on keeping the ballot public makes a lot of sense to >> me though and I'm now in favor of keeping the usual decision making >> processes intact, and to change the constitution later in time - if the >> project wishes to do so. > > Thanks to the three of you -- very carefully and reasonably worded. As someone > who initially also prefered a secret vote [1] (although that was *before* > voting started), I find this entirely convincing. One tiny extra point that I find in favour of making the votes public (at least to other DDs) is that I think it provides the chance for one to track down a friend who's opinion one generally trusts, who happens to hold an opposing view on the question in hand. In the past I've found doing this to be a good way of avoiding falling into the trap of assuming all those on the other side of an argument are simply mistaken about it. Occasionally I've bothered to ask how they arrived at their opinion, but generally I find that simply knowing the fact of their vote is enough. Despite our community being quite diverse in many ways, I'd say the things that unite us are much more important than the things that divide us, and having a chance to realise that people you like and trust happen to have come to differing conclusions when presented with the same facts is a welcome reminder that reasonable people can differ on such matters simply because they assign those facts differing weights, rather falling for the temptation to think that they are evil or stupid. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: What does FD Mean
Mathias Behrle writes: > * Sam Hartman: " Re: What does FD Mean" (Fri, 02 Apr 2021 20:53:05 -0400): > >> >>>>> "Mathias" == Mathias Behrle writes: >> >> >> But for a two option situation, option A do the thing and option >> >> B FD, FD probably does map to no fairly well. >> >> Mathias> I would really like to avoid this situation, where FD is >> Mathias> expected to leave room for such wide interpretations, >> Mathias> especially if it is avoidable as easy as to put at least >> Mathias> some of the alternative options on the ballot. A ballot >> Mathias> with only 'yes' and 'FD' should IMO just not happen. >> >> I think it's fine in cases where you have fairly strong confidence that >> yes will win. >> Let's say that for some reason we really needed a project statement that >> the GPL was a DFSG-free license. >> I think yes|FD would be fine. >> Or for an example that actually happened, we needed a GR to replace >> chairman with chair in the constitution. >> In that case, I think yes|FD is fine. > > I see your use case, but I still think that even on such a topic there could > be > someone who thinks that the topic - for whatever reason - shouldn't be > discussed at all. Why should they vote FD? The reason we have it as FD rather than some explicit end-of-discussion option is to avoid the disappointment that would result from a majority of the project voting for e.g. "Just Stop!" ... and the discussion continuing nonetheless. At least with FD you know what to expect. Also, for the people that want to continue going on about something, I think FD is more likely to make them calm down than an explicit prohibition against which they could feel righteous anger[1]. Cheers, Phil. [1] prompting long and tedious threads about Freedom of Speech. If you're looking for less discussion, vote FD ;-) -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Amendment to RMS/FSF GR: Option 5
Roberto C. Sánchez writes: > On Fri, Apr 02, 2021 at 06:18:51PM +0200, Zlatan Todoric wrote: >> >> On 4/2/21 16:56, Roberto C. Sánchez wrote: >> > On Fri, Apr 02, 2021 at 03:49:04PM +0200, Zlatan Todoric wrote: >> > > On 4/2/21 09:20, Craig Sanders wrote: >> > > > TEXT OF OPTION 5 >> > > > >> > > > >> > > > Debian refuses to participate in and denounces the witch-hunt against >> > > > Richard >> > > > Stallman, the Free Software Foundation, and the members of the board >> > > > of the >> > > > Free Software Foundation. >> > > > >> > > > >> > > > >> > > > >> > > I sincerely think debian-vote should be read-only for non-DDs because >> > > this >> > > person is not a DD (afaict) and is just polluting our list with such >> > > non-sense. >> > > >> > Zlatan, it is clear that you disagree with Craig's mail, but that is no >> > reason attack him personally as you have done. >> Attack? I stated that he is (afaict) not a DD. He used 'witch-hunt" term, >> which is just a pollution of the list. People throwing random words from >> past with no connection to present doesn't give me any hope that they mean >> good nor that they think about their actions. > > Using the word 'witch-hunt' is an expression of an opinion. Perhaps > 'character assissination' might have been less opinionated, though still > very much a loaded term. Incidentally, the use of "witch hunt" in > modern English is idiomatic. It has nothing to do with hunting actual > witches or with any sort of extreme punishment associated with > historical real witch hunts. In the modern usage it is about punishing > someone (frequently someone who is a part of the group but not at fault) > so that the larger group or its leaders can feel as though action has > been taken to deal with some "evil" which has been exposed. You'll need to ask Craig what he actually meant by that. My assumption would be that it was an allusion to McCarthyism, and the associated anti-communist moral panic in the 1950s that Arthur Miller dramatised in The Crucible. The term's been given a recent retread as a thing that strong-man leaders use as a weapon against investigative journalists who are doing their jobs, but I doubt Craig meant that. The problem I see with his proposal is in the way it uses the term 'witch-hunt' as though it is an undisputed fact that such a thing is currently in progress. The way things normally go in a witch-hunt is that some people are accused of something, then those in authority coerce the accused into naming conspirators, and then people start inflating the charges being made in order to distance themselves from the accused and prove their own purity -- defending any of the accused just gets you added to the list of wrongdoers. A consequence of that is that the middle ground becomes a very dangerous place to be, and people flee to the extremes in order not to be accused of being on the other side of the argument. Is that really what we're seeing? This GR seems to encompass a pretty broad spectrum of options, and I don't think there was that much in the way of accusing people of being as bad as the person they were defending, or anything of that sort. I hope that people are not being attacked in private -- indulging in such behaviours would definitely be a Code of Conduct violation, but I think even that would fail to qualify as a witch-hunt, because the intimidation needs to be made obvious to the wider group for something to qualify as a witch-hunt. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Secret ballot and RMS Resolution
Kurt Roeckx writes: ... >after the vote the Project Secretary lists all the votes cast. ... > You could say that "all the votes cast" could mean what was voted, You could also note that there is no stipulation of how soon after the vote that publication must occur, and decide that in this case that an appropriate interval would be e.g. no less than ten years. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Amendment to GR on RMS rejoining FSF
Sruthi Chandran writes: > On 26/03/21 10:45 pm, Sruthi Chandran wrote: > >> >> Dear fellow DDs, >> >> Second the amendment text if acceptable to you :) >> > Re-sending with fixed signature and replacing twitter link with > gnusocial link. > > >> Begin text >> >> Under section 4.1.5 of the constitution, the Developers make the >> following statement: >> >> *Debian’s statement on Richard Stallman rejoining the FSF board* >> >> We at Debian are profoundly disappointed to hear of the re-election of >> Richard Stallman to a leadership position at the Free Software >> Foundation, after a series of serious accusations of misconduct led to >> his resignation as president and board member of the FSF in 2019. >> >> One crucial factor in making our community more inclusive is to >> recognise and reflect when other people are harmed by our >> own actions and consider this feedback in future actions. The way >> Richard Stallman announced his return to the board unfortunately lacks >> any acknowledgement of this kind of thought process. We are deeply >> disappointed that the FSF board elected him a board member again despite >> no discernible steps were taken >> by him to be accountable for, much less make amends for, his past >> actions or those who have been harmed by them. Finally, we are also >> disturbed by the secretive process of his re-election, and how it was >> belately conveyed [0] to FSF’s staff and supporters. >> >> >> We believe this step and how it was communicated sends wrong and hurtful >> message and harms the future of the Free Software movement. The goal of >> the software freedom movement is to empower all people to control >> technology and thereby create a better society for everyone. Free >> Software is meant to serve everyone regardless of their age, ability or >> disability, gender identity, sex, ethnicity, nationality, religion or >> sexual orientation. This requires an inclusive and diverse environment >> that welcomes all contributors equally. Debian realises that we >> ourselves and the Free Software movement still have to work hard to be >> in that place where everyone feels safe and respected to participate in >> it in order to fulfil the movement's mission. >> >> >> That is why, we call for his resignation from all FSF bodies. The FSF >> needs to seriously reflect on this decision as well as their >> decision-making process to prevent similar issues from happening again. >> Therefore, in the current situation we see ourselves unable to >> collaborate both with the FSF and any other organisation in which >> Richard Stallman has a leading position. Instead, we will continue to >> work with groups and individuals who foster diversity and equality in >> the Free Software movement in order to achieve our joint goal of >> empowering all users to control technology. >> > [0] https://status.fsf.org/notice/3796703 >> >> Heavily based on: >> >> [1] https://fsfe.org/news/2021/news-20210324-01.html >> >> [2] >> https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-stallman-fsf-board >> >> End of text Seconded. Thanks, Sruthi. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: How to leverage money to accomplish high impact Debian projects
Christian Kastner writes: ... > * Someone gets paid to improve Debian Some packages end up in this situation because there is no need for them to be in the archive. If you pay someone to keep them in, you are removing the evolutionary pressure that ensures that Debian doesn't fill up with dross, so you're actually paying someone to make Debian worse in that case. How can one tell the difference between useful stuff and dross? Given the diversity of use cases that Debian covers, I think the only way is to allow things to drop out of the archive if they attract insufficient interest to stay in, be that from volunteers or paid-for effort funded by interested users. That way, people that care get to notice the thing dropping out of the archive, and do something about it ... or not. If we had a committee deciding which mediocre packages were sufficiently important to have money thrown at them, we'd effectively block new enthusiastic volunteers to step up to do the job unpaid, we'd remove any incentive for users to fund such work directly, and we'd remove a lot of the incentive for writing a replacement that was better than the things that nobody wants to maintain. As Jonas points out, we'd almost certainly also demoralise the fine people that already maintain loads of rather uninspiring packages, and cause them to make the problem worse by orphaning those packages. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Willingness to share a position statement?
Daniel Lenharo writes: > Em 24/03/2021 18:53, Jonathan Carter escreveu: > >> I'm comfortable making a statement on behalf of the project if >> necessary. On this particular issue, I feel it's better that individual >> developers go and make their voices heard. That said, I will also >> respect the outcome of the GR and follow it if it completes within my term. >> >> -Jonathan >> > > i didn't understand why people can't sign the letter individually. > I wouldn't like to see my name associate with an action like this. I can certainly understand that it is very uncomfortable if some organisation one is associated with adopts a stance you are unable to support for whatever reason, in a way that implies that you do support it. That being the case, would it suffice (in the case where the GR gets approved) for it to be announced with something like: Having passed a General Resolution by majority vote[1], the Debian project ... so that it is very clear that there is room for dissenting opinion, and with a link to the vote page so that anyone that is interested can easily discover how individuals voted on the issue? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Willingness to share a position statement?
Adam Borowski writes: > On Tue, Mar 23, 2021 at 04:56:39PM -0600, Gunnar Wolf wrote: >> Hello, >> >> I hope not to be too inflamatory with this. As you are surely aware, >> last week Richard Stallman was reinstated as part of the Board of >> Directors of the FSF. That is something deeply disturbing and >> confidence-shattering for many of us. >> >> Some people have moved to action -- if nothing more, at least to >> express they are disgusted with the turn of events > > I'm also disgusted with such hatred towards the person who started the > whole "Free Software" thing, and personally did most of the work in the > early days. You seem very easily able to ascribe hatred to others, on the basis of no evidence, which makes me wonder whether hatred might be an emotion that you regularly feel yourself, and thus imagine it drives others. If that is the case, you have my sympathy, because I have only very occasionally managed to hate someone during my life, and I found it a thoroughly unpleasant experience. As it happens, I'm happy to give RMS the credit for the direction of quite a lot of my life, given that I read the GNU manifesto at around the time I left university, and the thinking therein was definitely a major driver in me setting up my business supporting Free Software. Despite the respect that inevitably goes with that, I just signed the letter[1], not out of hate, but rather in the hope that RMS will not again be placed in a position where he can further tarnish his reputation with his obnoxious opinions about things other than Free Software. Cheers, Phil. [1] https://rms-open-letter.github.io/ -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: How to leverage money to accomplish high impact Debian projects
Jonathan Carter writes: > On 2021/03/18 21:44, Philip Hands wrote: >> I've been pondering how it might be possible to spend more of Debian's >> money, and it occurred to me that we could allocate a budget to each DD >> which they could spend on pretty-much anything (as long as, for Debian >> funds, the expenditure is allowed under the relevant non-profit >> restrictions that apply to the funds that we hold -- you could apply >> your own criteria of course). >> >> That way you get to take advantage of the wisdom of the crowd, since >> people in various areas of Debian are bound to know about things that >> have been left undone for years or decades, that some targeted funding >> would almost certainly sort out once and for all. >> >> You'd probably want to have some sort of oversight (e.g. some ex-DPLs) >> just to ensure that the madder ideas get filtered out, but if you ask >> people to only suggest ideas that they'd want to spend their own money >> on if they had it to spare, that should ensure that most people don't >> get too silly. >> >> Also, one could say that the people suggesting the project should not be >> the beneficiary, and should write some sort of report indicating how >> well it went before they would get any new budget allocated. People >> that had thought of funding things that turned out to be successful >> could then be given larger budgets to play with in future. >> >> Encouraging people to pool their budgets to fund bigger things would >> hopefully result in them forming teams of mentors to oversee the work. > > I think as things stand now, every DD pretty much already has the entire > Debian budget available at their disposal if they can think of a way to > spend it that benefits the project. I was reflecting on the way the Peertube funding was achieved. There were enough people keen on that happening that if we'd each had an earmarked e.g. 1k budget to allocate, we could have just agreed it amongst ourselves, and done it, without a lot of back and forth on the lists trying to establish whether there really was something like a project-wide consensus about it, and perhaps even not needing to ask permission from the DPL[1]. Then again, maybe it's good to have that project-wide consensus phase, but it means that things take much longer to get done, and are a lot more effort than they ought to be, which is probably enough to make sure that fewer such things get done. One major benefit that I'd expect to see coming from the personal budget approach would be that all those that had contributed their budgets towards something would feel a personal responsibility for how it went, and thus would be much more likely to follow up to make sure that things went well, if only in order to justify having a budget in future. Cheers, Phil. [1] one would presumably need to run it past someone to check that the non-profit rules were being complied with, but that could be done by a delegated team. I'd have thought that could mostly be managed by having a good write-up of what is and is not allowed on the wiki, so people know not to bother trying things that are not allowed. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: How to leverage money to accomplish high impact Debian projects
Hi Raphael, I'm not running for DPL, but since you asked... Raphael Hertzog writes: > 1/ How do you explain this lack of interest? > > I have read recently from other Debian members that they have a feeling > that Debian is stagnating, and I share that feeling to some degree. If we > had plans and motivated people, surely some of those would have stepped up > to implement them in exchange of some remuneration. Do you share that > feeling too? Could it be that people are being protective of their motivation? I'd guess that many people know about studies showing that one can turn a pleasurable hobby into a tiresome chore simply by being paid to do it. I think one might be able to avoid that to some extent if it's clear that the work is something that has attracted no volunteers so far, despite being a good idea that's been around for a while -- that should allow people to draw a line between those things they were happy to do unpaid, and the thing that they're being paid to do, such that they don't stop doing both when the payments stop. > 2/ I really want this initiative to be successful so I'm now looking into > ways to make it work. I'm considering paying someone to identify useful > projects. That person could talk to various teams, make proposals based on > their own experience, and even run a poll among Debian developers. The > idea is that we want to find high-impact projects that can help Debian get > out of this "stagnation". > > What do you think of this idea? > > I'm considering past DPLs for this role as they have a broad knowledge of > the project and usually also some vision for the future. But I'm open to > anyone than can convince me they would do a good job for this. :-) I've been pondering how it might be possible to spend more of Debian's money, and it occurred to me that we could allocate a budget to each DD which they could spend on pretty-much anything (as long as, for Debian funds, the expenditure is allowed under the relevant non-profit restrictions that apply to the funds that we hold -- you could apply your own criteria of course). That way you get to take advantage of the wisdom of the crowd, since people in various areas of Debian are bound to know about things that have been left undone for years or decades, that some targeted funding would almost certainly sort out once and for all. You'd probably want to have some sort of oversight (e.g. some ex-DPLs) just to ensure that the madder ideas get filtered out, but if you ask people to only suggest ideas that they'd want to spend their own money on if they had it to spare, that should ensure that most people don't get too silly. Also, one could say that the people suggesting the project should not be the beneficiary, and should write some sort of report indicating how well it went before they would get any new budget allocated. People that had thought of funding things that turned out to be successful could then be given larger budgets to play with in future. Encouraging people to pool their budgets to fund bigger things would hopefully result in them forming teams of mentors to oversee the work. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Proposed GR: State exception for security bugs in Social Contract clause 3
Scott Kitterman writes:
> On Thursday, January 12, 2017 02:26:59 PM Sean Whitton wrote:
>> Hello,
>>
>> On Thu, Jan 12, 2017 at 03:11:46AM +, Scott Kitterman wrote:
>> > Here's an example of possible unintended consequences:
>> >
>> > Currently we enumerate no specifics about exceptions to when things
>> > should be public. Once we have a foundational list of acceptable
>> > reasons to not be public (security would be the only one), then it's
>> > easy to infer that's the complete list.
>> >
>> > Would this GR prohibit the tech ctte practice of private deliberations
>> > about recommendations for new members? I think it might.
>> >
>> > I've worked in private with other DDs to resolve disputes within the
>> > project. Often a quiet conversation out of the public glare can make
>> > solutions possible that wouldn't happen if all discussion was public.
>> > Does this GR prohibit that? Maybe.
>>
>> Thank you for your e-mail -- I now understand your objection.
>>
>> All the other wording in clause 3 is about bug reports against the
>> Debian system. The examples that you give are about unresolved issues
>> in the Debian project -- disputes between people, rather than problems
>> in source and binary packages. I find the line between the Debian
>> system and the Debian project to be fairly sharp. I'd be interested to
>> hear if you disagree.
>>
>> The header of clause 3 ("We will not hide problems") admittedly could
>> refer to your examples. Would it help if my GR text were amended to
>> append "in the Debian system" to the header of the clause?
>
> That then has the opposite problem. It clearly narrows the notion of not
> hiding problems and I don't think that's good either.
>
> I'm still at don't monkey with foundational documents to solve
> non-problems.
Quite.
I'm yet to be convinced that there exists anyone that would be upset by
the fact that our security team might abide by embargoes in supposed
defiance of 'not hide problems'. I am also not convinced that if there
does exist such a person, and they are capable of becoming upset enough
about it to be driven away from Debian, that that would be a great loss.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Gunnar Wolf writes:
> Ansgar Burchardt dijo [Sun, Jul 24, 2016 at 02:40:44PM +0200]:
>> >> 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.
>>
>> That sounds like what a president does when there is no dedicated
>> secretary role (which we don't have for the ctte)?
>>
>> But there are also the choices of moderator, facilitator, and convenor
>> left from [1]. Though "moderator" is also a thing in certain contexts
>> ("neutron moderator") and the Wikipedia article on "facilitator"[2]
>> mentions a neutral position which doesn't quite fit with tie-breaking.
>>
>> [1] <https://en.wikipedia.org/wiki/Chairman>
>> [2] <https://en.wikipedia.org/wiki/Facilitator>
>>
>> All non-Chair choices also avoid confusion with a possible future Chair
>> of the Technical Committee that might be used as part of an inauguration
>> ceremony ;)
>
> This topic is getting contentious. Should we submit it to the
> Technical Committee for them to recommend an optimal way out?
If possible, the subject experts should make such decisions -- assuming
that we're talking about an armchair, how about moving this discussion
to debian-arm?
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
signature.asc
Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Lionel Elie Mamane writes: > On Fri, Jul 22, 2016 at 12:14:14PM +0200, Lionel Elie Mamane wrote: > >> I'd rather you asked me for a signed agreement in triplicate before >> taking it out of the debian-private debian-developer-only archives to >> quote/post somewhere else. > > Except I'm not posting to debian-private, but to debian-vote. Oh, > silly me. In light of the preceding mail, I can only agree with your final assessment. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Margarita Manterola writes: > The Debian Constitution is very well written, in a way that is almost > completely > ungendered. The only gendered word left is the Chairman of the Technical > Committee. There is no reason for this position to be gendered. Ungendered > alternatives for Chairman are Chair and Chairperson. While both work, Chair is > simpler and shorter. > > I'm therefore proposing the following General Resolution: > > === 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. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: General Resolution: Fix Minor Bugs in Constitution
Sam Hartman writes: >- 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 >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, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Restated Amendment: We Choose Wording of the Day
I second the below amendment. BTW I seconded Andreas's original GR too, but am persuaded by this so would like to see it on the ballot. Sam Hartman writes: > Restated to fix comments received. > For formality, to the extent that I am able, I withdraw my previous > amendment. > > As I discussed, in Andreas's resolution, I think that the strategic > voting fix introduces more problems than it serves. INstead, I propose > that we don't fix that, but trust ourselves to propose ballot options > that are statement-of-the-day-like ballot options not requiring a > super-majority when doing so is wise. I think that doing so is > generally a good idea when you have a super-majority option and its > opposite on the same ballot--when there is substantial contraversy about > whether to move in the direction of the super-majority option or some > other option on the same ballot. > > I have chosen to retain the preference for the default option in the TC. > If four members of the TC really cannot live with an option, we're > better off with more discussion or taking it to a GR. > > Even in the Init system discussion, which I think is the most > controversial decision to come before the TC, several of the TC members > who preferred options that did not win explained what changes would need > to be made for them to consider options similar to the one that won to > be acceptable (ranked above FD). > As it happened, four TC members didn't think no decision was better than > the decision we got: if four members had ranked the winning option below > FD, the chair would not have had the opportunity to use his casting > vote. > > We also have some strong evidence from emails where some TC members > explained their balloting decisions including what they ranked above FD > that the tactical voting people were afraid of didn't happen. > > We're actually quite good at deciding whether another round of painful > discussion is worth the cost or not, and when people we've appointed to > make these decision decide that it is, I'd rather not second guess them. > > Specifically, I formally propose to replace the GR text with: > >- 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 >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 - -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
t; > > > > >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 - > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJV3h0PAAoJENrvwFpthGSOgRIH/iHtX2bvWjRabw58huFsgaVn > MX0D3JPXZlaPv9b8doerfuhQQc4MJHEhqDyz4Bd93L2tzHfs/ZYqSVOlEQC1JalJ > 7/ZV7Qyr9QNRtU6RMP0v5F3PoDpZGn454V4bKiaqcwsvM/WAzPxHZPsyy1lkqfeS > GS+cGORdMmt3vKVze36ZeOK1hMMpHvpG61noepQtvVkIV2uKG/XLfxLCSP0J+fMH > y/idIuxeeyCOpij3YDdzUZcj3csOgDn5GaTSWxUkS2zTulMGpczek2I4CTxJyIMT > CQuP6Z2hRzQ3if6L2/XViLd0jVCrddYuCZlE0LsBs1zEPxKqQD3xW1CB2/rmWSo= > =LOrV > -END PGP SIGNATURE- > -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: ballot
Kurt Roeckx writes: > On Thu, Dec 18, 2014 at 09:48:45AM +0000, Philip Hands wrote: >> Hi Kurt, >> >> You should probably have included a >> >> Reply-To: gr_cttet...@vote.debian.org >> >> in the absence of that, people need to concentrate :-) > > This is not the call for vote yet. That will include it. Doh -- silly me -- so _I_ concentrate ;-) Sorry for the noise. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpx3RYfxLutq.pgp Description: PGP signature
Re: ballot
Hi Kurt, You should probably have included a Reply-To: gr_cttet...@vote.debian.org in the absence of that, people need to concentrate :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpxvMIlAXmHZ.pgp Description: PGP signature
Re: Suggestion to simplify clause 2. (was: Re: GR proposal, Call for Seconds - term limit for the tech-ctte)
Lucas Nussbaum writes: > On 02/12/14 at 12:52 +0100, Stefano Zacchiroli wrote: >> If there is consensus that simplicity is preferable and Lucas won't mind >> dealing with the upcoming ties (in a way that is constitutionally >> sound), I'll be happy to formally accept an amendment to that end. > > I would find it a bit strange to deal with the vorlon/aba tie, but would > of course accept to do it if the resulting general resolution put that > responsibility in the DPL's hands. Didn't you just do it already ;-) > How would you implement that? By expliciting making the DPL the > tie-breaking entity in that case, or by implicitely falling back to > 5.1.4 "Make any decision for whom noone else has responsibility."? > > If you make it explicit, it would be better to clarify if the DPL who > makes the decision is the DPL on January 1st, or on the following > December 31st. Which might result on more verbosity that the current > version, heh :-) Since it will only ever be relevant for the vorlon/aba tie, it seems superfluous to put anything into the constitution. If you insist on something explicit, I'd suggest: 3. Appointments are not simultaneous. That way, if they might appear to be simultaneous, as in the aba/vorlon case, it's up to someone (i.e. the DPL) to decide which one was done first. I'd suggest that that isn't really needed, but seems harmless. Conveniently, as you point out, the announcement order for vorlon/aba coincides with the way the tie-breaker would have acted anyway, so we can just say that vorlon was appointed moments before aba and all is well, and the problem never needs to arise again, so no complicated clauses required. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpxzgrbYhZAd.pgp Description: PGP signature
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
Tollef Fog Heen writes: > ]] Stefano Zacchiroli > >> 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. > > I like the term limit concept. I'm wondering if we should have a wider > proposal in which we just make the CTTE an elected body. I'm not sure > it's a good idea, but I'm also not sure if it's been discussed at all > (only having followed some of the -vote discussions around this from the > web archives). Wouldn't it have been great if the various factions around the systemd issue had got the idea early on to try to stuff the committee with their respective friends before the decision. Personally I think there's more than enough voting going on as it is, and adding reasons to have more regular votes will just promote the idea (that is already rather hard to dissuade people of) that all one needs to do is vote for a thing, and somehow it will magically do itself. It does not strike me as obvious that popularity correlates to competence. Also, it would not be helpful if members of the committee were tempted to take the popular side of an argument, against their better judgement, because they were coming to the end of their term, and they would like to be reelected. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp61ZJt3rftT.pgp Description: PGP signature
Suggestion to simplify clause 2. (was: Re: GR proposal, Call for Seconds - term limit for the tech-ctte)
Scott Kitterman writes: > On Monday, December 01, 2014 04:59:53 PM Colin Tuckley wrote: >> On 01/12/14 16:50, Scott Kitterman wrote: >> > As an amendment, I propose the transitional measure be removed. >> >> Why not support the amendment from Lucas instead which has more or less >> the same effect? > > It has the ~same effect right now, but behaves differently in the future. > When > we vote, I think it would be a better choice if the transitional language > weren't there. I'd like to see all the options be as good as possible before > the vote. In the spirit of making things as good as possible before the vote, I'll mention an idea that was kicked around earlier, and seemed to meet with a fair amount of approval, just to see if people at large prefer it: We could simply remove the sub-clauses about tie-breaking in 2. There's no need for the situation ever to arise as long as we establish a custom (which need not be defined in the constitution) that the DPL always makes it clear that appointments to the TC happen in series. Then there would never be any simultaneous appointments, so we'd never need a tie-breaker. Even if a DPL forgets that, there will be an official announcement, and we could just decide (or the DPL could later declare) that the order the names appeared in the announcement was the order of appointment. It's not as though it's vitally important, and if people like the "age in the project" tie-breaker the DPL just needs to appoint people in that order and that gives us the same effect. We could perhaps replace part 2 of the proposals with something like: 2. Seniority in this context is a measure of how long a member has served in their current term on the committee: whoever was appointed first is considered to be the more senior. I'm not proposing this as an amendment yet, but if it meets with general approval, I will, and it it seems to upset anyone I'll just drop it. I'd personally prefer the simplicity, but I'm unwilling to make a fuss about it. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpEUdS0Tege3.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Stefano Zacchiroli writes: > On Sun, Nov 23, 2014 at 09:00:11PM +0000, Philip Hands wrote: >> Stefano Zacchiroli writes: >> > If people really want to add a tie breaking rule, >> >> I was mostly trying to get rid of the need for one. >> >> How about just saying that appointments must be done one at a time? > > You mean informally as a custom? Yeah, that sounds good enough to me, > it's easy for the DPL to do so --- or to mention in the appointment > email that the order is significant, or answer publicly to nitpickers > who will call them out for having forgot to do so :-) Sounds fine to me. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpdRtSQoeIKZ.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Stefano Zacchiroli writes: > If people really want to add a tie breaking rule, I was mostly trying to get rid of the need for one. How about just saying that appointments must be done one at a time? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpaa49E1gulR.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Philip Hands writes: > Wouter Verhelst writes: > >> On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: >> [...] >>> 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. >> >> I think it makes more sense to have someone who was previously a member >> of the TC have more seniority, before "age" within the project: > > I think since this is a tie-breaker situation which will presumably > rarely happen, it doesn't really matter much. How about: For the purpose of determining seniority, simultaneous appointments are deemed to have taken place in the order of names in the mail that announced their appointment. The TC can then decide how they're going to do the ordering at appointment time, and that's then clear to all -- no need to come up with lots of words that might still not give a distinct result. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpHVbmULUPTx.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Wouter Verhelst writes: > On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: > [...] >> 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. > > I think it makes more sense to have someone who was previously a member > of the TC have more seniority, before "age" within the project: I think since this is a tie-breaker situation which will presumably rarely happen, it doesn't really matter much. I was tempted to suggest that we deal with it by doing something like combine the appointment date and debian username, checksum that and sort by the result, but actually why don't we just avoid the problem completely by saying that we don't do simultaneous appointments? If we have multiple appointments on the same day, we can select at that moment who is going to be considered the earlier appointment, and appoint them a minute earlier, or some such. That decision can be made on any basis that the people in the TC feel reasonable at the time. The timestamps of the emails where the candidates declare that they're willing to be appointed would be a reasonable default. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpOHrCyUU85E.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Anthony Towns writes: > On Thu, Nov 20, 2014 at 07:51:16PM +0000, Philip Hands wrote: >> Lucas Nussbaum writes: >> > - only resignations from people who would have been expired count in S >> FWIW I think either of those deals with the concerns I raised, as it's >> going to be way too much effort to game that, and I cannot see why >> anyone would want to bother to do so. > > I think: > > On Jan 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 Dec 31st of that year. > > would work as a description of that approach. Seems like a pretty good > compromise between '2' and '2-R'. > > Also, it makes the arbitrarily chosen constant 42, which is always a > good thing. That's clearly The Answer :-) The fact that people will get a year's notice, means that they can make sure that they leave at a time that minimises disruption, which seems like a very worthwhile idea. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpB2vbdYTXaf.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Lucas Nussbaum writes: > On 20/11/14 at 13:04 -0500, Hubert Chathi wrote: >> On Thu, 20 Nov 2014 17:59:31 +0100, Stefano Zacchiroli >> said: >> >> > On Thu, Nov 20, 2014 at 12:33:28PM +, Sam Hartman wrote: >> >> While I do think that 4-5 years is a good term length, I do think a >> >> lot of churn can be bad, and 2-r makes a lot of sense to me for the >> >> reason you give above. >> >> > Not sure if you've read it Sam, but just in case: I find Phil's >> > example in <871toz16nz@hands.com> to be most convincing against >> > the 2-R model in general. ... >> >> I think someone had already mentioned this option, but one way to avoid >> the effects of that issue, for those who want to avoid always expiring 2 >> members, is to expire 2-S members, where S is the number of members who >> have resigned since the last review period, and who would have been >> expired at the current review period if they had not resigned. So the >> resignation of a junior member would not affect the expiry process, but >> the resignation of a senior member would mean that we would have one >> less expiry. > > It was proposed by Anthony in <20141119220621.ga31...@master.debian.org>: > >> However, another option would be "2-R'" where only retirements of people >> who would otherwise be candidates for expiry count. So Russ quitting >> after serving 5.8 years would count, but Colin resigning after serving >> "just" 3.2 years wouldn't. That doesn't seem like it's especially easy >> to specify either though. > > Note that there are two subtle variants: > - only resignations from people > 4.5y count in R' (Anthony's) > - only resignations from people who would have been expired count in S > (yours) FWIW I think either of those deals with the concerns I raised, as it's going to be way too much effort to game that, and I cannot see why anyone would want to bother to do so. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpj0TgR54iJJ.pgp Description: PGP signature
Re: [DRAFT] Maximum term for tech ctte members
Stefano Zacchiroli writes: ... >> 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 agree that this would most certainly happen. But my judgement on it is > that it would be a *bad* thing, not a good one. In fact, I would see > that as a tactical behavior on the part of the CTTE to work around an > agreed upon judgement on the fact that turn-over is good, and that > remaining in charge too long is bad. Quite. This reminds me of a rule that for the EU's framework programs, where they must make sure that (IIRC) 30% new blood is brought into the review process every year to try to avoid cronyism. That sounds like a decent rule, in that it seems to imply that one replaces the reviewers every 4 years or so, but that's not what actually happens for various reasons. The actual outcome is that the same 60+% tend to do reviews year after year, with the 30% each year mostly replacing the 30% from the year before. Of course, with the TC it doesn't matter as much, because the TC is not allocating millions of Euros of funding. Even so, if someone wanted to stay in post on the TC for whatever reason, this '2-R' rule would just encourage them to be difficult to work with in the hope that a couple of less senior members became fed up enough to leave early. It doesn't seem wise to have such an incentive to behave badly. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpZZ4VfOnu2O.pgp Description: PGP signature
Re: "done with consensus decisionmaking", "war", "rearguard battles" [was: Re: REISSUED CfV: General Resolution: Init system coupling]
Bas Wijnen writes: ... >> (or fighting "bitter rearguard battles"). > > This may be a language issue, but I have been thinking about what a > "rearguard battle" is, and I can't think of any way Ian can possibly be > talking about himself. The rear guard is on the back. This must mean > that somebody has won a fight, but continues fighting anyway. Since Ian > doesn't seem to have won the fight at least so far, don't you think he > would be talking about the opposing army? And from what I've seen, that > might be correct, too. At least Lennart seems like he can't get enough > of fights. (But then complains that he gets attacked so much...) A rearguard action is one in which the rearguard of a retreating army lays traps and ambushes for the advancing force, to impede their progress. http://www.oxforddictionaries.com/definition/english/rearguard-action You seem to have misunderstood that, and have based much of the rest of your post on that misunderstanding. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp8sugpX7XIG.pgp Description: PGP signature
Re: REISSUED CfV: General Resolution: Init system coupling
Hi Neil, Philip Hands writes: >> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- >> 57dd4d7c-3e92-428f-8ab7-10de5172589e ... Oh, oops! maybe you should set the Reply-To for bears of little brain like me. I'm sure you probably do so normally, and that having to reissue this was just enough to make it slip your mind. Thanks for dealing with it. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgps1pWcLipSw.pgp Description: PGP signature
Re: REISSUED CfV: General Resolution: Init system coupling
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 57dd4d7c-3e92-428f-8ab7-10de5172589e > [ 5 ] Choice 1: Packages may not (in general) require a specific init system > [ 3 ] Choice 2: Support for other init systems is recommended, but not > mandatory > [ 2 ] Choice 3: Packages may require specific init systems if maintainers > decide > [ 1 ] Choice 4: General Resolution is not required > [ 4 ] Choice 5: Further Discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- pgpEJQ4U3G8HG.pgp Description: PGP signature
Re: Last minute discussion
Paul Wise writes: > On Tue, Nov 4, 2014 at 5:25 AM, Saul Goode wrote: > >> I imagine I've missed other contributors, but the point is that for each of >> the 1084 Debian Developers who are being asked to vote in this GR, there are >> dozens, if not hundreds, of contributors who are deserving not only of >> recognition for their contributions, but representation within the Debian >> governance model; and the Debian Developers collectively serve the role of >> that representation. > > We attempt to recognise the contributions of all direct contributors here: > > https://contributors.debian.org/ > > Many of the contributors you mention are actually eligible to join > Debian and become voting members. Also, "do-ocracy" has nothing to do with getting a vote. In fact it is the antithesis of the voting that goes on. "do-ocracy" is about the idea that if you are the person that does the work, you should be given the freedom to do your job in the way you deem most appropriate, on the basis that people gravitate towards their areas of competence, so in this manner we have people of above average competence doing each job. Voting for someone else to do a job that has as yet failed to attract a volunteer rarely makes anyone happy. If the designated volunteer objects, they're just as likely to simply give up, leaving both the new job and their existing work undone. Hence "do-ocracy": Those doing the work end up with most of the detailed decision making power, and if one doesn't like that the way to change it is to find something useful to do, and do it in a manner that demonstrates the way you think things should be done. Proposing a vote is rarely as persuasive. To that extent Debian is _not_ a democracy. Also, note that one can very often do something useful for Debian without going anywhere near the new maintainer queue, so this is much more inclusive than the list of people who get a vote. Thinking about any of this as a democratic failure, or the result of people being disenfranchised is missing the point wildly. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpHUvNwINzoi.pgp Description: PGP signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
[cross-post to -project dropped]
Hi Ian,
Ian Jackson writes:
> Thanks to Steve for his perceptive and well-reasoned article.
>
> Steve Langasek writes ("Legitimate exercise of our constitutional
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
>> 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.
I thought you said that your GR (i.e. option 1) was effectively a NOP
for Jessie (that's certainly how I read the text of your clause 4) in
which case the people that would prefer to avoid systemd have several
years (until the end of jessie-LTS) to come up with alternatives that
they prefer, so there is absolutely no reason to panic about it now.
If we were to adopt Option 1, then we'll be dragging sysvinit behind us
like a ball and chain long past the last person who clung to it notices
that there are better alternatives available -- which presumably will
come to pass eventually (or more likely happened some time ago, but the
inertia in Debian is blinding us to that fact).
The network effect that Steve tried to conjure for systemd will actually
come into effect, but for sysvinit, because the few people that might
have a good reason to depend on systemd-as-init will be forced to cobble
something together for sysvinit to act as a shield against the newly
created RC missiles. I cannot see them being very motivated to maintain
that sysvinit-shield though, so we should expect those to rot over time.
Also, they'll be doing all that under duress, so will likely be irritable
when anyone asks them to support a third init, whereas without this
meddling in the natural order they'd probably be quite interested to
adopt an emerging competitor to systemd that supports their needs.
The result being that we'll be tied to sysvinit way beyond it's usefulness.
Of course, for the likes of Gnome, voting for Option 1 really will have
an immediate effect, which will be to completely demotivate our Gnome
maintainers, since this would be a vote against them.
I think Debian without Gnome would be a diminished thing, and that seems
like a reasonably likely outcome of Option 1 passing.
That's why I'll be voting for Charles' amendment (Option 4).
The mechanisms we already have will continue to serve us to resolve any
real instances of the breakage you're worried about. If there are
enough people that care, Gnome will be made to run without systemd. If
not, not, and in that case very few people will care. If nobody cares
to do the work, there is no need for it to be done.
Option 1 seems like a Luddite reaction to me, which is of course very
tempting to the grey-bearded unix user in me, but I'd suggest that that
is just a symptom of old age, so the temptation should be resisted IMO.
If we cannot embrace innovation we should get out of the way of the
youngsters, whose brains are yet to fossilise, and see what wonders they
can surprise us with.
It may not be as awful as you imagine.
Cheers, Phil.
P.S. for those of you busily making assumptions about what my motives
are: I'm an xmonad user, have only recently installed systemd on my
laptop (with some minor issues that will get reported as bugs once I
track them down), and rarely manage to install Gnome to my satisfaction
(because I'm generally trying with old hardware), so on the whole this
doesn't affect me greatly either way (apart from the vast waste of time
involved in following the interminable arguments).
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
pgppxSvtWyV0j.pgp
Description: PGP signature
Re: [Sorry Neil] Wording modification of the The ???no GR, please??? amendement.
Charles Plessy wrote: > I propose the following replacement as per article A.1.5 of our > Contitution. > > > > 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 > procedures for decision making and conflict resolution are working > adequately and thus a General Resolution is not required. > > I don't suppose it's necessary, but since that perfectly fits my thoughts on this subject: Seconded. Thank you for your efforts on this, and especially for this improved wording. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpOJJ_dQ_b1F.pgp Description: PGP signature
Re: GR: welcome non-packaging contributors as Debian project members
On Tue, 14 Sep 2010 17:53:46 +0900, Stefano Zacchiroli wrote: ... > * Active contributors of non-packaging work, which share Debian values > and are ready to uphold Debian Foundation Documents, deserve the > opportunity for becoming Debian project members. to become or if you prefer: of becoming > - Constitution §4.2.1 does not require seconds in this case, but I would > appreciate them nonetheless. Seconded. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpNvD6uNKL7w.pgp Description: PGP signature
Re: New maintainer proposal, re-announce
Joey Hess <[EMAIL PROTECTED]> writes: > Dale Scheetz wrote: > > The project secretary has already said that he has seen no proposal, > > properly submitted, that anyone can act upon, according to our > > constitution. > > > > Until a proposal has been properly made to debian-vote, there can be no > > proper action for a developer to take. > > Who ever said we were going to vote on this? > > Wichet is delegating his athority to the new-maintainer team, I don't see > why a project-wide vote is called for to reorganize that group. > > After all, we want this resolved *soon*, not months from now after a > worthless vote. Damn straight. You've got my vote ;-) Cheers, Phil.
Re: Proposed change to Debian constitution
Edward Brocklesby <[EMAIL PROTECTED]> writes: > Please offer sensible, well considered, useful comments. Replies from > rude, abrasive people (you know who you are) will be ignored. How very diplomatic of you ;-) > 3. The Project Leader's Delegate(s) may decide not to admit any new >Developers (close the New Maintainer process), until the next >release of debian, provided Developers are in favour of this >by a 3:1 majority. New Maintainer may be reopened either when the >Developers agree to do so by a 3:1 majority, or the next version >of Debian has been released. New maintainer may be closed for longer >than this time only if a General Resolution is passed. This (closing n-m) is not something anyone seems to want, so codifying a way to make it happen seems a little pointless to me. > 8.4 Composition > >1. Any critical package or system team (e.g, the New Maintainer team, > the FTP Admin team, any Essential package's maintainers) must have > a reasonable number of active members at all times. and what happens if this condition is not met ? >2. If, for any reason, it is not possible for a reasonable number of > members of any team to be active, the Project Leader, one of > the Leader's Delegates, or a member of the team must appoint > enough members to ensure there are at least two active. how about if there are no volunteers ? and if there are volunteers with the right skills, why would this not happen naturally without the need for the above clause. >3. All mailing lists for a particular team must be open, unless > the Developers agree that it may be closed, by a vote with a > majority of at least 3:1, or the Project Leader gives permission > for the list to be closed, and no Developers object to this. If people on a team decide that the list is better closed for some reason, and the project attempts to bar this, then they'll just take it to private email --- this is unenforcible. >4. An "Active" member shall mean a member who, in any given day, would > be able to take suitable action on any situation relating to that > particular team. Hm, I wonder how many ``active'' developers we have by that definition. >5. "Reasonable number" shall mean either the amount of people required > to handle all issues relating to that team, or two, whichever is > greater. I think we generally assume that our fellow developers will act in a sensible manner, so writing constitutional clauses to that effect seems somewhat redundant. >6. An "open" mailing list shall mean a mailing list to which anyone > can subscribe to and read. The list may restrict who is allowed > to post to it (a "moderated" list). The list must be archived > in a publically accessible place, for a period of at least two > years. Again, why on earth do we need this in the constitution ? It strikes me that this proposal is just a way of airing your grievance about n-m being closed. As far as I can tell, the matter is in hand and will be resolved in the near future, so perhaps you should do us all a favour and spend your time on something constructive instead. I generally object to anything that introduces or supports the idea that voting on things is a good way to run Debian. Things get done around here because people feel like doing them, not because we all voted and told some poor sod that they've been elected to do the job. Was that abrasive enough for you to ignore me? Cheers, Phil.
Re: Logo swap vote is bogus
> There was discussion of swapping the official and unofficial images > for a number of submissions to both the Gimp contest and the logo > vote. Not just the swirl. Many people said, "what if I like , but > want them swapped?" It's an idea that's been in the air the whole > time. I have no idea how you managed to avoid hearing about it until > Branden's proposal. Ah OK. Sounds like that was during the period that I was REALLY busy with other things, so you are right, I wasn't paying attention to logo matters back when the gimp competition was on. Sorry about that. I'm not normally as stroppy as this thread might have read. I think I've probably not been getting enough sleep of late. I guess democracy in Debian just winds me up. I tend to think of it as a way of finding out what the people who like voting, felt like voting for at a random moment --- so not terribly useful in the general case. Unfortunately, there are some issues where we seem to have to resort to this (like now) but the fewer votes we have the happier I'll be. Cheers, Phil. -- Time for bed said Zebedee. Bdoing!
Re: Logo swap vote is bogus
Chris Waters <[EMAIL PROTECTED]> writes: > Philip Hands <[EMAIL PROTECTED]> writes: > > Where was the swap discussed? > On -devel. (I wasn't even subscribed to -vote until last night.) Oh, I saw Brenden's comment that he might propose a swap (but didn't want to talk about it), I just failed to realise that the constitution said that we should assume that the terms of the vote were changed by him saying that ;-) > > Would that also be the hiding place that was found for the definition of > > ``Modified Swirl'' ? > > I don't know -- I didn't vote for any logos. I'm not even sure what > all the candidates were. I know nothing about "Modified Swirl" except > that I noticed the name on the ballot, before I deleted the ballot. The reason you know nothing about Modified Swirl is that it was only mentioned on debian-vote, to which few people were subscribed at the time. > > Is anyone else feeling just a little disenfranchised here? > > What on earth are you talking about? It's not like it was hard to > find this info. I wasn't subscribed to -vote, I only skim -devel and > -private -- the only lists that I read carefully all the time are > -devel-announce and -news. Yet somehow, I, a disinterested skimmer, > managed to find all this information that you, who care so > passionately and deeply about all this, managed to overlook? Well no actually. You didn't find out about Modified Swirl, as I would guess is true of the majority of the developers. Despite that, the fact that Modified Swirl got a limited number of votes is being touted as a significant data point, in order to give credence to the idea that there is any mandate for swapping the logos. [ Just in case anyone else is still in the dark about Modified Swirl, it was to have the plain swirl for both logos, with the official one having the word ``official'' tacked onto it. ] > Is it a > matter of being "disenfranchised," or just NOT PAYING ATTENTION? I was paying attention as it happens, I even wasted about an hour before voting, looking for a definition of Modified Swirl. > I just think it would be nice to have an image to stick on my pathetic > little web page, and then I'll get back to coding. Generally, I agree with you, and I could have just voted for the swap, and got what I want as a result. So why am I still ranting ? Because next time the voting system is abused in this way, it might be on an important issue. Also, my ranting is not delaying the completion of the vote (it continues regardless), and could actually be speeding a conclusion, since I've managed to inform a few people that a vote was on, which could help the vote achieve quorum. Also, discussing this now means we can shake out the arguments a little. If the logo4 vote fails to reach quorum, this should actually save time on logo5 (which I think we can expect to pop out of the woodwork immediately). I'm sorry if my ranting is pissing you off, but it might just raise the level of credibility of either this vote, or the next one (if we have to endure another), which should result in a quicker conclusion than would otherwise have been achieved. You clearly don't care about our voting system, whereas I care about it because I can see it being used to justify decisions supposedly taken in the names of the developers, when less than a quarter of the electorate currently vote (well less than a sixth in this vote) Do we even know what proportion of the developers are subscribed to this list? (a rapidly diminishing number perhaps, as they get fed up with me. Sorry) Cheers, Phil.
Re: Logo swap vote is bogus
> Philip Hands <[EMAIL PROTECTED]> writes: > > > I'll leave you with a fairly simple question: > > > I like the swirl logo, and want it to be widely used. > > I don't like the bottle logo, and don't want it as our official logo. > > > > How should I vote ? > > AH! Now I understand where you're coming from. And I sympathize, I > do, but the time for that option was during the main logo vote. The > Modified Swirl did NOT win, and I'm afraid you may just have to learn > to live with that. Well, quite. If people had left it alone, I probably would have too, at least until last weekend when I found myself explaining to several people that I couldn't sell them a swirl T-Shirt, because they were licensed in a way that probably meant that only developers, on official business can wear them :-( (we were giving away CDs at the time, which seems sort of official) > (I don't know if the details should be discussed publicly, but I can > tell you that I have strong reason to believe that the bottle may not > be used much if it *does* become the official logo. So you may *well* > get your wish *if* the swap passes.) Here's my problem. Subverting the process by proposing something that is tangential to ones aims seems plain wrong to me. We're not sneaky politicians here, so why are we acting like them ? You went on on to say two other things: 1) the logo swap was aired during the vote. 2) the Modified swirl lost, so should be discounted Where was the swap discussed? Let me guess: On debian-vote prior to it being published on the archive pages? Would that also be the hiding place that was found for the definition of ``Modified Swirl'' ? Is anyone else feeling just a little disenfranchised here? To quote one of the messages that did actually make it onto the web pages (after I'd voted BTW), written by Darren O. Benham: <http://www.uk.debian.org/Lists-Archives/debian-vote-9905/msg00010.html> On Fri, May 28, 1999 at 07:06:15PM +0100, Julian Gilbey wrote: > [an explanation of what Modified Switl was, deleted for brevity] ... > I have no idea how many developers understood this when voting -- I > certainly didn't without checking the -vote archives. Actually, I was told before the vote took place that the pages were being archived so I was relying on that for clarification. I wasn't aware until recently that the archives WERENOT up. That has been fixed. I saw some may archives today. That pretty neatly describes the situation I was in at the time. I've had a couple of mails today from people who were unaware that a vote was on, until I started making waves on -devel. This really isn't good. Swirl had pretty much won when I voted IIRC (which looking at my mail was 28 May 1999) whereas the description of what Modified Swirl was didn't appear on the vote page until some time later. How can you draw any conclusion from the fact that Swirl got more votes in these circumstances? As it happens, I voted for Swirl over Modified Swirl at the time, and didn't bother to change it because I couldn't imagine that anyone was going to try to use the relative ordering as significant, given the cock-up of the vote page for the bulk of the voting period. Interestingly, the fact that we were voting on a swapable bottle when we voted swirl, is still not mentioned on that page. Perhaps someone should add this now in order to legitimise the latest vote. To reinforce that point, a quote from joey on the same day: Looking at the current state, the logos named SWIRL will win, but these are two logos x 2, so we have four. Err, which swirl is will it be? Or do we need to vote again if bottle only or not, if swirl plus bottle, or swirl only. Or am I going crazy? Regards, Joey BTW Please don't accuse me of trying to restart the logo vote. I'm pretty certain there is a consensus for the swirl, and I don't want that to change. What I don't think we have a consensus on is how precisely that logo is to be deployed, or whether there should be two licenses, or whether one of them should include a bottle. Looking at the voting record, only 21 people listed both Swirl and Dual as 1. These are the only people you can claim definitely wanted the bottle for some purpose, and some of them may have actually wanted it the way it is, not swapped. In fact there is a much stronger case for suggesting that we agreed that there should be two licenses, since at least it was completely clear what that vote was about, and yet this latest vote seems likely to put one of those licenses out to pasture, along with the bottle that will never be used. Is this the hidden agenda that I was smelling ? Cheers, Phil.
Re: Logo swap vote is bogus
Chris Waters <[EMAIL PROTECTED]>: > On -vote yes, because most of the seconders had already posted > comments on -devel. All the discussion seems to have been on -devel, > in fact. (You'll have to check the archives on master if you don't > believe me, because the stuff on the web page is woefully behind.) OK, it looks like a mail SNAFU and the web pages being behind, have conspired to ensure that I didn't see that. I'll leave you with a fairly simple question: I like the swirl logo, and want it to be widely used. I don't like the bottle logo, and don't want it as our official logo. How should I vote ? Can we expect the logo4 vote to be about getting rid of the bottle ? Cheers, Phil. P.S. Just in case anyone's interested in where I've been coming from, a few of clarifications: on my initial suggestion that we open up the vote for swirl alternatives: I was actually after an opportunity to vote for ``Modified Swirl'', but didn't want to limit it to that if someone managed to come up with an even better idea --- if there's a better idea, we should use it. Raul has since done a version with the word ``official'' added, and I think it looks pretty good. on my problems with the legitimacy of the current vote: It relies on the authority of the previous votes for it's selection of the two logos, but it rejects the authority of the previous logo vote, by effectively implementing the important bit of Modified Swirl (which lost last time). Either the previous votes were valid, in which case their decision should stand, or they were flawed, in which case we should have a chance to determine the extent of the flaw, and fix it. on the assumption that I want to discuss it ad infinitum: I'd rather that we made sure that there was no room for anyone to claim that there is something wrong with this vote, so that the discussion gets settled once and for all. We're already voting once more than we should have been. on the reasons for starting this: I guessed that people wanted to use the swirl for general use, and were likely to vote for any proposal that allowed that. If that's the case, we should have a vote that offers all the alternative ways of achieving that aim: 1) Swap the logos 2) Drop the duel license idea 3) Use the ``Modified Swirl'' suggestion 4) leave it as it is 5) Further discussion As It happens, this vote is struggling to reach a quorum, so maybe I was wrong about my guess. Either way, this vote does little to tell us if people actually like the bottle logo, and I don't think the previous two votes told us this either. I should have said all this prior to the start of voting, but I was busy -- sorry.
Re: Moving contrib and non-free of master.debian.org
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes: > I suggest also to purge master of non-free software, if we are > really serious about free software purity: SSH Difficult to replace at present. Once lsh is a little more mature, then it will be a different story, but not yet. Cheers, Phil.
Re: Logo swap vote is bogus
> Philip Hands <[EMAIL PROTECTED]> writes: > > > My complaint comes from the fact that there was absolutely no > > discussion about this new vote prior to it being proposed. > > If that were true, I might sympathize. Since it's not true, I have to > wonder just what you're trying to pull here. (To be kind, I'll assume > that this is just hyperbole.) OK, show me any discussion in the archives (URL's please) I've looked, and didn't find any. The only replies to the proposal mail were ``seconded'' type responses, with no attempt to show a justification for the view. It seems that at least one person that replied to my start of this thread, freely admits that they are in favour of this vote because they see it as a way of overturning the ``Dual License'' vote, so perhaps if the seconders had said something like: seconded, because I think we should only have one logo, and swapping them will allow the bottle logo to sink without trace. Then I might agree that there had been some discussion. We might also have decided the issue by simply discussing it. If a vote had actually been needed, it might actually have been worded in order to decide the real issue, and not some tangential issue on which people are tempted to vote tactically. The only discussion that I'm aware of was a very brief exchange between me and Branden, where I suggested that the question was too narrow. Perhaps I should have repeated my mail when Branden repeated his, since the threads got lost, but at the time I wasn't subscribed to debian-vote IIRC, and I've been a bit busy since. > Pretty hard to get any seconds without a discussion :-) saying ``seconded'' doesn't count as discussing an issue IMO. Cheers, Phil. P.S. as far as what I'm trying to pull here is concerned, I'm just trying to make sure that some sort of discussion does actually happen, in a wide enough arena, so that once the vote is over we don't get too many ``When was that announced ?'' type complaints, which would undermine the validity of the vote.
Re: Logo swap vote is bogus
Chris Waters <[EMAIL PROTECTED]> writes: > Ah, so your suggestion is that we continue discussing and debating the > idea for a few more YEARS!?! The entire logo issue has been on hold > since, what, '97? Late '96? > > If we had a concensus, we wouldn't need a vote, yes? Or am I missing > something here? Yes, you are. The situation has changed. We now have a logo, we voted on that, and I'm certainly not trying to change that fact. If you want to be pedantic this vote is actually an attempt to reverse the previous logo vote, since we voted against the swirl as the free-use logo when ``Modified Swirl'' failed to win. My complaint comes from the fact that there was absolutely no discussion about this new vote prior to it being proposed. If it had been discussed, I think we could have reached a consensus without a vote. At least if it had finally required a vote, then the question being voted on might actually have addressed the problem, rather than approaching it from an obtuse angle. Just because something isn't a technical issue, doesn't mean that it is inconceivable that someone could come up with a convincing enough argument to persuade people about it. Cheers, Phil. P.S. I must say, it was deeply embarrassing having to explain at the UKUUG Linux'99 conference, that I could not actually sell Debian T-Shirts to the people that wanted to buy them, because the license probably meant that only developers on official business were allowed to wear them. We need to sort this out, just not this way.
Logo swap vote is bogus
I think we have a problem with the way the current vote came about. [ I'm cross-posting this, because it seems that people managed to miss what is going on what with messages being spread across debian-vote, and debian-publicity. Please follow up to -publicity] >From talking to people over the weekend at the UKUUG Linux conference, I get the impression that there is a consensus that the plain swirl is nicer that the with-bottle-swirl, and that if we must have two logos, then it would be better to have the plain-swirl in the widest possible use (because it's nicer). If that's true, then we should be discussing it, rather than going to a vote with practically no discussion whatsoever. Decision making in Debian has always previously been based on consensus, even if the consensus was simply ``We should vote on it''. In this case, I seen no evidence that there was a consensus for a vote, so I'm not convinced that there will be any validity to the result. >From reading the archives again, it seems that events happened like this: Branden mentioned the vote idea (not sure which list). I objected because (IIRC) it was too specific, and should allow for other possibilities (such as alternatives that Raul could come up with). Branden resubmitted his unchanged proposal to debian-vote and debian-publicity A bunch of people seconded it. Later, on -publicity, Adam Di Carlo said that we shouldn't be voting on this in the first place. Raul followed up by saying that he agreed that discussions should continue on -publicily, for a final decision, and that he'd come up with some more versions of the logo. Witchert said that in that case, he was against the logo swap. Then nothing more was said, as far as I can see. In the old days, that would have been the end of it, until we heard back form Raul, but now we get automatically bulldozered into a vote, despite the fact that there seems to be no consensus that we should even have a vote. The trouble is, that I think the majority of the people voting for ``Swap'' are actually voting for ``Use the swirl, and forget the bottle'', which is something different. I can see this sort of thing happening again --- we need to stop people proposing votes before there has been a chance to build a consensus (without a vote). Otherwise the minority of people who can be bothered to vote, will be able to push through all sorts of drivel. Do the right thing, and vote ``Further Discussion'' now! Cheers, Phil.
