Re: Summary of the current state of the tag2upload discussion

[Bart Martens]

On Tue, Jun 25, 2024 at 08:55:56AM +0200, Matthias Urlichs wrote:
> On 24.06.24 23:20, tho...@goirand.fr wrote:
> > I see it as signing the very thing that is pushed to the Debian archive.
> > You aren't uploading a bunch of git SHA to the archive but a source
> > package. It feels very normal that therefor, that is the thing that we
> > would like you to sign. Too bad this is less convenient for your
> > workflow, but that is the correct semantic.
> 
> Well, yes. Right now this is the case, and t2u adds an additional step to
> that equation which historically we didn't have.
> 
> However …
> 
> (a) the thing I'm signing isn't the thing I worked on. I didn't look at it
> and, given a git-centric work flow, nobody else will either. It feels very
> unnormal to me that I'm signing some artifact that I didn't even look at.
> Heck it felt unnormal to me 20 years ago when I joined and built my first
> packages.

The unit of signing should remain close of the unit of distribution. It makes
the signer aware of what exactly they are responsible for. I mean, that is in
the current workflow, with the signer being the DD doing the last human
verification.

> 
> (b) we might decide, sometime in the future, that sources.dgit.d.o is to be
> treated as part of "the Debian archive" and that our builders shall pull
> from there instead of unpacking a tarball if the maintainer used t2u, thus
> effectively removing your objection.

In my view git will be replaced by the next vcs while Debian will still be
distributing source packages to be finally signed by some human. Sure, git is
useful today and it's worth giving it a prominent place in the workflows of
today. I just think that the source code package that gets distributed should
remain independent of any product like a vcs that happens to be hot today.

> 
> -- 
> -- mit freundlichen Grüßen
> -- 
> -- Matthias Urlichs
> 




-- 

Re: [RFC] General Resolution to deploy tag2upload

[Bart Martens]

On Sun, Jun 16, 2024 at 03:31:25PM +0200, Matthias Urlichs wrote:
> On 13.06.24 10:26, Sean Whitton wrote:
> > Yes.  A proposal that has not yet engaged with the complexities of
> > 3.0 (quilt) is not one in which we can yet have any confidence.
> 
> The proposal simply intends to do whatever the uploader would do to build
> the source package from a tagged git worktree, except in a controlled and
> sandboxed environment.
> 
> I fail to understand why we should have any less confidence in that than in
> whatever the uploader does manually to achieve the same result (we hope!!).

One could argue that neiter matter. It is the outcome that matters: the source
package itself. That's what gets distributed.

> 
> -- 
> -- regards
> -- 
> -- Matthias Urlichs
> 




-- 

Re: [RFC] General Resolution to deploy tag2upload

[Bart Martens]

Hi Sean,

On Wed, Jun 12, 2024 at 06:25:02AM +0800, Sean Whitton wrote:
> BEGIN FORMAL RESOLUTION TEXT
> 
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.

Question. Does the tag signer need to trust the remote vcs and its admins at
the moment of tag signing? With a .changes file the signer has full local
control: local source code inspection, local checksums generation, and local
signing. I wonder how tag2upload would offer this level of control without
lowering the value of the signatures.

Cheers,

Bart

Re: CRA and PLD vote status

[Bart Martens]

On Fri, Dec 08, 2023 at 10:06:45PM +0100, Lucas Nussbaum wrote:
> Hi,
> 
> On 08/12/23 at 21:58 +0100, Kurt Roeckx wrote:
> > [ ] Choice 1: CRA and PLD proposals include regulations detrimental to FOSS
> > [ ] Choice 2: The EU should clarify that non-commercial FOSS is exempted
> 
> "non-commercial FOSS" sounds like CC BY-NC-SA (which is not FOSS). What
> this option is trying to say is that FOSS development outside commercial
> context should be exempted (or non-commercial FOSS organizations).
> 
> However I cannot find a wording that fits on a single line...

Maybe this?
[ ] Choice 2: The EU should exempt non-commercial use of FOSS"

> 
> Lucas
> 

-- 

Re: CRA and PLD vote status

[Bart Martens]

May I suggest for proposal C:
"The EU should not overrule DFSG 6 and FOSS licenses"


On Thu, Dec 07, 2023 at 07:19:44AM +0300, Kurt Roeckx wrote:
> Can people make suggestions for the ballot options text?
> 
> Kurt
> 
> On November 30, 2023 12:39:38 AM GMT+03:00, Kurt Roeckx  
> wrote:
> >Hi,
> >
> >I've updated the page at https://www.debian.org/vote/2023/vote_002 which
> >the current status.
> >
> >We're at the maximum discussion period of 3 weeks, so the vote will
> >probably start the 10th of December.
> >
> >
> >Kurt
> >

-- 

Re: Call for seconds: Delegate to the DPL

[Bart Martens]

On Sat, Dec 02, 2023 at 01:07:21AM +0100, Bill Allombert wrote:
> On Tue, Nov 28, 2023 at 04:36:29PM -0600, Gunnar Wolf wrote:
> > Bill Allombert dijo [Tue, Nov 28, 2023 at 10:07:29PM +0100]:
> > > On Tue, Nov 28, 2023 at 09:25:17AM -0600, Gunnar Wolf wrote:
> > > > This is also something we discussed before sending this call for
> > > > votes. But how can we gauge whether the project is OK with issuing
> > > > political statements or not? The only tool we were able to find is a
> > > > GR.
> > > 
> > > The less we know about the political opinion of each others, the better 
> > > for
> > > the project. After all we only agreed to uphold the SC and nothing else.

One of the proposal texts puts the focus on that SC.

> > > 
> > > We are a technical entity. We do not need to know other developers 
> > > opinions on
> > > issues unrelated to FLOSS to work together, and let us face it, it is 
> > > easier to
> > > work together if we ignore whether we have major political disagreement.
> > 
> > Yet, my belief is that all human interactions are political in
> > nature. In some aspects of politics, you and I will not be the least
> > aligned. But I believe our project is _first and foremost_ a political
> > statement (that produces a first-grade technological artifact).
> 
> One major risk for Debian continued existence is that we start to become
> suspicious of each other political views outside FLOSS, that we start to see
> "collaborating with someone as part of our Debian activity" as "associating" 
> with them, and that "associating" with them start to become socially
> problematic.  There is a precedent for that.
> 
> That is why I am quite against the whole 'community' view of Debian.
> 
> In practice, it is very hard to participate in such GR without revealing 
> political views, as you can see by reading the discussion.
> 
> > > And it is quite difficult discussing a ballot option without revealing 
> > > such
> > > opinions. We have enough topics for flamewar already. This will only leads
> > > to more fracturation of the project.
> > > 
> > > But this GR is not about issuing political statements in general, it is 
> > > about
> > > issuing a particular statement, which leads directly to the second issue, 
> > > are
> > > GR (with the time limit, the amendment process, etc) the best medium to 
> > > draft
> > > political statement that correctly addresses the issue while furthering 
> > > Debian
> > > goal ?
> > 
> > I do not know. But I think that's something that can, and ought, be
> > put to the table.
> 
> It seems like you are underestimating the risks and overestimating the 
> rewards.
> Such statement is only useful if written by people that understand enough of
> EU law terminology to address the issue. I asked whether the lawyer that 
> drafted
> it was familiar with EU law and it does not seem to be the case. We should not
> make a statement that can be used against us.

I think we're fine if the GR states what Debian already continuously states.

> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here.
> 

-- 

Re: Call for seconds: Delegate to the DPL

[Bart Martens]

On Tue, Nov 28, 2023 at 07:59:01PM -0700, Bdale Garbee wrote:
> Gunnar Wolf  writes:
> 
> > But I believe our project is _first and foremost_ a political
> > statement (that produces a first-grade technological artifact).
> 
> I understand your position, but I see this exactly in the opposite way.

I'm a bit in between. Free Software may have originally started as an anti- big
companies movement, but nowadays it has matured, and those big companies are
now migrating their critical businesses to it.

Cheers,

Bart

Re: call for seconds - separate proposal text for 2023/vote_002

[Bart Martens]

On Fri, Nov 24, 2023 at 07:55:01AM -0600, Gunnar Wolf wrote:
> Hello Bart,

Hi Gunnar!

> 
> Bart Martens dijo [Wed, Nov 22, 2023 at 07:16:48PM +0100]:
> > Hello, I hereby welcome seconds for adding this text to 2023/vote_002
> > as a separate proposal.
> 
> Thanks for your contribution to this discussion!

And thank you for your feedback.

> As I said in another
> thread, I believe that in a voting system such as the one we use in
> Debian, more versions is unambiguously better, and options should only
> be merged together in the case they are semantically equivalent.
> 
> > Debian Public Statement about the EU Cyber Resilience Act (CRA) and the
> > Product Liability Directive (PLD)
> > 
> > The CRA includes requirements for manufacturers of software, followed
> > up by the PLD with compulsory liability for software. The Debian
> > project has concerns on the impact on Free and Open-Source Software
> > (FOSS).
> > 
> > The CRA makes the use of FOSS in commercial context more difficult.
> > This goes against the philosophy of the Debian project. The Debian Free
> > Software Guidelines (DFSG) include "6. No Discrimination Against Fields
> > of Endeavor - The license must not restrict anyone from making use of
> > the program in a specific field of endeavor." A significant part of the
> > success of FOSS is its use in commercial context. It should remain
> > possible for anyone to produce, publish and use FOSS, without making it
> > harder for commercial entities or for any group of FOSS users.
> > 
> > The compulsory liability as meant in the PLD overrules the usual
> > liability disclaimers in FOSS licenses. This makes sharing FOSS with
> > the public more legally risky. The compulsory liability makes sense for
> > closed-source software, where the users fully depend on the
> > manufacturers. With FOSS the users have the option of helping
> > themselves with the source code, and/or hiring any consultant on the
> > market. The usual liability disclaimers in FOSS licenses should remain
> > valid without the risk of being overruled by the PLD.
> > 
> > The Debian project asks the EU to not draw a line between commercial
> > and non-commercial use of FOSS. Such line should instead be between
> > closed-source software and FOSS. FOSS should be entirely exempt from
> > the CRA and the PLD.
> 
> My issue with your text is that I read it –bluntly over-abridged– as
> «The CRA+PLD will make it harder to meaningfully develop Debian,
> because we are compelled by our own foundation documents not to
> distringuish between free and commercial. Many people use Debian in
> commercial settings. If you enact this legislation, some of our users
> be at risk of getting in trouble for using our fine intentions for
> their economic benefit, as they will be covered by your
> regulation. Please formally except us fully from your rules!»
> 
> That is, it basically means: "European Parliament/Council: Our
> foundation documents are at unease with the CRA and PLD".

That is praphrasing my proposal rather roughly, but let's focus on the point
you want to make.

> That is
> true, but a fair answer from them (if we warrant it!) could be "We
> represent more people and wider interests than yours. Your SC is over
> a quarter of a century old. Update your SC to comply with the changing
> times". Which could even make sense! (although it would make Debian
> stop being Debian!)
> 
> This reading is the main reason I'm not endorsing it, and still prefer
> our original proposal instead.

How would such hypothetical answer from the EU matter for preferring one
proposal over the other? I'm trying to understand your motive.

Allow me to point out some weak points in proposal A, motivating me to write my
separate proposal.

- 1.a. The phrase "with no legal restrictions" is incorrect in the sense that
  FOSS uses legal restrictions for keeping it FOSS.

- 1.b. I read "Knowing whether software is commercial or not". It is, in my
  understanding, about commercial use or non-commercial use.

- 1.b. Arguing that knowing what's commercial or not isn't feasible implies
  accepting such distinction when the EU can give a practical legal definition.

- 1.c. Stopping development would not exempt the author from CRA. Stopping the
  commercial use would.

- 1.d. This somewhat implies accepting CRA requirements for big companies.

- 2.a. Explaining that the 24h window would disrupt FOSS' well working system
  of responsible disclosures of security issues, implies accepting that the
  FOSS community would be legally required to provide security support.

- 2.b. Mentioning the efforts Debian is doi

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Bart Martens]

On Thu, Nov 23, 2023 at 10:30:01AM +, Luca Boccassi wrote:
> On Wed, 22 Nov 2023 at 20:35, Bart Martens  wrote:
> >
> > On Wed, Nov 22, 2023 at 06:46:06PM +, Luca Boccassi wrote:
> > > On Wed, 22 Nov 2023 at 09:28, Bart Martens  wrote:
> > > >
> > > > On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
> > > > > I feel like we're getting trapped by big corp and their lobbying
> > > > > power, and we need to use stronger words.
> > > >
> > > > Probably in a different way. I'd rather prefer Debian to defend the 
> > > > DFSG,
> > > > including DFSG 6. If the EU were to draw a line for compulsory 
> > > > liability, then
> > > > it should not be between commercial and nonprofit, but rather between 
> > > > FOSS and
> > > > non-FOSS. For example, in my opinion "awscli" is FOSS, and the usual 
> > > > liability
> > > > disclaimer in FOSS licenses should also be valid for "awscli". This is, 
> > > > in my
> > > > understanding, a different opinion than discussed so far, right?
> > >
> > > That would not be a good outcome. Just because a smartphone ships open
> > > source software, it doesn't mean its vendor should get away with not
> > > providing security updates after a few months, causing the phone
> > > owners to lose their data or worse.
> >
> > That is a different case. The user of a smartphone depends on the vendor for
> > keeping the smarthpone safe for use during a reasonable time after purchase.
> > I follow you on that.
> 
> It's not really different, if you can get out of security maintenance
> of some software just because of its license, then it affects any
> product using software. That would be quite an obvious loophole to
> take advantage of, and that's probably why the distinction in these
> regulations is never on the license, but on whether it's a commercial
> activity or not.

Well, I think that the CRA & PLD are meant to cover such loopholes. The CRA &
PLD are useful when they introduce compulsory liability for closed products
entirely, also when those products contain pieces of FOSS. The criterion is
that the FOSS is embedded in a closed product, so the user of the product
relies on the product manufacturer for updating that FOSS.

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Bart Martens]

On Wed, Nov 22, 2023 at 06:46:06PM +, Luca Boccassi wrote:
> On Wed, 22 Nov 2023 at 09:28, Bart Martens  wrote:
> >
> > On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
> > > I feel like we're getting trapped by big corp and their lobbying
> > > power, and we need to use stronger words.
> >
> > Probably in a different way. I'd rather prefer Debian to defend the DFSG,
> > including DFSG 6. If the EU were to draw a line for compulsory liability, 
> > then
> > it should not be between commercial and nonprofit, but rather between FOSS 
> > and
> > non-FOSS. For example, in my opinion "awscli" is FOSS, and the usual 
> > liability
> > disclaimer in FOSS licenses should also be valid for "awscli". This is, in 
> > my
> > understanding, a different opinion than discussed so far, right?
> 
> That would not be a good outcome. Just because a smartphone ships open
> source software, it doesn't mean its vendor should get away with not
> providing security updates after a few months, causing the phone
> owners to lose their data or worse.

That is a different case. The user of a smartphone depends on the vendor for
keeping the smarthpone safe for use during a reasonable time after purchase.
I follow you on that.

call for seconds - separate proposal text for 2023/vote_002

[Bart Martens]

Hello, I hereby welcome seconds for adding this text to 2023/vote_002
as a separate proposal.

START OF PROPOSAL TEXT

Debian Public Statement about the EU Cyber Resilience Act (CRA) and the
Product Liability Directive (PLD)

The CRA includes requirements for manufacturers of software, followed
up by the PLD with compulsory liability for software. The Debian
project has concerns on the impact on Free and Open-Source Software
(FOSS).

The CRA makes the use of FOSS in commercial context more difficult.
This goes against the philosophy of the Debian project. The Debian Free
Software Guidelines (DFSG) include "6. No Discrimination Against Fields
of Endeavor - The license must not restrict anyone from making use of
the program in a specific field of endeavor." A significant part of the
success of FOSS is its use in commercial context. It should remain
possible for anyone to produce, publish and use FOSS, without making it
harder for commercial entities or for any group of FOSS users.

The compulsory liability as meant in the PLD overrules the usual
liability disclaimers in FOSS licenses. This makes sharing FOSS with
the public more legally risky. The compulsory liability makes sense for
closed-source software, where the users fully depend on the
manufacturers. With FOSS the users have the option of helping
themselves with the source code, and/or hiring any consultant on the
market. The usual liability disclaimers in FOSS licenses should remain
valid without the risk of being overruled by the PLD.

The Debian project asks the EU to not draw a line between commercial
and non-commercial use of FOSS. Such line should instead be between
closed-source software and FOSS. FOSS should be entirely exempt from
the CRA and the PLD.

END OF PROPOSAL TEXT



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

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Bart Martens]

On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
> On 11/20/23 00:21, Luca Boccassi wrote:
> > Second version, taking into account feedback. Looking for seconds at
> > this point:
[...]
> 
> Thanks a lot for taking the time to word out things this way.
> 
> However, I really think this text is being too nice with the EU. The feeling
> in short is reading:
> - what you did was good
> - what you did was good
> - what you did was good
> - oh, btw, there's room for improvement... it'd be nice if...
> 
> That's not at all my feeling about the CRA. I'm once more really unhappy
> about EU,

Same here. But...

> I feel like we're getting trapped by big corp and their lobbying
> power, and we need to use stronger words.

Probably in a different way. I'd rather prefer Debian to defend the DFSG,
including DFSG 6. If the EU were to draw a line for compulsory liability, then
it should not be between commercial and nonprofit, but rather between FOSS and
non-FOSS. For example, in my opinion "awscli" is FOSS, and the usual liability
disclaimer in FOSS licenses should also be valid for "awscli". This is, in my
understanding, a different opinion than discussed so far, right?

> 
> In the absence of something better, I'll still vote for the above...
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Bart Martens]

On Sat, Nov 18, 2023 at 11:43:27AM -0700, Sam Hartman wrote:
> >>>>> "Bart" == Bart Martens  writes:
> 
> Bart> On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
> >> I wonder if we should have something like "Free software
> >> development by nonprofit organizations" somewhere.
> 
> Bart> Are we now drawing a line between profit and nonprofit? In my
> Bart> view, with Free Software it should not matter who produces,
> Bart> publishes or uses the software, in commercial or nonprofit
> Bart> context. That is, in my view, an essential element of the
> Bart> continuous growth and success of Free Software. This should be
> Bart> the main message if Debian would make a public statement in
> Bart> this context. Debian should not try to fix the EU text by
> Bart> defining which categories of contributors are to be
> Bart> protected. On the contrary, we should aim at keeping the
> Bart> existing freedoms for anyone alike, including commercial
> Bart> companies. That is also publishing open source software under
> Bart> licenses with the usual disclaimers of liabilities.
> 
> I think that when your practices can be best described as monatizing
> your customers, or monatizing the users of your open-source software,
> then you have extended beyond the free-software ethos, and I think
> commercial liability makes sense.

My point was that Debian's role in this context is promoting the DFSG, and not
helping the EU with overruling DFSG 6.

> 
> So let's consider some situations.
> 
> * A commercial company writes free software.  Should they have liability
>   to someone who grabs that software uses it unrelated to that company's
>   business and they never make money from that person?  Example: A large
>   company makes a useful library that they and others use; the library
>   is ancillary to their business; they do not provide support for the
>   library.
>   I'd generally say that the commercial company is writing free software
>   and I agree that Debian should support the idea they should have all
>   the protections of anyone writing free software.

I follow that.

> 
> * A commercial company writes free-software that for all practical
>   purposes can be used only for access to their proprietary web
>   service.  I'd rather not allow arguments about whether a flaw is on
>   the web service side or the client API side to be used to help the
>   company get out of liability to their customers/users.

I guess "awscli" is an example of this situation.
https://packages.debian.org/sid/awscli
https://metadata.ftp-master.debian.org/changelogs//main/a/awscli/awscli_2.12.0-1_copyright
So the EU would hold Amazon liable for damages caused by using "awscli",
overruling the "without warranties" clause in the license. Well, then next time
Amazon might choose to only provide documentation of the API, without
publishing an open source example implementation like "awscli". That's a loss
for foss. It illustrates the value of DFSG 6.

> 
> *A company writes software.  They sell support for that software.  They
>  have a track record of being bad about providing security updates to
>  people who do not pay for support; it is hinted that this helps them
>  drive support revenue.

Example of such software in Debian?

> I think they should be in the same boat as any company giving software
>  away for free and also selling support.  I.E. the fact that the source
>  is available should not in this instance help them escape liability.
>  Whether not giving away security updates for free should be considered
>  good business or a social evil seems like a debate for another forum,
>  but I don't think open source should be a factor here.

We have a different opinion on that.

> 
> So, there are some cases where I agree with you that the commercial
> nature of the company should not matter to free software protection and
> other cases where it is a lot less clear to me.
> 
> I do think we want to avoid cases where releasing something as free
> software or open source increases liability over giving the same
> software away for gratis as closed-source.

I follow those two points.

Cheers,
Bart

> 
> --Sam

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Bart Martens]

On Mon, Nov 13, 2023 at 03:57:44PM +0100, Aigars Mahinovs wrote:
> On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer <
> perezme...@gmail.com> wrote:
> 
> > On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs  wrote:
> > > Whether accepting donations *in general* makes your activity in
> > providing software a "commercial activity" in the context of
> > > this directive proposal is not really a supported notion in the text.
> > There are a few specific examples of what does make
> > > a "commercial activity" in point 10, but none of those examples directly
> > apply to general donations to a project or person.
> >
> > I am not mixing, I think the current wording does not _exactly_ says
> > so, leaving a door open for abuse.
> >
> 
> The current working does say what is commercial activity and accepting
> donations does not fall into any of those examples.

It does. Quoted by Ilu: "Accepting donations without the intention of making a
profit should not count as a commercial activity, unless such donations are
made by commercial entities and are recurring in nature."

> 
> But EFF, among others, does mention that it would be more comforting if
> accepting donations was explicitly highlighted as an example of
> activity that clearly falls outside of the commercial activity definition.
> 
> -- 
> Best regards,
> Aigars Mahinovs

-- 

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Bart Martens]

On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
> I wonder if we should have something like "Free software development by
> nonprofit organizations" somewhere.

Are we now drawing a line between profit and nonprofit? In my view, with Free
Software it should not matter who produces, publishes or uses the software, in
commercial or nonprofit context. That is, in my view, an essential element of
the continuous growth and success of Free Software. This should be the main
message if Debian would make a public statement in this context. Debian should
not try to fix the EU text by defining which categories of contributors are to
be protected. On the contrary, we should aim at keeping the existing freedoms
for anyone alike, including commercial companies. That is also publishing open
source software under licenses with the usual disclaimers of liabilities.

Cheers,
Bart

Re: Voting period

[Bart Martens]

On Sat, Sep 17, 2022 at 08:58:23PM +0200, Kurt Roeckx wrote:
> On Sat, Sep 17, 2022 at 12:28:23PM +0200, Bart Martens wrote:
> > On Fri, Sep 16, 2022 at 05:18:21PM -0700, Russ Allbery wrote:
> > > Kurt Roeckx  writes:
> > > 
> > > > I welcome suggestion for the ballot texts.
> > > 
> > > Tentative proposal, and the proponents of other options should jump in and
> > > correct these.
> > > 
> > > A: "Only one installer, including non-free firmware"
> > > B: "Recommend installer containing non-free firmware"
> > > C: "Provide installers with and without non-free firmware"
> > 
> > More accurate would be:
> > C: "Allow presenting non-free installers alongside the free one"
> > 
> > > D: "Installer with non-free firmware not part of Debian"
> > 
> > And here:
> > D: "Installer with non-free software not part of Debian"
> 
> That looks the same? Do you mean to says "is not part of Debian"?

The difference is "firmware" replaced by "software". The word "firmware" is
nowhere in the texts of options C and D.

> 
> 
> Kurt
> 

-- 

Re: Voting period

[Bart Martens]

On Fri, Sep 16, 2022 at 05:18:21PM -0700, Russ Allbery wrote:
> Kurt Roeckx  writes:
> 
> > I welcome suggestion for the ballot texts.
> 
> Tentative proposal, and the proponents of other options should jump in and
> correct these.
> 
> A: "Only one installer, including non-free firmware"
> B: "Recommend installer containing non-free firmware"
> C: "Provide installers with and without non-free firmware"

More accurate would be:
C: "Allow presenting non-free installers alongside the free one"

> D: "Installer with non-free firmware not part of Debian"

And here:
D: "Installer with non-free software not part of Debian"

> E: "Change SC for non-free firmware in installer, one installer"
> F: "Change SC for non-free firmware in installer, keep both installers"
> 
> It's tricky to word the last two sufficiently succinctly to keep them on
> one line without making them too cryptic.  Any better suggestions very
> much welcome.
> 
> -- 
> Russ Allbery (r...@debian.org)  
> 

 

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

[Bart Martens]

On Mon, Sep 12, 2022 at 02:16:53AM +0100, Steve McIntyre wrote:
> However, I feel strongly that the non-free installer *has* to be
> handled differently. If not, we're choosing to fail on (some of) our
> principles. This is why I'm here with this GR after all.

So do I. Or does proposal A describe a free installer?

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> "The problem with defending the purity of the English language is that
>  English is about as pure as a cribhouse whore. We don't just borrow words; on
>  occasion, English has pursued other languages down alleyways to beat them
>  unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll



-- 

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

[Bart Martens]

On Sun, Sep 11, 2022 at 10:13:26AM +0800, Paul Wise wrote:
> On Sat, 2022-09-10 at 09:16 +0200, Simon Josefsson wrote:
> 
> > So the practical problems facing people requiring non-free software
> > appears solved or possible to solve.
> 
> As I understand it there are two problems solved by proposal A/E:
> 
> Users who aren't aware of the firmware problem are directed by the
> Debian website to download the free installer, they try it out, find it
> doesn't work on their hardware and then abandon Debian in favour of
> other distros, or ask questions about it to the Debian support channels
> or the Debian teams involved in the image creation/distribution. They
> always get the non-free installer eventually, but we have wasted their
> time and ours by directing them to the free installer by default.
> 
> Since the hardware most users use causes the first problem, the people
> fielding these support requests see that the free installer is in most
> cases not useful and therefore want to stop building or working on it.
> 
> My earlier proposal that solves these issues without a GR or SC change:
> 
> https://lists.debian.org/msgid-search/683a7c0e69b081aae8c46bd4027bf7537475624a.ca...@debian.org

Yes, that totally makes sense. I wansn't sure whether the mentioned
"side-by-side" would be allowed without GR, so I made it a ballot option.
And indeed, keeping the free media alive may require calling volunteers.
It looks like this kind of solutions has been discussed already in April.

> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise



-- 

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

[Bart Martens]

On Fri, Sep 09, 2022 at 08:01:58PM +0200, Jonathan Carter (highvoltage) wrote:
> On 2022/09/09 18:04, Russ Allbery wrote:
> >  We encourage careful review of the licensing of these packages before
> >  use or redistribution, since the guarantees of the Debian Free
> >  Software Guidelines do not apply to them.
> 
> Looks good to me. It summarizes the gist of the issue very concisely without
> using any loaded terms.

The word "guarantees" can make Debian liable for mistakes.

> 
> -Jonathan
> 

-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> I think the problem is with "non-free section". I think Steve looks at
> that like the non-free-firmware section is now allowed. I suggest you
s/now/not/
> just rewrite it as: "containing non-free software from the Debian
> archive".

Hi Kurt,

Yes, let's do that, thanks. So here is the adapted proposal C:

=

The Debian project is permitted to make distribution media (installer images
and live images) containing non-free software from the Debian archive available
for download alongside with the free media in a way that the user is informed
before downloading which media are the free ones.

=

The modification:
Old: containing packages from the non-free section of the Debian archive
New: containing non-free software from the Debian archive

The old phrase was misunderstood as if this proposal would be opposing the
addition of a new section named non-free-firmware. The new phrase better
reflects that software in section non-free-firmware is also covered.

Then why not simply mention section non-free-firmware? Well, this proposal is
meant to be more future proof. This proposal is applicable to an installer
using the non-free-firmware section, and also to the existing non-free
installer. And to any future designs of non-free installers.

My subjective comparison of the available proposals so far:

- Proposal A replaces the free installer by one containing non-free firmware.
- Proposal B gives the free installer less visibility than the non-free one.
- Proposal C keeps the free installer and no longer hides the non-free ones.
- Proposal D would be equivalent to NOTA in my understanding.

Proposal C could use some more seconding. If you find that proposal C is a
valid option on the ballot (regardless of what you'll later vote for), then
you're most welcome to add your seconding.

Cheers,

Bart



signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> > On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> > > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> > > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > > >> > I hereby propose the following alternative text to Steve's original 
> > > >> > proposal.
> > > >> > 
> > > >> > =
> > > >> > 
> > > >> > The Debian project is permitted to make distribution media 
> > > >> > (installer images
> > > >> > and live images) containing packages from the non-free section of 
> > > >> > the Debian
> > > >> > archive available for download alongside with the free media in a 
> > > >> > way that the
> > > >> > user is informed before downloading which media are the free ones.
> > > >> > 
> > > >> > =
> > > >> 
> > > >> Wondering if this should be s/non-free section/non-free-firmware 
> > > >> section/
> > > >
> > > >Thanks for asking. The short answer is no. I kept my proposal very short,
> > > >keeping the focus on the smallest possible action we can do for helping 
> > > >those
> > > >users that need non-free firmware: allowing ourselves to advertise 
> > > >non-free
> > > >installers just as visible as our free installer. Moving non-free 
> > > >firmware to a
> > > >separate section might be useful, but it is in my view not part of that
> > > >smallest possible action. So what's my position on such new section? 
> > > >Well, what
> > > >is not mentioned is not proposed and not opposed. That's all. - B.
> > > 
> > > Argh. So this does *not* work with the plan that we have *already
> > > started*, where we're going to move firmware things to
> > > non-free-firmware instead. Please switch to "non-free and/or
> > > non-free-firmware sections" in your text.
> > 
> > I'm surprised. Please read what is written. Proposal C leaves open whether 
> > such
> > new section would be added in the future. So if proposal C would win, then 
> > the
> > started work you describe can continue. Proposal C uses the term "non-free"
> > because that is where all non-free packages are still residing today.
> 
> I think the problem is with "non-free section". I think Steve looks at
> that like the non-free-firmware section is now allowed. I suggest you
> just rewrite it as: "containing non-free software from the Debian
> archive".

Steve, would this idea from Kurt bring you back?

> 
> 
> Kurt
> 

-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> > On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> > > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> > > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > > >> > I hereby propose the following alternative text to Steve's original 
> > > >> > proposal.
> > > >> > 
> > > >> > =
> > > >> > 
> > > >> > The Debian project is permitted to make distribution media 
> > > >> > (installer images
> > > >> > and live images) containing packages from the non-free section of 
> > > >> > the Debian
> > > >> > archive available for download alongside with the free media in a 
> > > >> > way that the
> > > >> > user is informed before downloading which media are the free ones.
> > > >> > 
> > > >> > =
> > > >> 
> > > >> Wondering if this should be s/non-free section/non-free-firmware 
> > > >> section/
> > > >
> > > >Thanks for asking. The short answer is no. I kept my proposal very short,
> > > >keeping the focus on the smallest possible action we can do for helping 
> > > >those
> > > >users that need non-free firmware: allowing ourselves to advertise 
> > > >non-free
> > > >installers just as visible as our free installer. Moving non-free 
> > > >firmware to a
> > > >separate section might be useful, but it is in my view not part of that
> > > >smallest possible action. So what's my position on such new section? 
> > > >Well, what
> > > >is not mentioned is not proposed and not opposed. That's all. - B.
> > > 
> > > Argh. So this does *not* work with the plan that we have *already
> > > started*, where we're going to move firmware things to
> > > non-free-firmware instead. Please switch to "non-free and/or
> > > non-free-firmware sections" in your text.
> > 
> > I'm surprised. Please read what is written. Proposal C leaves open whether 
> > such
> > new section would be added in the future. So if proposal C would win, then 
> > the
> > started work you describe can continue. Proposal C uses the term "non-free"
> > because that is where all non-free packages are still residing today.
> 
> I think the problem is with "non-free section". I think Steve looks at
> that like the non-free-firmware section is now allowed.
 not

He wants "non-free-firmware section" mentioned in proposal C, see above.

> I suggest you
> just rewrite it as: "containing non-free software from the Debian
> archive".

That would indeed leave out the existing section name. I'll consider it.

> 
> 
> Kurt
> 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 08:25:44PM +0100, Steve McIntyre wrote:
> On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> >On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> >> On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> >> >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> >> >> > I hereby propose the following alternative text to Steve's original 
> >> >> > proposal.
> >> >> > 
> >> >> > =
> >> >> > 
> >> >> > The Debian project is permitted to make distribution media (installer 
> >> >> > images
> >> >> > and live images) containing packages from the non-free section of the 
> >> >> > Debian
> >> >> > archive available for download alongside with the free media in a way 
> >> >> > that the
> >> >> > user is informed before downloading which media are the free ones.
> >> >> > 
> >> >> > =
> >> >> 
> >> >> Wondering if this should be s/non-free section/non-free-firmware 
> >> >> section/
> >> >
> >> >Thanks for asking. The short answer is no. I kept my proposal very short,
> >> >keeping the focus on the smallest possible action we can do for helping 
> >> >those
> >> >users that need non-free firmware: allowing ourselves to advertise 
> >> >non-free
> >> >installers just as visible as our free installer. Moving non-free 
> >> >firmware to a
> >> >separate section might be useful, but it is in my view not part of that
> >> >smallest possible action. So what's my position on such new section? 
> >> >Well, what
> >> >is not mentioned is not proposed and not opposed. That's all. - B.
> >> 
> >> Argh. So this does *not* work with the plan that we have *already
> >> started*, where we're going to move firmware things to
> >> non-free-firmware instead. Please switch to "non-free and/or
> >> non-free-firmware sections" in your text.
> >
> >I'm surprised. Please read what is written. Proposal C leaves open whether 
> >such
> >new section would be added in the future. So if proposal C would win, then 
> >the
> >started work you describe can continue. Proposal C uses the term "non-free"
> >because that is where all non-free packages are still residing today.
> >
> >Does this cover your concern?
> 
> No, it doesn't.

> Your words may cover where those packages are *today*,

Exactly.

> but they most likely will *not* be in "non-free" when we come to make
> the changes. "non-free-firmware" != "non-free".

I understood that part.

> Please tweak your
> wording to be more flexible and cover what we're aiming to do.

I think we have a different view on which proposal is the most flexible. And I
understand that you want my proposal to cover what you are aiming at.

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> "This dress doesn't reverse." -- Alden Spiess

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> >> > I hereby propose the following alternative text to Steve's original 
> >> > proposal.
> >> > 
> >> > =
> >> > 
> >> > The Debian project is permitted to make distribution media (installer 
> >> > images
> >> > and live images) containing packages from the non-free section of the 
> >> > Debian
> >> > archive available for download alongside with the free media in a way 
> >> > that the
> >> > user is informed before downloading which media are the free ones.
> >> > 
> >> > =
> >> 
> >> Wondering if this should be s/non-free section/non-free-firmware section/
> >
> >Thanks for asking. The short answer is no. I kept my proposal very short,
> >keeping the focus on the smallest possible action we can do for helping those
> >users that need non-free firmware: allowing ourselves to advertise non-free
> >installers just as visible as our free installer. Moving non-free firmware 
> >to a
> >separate section might be useful, but it is in my view not part of that
> >smallest possible action. So what's my position on such new section? Well, 
> >what
> >is not mentioned is not proposed and not opposed. That's all. - B.
> 
> Argh. So this does *not* work with the plan that we have *already
> started*, where we're going to move firmware things to
> non-free-firmware instead. Please switch to "non-free and/or
> non-free-firmware sections" in your text.

I'm surprised. Please read what is written. Proposal C leaves open whether such
new section would be added in the future. So if proposal C would win, then the
started work you describe can continue. Proposal C uses the term "non-free"
because that is where all non-free packages are still residing today.

Does this cover your concern?

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
>   Armed with "Valor": "Centurion" represents quality of Discipline,
>   Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
>   concord the digital world while feeling safe and proud.

Re: Changing how we handle non-free firmware

[Bart Martens]

On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > I hereby propose the following alternative text to Steve's original 
> > proposal.
> > 
> > =
> > 
> > The Debian project is permitted to make distribution media (installer images
> > and live images) containing packages from the non-free section of the Debian
> > archive available for download alongside with the free media in a way that 
> > the
> > user is informed before downloading which media are the free ones.
> > 
> > =
> 
> Wondering if this should be s/non-free section/non-free-firmware section/

Thanks for asking. The short answer is no. I kept my proposal very short,
keeping the focus on the smallest possible action we can do for helping those
users that need non-free firmware: allowing ourselves to advertise non-free
installers just as visible as our free installer. Moving non-free firmware to a
separate section might be useful, but it is in my view not part of that
smallest possible action. So what's my position on such new section? Well, what
is not mentioned is not proposed and not opposed. That's all. - B.

Re: Changing how we handle non-free firmware

[Bart Martens]

On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
> 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.

This means that non-free-firmware would be always enabled, also when the system
would not determine that the included firmware binaries are required. Intended?

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



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Aug 30, 2022 at 09:22:51PM +0200, Bart Martens wrote:
> On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:
> > Hi Steve (and everyone else),
> > > 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.
> > 
> > Gulp, such a big jump! :) I personnally feel that we should make it
> > easier for people to install Debian, but I'm not quite sure I'm ready to
> > completely ditch the free images just yet. Maybe we could just promote
> > non-free images a little better, but I would much rather keep the free
> > images around. I guess that makes me a supporter of option "B",
> 
> Rather option C. Option B is reinforcing the current situation. C proposes to
> promote non-free images a little better while keeping the free images.

Oops, my bad. B and C are similar on this aspect. A relevant difference is
however that in B the non-free images are promoted above the free ones.

> 
> > if I
> > understand correctly, but I am known for struggling with parsing GR
> > proposals. :)
> > 
> > Thanks again for all your work, and for everyone for having a (so far)
> > rather polite discussion on this possibly difficult topic.
> > 
> > a.
> > 
> > -- 
> > Time is a created thing. To say, "I don't have time" is like saying,
> > "I don't want to."
> > - Lao Tzu
> 
> 
> 

-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:
> Hi Steve (and everyone else),
> > 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.
> 
> Gulp, such a big jump! :) I personnally feel that we should make it
> easier for people to install Debian, but I'm not quite sure I'm ready to
> completely ditch the free images just yet. Maybe we could just promote
> non-free images a little better, but I would much rather keep the free
> images around. I guess that makes me a supporter of option "B",

Rather option C. Option B is reinforcing the current situation. C proposes to
promote non-free images a little better while keeping the free images.

> if I
> understand correctly, but I am known for struggling with parsing GR
> proposals. :)
> 
> Thanks again for all your work, and for everyone for having a (so far)
> rather polite discussion on this possibly difficult topic.
> 
> a.
> 
> -- 
> Time is a created thing. To say, "I don't have time" is like saying,
> "I don't want to."
> - Lao Tzu

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 29, 2022 at 09:49:14PM +0100, Steve McIntyre wrote:
> Hi Simon!
> 
> On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote:

> >
> >Thereby re-inforcing the interpretation that any installer or image with
> >non-free software on it is not part of the Debian system, but that we
> >support their use and welcome others to distribute such work.
> >
> >==
> 
> This last bit of wording is slightly unclear to me. Should *Debian* be
> allowed to distribute an installer or image with non-free software on
> it?

Debian already does that. Anything available for download on *.debian.org is in
fact distributed by Debian. The label "unofficial" doesn't change that.
My point is that the last paragraph in Simon J's proposal correctly reflects
the current reality. (But I fail to see the value of Simon J's proposal on the
ballot because it is in my understanding equivalent with "further discussion" /
"none of the above" which is already on the ballot.)

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> < liw> everything I know about UK hotels I learned from "Fawlty Towers"
> 

 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 29, 2022 at 11:02:09PM +0200, Kurt Roeckx wrote:
> If you believe that any of the options conflict with the DSC, I would
> like to see a discussion about that too.
> 
> It's my current interpretation that all voting options, even if they
> might conflict with the DSC, will be on the ballot, and might not
> require a 3:1 majority. That is, I don't think the Secretary can decide
> not to include an option that might conflict, or put a 3:1 majority
> requirement on it because they think it conflicts.
> 
> However, if an option that might conflict wins, the Secretary might
> have to decide if it conflicts or not, and if it conflicts void the
> GR.

Or not void the GR and inform the DPL that the outcome of the GR cannot be
implemented until another GR about the DSC...

> 
> 
> Kurt
> 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Sat, Aug 27, 2022 at 01:02:31PM +0200, Jonas Smedegaard wrote:
> Quoting Bart Martens (2022-08-26 18:03:30)
> > On Fri, Aug 26, 2022 at 04:18:19PM +0200, Jonas Smedegaard wrote:
> > > Quoting Bart Martens (2022-08-26 10:02:16)
> > > > On Fri, Aug 26, 2022 at 07:06:01AM +0200, Jonas Smedegaard wrote:
> > > > > [...] it lacks a detail I find crucial:
> > > > > Explicitly spelling out whether or not images containing non-free bits
> > > > > are official part of Debian or not.  Personally I find it obvious that
> > > > > anything that would not be allowed into main also would not be treated
> > > > > as official part of Debian,
> > > > 
> > > > I share the same concern as you: Steve's proposal would mean that 
> > > > installers
> > > > containing non-free firmware become official part of Debian. My text 
> > > > does not.
> > > > 
> > > > > If Bart chose to extend the proposal to include that such media
> > > > > containing non-free bits (although permitted "alongside with the free
> > > > > media) would *not* be considered official part of Debian, then I would
> > > > > endorse the amended proposal.
> > > > 
> > > > That would be repeating what's already true. My text includes only 
> > > > things that
> > > > I propose to change. So what is off/unofficially today, remains that. 
> > > > It's like
> > > > "the name of the project remains Debian". Why would I mention that.
> > > > 
> > > > Does this cover your concern?
> > > 
> > > It clarifies that my reading matches your intended reading. Thanks!
> > 
> > Haa wonderful.
> > 
> > > Unfortunately it does not cover my concern that the text is ambiguous -
> > > i.e. despite intent your choice of words can lead voters to vote for
> > > this text but with varying expectations, which is a very bad situation.
> > 
> > What exactly in my text do you mean?
> 
> The part you *didn't* include (so I cannot point at it or quote it) ;-)

Indeed, I see now that it's the point you made earlier.

> 
> > > 
> > > I still urge you to make explicit what will not change.  Perhaps borrow
> > > from Simons text, if you (like me) like that?
> > 
> > Simon Richter's text would permit the Debian project to replace the free
> > installer by a non-free one. My text clearly mentions that the free 
> > installer
> > is still there. Didn't you prefer the free installer to remain available?
> 
> Ha!  Indeed Simon Richter's text omit explicitly mentioning that a
> non-free installer is in _addition_ to the already free one -

Indeed, it's a difference that is easily overlooked.

> although
> that intent is clear from his more elaborate text before the concrete
> draft ballot text.

Very true, it's not in the draft ballot text, my point exactly.

> 
> ...or paraphrased in your style: His text doesn't say "replace".

I wrote "would permit to replace", not "will replace".

> 
> Perhaps you see now - through an example not your own - how being
> explicit helps avoid ambiguity?

True. Humans tend to read what's not written. That said, it is hard to prevent
all possible unintended interpretations.

> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Changing how we handle non-free firmware

[Bart Martens]

On Fri, Aug 26, 2022 at 11:39:42AM -0500, Gunnar Wolf wrote:
> Bart Martens dijo [Fri, Aug 26, 2022 at 11:59:44AM +0200]:
> > > > If you mean official media, this is more radical than Steve's proposal.
> > > > It would permit arbitrary non-free packages as long as users were
> > > > informed.
> > > > 
> > > > If you mean unofficial media - that's the status quo.  In which case,
> > > > this option is the same as Simon's and none of the above.
> > > > 
> > > > Ross
> > > >
> > > 
> > > /packages from the non-free *firmware* section/
> > 
> > My proposal does not add such new section ...
> 
> Right. I would _oppose_ your proposal if it is to appear in the
> ballot, because a freeness _win_ of Steve's proposal is that... People
> that need to enable non-free firmware don't need to pull in all of
> non-free in order to keep it updated.
> 
> I often install packages for getting to know them, just because they
> appeared in my list. And my list nowadays includes non-free because of
> some firmware. So I have installed non-free software without
> noticing. Splitting non-free firmware grants the user some more system
> freeness guarantees.

My proposal does not forbid adding such new section.

> 
> Greetings,

Re: Changing how we handle non-free firmware

[Bart Martens]

On Fri, Aug 26, 2022 at 04:18:19PM +0200, Jonas Smedegaard wrote:
> Quoting Bart Martens (2022-08-26 10:02:16)
> > On Fri, Aug 26, 2022 at 07:06:01AM +0200, Jonas Smedegaard wrote:
> > > [...] it lacks a detail I find crucial:
> > > Explicitly spelling out whether or not images containing non-free bits
> > > are official part of Debian or not.  Personally I find it obvious that
> > > anything that would not be allowed into main also would not be treated
> > > as official part of Debian,
> > 
> > I share the same concern as you: Steve's proposal would mean that installers
> > containing non-free firmware become official part of Debian. My text does 
> > not.
> > 
> > > If Bart chose to extend the proposal to include that such media
> > > containing non-free bits (although permitted "alongside with the free
> > > media) would *not* be considered official part of Debian, then I would
> > > endorse the amended proposal.
> > 
> > That would be repeating what's already true. My text includes only things 
> > that
> > I propose to change. So what is off/unofficially today, remains that. It's 
> > like
> > "the name of the project remains Debian". Why would I mention that.
> > 
> > Does this cover your concern?
> 
> It clarifies that my reading matches your intended reading. Thanks!

Haa wonderful.

> Unfortunately it does not cover my concern that the text is ambiguous -
> i.e. despite intent your choice of words can lead voters to vote for
> this text but with varying expectations, which is a very bad situation.

What exactly in my text do you mean?

> 
> I still urge you to make explicit what will not change.  Perhaps borrow
> from Simons text, if you (like me) like that?

Simon Richter's text would permit the Debian project to replace the free
installer by a non-free one. My text clearly mentions that the free installer
is still there. Didn't you prefer the free installer to remain available?

> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Fri, Aug 26, 2022 at 11:31:19AM +0100, Phil Morrell wrote:
> From absorbing this lengthy thread, my impression is that most folks are
> considering the nature of "officialness",

I would keep that separate from this GR.

> therefore I'd like to ask any
> proposed text to elaborate on intentions for what "Official Debian"
> means

In my proposal I intentionally left out "official".

I think that with this GR we can help our users more easily find the installer
they need for their hardware without reopening the debate on what we call
official and what our users perceive as official.

> [...]

> I hope this kind of email is ok here, even though I'm not able to
> directly interact with the GR process (proposing/seconding etc.). If
> not, sorry for adding to the 138 messages.

Sure! I can only hope that with this GR we keep the focus on helping the users.

Cheers, - Bart

Re: Changing how we handle non-free firmware

[Bart Martens]

On Thu, Aug 25, 2022 at 06:36:36PM +, Andrew M.A. Cater wrote:
> On Thu, Aug 25, 2022 at 08:18:55AM -0700, Ross Vandegrift wrote:
> > Hi Bart,
> > 
> > On Wed, Aug 24, 2022 at 10:12:48AM +0200, Bart Martens wrote:
> > > The Debian project is permitted to make distribution media (installer 
> > > images
> > > and live images) containing packages from the non-free section of the 
> > > Debian
> > > archive available for download alongside with the free media in a way 
> > > that the
> > > user is informed before downloading which media are the free ones.
> > 
> > Do you mean that official or unofficial media can contain packages from
> > non-free?
> > 
> > If you mean official media, this is more radical than Steve's proposal.
> > It would permit arbitrary non-free packages as long as users were
> > informed.
> > 
> > If you mean unofficial media - that's the status quo.  In which case,
> > this option is the same as Simon's and none of the above.
> > 
> > Ross
> >
> 
> /packages from the non-free *firmware* section/

My proposal does not add such new section ...

> 
> This is _only_ firmware and not arbitrary non-free packages. It's not drivers
> per se.

... does not make such distinction ...

> 
> The "official" and "unofficial" media are currently prepared by the same
> team on the same machines. The "unofficial" media contains non-free firmware
> (and drivers of all sorts, potentially, that go wider than firmware).
> 
> IMHO, they're both official - one is free + free firmware, one is 
> free+non-free
> firmware.

... and does not change the meaning and scope of "official".

> 
> Steve's proposal is strictly limited to firmware, here, and there is a 
> separate non-free firmware portion of the archive that was created at
> Debconf22 in Pristina.

Steve's proposal is adding non-free firmware in our currently free installer.
Introducing a new section in the archive doesn't change that.

My proposal focuses on one thing: helping our users find the installer they
need for their hardware by no longer hiding our non-free installers. This
applies to the existing non-free installers and also to the new kind of
installer Steve has in mind. So our free installer remains free.


> 
> All best, as ever,
> 
> Andy Cater
> 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Thu, Aug 25, 2022 at 08:18:55AM -0700, Ross Vandegrift wrote:
> Hi Bart,
> 
> On Wed, Aug 24, 2022 at 10:12:48AM +0200, Bart Martens wrote:
> > The Debian project is permitted to make distribution media (installer images
> > and live images) containing packages from the non-free section of the Debian
> > archive available for download alongside with the free media in a way that 
> > the
> > user is informed before downloading which media are the free ones.
> 
> Do you mean that official or unofficial media can contain packages from
> non-free?
> 
> If you mean official media, this is more radical than Steve's proposal.
> It would permit arbitrary non-free packages as long as users were
> informed.

My text not propose that installers containing non-free bits would become
official part of Debian.

> 
> If you mean unofficial media - that's the status quo.  In which case,
> this option is the same as Simon's and none of the above.

The difference with Simon's text and NOTA is that I do propose a change.

> 
> Ross
> 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Fri, Aug 26, 2022 at 07:06:01AM +0200, Jonas Smedegaard wrote:
> [...] it lacks a detail I find crucial:
> Explicitly spelling out whether or not images containing non-free bits
> are official part of Debian or not.  Personally I find it obvious that
> anything that would not be allowed into main also would not be treated
> as official part of Debian,

I share the same concern as you: Steve's proposal would mean that installers
containing non-free firmware become official part of Debian. My text does not.

> If Bart chose to extend the proposal to include that such media
> containing non-free bits (although permitted "alongside with the free
> media) would *not* be considered official part of Debian, then I would
> endorse the amended proposal.

That would be repeating what's already true. My text includes only things that
I propose to change. So what is off/unofficially today, remains that. It's like
"the name of the project remains Debian". Why would I mention that.

Does this cover your concern?

> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Wed, Aug 24, 2022 at 07:14:26PM +0200, Jonas Smedegaard wrote:
> Quoting Bart Martens (2022-08-24 10:12:48)
> > =
> > 
> > The Debian project is permitted to make distribution media (installer images
> > and live images) containing packages from the non-free section of the Debian
> > archive available for download alongside with the free media in a way that 
> > the
> > user is informed before downloading which media are the free ones.
> > 
> > =
> 
> Seconded.  Thanks for proposing this alternative, Bart.
> 
> In my view, this alternative and the one proposed by Simon achieve
> technically the same

Really? My text is meant to cover the concerns of both Simon and Steve. I
share Simon's concern on keeping free and non-free strictly separate, and I
also share Steve's concern on users needing non-free firmware for smoothly
installing Debian on their hardware.

> but communicated vastly different - which to me is
> (unfortunately) a sensible reason to have them both on the ballot.
> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Aug 23, 2022 at 04:39:27PM +0200, Enrico Zini wrote:
> On Mon, Aug 22, 2022 at 06:20:15PM +0200, Bart Martens wrote:
> 
> > With this GR proposal there would no longer be an installer without those
> > non-free bits.
> 
> Would you consider proposing an alternative ballot option,

I just did. Thanks for encouraging me to do that.

> instead of
> repeatedly stating your dislike of this one?
> 
> Debian's voting system allows anyone to propose a ballot option that has
> their position represented, and Steve explicitly invited it. This will
> lead to a ballot which represents the various positions in the project
> and allows anyone to rank them.
> 
> This is a rather beautiful way to turn the conflict of different
> opinions into value, rather than hostility.
> 
> 
> Enrico
> 
> -- 
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

Hello,

I hereby propose the following alternative text to Steve's original proposal.

=

The Debian project is permitted to make distribution media (installer images
and live images) containing packages from the non-free section of the Debian
archive available for download alongside with the free media in a way that the
user is informed before downloading which media are the free ones.

=

The text focuses on how we make the existing and any new non-free installers
available to our users: less hidden. Other discussed aspects are intentionally
left out of this text.

Cheers,
Bart



signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Aug 23, 2022 at 03:33:27PM +, Holger Levsen wrote:
> On Tue, Aug 23, 2022 at 05:04:49PM +0200, Jonas Smedegaard wrote:
> > I would find it problematic if the official way to install Debian
> > *required* a non-DFSG image.
> 
> would you also find it problematic if there were *two* official
> images, a "free one" (as we know it) and a "free one plus firmwares"?

It would be nice to have both installers presented on the front page, so users
can choose. I have no strong opinion on whether the "plus" installer would be
called official or not.

> 
> 
> -- 
> cheers,
>   Holger
> 
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
>  ⠈⠳⣄
> 
> There are no jobs on a dead planet.



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 22, 2022 at 11:32:23AM -0500, Gunnar Wolf wrote:
> Bart Martens dijo [Mon, Aug 22, 2022 at 06:24:32PM +0200]:
> > > >   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).
> > > >   ...
> > > >   We will publish these images as official Debian media, replacing the
> > > >  ^
> > > >   current media sets that do not include non-free firmware packages.
> > > 
> > > We are replacing stuff very often, for example when we update the 
> > > installer it
> > > is replaced too. For me, the replace in the proposal is meaning that kind 
> > > of
> > > replacing.
> > 
> > Yes indeed. It's replacing a free installer by a non-free one.
> > 
> > > We'd not taking anything away in respect to the spirit of SC-1.
> > 
> > We'd take away the free installer.
> 
> If a free installer is still produced and offered alongside the one
> including non-free-firmware, would you feel more at ease?

Yes, alongside would be perfect for me.

> That sounds
> like an easy compromise to make, and many people would probably
> welcome it.

That could be true, indeed.

> 
> Debian would recommend the one with non-free-firmware, for the
> purposes of enabling users to install on current hardware, but both
> would be available.

Do we need to recommend one above the other? I'd rather use some short
explanation per installer to help the user choose.

Cheers, Bart

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 22, 2022 at 11:30:43PM -0400, Theodore Ts'o wrote:
> I would consider making both installers equally easy to find a better
> outcome than the current status quo, where the version which is more
> likely to be useful for modern laptops is kept hidden and hard to find

I like your idea of "equally easy to find". It's a quick-win: present the
existing installers side-by-side so the user can easily choose. - B.

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 22, 2022 at 05:57:36PM +0200, Tobias Frost wrote:
> On Mon, Aug 22, 2022 at 05:48:28PM +0200, Simon Josefsson wrote:
> > Tobias Frost  writes:
> > That seems incorrect.  Here is a quote from the proposal:
> > 
> >   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).
> >   ...
> >   We will publish these images as official Debian media, replacing the
> >  ^
> >   current media sets that do not include non-free firmware packages.
> 
> We are replacing stuff very often, for example when we update the installer it
> is replaced too. For me, the replace in the proposal is meaning that kind of
> replacing.

Yes indeed. It's replacing a free installer by a non-free one.

> We'd not taking anything away in respect to the spirit of SC-1.

We'd take away the free installer.

> 
> --
> tobi 
> 



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 22, 2022 at 03:57:01PM +0200, Tobias Frost wrote:
> 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.

"All non-free bits are equal but some are more equal than other." Let's face
it, when we would start including non-free bits in the installer, then the
installer is no longer free. Regardless of whether those bits get installed.

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

With this GR proposal there would no longer be an installer without those
non-free bits.

> 
> 
> --
> tobi's 0.02 €



-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Thu, Aug 18, 2022 at 11:36:33PM +0200, Joerg Jaspert wrote:
> On 16594 March 1977, Timo Lindfors wrote:
> 
> > 3) Ensure that the filename of the installation media includes
> > "non-free-firmware" or something similar so that it is clear to
> > everyone what they are getting into. Debian has had such a long
> > history of not including non-free bits in the installation image
> > that people will definitely be surprised if the filename does not
> > reflect this change.
> 
> Actually, people are surprised we are hiding the useful images (with
> firmware) somewhere in some subdirectory away currently.

I recognize myself in both. I prefer the installer not including non-free bits,
and the ("unofficial") installer is difficult to find when I need it. Why not
advertise the free and non-free installers side-by-side?

Cheers,
Bart

Re: Secret ballot and RMS Resolution

[Bart Martens]

On Thu, Apr 01, 2021 at 05:00:47PM +0200, Kurt Roeckx wrote:
> The constitution says:
> 3. Votes are taken by the Project Secretary. Votes, tallies, and
>results are not revealed during the voting period; after the vote
>the Project Secretary lists all the votes cast. The voting period
>is 2 weeks, but may be varied by up to 1 week by the Project
>Leader.
> 
> While for DPL election it says:
> 5. The next two weeks are the polling period during which Developers
>may cast their votes. Votes in leadership elections are kept
>secret, even after the election is finished.
> 
> You could say that "all the votes cast" could mean what was voted,
> now who voted what, but I think that conflicts with the intention
> of the text.

Kurt, one could argue that publishing the names is always forbidden. Article 5
already plainly forbids it. And article 3 does not specify it, so with
privacy... I'm just sharing another way of looking at this, without suggesting
to change commonly accepted practice now in the middle of two votings. - B.



signature.asc
Description: PGP signature

Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms

[Bart Martens]

On Sat, Mar 27, 2021 at 11:51:40AM +0100, Timo Weingärtner wrote:
> Updated text:
> ---8<---8<---8<---
> The Debian Project will not issue a public statement on whether Richard
> Stallman should be removed from leadership positions or not.
> 
> Any individual (including Debian members) wishing to (co-)sign any of the 
> open 
> letters on this subject is invited to do this in a personal capacity.
> ---8<---8<---8<---

Seconded.



signature.asc
Description: PGP signature

Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms

[Bart Martens]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2021-03-26 at 09:19 +0100, Timo Weingärtner wrote:
> Updated text:
> ---8<---8<---8<---
> The Debian Project will not issue a public statement on whether
> Richard 
> Stallman should be removed from leadership positions or not.
> 
> Any individual (including Debian members) is free to issue such
> statements or 
> (co-)sign any open letter.
> ---8<---8<---8<---

Seconded.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZaEt9P4xrWusTXauM1X01jtYIcwFAmBdmgAACgkQM1X01jtY
IcyVSg/+P8sWEm0y9NzFP6BMRLafIKLuyqBAGLym5mRXdTwFPKoleAL/Sy78fTPA
fG2OHDmliD0729DJZbwHaJ8FT6dQvmIMy1x1ZqRRGKg7LuCPhwP1hHsgVbqaUPq1
q4FKnbGZPYG5T0xtY3lacaySKJ+25hvLh675vd3/IqQl+KiQXdycTW8ntPWItKTr
dW1OBt01A9ELJmC9PhC5vXc6ef18agZOD8J3zc5qIZ96P+60HTpSqIwYRjPC02+p
KoXVAErDxHm4XW295eye7mpBAGxdiIr0uIehD/7C/7hiX7frW59RgPaizU/I5V+n
P+29W9VAJ26+BEEz7QaPkt2VhcBdrm7XMFyD0aav0uYBgaEUMWvpb+xZVKVPI2Fz
ojLOcRf5yMOvWCm+65tIHkmFe/zjpcYomZ+Rw3xhOGXAVe/x8TIvH6HyxplKCkd2
34VmwAcLxFbLhZbz8e+slo+HOd+qDPeoSYjadDYke9oktpD72k7drM4WzDSiZkfa
xQAXNHEsgGqcW+9V8fm6RWMHyl4V7T77c0xdIFGi3mAmdYZRPVkHlgpUU8iwr5ln
I/4K0G9NQrt/TYK8HacD3hj8TrHRUdsqj59jmtyGoFjloPr2hA/EyNNCwiW+bA/j
gFd9YVnw9nyB67/yZsJgUJS5reomrotdzc6fe2fpa46/Ue0/ONw=
=sQ5Y
-END PGP SIGNATURE-

Re: Willingness to share a position statement? (rms-open-letter)

[Bart Martens]

On Wed, Mar 24, 2021 at 11:53:23PM +0200, Jonathan Carter wrote:
> On this particular issue, I feel it's better that individual
> developers go and make their voices heard.

Thank you Jonathan! I really hope most DDs feel the same way.

Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io

[Bart Martens]

On Wed, Mar 24, 2021 at 11:25:19PM +0100, Thomas Goirand wrote:
> Can't you just express your opinion by yourself, by signing the letter?

I'm with Thomas on this.

diversity

[Bart Martens]

Hello DPL candidates,

A question about diversity. We all know that some profiles are
underrepresented: gender, etnic group, disability, age, sexual preference,
education degree, rich/poor, spoken & written languages...

1/ One way of addressing this, is actively BENEFIT the underrepresented
profiles. Positive discriminiation is needed, at least to get over an initial
resistance. Put diversity in the spotlights, to speed up improvement.

2/ Another way is active NEUTRALITY treating everyone alike. No discrimination,
positive nor negative. Make room for diversity to evolve. Diversity
matters, although in the shadow of free software.

3/ ... ?

Now the QUESTION ---> What is your view on this? Your preferred approach? What
is the priority of diversity? Practical action points, how to measure progress?

Best regards,

Bart

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

[Bart Martens]

On Tue, 2016-09-20 at 21:22 +0200, Kurt Roeckx wrote:
> On Sun, Sep 11, 2016 at 10:17:46AM +0200, Bart Martens wrote:
> > 
> > On Thu, 2016-09-01 at 23:15 -0500, Gunnar Wolf wrote:
> > > 
> > > === BEGIN GR TEXT ===
> > > 
> > > Title: Acknowledge that the debian-private list will remain
> > > private.
> > > 
> > > 1. The 2005 General Resolution titled "Declassification of
> > > debian-
> > > private
> > >    list archives" is repealed.
> > > 2. In keeping with paragraph 3 of the Debian Social Contract,
> > > Debian
> > >    Developers are strongly encouraged to use the debian-private
> > > mailing
> > >    list only for discussions that should not be disclosed.
> > > 
> > > === END GR TEXT ===
> > 
> > Seconded.
> 
> This key does not appear to be in the keyring.  It's signed by
> key 09D97D749FBA061AFA6C00B4C85DA67CD5C0FC14, please sign it with
> 65A12DF4FE31AD6BAC4D76AE3355F4D63B5821CC.

My apologies, you're right, hereby signed with the right key.

Regards,

Bart Martens


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

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

[Bart Martens]

On Thu, Sep 08, 2016 at 05:07:47PM +0100, Ian Jackson wrote:
>  * We do not want to introduce any new barriers to declassification.

I do.

Regards,

Bart Martens

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

[Bart Martens]

On Fri, Sep 02, 2016 at 11:27:31AM +0300, Lars Wirzenius wrote:
> * Whatever else people come up.

I suggest to just repeal the 2005 GR, so we don't have any rules on
declassification of debian-private by GR. I suggest we rely on common sense
instead: The part "-private" in debian-private should make clear (without the
need for a GR) that the project should treat the contents of the list private,
regardless of the potential public value of what's written on debian-private.
Anyone reading something of potential public value on debian-private can always
request the original author for permission to quote in public. Note that the
original author is the only person who can fully assess how private the message
was, since personal limits differ and the relevant privacy aspects may not even
be explicitly mentioned in the message.

Which is why I seconded this GR proposal.

I would also second the GR proposal without article 2, but I think it's good to
include it so the GR proposal may win some more votes from DDs who want
debian-private to be used for truly private stuff only, and have Debian related
stuff discussed on the public mailing lists.

Regards,

Bart Martens

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

[Bart Martens]

On Thu, 2016-09-01 at 23:15 -0500, Gunnar Wolf wrote:
> === BEGIN GR TEXT ===
> 
> Title: Acknowledge that the debian-private list will remain private.
> 
> 1. The 2005 General Resolution titled "Declassification of debian-
> private
>    list archives" is repealed.
> 2. In keeping with paragraph 3 of the Debian Social Contract, Debian
>    Developers are strongly encouraged to use the debian-private
> mailing
>    list only for discussions that should not be disclosed.
> 
> === END GR TEXT ===

Seconded.

Bart Martens


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

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

[Bart Martens]

On Mon, Aug 08, 2016 at 09:58:45AM -0500, Don Armstrong wrote:
> On Sun, 07 Aug 2016, Micha Lenk wrote:
> > That would establishing some kind of "ex post facto" law (which by the
> > way is prohibited in many constitutions for good reasons). I really
> > don't want to leave the decision whether past messages will be
> > affected or not up to the list masters.
> 
> This is why the GR text requires that at minimum DDs can object via GR.

