Re: [DRAFT] resolving DFSG violations

classic Classic list List threaded Threaded
137 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Manoj Srivastava
On Tue, Oct 21 2008, Pierre Habouzit wrote:


> Though, when this software is central to all Debian (as the kernel is,
> or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
> then as it's a long and slow work to either prune the firmware, or deal
> with the copyright holders to relicense (and mesa has made it, proof
> that it's possible, but it needed like 2 or 3 releases of Debian to do
> so !), the Release team acknowledge that progress has been made, and
> tags the bugs $suite-ignore.

        This is the part I am not comfortable with. I do not think the
 delegates have the powers to decide when enough progress has been made
 to violate a foundation document in our release.  Just like an
 individual developer does not have a right to decide to violate the
 DFSG in their work, I think the release team, which prepares the
 release, can do so unilaterally either (I did not vote for Bush).

        This is why my contention has been that the developer body, as a
 whole, has to be brought into the decision loop, like they have
 for the last two releases, and  make sure we, as a project, stand
 behind the decision, not just a few hapless RMs.

        So, I would like to see an option on the ballot that sates that
 we will release Lenny with known DFSG violations, we believe in the SC,
 but we also have to respect the needs of users, and we think progress
 is being made towards ensuring that the needs of our users can be met
 with free software in the future. I just do not think this is within
 delegate or individual developer powers.

        manoj

--
VMS must die!
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
On Tue, Oct 21, 2008 at 05:52:28PM +0000, Manoj Srivastava wrote:

> On Tue, Oct 21 2008, Pierre Habouzit wrote:
>
>
> > Though, when this software is central to all Debian (as the kernel is,
> > or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
> > then as it's a long and slow work to either prune the firmware, or deal
> > with the copyright holders to relicense (and mesa has made it, proof
> > that it's possible, but it needed like 2 or 3 releases of Debian to do
> > so !), the Release team acknowledge that progress has been made, and
> > tags the bugs $suite-ignore.
>
>         This is the part I am not comfortable with. I do not think the
>  delegates have the powers to decide when enough progress has been made
>  to violate a foundation document in our release.  Just like an
>  individual developer does not have a right to decide to violate the
>  DFSG in their work, I think the release team, which prepares the
>  release, can do so unilaterally either (I did not vote for Bush).
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.

FWIW you can query all the lenny-ignore bugs on the BTS, there arent a
lot, and check if you agree. Unlike Bush (and the reference is quite
offensive, really) we don't hide such matters, and we never said we're
not open to discussion.

BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
delegated for that (among other things).
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Thomas Bushnell, BSG-2
On Tue, 2008-10-21 at 20:24 +0200, Pierre Habouzit wrote:

> On Tue, Oct 21, 2008 at 05:52:28PM +0000, Manoj Srivastava wrote:
> >         This is the part I am not comfortable with. I do not think the
> >  delegates have the powers to decide when enough progress has been made
> >  to violate a foundation document in our release.  Just like an
> >  individual developer does not have a right to decide to violate the
> >  DFSG in their work, I think the release team, which prepares the
> >  release, can do so unilaterally either (I did not vote for Bush).
>
> And you're comfortable with ftp-master ruling DFSG-iness through NEW
> then ? I don't really see the difference.

I can't speak for Manoj, but for my own part, I have not seen any
evidence that ftp-master is letting things through NEW which are in
clear violation of the DFSG, so it doesn't come up.

> FWIW you can query all the lenny-ignore bugs on the BTS, there arent a
> lot, and check if you agree. Unlike Bush (and the reference is quite
> offensive, really) we don't hide such matters, and we never said we're
> not open to discussion.
>
> BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
> delegated for that (among other things).

So far, the release team has shown no awareness in this thread that
ignoring a technical RC bug is entirely different from ignoring a
violation of the core documents of the project.  Nobody is talking about
technical bugs, and it would be helpful if y'all stopped bringing them
up.

Thomas



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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Manoj Srivastava
In reply to this post by madcoder (Bugzilla)
On Tue, Oct 21 2008, Pierre Habouzit wrote:


> And you're comfortable with ftp-master ruling DFSG-iness through NEW
> then ? I don't really see the difference.

        I would be uncomoftable with ftp-masters willfully allowing DFSG
 violations in main without ratification from the project as a whole as
 well.


> BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
> delegated for that (among other things).

        Every developer has the right to manage their own bugs too. But
 they do not have the right to just downgrade or close bugs saying that
 their package has a DFSG violation. I think the same principle applies
 here.

        manoj
--
Silence is the element in which great things fashion themselves. Thomas
Carlyle
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
On Wed, Oct 22, 2008 at 01:15:55PM +0000, Manoj Srivastava wrote:
> On Tue, Oct 21 2008, Pierre Habouzit wrote:
>
>
> > And you're comfortable with ftp-master ruling DFSG-iness through NEW
> > then ? I don't really see the difference.
>
>         I would be uncomoftable with ftp-masters willfully allowing DFSG
>  violations in main without ratification from the project as a whole as
>  well.

I have no evidence they do, my point is they have the same power, and if
they do, it's silent. When a RM choses to ignore a bug it's completely
non-silent and easy to post-check[0].

Though technically, as every new kernel goes through NEW, they *did*.
They willfully allowed DFSG violations last time they accepted a kernel
(some of the bugs on firmwares predate the last passage through NEW I
think).

> > BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
> > delegated for that (among other things).
>
>         Every developer has the right to manage their own bugs too. But
>  they do not have the right to just downgrade or close bugs saying that
>  their package has a DFSG violation. I think the same principle applies
>  here.

At some point, someone has to decide. Doing a vote for each is
impractical. As our choice is _not_ silent, if someones (like usually
the reporter who _sees_ such tags happen) disagree, he can raise a
discussion. AFAICT it's what is happening currently, and it shows that
the system is sane and works. At some point if we want to scale, we have
to delegate, and it's just that.


  [0] http://bugs.debian.org/tag:lenny-ignore
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Raphael Hertzog-3
In reply to this post by Thomas Bushnell, BSG-2
On Tue, 21 Oct 2008, Thomas Bushnell BSG wrote:

> On Tue, 2008-10-21 at 20:24 +0200, Pierre Habouzit wrote:
> > On Tue, Oct 21, 2008 at 05:52:28PM +0000, Manoj Srivastava wrote:
> > >         This is the part I am not comfortable with. I do not think the
> > >  delegates have the powers to decide when enough progress has been made
> > >  to violate a foundation document in our release.  Just like an
> > >  individual developer does not have a right to decide to violate the
> > >  DFSG in their work, I think the release team, which prepares the
> > >  release, can do so unilaterally either (I did not vote for Bush).
> >
> > And you're comfortable with ftp-master ruling DFSG-iness through NEW
> > then ? I don't really see the difference.
>
> I can't speak for Manoj, but for my own part, I have not seen any
> evidence that ftp-master is letting things through NEW which are in
> clear violation of the DFSG, so it doesn't come up.

Every kernel upload changing the ABI goes through NEW.

Your lack of knowledge of Debian processes sucks (that means: you
annoy us (at least me) with your stance and the fanatic way you defend it
in public, please stop this and come back to more constructive
discussions).

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Reply | Threaded
Open this post in threaded view
|

DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Thomas Viehmann
Raphael Hertzog wrote:
> Every kernel upload changing the ABI goes through NEW.

The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware). Sure, the ftp team can make this into a stand-off,
but the situation is much less clear than e.g. when the ftp team had
openjdk-6 in NEW, which had its (known or discovered during the vetting)
DFSG problems fixed rather fast and before it entered the archive in
first place, thanks to the maintainer (Matthias) willing to get the bugs
fixed and thanks to a cooperative upstream.

So let's evaluate options other than rejecting:
As for the suggestions to move linux-2.6 to non-free (which, again,
would have required someone to upload that): The ftp team usually are
pretty ruthless about pulling stuff from main with problems if it
doesn't get fixed fast, but in the case of the kernel and glibc the
Social Contract's
  We will never make the system require the use of a non-free component.
puts a limit on what can be done: Aside from the additional work it
would cause to everyone (installer, ...) and the undesirable effect of
effectively forcing people to add non-free, moving stuff required for
running Debian into non-free seems shady from a Social Contract point of
view.
Note how the situation would be vastly different if we had a known-good
kernel package was somewhere in the archive (be it testing or unstable).

And about the options of fixing it or just insulting other people to fix
it I should note that the objection that finding a widely welcomed fix
involves work (on blob loaders) that someone interested in a free kernel
has no intrinsic motivation to do: A lot of tasks do that. I want a
release and when I ask the release team, they tell me to fix RC bugs in
stuff I personally don't care about one single bit. I don't get to yell
at the release team for that (though I do at the maintainers of RC buggy
packages possibly more than I should), but have the choice of working on
stuff or not. Claiming that "I want a release now and we could just
release, all the RC bugs are in packages I have no interest in" would be
openly preposterous and in the case of "I would work on freeing the
kernel of but finding something to make everyone happy involves making
the firmware loadable in non-free" thinly disguises the same sentiment
of "I'm not going to help unless it's 100% my way" in the disguise of a
taking a higher moral stance than everyone else. "Moral, das ist, wenn
man moralisch ist, versteht Er."

Kind regards

T.
--
Thomas Viehmann, http://thomas.viehmann.net/


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by Raphael Hertzog-3
On Thu, Oct 23, 2008 at 08:36:24AM +0200, Raphael Hertzog wrote:
>
> Every kernel upload changing the ABI goes through NEW.
>
> Your lack of knowledge of Debian processes sucks (that means: you
> annoy us (at least me) with your stance and the fanatic way you defend it
> in public, please stop this and come back to more constructive
> discussions).

And I take it that Thomas is supposed to take your attitude as an example
on how being constructive?

--
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Manoj Srivastava
In reply to this post by madcoder (Bugzilla)
On Wed, Oct 22 2008, Pierre Habouzit wrote:


> At some point, someone has to decide. Doing a vote for each is
> impractical. As our choice is _not_ silent, if someones (like usually
> the reporter who _sees_ such tags happen) disagree, he can raise a
> discussion. AFAICT it's what is happening currently, and it shows that
> the system is sane and works. At some point if we want to scale, we have
> to delegate, and it's just that.

        Look, I am not proposing we have a GR for every upload. I am
 saying that non-free bits in main are a bug. A serious bug. A RC
 bug. It is a big fucking deal. It comes to the core of what Debian is.

        Now, we know there are unknon bugs and known bugs in the
 archive, especially in Sid. Shit happens.  Bugs take time to fix. But
 releasing with DFSG violations should still be a big deal. It is not
 something that some delegate decides is OK to do. The project tands up,
 acknowledges we failed out users by not providing them a free operating
 system like we promised in the social contract, acknowledge that the
 SC is still what we would like to do, but we failed this time around,
 and, as a project, take responsibility for our failure.

        This is what we have done in the past, through GR's for Sarge
 and Etch. We should not become Blase about shipping non-free operating
 systems. It should not become common place.

        manoj
--
Ditat Deus. [God enriches]
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Manoj Srivastava
In reply to this post by Manoj Srivastava
On Thu, Oct 23 2008, martin f krafft wrote:

> It's all a matter of defining what your priorities are, which brings
> us back to the Social Contract, which says that these include:
>
>   - 100% freeness
>   - cater best to the interests of our users

        Frankly, this mindset infuriates me. It frames the discussion
 incorrectly, it implies that freeness and user interest are at
 odds. Logically, it aargues that Windows is the best for users, since
 it caters to newbies, and is not free-  and since the implication is
 that freedom can be taken too far, allowing the users freedom to see
 movies legally, to use MS office and photoshop legally might triump the
 new fangled linux thingy.

        No. Freedom is in the long term best interests of the users. We
 allow people to use non-free stuff, yes -- but we do so not by
 tainting main, but by putting these tools to help the unfortunate
 folks who cannot take advantage of a free operating system.
 

        The same goes for people who are complaining oabout advocates
 of the social contract and libre software, calling them folks who do
 not care for users. I contend that people who stuff main with non-free
 stuff _are_ the ones acting against the interests of the suers in the
 long term, since freedom is the gift that Debian started out trying to
 give users.

        Why is not putting non-free firmware in non-free not the right
 thing to do? Why is trying to create a 100% free distribution, as our SC
 states, supposed ot be the dark side? I hope the few loud voices acting
 against the interests of the users by trying to prevent Debian from
 providing them a free operating system are indeed few.

        manoj
--
The beauty of a pun is in the "Oy!" of the beholder.
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Ean Schuessler-2
----- "Manoj Srivastava" <[hidden email]> wrote:

> On Thu, Oct 23 2008, martin f krafft wrote:
>
> > It's all a matter of defining what your priorities are, which brings
> > us back to the Social Contract, which says that these include:
> >
> >   - 100% freeness
> >   - cater best to the interests of our users
>
>         Frankly, this mindset infuriates me. It frames the discussion
>  incorrectly, it implies that freeness and user interest are at
>  odds. Logically, it aargues that Windows is the best for users, since
>  it caters to newbies, and is not free-  and since the implication is
>  that freedom can be taken too far, allowing the users freedom to see
>  movies legally, to use MS office and photoshop legally might triump the
>  new fangled linux thingy.

Its a lot like exercise. Its not convenient and its not easy but in the long run its a good idea.

I think the loud voices you are talking about are the same kind of loud, short-term gain voices that have caused so much trouble for the American economy. The point is that what is "best for the user" and what is "convenient or easy for the user" may not be the same thing. It is convenient and easy to eat fast food every day but it will make you fat and unhealthy.

So it is the same way with your computer. It is easy and convenient to give up freedom and control so you can watch a movie and play a cool 3D game, but you end up with your data trapped in an infrastructure controlled by the interests of others.

Now, breaking the law to keep control... I don't know how we advocate that. That's a harder question. Without law the whole notion of copyright is farcical and the DFSG becomes largely meaningless unless we are looking to some kind of "higher law". Not clear how that works.

--
Debian, choice of a GNU generation.


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Thilo Six
In reply to this post by Manoj Srivastava
Manoj Srivastava wrote the following on 23.10.2008 19:06


<- *snip* ->


>         Look, I am not proposing we have a GR for every upload. I am
>  saying that non-free bits in main are a bug. A serious bug. A RC
>  bug. It is a big fucking deal. It comes to the core of what Debian is.
>
>         Now, we know there are unknon bugs and known bugs in the
>  archive, especially in Sid. Shit happens.  Bugs take time to fix. But
>  releasing with DFSG violations should still be a big deal. It is not
>  something that some delegate decides is OK to do.

manoj
 who has not yet switched to the free drivers for nvidia cards yet


<- *snip* ->



--
bye Thilo

key: 0x4A411E09


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

Reply | Threaded
Open this post in threaded view
|

Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Steve Langasek
In reply to this post by Thomas Viehmann
On Thu, Oct 23, 2008 at 09:44:33AM +0200, Thomas Viehmann wrote:
> Raphael Hertzog wrote:
> > Every kernel upload changing the ABI goes through NEW.

> The typical situation here is that code that has the same set of DFSG
> bugs is already in place and so it is questionable of what a reject
> really achieves (i.e. does the archive become more DFSG-compliant or
> not) and quite typically fixes some RC bugs (not always trashing
> people's hardware).

This does not seem to be a position universally held by the ftp team, given
that a library I uploaded to binary NEW ths summer for a
release-team-approved transition was rejected over a source-only issue of
not mentioning in debian/copyright a pre-existing user guide not shipped in
any of the binary packages.  Or is it only kernel DFSG-compliance bugs that
get ignored in binary NEW, while all the other nitpicky checks are grounds
for a package reject?

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]


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

Reply | Threaded
Open this post in threaded view
|

Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Reinhard Tartler-5
Steve Langasek <[hidden email]> writes:

>> The typical situation here is that code that has the same set of DFSG
>> bugs is already in place and so it is questionable of what a reject
>> really achieves (i.e. does the archive become more DFSG-compliant or
>> not) and quite typically fixes some RC bugs (not always trashing
>> people's hardware).
>
> This does not seem to be a position universally held by the ftp team

What is the designated way for escalating a dispute like this with
ftp-master?

With "Like this" I mean packages that have been held back in NEW for a
very long time without response or REJECTED with an reason not
acceptable to the maintainer? Does mediating this kind of issues fall
under the authority of the TC, or should they be escalated rather to the
DPL?


--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Reply | Threaded
Open this post in threaded view
|

Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Kalle Kivimaa
Reinhard Tartler <[hidden email]> writes:
> With "Like this" I mean packages that have been held back in NEW for a
> very long time without response or REJECTED with an reason not
> acceptable to the maintainer? Does mediating this kind of issues fall
> under the authority of the TC, or should they be escalated rather to the
> DPL?

Well, if a package is in NEW for a long time, that's something that
really cannot be mediated, as it probably means that none of the
ftpmasters (or assistants) have had the time to look into it (meaning
it is very likely a very complex package with licensing issues), and
no authority in Debian can force any project member to do work the
member doesn't want to do.

If a package is REJECTED with a reason the maintainer thinks is
invalid, I think the first step should be to tell the ftpmaster (as a
group) the reasons. It is always possible that a ftpmaster (as a
person) has made a mistake.

--
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*           PGP public key available @ http://www.iki.fi/killer           *


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

Reply | Threaded
Open this post in threaded view
|

Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Martin Meredith
On Fri, 2008-10-24 at 10:57 +0300, Kalle Kivimaa wrote:

> Reinhard Tartler <[hidden email]> writes:
> > With "Like this" I mean packages that have been held back in NEW for a
> > very long time without response or REJECTED with an reason not
> > acceptable to the maintainer? Does mediating this kind of issues fall
> > under the authority of the TC, or should they be escalated rather to the
> > DPL?
>
> Well, if a package is in NEW for a long time, that's something that
> really cannot be mediated, as it probably means that none of the
> ftpmasters (or assistants) have had the time to look into it (meaning
> it is very likely a very complex package with licensing issues), and
> no authority in Debian can force any project member to do work the
> member doesn't want to do.
>
> If a package is REJECTED with a reason the maintainer thinks is
> invalid, I think the first step should be to tell the ftpmaster (as a
> group) the reasons. It is always possible that a ftpmaster (as a
> person) has made a mistake.

Indeed, I recently actually had this happen to me. An upload that I made
was rejected by an FTP Master (for convenience copies of code) - when I
pointed out to the FTP master the reason(s) why this was there (was
actually modified from upstream, debian didn't have the latest package,
the latest packages had huge API changes, etc etc) - he was happy to let
it through.


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Josselin Mouette
In reply to this post by Robert Millan
Le jeudi 23 octobre 2008 à 16:08 +0200, Robert Millan a écrit :
> On Thu, Oct 23, 2008 at 08:36:24AM +0200, Raphael Hertzog wrote:
> > Your lack of knowledge of Debian processes sucks (that means: you
> > annoy us (at least me) with your stance and the fanatic way you defend it
> > in public, please stop this and come back to more constructive
> > discussions).
>
> And I take it that Thomas is supposed to take your attitude as an example
> on how being constructive?

Maybe you should take it that even our favorite care bear is starting to
be pissed of by his behavior.

--
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...

Thomas Viehmann
In reply to this post by Steve Langasek
Hi Steve,

Steve Langasek wrote:

> On Thu, Oct 23, 2008 at 09:44:33AM +0200, Thomas Viehmann wrote:
>> Raphael Hertzog wrote:
>>> Every kernel upload changing the ABI goes through NEW.
>
>> The typical situation here is that code that has the same set of DFSG
>> bugs is already in place and so it is questionable of what a reject
>> really achieves (i.e. does the archive become more DFSG-compliant or
>> not) and quite typically fixes some RC bugs (not always trashing
>> people's hardware).
>
> This does not seem to be a position universally held by the ftp team, given
> that a library I uploaded to binary NEW ths summer for a
> release-team-approved transition was rejected over a source-only issue of
> not mentioning in debian/copyright a pre-existing user guide not shipped in
> any of the binary packages.  Or is it only kernel DFSG-compliance bugs that
> get ignored in binary NEW, while all the other nitpicky checks are grounds
> for a package reject?

Thank you for voicing your concern about inconsistencies you perceive in
the processing of NEW (note that "binary NEW" is not a separate location
to upload to). As with any manual process, particularly when handled by
several individuals, NEW processing will quite probably not be as
deterministic as one might wish, if only in the style of reject
messages, but probably also in cases that are not entirely clear. As you
may know, the ftp team is split into roles of ftp-master and
ftp-assistant, with myself being listed as assistant[1]. I have to
balance my (felt[2]) obligation to provide the project with information
about my work in that position with the fact that my this work
necessarily involves assessments that are neither necessarily uniform
nor binding for other members of the ftp team.
My comment you quote above gives some rationale of why I did choose to
add overrides for certain binaries added by linux-2.6, as Raphaël
pointed out I had. If you disagree with the descision of letting these
pass through NEW, I would be very happy to learn why I should not have
done so in your opinion.

Unfortunately, you do not give a reference, but if the upload of yours
that you have in mind is freetds[3], let me venture that perhaps the
considerations[4] I offered in the thread you started about it in July
might actually help to put both things into more context. I am sorry to
hear that these explanations were not satisfactory to you but must admit
that I may have overlooked previous indication of how they fall short.
Note that I do not agree with you on the issues you raise in[3], but you
surely have more information to add when you bring it up here.

If just did not want to pass the excellent chance of someone on the ftp
team actually posting something to add some flames about the pet grudge
you hold when I was trying to provide information to enable the project
at large to take into account the rationale of actions when deciding
whether to instruct the people to make better decisions than they do by
their own, that is very valuable to me, too. You could be even more
effective by CCing the DPL as surely he will be happy to correct
appointments his predecessor made precisely eight months ago on this
day[5] when they do not work out as expected.

Again, thank you for helping to improve Debian's processes by providing
your critique.

Kind regards

T.

1. http://www.debian.org/intro/organization
2. I had the impression that sometimes the ftp team is criticized as not
   operating transparently enough and think that it is reasonable that
   the project deserves explanations when they feel that a decision
   needs scrutiny.
3. http://lists.debian.org/debian-project/2008/07/msg00017.html
4. http://lists.debian.org/debian-project/2008/07/msg00032.html
5. http://lists.debian.org/debian-devel-announce/2008/02/msg00009.html
--
Thomas Viehmann, http://thomas.viehmann.net/


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Chris Bannister-4
In reply to this post by Ean Schuessler-2
On Thu, Oct 23, 2008 at 01:02:30PM -0500, Ean Schuessler wrote:
> Its a lot like exercise. Its not convenient and its not easy but in the long run its a good idea.

Nice pun! :)

--
Chris.
======
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
                                           -- Stephen F Roberts


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

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Steve Langasek
In reply to this post by Manoj Srivastava
On Thu, Oct 23, 2008 at 12:23:22PM -0500, Manoj Srivastava wrote:
> On Thu, Oct 23 2008, martin f krafft wrote:

> > It's all a matter of defining what your priorities are, which brings
> > us back to the Social Contract, which says that these include:

> >   - 100% freeness
> >   - cater best to the interests of our users

>         Frankly, this mindset infuriates me. It frames the discussion
>  incorrectly, it implies that freeness and user interest are at
>  odds.

No, it acknowledges that freeness and user interest are *sometimes* at
odds, and leaves it up to humans with faculties of reason to sort out which
of these two competing factors takes precedence in any given situation.

Otherwise, it might as well have just said "Our priority is our users"; if
you believe that what's best for free software is *always* what's best for
our users, and that what's best for our users is to use only free software,
then there's no need to spell this out as two *separate* priorities, right?

For users whose world is not circumscribed by the boundaries of the Debian
project, it is often the case that their short-term needs cannot be
satisfied by strictly free-software solutions.  To demand, then, that users
make do with Free Software when it doesn't meet their needs is
self-defeating: it denies us the support of users who are potentially
sympathetic to the principles of Free Software, and it denies them the use
of the best OS on the planet.

To forestall the inevitable strawmen, I'll say plainly that I am *not*
arguing that this justifies including non-free software in Debian proper.
What I *am* arguing is that we are called by the Social Contract to help
ensure Debian's continued utility to the general population, because if
nothing else, that's where we find the next generations of developers who
will keep our project alive.  This doesn't mean we should all drop what
we're doing and work on the firmware issue; but at the very least,
developers shouldn't be sanguine about proposing the outright removal of
firmware blobs, with no support for loading them from non-free, as a
"solution".

>         The same goes for people who are complaining oabout advocates
>  of the social contract and libre software, calling them folks who do
>  not care for users. I contend that people who stuff main with non-free
>  stuff _are_ the ones acting against the interests of the users in the
>  long term,

It's pretty insulting to suggest that there is a non-zero set of developers
who have been "stuffing" non-free stuff into main, particularly when the
very kernel team that's being maligned by this implication is the same group
that has already done the heavy lifting of as much of the sourceless
firmware removal as we've achieved so far.

>         Why is not putting non-free firmware in non-free not the right
>  thing to do?

It is the right thing to do; and while I know there are people that
disagree, I haven't seen anyone in *this thread* disagree with that.  But
there are lots of other things that are "right" to do, and not all of them
are possible to achieve at the same time with limited resources.  Is it
still the Right Thing to remove non-free firmware if we don't also make it
possible to load it from non-free at the same time?  Is it the Right Thing
to delay the next release indefinitely while the firmware problems are
sorted out?

Right now, I suspect the right thing to do might be for me to abandon this
thread and go fix some bugs instead.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[hidden email]                                     [hidden email]


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

1234 ... 7