Re: [DRAFT] resolving DFSG violations - Debian

This is a discussion on Re: [DRAFT] resolving DFSG violations - Debian ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Re: [DRAFT] resolving DFSG violations

  1. Re: [DRAFT] resolving DFSG violations

    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 madcoder@debian.org
    OOO http://www.madism.org

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkj+HnsACgkQvGr7W6Hudhx1vACfYVXBWmJ8mR NJWJ/XOG0FFIgu
    NkIAoKlX4G3z78JQiXXcpFTKkQHjBcLc
    =2l/4
    -----END PGP SIGNATURE-----


  2. Re: [DRAFT] resolving DFSG violations

    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 madcoder@debian.org
    OOO http://www.madism.org

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkj/Mb4ACgkQvGr7W6HudhwPcACgpPkXPCQ7uZGlxSYVV/zrMrID
    BhYAoIlQZbd98PBt7rPz9A4CFdVC8nmF
    =Gpe8
    -----END PGP SIGNATURE-----


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

    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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: [DRAFT] resolving DFSG violations

    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 debian-vote-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: [DRAFT] resolving DFSG violations

    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 ****ing 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. **** 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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    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/
    slangasek@ubuntu.com vorlon@debian.org


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    Steve Langasek 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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    Reinhard Tartler 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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

    On Fri, 2008-10-24 at 10:57 +0300, Kalle Kivimaa wrote:
    > Reinhard Tartler 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 debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: [DRAFT] resolving DFSG violations

    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.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBJAaN0rSla4ddfhTMRAgjPAKCyGPkh2nwxFJ+mMSsP0z 3mpmv2ZACeOr0d
    CrWhBgKc6rc7HFiwHdvFon4=
    =+a9V
    -----END PGP SIGNATURE-----


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

    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 Raphal
    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-proje.../msg00017.html
    4. http://lists.debian.org/debian-proje.../msg00032.html
    5. http://lists.debian.org/debian-devel.../msg00009.html
    --
    Thomas Viehmann, http://thomas.viehmann.net/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread