On Mon, Aug 22, 2005 at 11:51:26AM +0200, Peter 'p2' De Schrijver wrote: > > I don't agree with that interpretation of "arch-specific", and neither > > do the maintainers of the Packages-arch-specific list AFAICT, so please > > stop trying to use creative interpretations of people's words to torpedo > > the proposal that porters should be accountable for their ports. > I have no idea what you're trying to say here. I'm saying that it is my impression that you are not making a good-faith effort to work with the release team to ensure that Debian's ports are of high quality and that unmaintained ports don't cause release delays. You are dismissive of requirements that are currently met by all the ports, as if these are immutable truths and we're all stupid for suggesting they should be spelled out; you argue definitions in the proposal, rather than accepting clarifications of meaning when offered or offering suggestions to improve the wording; and you reject any requirements that would cause more work for porting teams. If you want to be an asshole about this, that's your choice, but don't be surprised when your "input" is ignored. > > > > well, if the package is bogus from the language usage, than that's not > > > > the porters problem (but how often did that hit exactly one arch?). If > > > > the arch can't e.g. use C++-packages because it doesn't have the > > > > toolchain for c++, I think that is the porters problem (just to give an > > > > possible example). > > > I have seen multiple examples of builds failing because the testsuite or > > > a buildtime generated tool crashed on a specific arch due to bad coding > > > practices. > > And in some cases these are so severe that the package should > > unequivocally be ignored for that architecture. In other cases, it is > > incumbent upon porters to, y'know, *port*. If we're going to give a > > port a free pass every time some base package, or package that's > > installed as part of the desktop task (for example) manages to include > > code that's not portable, then I don't see any point at all in treating > > these as release architectures to begin with, because at that point > > they're *not* shipping the same OS that the other architectures are. > What did you want to say here ? "An architecture that doesn't have porters willing to make sure the port ships as close as possible to the same system as all other ports should not be a release candidate architecture." -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature