* Manoj Srivastava [Mon, 20 Oct 2008 15:14:15 -0500]:
Hi,
> But developers are not the only infliences on your decision. You
> have agreed to abide by the social contract, have you not? That, too,
> should dictate how you act within your delegated role.
[...]
> There is nothing to feel betrayed by, all kinds of people make
> all kinds of mistakes, and I do not live in a perpetual feeling of
> victimization or betrayal.
[...]
> In other words, if the release team is allowing packages to
> violate the DFSG, one must prove something to the relese team (not sure
> what that is, exactly). Is it in dispute that non-free blobs that
> violate the DFSG actually violate the DFSG?
> Or does the release team need someone to quote the contitution
> and the social contrat to them? (I doubt that is the case, since the
> RM"s are mostly quite competent)
> Are you saying you want the project to show you that the SC is
> still relevant, by passing yet another GR?
> Please pardon my confusion, since you ought to be aware that
> English is not my first (or second) language.
> So, could you explain your view of the issue here, without
> bringing in feeling of betrayal, which I do not comprehend?
I agreed to abide by the social contract, but I happen to think that
these lenny-ignore tags at hand are acceptable in order to get a release
out, /and/ I also believe that a majority of the developers happens to
think the same (otherwise I wouldn't condone their use; I repeat: if I
thought most DDs would think they are not reasonable, I would not
approve of them even if they'd be reasonable to me).
I may as well be mistaken in this belief, so I'm open to being proved
wrong. To be proven, specifically, that the developers at large don't
want these lenny-ignore tags applied. (That should answer your question
above.)
> I have no idea about how betrayal features here: I just believe
> that the decision to ignore these problems in Lenny fall beyond the
> powers given to delegates.
This is a very interesting point, actually. My opinion is that: (a) they
are a tool the release team should have, (b) the release team should not
drift from the project at large in their use, (c) as with every other
decision from a developer, they are always overrideable by a GR.
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Dar Williams - This Was Pompeii
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