I don't see how that covers Micha's concern.

DDs can always initiate a GR, so the text in GR 2016/vote_002 "which at minimum
provides sufficient time and opportunity for Debian Developers to object by GR
prior to declassification" only gives the impression that one can prevent
declassification. In fact there is no way of preventing declassification since
the outcome of a GR is unknown in advance.

I think it's plain wrong that we're now about to give a permission for
declassifying debian-private possibly against the authors' will. GR
2005/vote_002 did include "requests by the author of a post for that post not
to be published will be honored" while 2016/vote_002 does not include any means
for the original authors to prevent declassification.

Regards,

Bart Martens

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

[Bart Martens]

On Sun, Aug 07, 2016 at 04:53:09PM +0200, Nicolas Dandrimont wrote:
> * Bart Martens  [2016-08-07 13:58:46 +]:
> 
> > Hi Nicolas,
> 
> Hi,
> 
> > On Sun, Aug 07, 2016 at 02:54:36PM +0200, Nicolas Dandrimont wrote:
> > > In my opinion the only point in this General Resolution is allowing the
> > > declassification of the early years of -private, where the mailing list 
> > > was
> > > used as a "project" mailing list rather than for discussing actually 
> > > sensitive
> > > matters.
> > 
> > Then the text of GR 2016/vote_002 should have reflected that.
> >
> > > I expect a sensible declassification process to allow the original 
> > > authors to
> > > decide on whether their messages should be declassified or not, if an 
> > > explicit
> > > disclaimer has not been put in the message.
> > 
> > Then the text of GR 2016/vote_002 should have reflected that.
> 
> Encoding the process down to the nitty gritty details

Don't get me wrong, I agree with your two points quoted above. I just think
that these are not just "nitty gritty details of the process" but elements that
make it a different GR.

> is what discouraged
> people to actually do the work in the first place. I'm glad that Don's
> amendment doesn't do that, and, who knows, it might even encourage people to
> get things done, finally.

I think we agree that GR texts should be formulated high-level (the "what"
part), allowing the people doing the actual work plenty room on the "how" part.

> > I have now voted against GR 2016/vote_002 because it allows 
> > declassification of
> > anything ever posted on debian-private against the authors' will.
> 
> But do we really think that's what is going to happen? Can't we trust the
> listmasters to respect the privacy that they have upheld for the last 10+
> years?
> 
> Why is it so hard to trust the people who actually want to do the work to
> come up with a sensible process?

I'm not questioning the trust that the listmasters deserve. I'm questioning the
scope of this GR. The listmasters are not malicious people but they may make
different privacy assessments than the original authors of messages on
debian-private might make. You've proven that point today on debian-private.

> 
> > I hope that everyone fully realizes that before voting.
> 
> And I hope that, at one point, we as a project will learn to trust one another
> and stop micro-managing people that actually want to get things done.

It's really not about trust and micro-management, but about "what" we want do
decide with this GR.

For example, your two points quoted above could easily be included in a GR text
using these phrases:

- "The scope is limited to messages posted on debian-private before
  debian-project was introduced." (And I have no strong opinion on whether this
  should be included.)
- "The consent of the original author of the message on debian-private is
  required before declassification." (I think this should have been in.)

Regards,

Bart Martens

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

[Bart Martens]

Hi Nicolas,

On Sun, Aug 07, 2016 at 02:54:36PM +0200, Nicolas Dandrimont wrote:
> In my opinion the only point in this General Resolution is allowing the
> declassification of the early years of -private, where the mailing list was
> used as a "project" mailing list rather than for discussing actually sensitive
> matters.

Then the text of GR 2016/vote_002 should have reflected that.

> I expect a sensible declassification process to allow the original authors to
> decide on whether their messages should be declassified or not, if an explicit
> disclaimer has not been put in the message.

Then the text of GR 2016/vote_002 should have reflected that.

I have now voted against GR 2016/vote_002 because it allows declassification of
anything ever posted on debian-private against the authors' will. I hope that
everyone fully realizes that before voting.

Regards,

Bart Martens

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Wed, Mar 20, 2013 at 07:35:19AM -0700, Russ Allbery wrote:
> Bart Martens  writes:
> > On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:
> 
> >> note that free software interfaces to proprietary cloud platforms are
> >> frequently used to manipulate the data in those platforms including
> >> pull data *out* of those platforms.  It would be quite ironic if we
> >> refused to include in the distribution the tools required to pull one's
> >> data out of non-free platforms.
> 
> > An interface to facebook or to twitter or to the internet movie database
> > or to websites with stock quotes may be freely redistributed but
> > "requires software outside of the distribution to function".  Why do we
> > make exceptions depending on how "ironic" things are ?
> 
> Because, similar to how all evil plans for taking over the world should be
> run past a fifth grader first, all grand principles of ideology should be
> checked for whether their actual outcomes are silly.

Which is why I'm open to change debian-policy or move packages from main to
contrib depending on what's the least silly.

Regards,

Bart Martens


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

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Wed, Mar 20, 2013 at 09:27:58AM +0100, Wouter Verhelst wrote:
> You can use flashplugin-nonfree to download a piece of software that has
> a nonfree license, which is then installed on your system; the result is
> that you now have a system which has some non-DFSG-free software
> installed. To be able to reach this situation on a system that only has
> "main" enabled would be utterly wrong.
> 
> You can use pidgin-facebookchat to talk to a non-free service; but
> whatever you do, the result will *never* be that you end up with a
> system which has some non-DFSG-free software installed. As such, I don't
> think it's necessary that you not be able to reach this on a system that
> only has "main" enabled.

OK, you seem to draw the line where non-free is installed or not on the local
system.  That makes somewhat sense to me.  But then the part "which require
software outside of the distribution to either build or function" in
debian-policy should be replaced by something like "which causes software
outside of the distribution to be installed on the local system".

Regards,

Bart Martens


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

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Tue, Mar 19, 2013 at 05:09:00PM -0700, Russ Allbery wrote:
> note that free software interfaces to proprietary cloud platforms
> are frequently used to manipulate the data in those platforms including
> pull data *out* of those platforms.  It would be quite ironic if we
> refused to include in the distribution the tools required to pull one's
> data out of non-free platforms.

An interface to facebook or to twitter or to the internet movie database or to
websites with stock quotes may be freely redistributed but "requires software
outside of the distribution to function".  Why do we make exceptions depending
on how "ironic" things are ?

Regards,

Bart Martens


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

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Tue, Mar 19, 2013 at 04:46:42PM -0700, Steve Langasek wrote:
> On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote:
> > 3. One test I've been taught to use to reason about free software is the
> >Desert Island test [2] which starts by:
> 
> >  Imagine a castaway on a desert island with a solar-powered
> >  computer.
> 
> >   Obviously, software that are only frontends to unreproducible “cloud”
> >   services do not pass the desert island test.
> 
> This is a mischaracterization of the "Desert Island test" as it was
> formulated on debian-legal.  The Desert Island test is about whether a user
> can *comply with the license* of the software on a desert island when they
> have no contact with the outside world.  That the software may not be
> *useful* to them on a desert island is a separate question, and applies to
> many sorts of software, not just those used for connecting to particular
> services over the Internet.

I'm missing the point on what Steve wrote above.  We could debate on what one
understands under the "Desert Island test".  What really matters is that the
phrase "require software outside of the distribution to either build or
function" (Debian Policy 2.2.2) clearly applies to software that is not
"*useful*" without that other "software outside of the distribution".

Regards,

Bart Martens


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

Re: [all candidates] Return to the desert island (cont.)

[Bart Martens]

On Tue, Mar 19, 2013 at 11:39:29PM +0100, Jérémy Bobbio wrote:
> 1. Some software Debian distribute are actually only useful when
>connected to the Internet to access services for which the
>source code is unavailable.
> 
> 2. The Debian policy states (emphasis is mine):
> 
>  # 2.2.2 The contrib archive area
> 
>  The contrib archive area contains supplemental packages intended to
>  work with the Debian distribution, but **which require software
>  outside of the distribution to either build or function**.
> 
>  Every package in contrib must comply with the DFSG.
> 
> 3. One test I've been taught to use to reason about free software is the
>Desert Island test [2] which starts by:
> [2] <http://people.debian.org/~bap/dfsg-faq.html>
> 
>  Imagine a castaway on a desert island with a solar-powered
>  computer.
> 
>   Obviously, software that are only frontends to unreproducible “cloud”
>   services do not pass the desert island test.
> 
> Dear candidates, do you think that libechonest [3] should be called free
> software? As it requires software outside of the distribution to
> function, do you think it should be moved to contrib? What about
> s3cmd [4] then?
> [3] <http://packages.qa.debian.org/libe/libechonest.html>
> [4] <http://packages.qa.debian.org/s/s3cmd.html>

Good question.  See also for example bug 681659.  I don't know why
pidgin-facebookchat would belong in section main while flashplugin-nonfree
would belong section contrib.  Both packages contain software that can freely
be redistributed but require software outside of the distribution to function.
Where to draw the line ?

> 
> Do you think that it's a fight that's worth fighting?

It's not about legal problems the Debian project could get in trouble with.
But it is related to one of the core goals of the Debian project.

Regards,

Bart Martens


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

Re: Ballot for leader2008

[Bart Martens]

On Sun, 2008-04-13 at 23:45 +0200, Josip Rodin wrote:
> -- 
>  2. That which causes joy or happiness.

Suggesting to vote for "Choice 2: John Doe 2" ? :)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The Debian Maintainers GR

[Bart Martens]

Hi aj,

Some parts feel very obvious to me.  Am I missing something?

On Thu, 2007-08-02 at 14:38 +1000, Anthony Towns wrote:
> At present, how do you find packages that have been packaged by non-DDs
> and uploaded with the minimal checks by a DD in order to review them,
> or just get a sense of how common it is?

The non-DD packager is identified by the "Maintainer:" field, and the
sponsors is identified by the signature.

> 
> With DMs, you check for uploads signed by a key in the DM keyring.

With sponsors you can check for uploads signed by a key in the Debian
Developers keyring.

> 
> At present, if you find someone doing a poor job as a non-DD maintainer
> or as a sponsor, and they reject suggestions on how to do better, what
> recourse do you have?

Suspending the upload right of the sponsor until the sponsor agrees to
do better.

> 
> With DMs, if you can get other DDs to agree with your analysis, you can
> pass it on to the DM keyring maintainers and have the non-DD maintainer's
> ability to upload removed, or provide evidence that stricter procedures
> for advocating DMs is necessary.

Without DMs, if you can get other DDs to agree with your analysis, you
can pass it on to the DPL and have the sponsor's ability to upload
suspended, or provide evidence that stricter procedures for sponsoring
is necessary.

> 
> At the moment, it's not possible to review if sponsors and non-DD
> maintainers are doing a good or a bad job on average, and its at best
> difficult even in specific cases. With the DM process as proposed, that
> becomes much easier

Anyone interested can make an overview of non-DD packagers and their
maintainers by scanning the "Maintainer:" fields and the package
signatures.

> : there's a public record of who's advocating who

There's currently a public record of who's sponsoring who.

> and why, 

As far as I know, the "why" part is currently not covered with
sponsoring.

> there's a chain of trust to the actual uploads, 

Introducing DM's uploading directly to unstable makes "the chain of
trust to the actual uploads" less safe.

> and there's
> the ability for negative reviews to actually result in some action.

No, DM's mistakes will already be in unstable and testing before
negative reviews by DD's are possible.  With sponsoring the negative
reviews by DD's happen before uploading to unstable.

> 
> As far as doing the same thing under NM is concerned, consider how
> you would review if the DAMs, FD or AMs are doing a good or a bad job,
> and what recourse you actually have if you think they're not.

No idea about that.  But the GR is not really about their work, is it.

I think that the way forward is to make existing procedures more
efficient, and not add more procedures.

Also, I think that a quick win could be to stop using the term "non-DD",
and instead calling all contributors "Debian Contributor" (DC).  That
could be made visible and official.  Such a DC can be a translator, a
packager, a bug fixer submitting patches to the bts, a release
manager :), a programmer writing code in svn or cvs, a bug triager just
tagging bugs and pinging people, ...  The information on the Debian
website about "joining Debian" could be modified to focus on becoming a
contributor instead of on becoming a DD via the NM queue.  I think that
the NM queue will become shorter and faster.  I'm sure that most DC's
will feel happy with the recognition of being an official DC, and don't
mind (or mind less) working via an active sponsor.  The term "non-DD"
sounds negative, almost insulting.  The term "Debian Contributor" is at
least honorable, and something to brag about. :)

Regards,

Bart Martens



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On the "Debian Maintainers" GR

[Bart Martens]

On Fri, 2007-07-27 at 16:24 +0200, Pierre Habouzit wrote:
> On Fri, Jul 27, 2007 at 01:48:52PM +0200, Bart Martens wrote:
> > On Fri, 2007-07-27 at 13:02 +0200, Holger Levsen wrote:
> > > On Friday 27 July 2007 12:22, Thijs Kinkhorst wrote:
> > > > As a subscriber to the debian-med list, I do not share your view of 
> > > > this.
> > > [...]
> > > > I therefore do not agree that your example is a valid one - rather, I 
> > > > think
> > > > teams/groups like debian-med are an excellent way to combine work of 
> > > > DD's
> > > > and non-DD's.
> > > 
> > > Sure. But why shouldnt trusted non-DDs not be able to upload their teams 
> > > packages? And a subscriber and active Debian Edu developer I think it 
> > > would 
> > > make complete sense and would be helpful, if certain non-DDs from our 
> > > team 
> > > (not all of them, but I have 2-3 in mind) could upload to Debian.
> > > 
> > > DDs are busy, are not available (working, traveling, broken hardware, 
> > > different timezones), and so on - why put more load on them without need?
> > 
> > I agree that some non-DD's simply deserve upload rights.
> 
>   I don't. I agree that some non-DD simply deserve to be fast tracked
> and be made DD in record times.
> 

You are right, that is what I meant, but I didn't write it. :)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: On the "Debian Maintainers" GR

[Bart Martens]

On Fri, 2007-07-27 at 13:02 +0200, Holger Levsen wrote:
> On Friday 27 July 2007 12:22, Thijs Kinkhorst wrote:
> > As a subscriber to the debian-med list, I do not share your view of this.
> [...]
> > I therefore do not agree that your example is a valid one - rather, I think
> > teams/groups like debian-med are an excellent way to combine work of DD's
> > and non-DD's.
> 
> Sure. But why shouldnt trusted non-DDs not be able to upload their teams 
> packages? And a subscriber and active Debian Edu developer I think it would 
> make complete sense and would be helpful, if certain non-DDs from our team 
> (not all of them, but I have 2-3 in mind) could upload to Debian.
> 
> DDs are busy, are not available (working, traveling, broken hardware, 
> different timezones), and so on - why put more load on them without need?

I agree that some non-DD's simply deserve upload rights.  I also agree
that some of those non-DD's waste time asking around for an upload.  But
I also think that the Debian Project must be very careful with selecting
the people with upload rights, because an upload to Unstable is in fact
an immediate release to many systems using Debian Unstable and a 10 days
delayed release to all Debian Testing machines.  This is not the case
with contributions in svn or cvs; no direct impact.

Another aspect if this debate about giving more people upload access
sooner, is that the more the Debian Project becomes a large community
based project, the less professional users (think large companies like
banks) want to trust the Debian Project as a decent and trustworthy
GNU/Linux distribution.  Strict control of what gets shipped with Debian
with high quality standards is essential to compete with commercial
distros like Red Hat in the market of big users/customers.

Part of the debate about the NM queue and about giving upload rights to
non-DD's is in my opinion related with the way the Debian Project
rewards the non-DD contributions.  I think that contributors actively
providing patches for bugs, do translations work, maintain website
contents, do package maintenance via svn or cvs, ..., or a combination
of these tasks, should be considered formally and officially worthy
"Debian contributors" or "Debian maintainers" or some other cool title.
Sponsors should congratulate new packagers for their first accepted
package with comments like "great, you're now an official Debian
packager, congratulations".  The difference with full DD's should be
moved to the background so that less people desperately want to become
full DD, just to get the recognition of being a worthy contributor to
Debian.

So I think that I will probably vote "further discussion" for the GR.  I
really worry about the quality of what gets uploaded to Unstable if
non-DD's get upload rights more easily.  No offence meant to anyone in
particular ; I know that some non-DD's simply deserve upload rights.

Regards,

Bart Martens



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal: GR to deal with effects of a personal dispute

[Bart Martens]

On Thu, 2007-05-31 at 10:02 +0100, MJ Ray wrote:
> Bart Martens <[EMAIL PROTECTED]> wrote: [...]
> > My point is that the Debian project has no responsibility in the
> > mentioned personal dispute, so the Debian project should not apologise
> > for not resolving that dispute in the name of all DD's. [...]
> 
> I disagree strongly with that.  The project as a whole has some
> responsibility for letting this continue in this way.

I see a difference between the personal dispute and the tolerance of
mailing list flooding.  The Debian project might be responsible for the
latter, but not the former.

But it's OK to disagree with me, really. :)



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

Re: Proposal: GR to deal with effects of a personal dispute

[Bart Martens]

On Wed, 2007-05-30 at 20:06 +0100, MJ Ray wrote:
> Bart Martens <[EMAIL PROTECTED]> wrote: [...]
> > GR's are, in my opinion, meant to handle more general decisions, like
> > describing to what extent the listmasters are authorized to [silently]
> > take actions for keeping good order on the mailing lists, for what
> > actions the listmasters need the DPL's approval, and similar guidelines.
> 
> That's one opinion, but it's not what GRs can currently do.  If that
> bothers anyone enough, amend the constitution instead of noisily
> refusing to support every GR that does stuff that GRs aren't "meant"
> to do.

It feels OK to me to express my opinion on debian-vote about this GR
proposal and about what GR's should be used for.

> 
> > > 7. We apologise publicly to everyone for not resolving this dispute
> >
> > I don't want to apologize in public to everyone for not having done any
> > publicly visible attempt to resolve this dispute.
> 
> Cool.  This proposal doesn't do that.  It apolgises for not resolving
> it, not for not attempting.  The bit you snipped even thanks everyone
> who has attempted, whether publicly-visible or not!

My point is that the Debian project has no responsibility in the
mentioned personal dispute, so the Debian project should not apologise
for not resolving that dispute in the name of all DD's.

> 
> > So I will not support this GR proposal.  Maybe I might support a GR that
> > introduces practical guidelines for the listmasters and the DPL about
> > taking immediate actions to keep order on the mailing lists.
> 
> I think it's very difficult to issue good practical guidelines, as it
> depends on humanity and too many variables.  What is acceptable on
> debian-esperanto may be too offensive on debian-i18n, for example.

I agree with that.  This seems to confirm that we cannot micro-manage
the mailing lists by GR's.  The listmasters need some room to make
immediate decisions to keep order on the lists, and those decisions may
differ depending on the context.

Regards,

Bart Martens



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

Re: Proposal: GR to deal with effects of a personal dispute

[Bart Martens]

On Wed, 2007-05-30 at 11:50 +0100, MJ Ray wrote:
> -  START OF PROPOSAL 
> 
> We resolve that:-
> 
> 1. Sven Luther is suspended from all debian lists for a year, 

Such things should not be handled by a GR.

GR's are, in my opinion, meant to handle more general decisions, like
describing to what extent the listmasters are authorized to [silently]
take actions for keeping good order on the mailing lists, for what
actions the listmasters need the DPL's approval, and similar guidelines.

> 
> 7. We apologise publicly to everyone for not resolving this dispute

I don't want to apologize in public to everyone for not having done any
publicly visible attempt to resolve this dispute.

So I will not support this GR proposal.  Maybe I might support a GR that
introduces practical guidelines for the listmasters and the DPL about
taking immediate actions to keep order on the mailing lists.

Regards,

Bart Martens



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

Re: GR PROPOSAL : The Debian Infrastructure is owned by the whole Debian project, and not a few select individuals.

[Bart Martens]

On Sun, 2007-05-27 at 17:30 +0200, Sven Luther wrote:
> By this resolution, the Debian Project resolves that :
> 
> = START OF THE GR text =
>   - No part of the Debian Infrastructure, is the sole province of a few select
> Debian Developpers, but is under the responsability and ownership of the
> project as a whole, and thus of each individual Debian Developper.
> 
>   - The Debian Instrastructure, includes, but is not limited to, the different
> Debian owned machines, the autobuilders, the archive, the mailing lists,
> the different source repositories, hosted at alioth or somewhere else, the
> core debian related projects at alioth or elsewhere, the mailing lists,
> the irc channels, the different teams, ...
> 
>   - As thus, no Debian Developper can be negated access of a ressource of the
> Debian Infrastructure. It is acceptable, for security reasons, that not
> every Debian Developper has access to some of these ressources, but if he
> request such an access, he should obtain it in a timely fashion (no less
> than two weeks).
> =  END OF THE GR text  =

I don't support this GR proposal because I want it to remain possible to
deny DD's access to some parts of Debian.



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

Re: Sven, GNAA, Dunc-Tank, and all the other distractions

[Bart Martens]

On Sat, 2007-05-12 at 00:57 +0100, Ben Hutchings wrote:
> I'm don't think we're doing so badly.
> 
> Ben.
> 

I agree with that.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A question to the Debian community ... (Was: Question for Sam Hocevar "Gay Nigger Association of America")

[Bart Martens]

On Thu, 2007-05-10 at 03:01 -0500, Peter Samuelson wrote:
> [Sven Luther]
> > So, you too, believe that what was done to me was acceptable, that
> > everything is justifiable
> 
> Stop it, Sven, stop it.  This thread is about Sam Hocevar and GNAA.  It
> is not about Sven Luther.  We have had lots of other threads about Sven
> Luther.  Can you please let us have just _one_ thread that is about
> something else?  If that's not too much to ask.

Lol!



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]