Manoj Srivastava <[EMAIL PROTECTED]> writes: > Is a developer merely a glorified packager, who mechanically > packages software, and shuffles off problems with the package > blindly upstream? I hope not, and I have long rejected this narrow > view of what a developer is.
Ahem, that is a strawman if ever I saw one. :) > I see a developer as an active participant in the improvement > of the software they maintain (we are maintainers, after all, not > packagers); who actively ensure the package integrates into the > Debian system. Of course. > A maintainer has always made changes, accepted by upstream or > not, to integrate the software into the set of Debian standards. That is her duty, yes. > As a project, we seem to have committed to supporting > multiple architectures. As maintainers, this means that we be > willing to accept modifications from our fellow developers working > on other arches (note I do not presuppose that all maintainers be > able and willing to port things to all 11 arches single handedly). > Indeed, I doubt if *ANY* upstream authors really have access to 11 > architectures, and test on them, with the exception of perhaps the > Linux kernel; the fact that we have 11 supported arches is because > the Debian project stood up to be counted. That's a fine point, but see below for some cases of exceptions. > Agreeing in principle, though nice, is irrelevant unless the > nitty gritty underpinning of that decision are also respected. And > that includes giving all architectures a chance at running the > software you maintain. Well, I guess I keep coming back to the example of the unportable software. This is the software rather mentioned in the DDR passage cited -- it has serious technical reasons why it's only available for a given port. I think we all agree there's a line somewhere, a fuzzy line, on what ought to be arch = any and what should be restricted. Lets get down to cases in the hopes that it will help us refine the principle underlying where this line generally is to be found. * jade A package I used to maintain; rather non-portable C++ when I had it. Dead upstream. I elected to set arch = any because I thought it was important for all arches to have this so they could build SGML/XML documentation. I didn't have to do the porting, but I did have to integrate patches -- and it wasn't very fun. But that was my choice, fine. The porters were very kind and sent patches, I integrated them, and later someone more knowledgable in C++ took over the package, it's now available for all arches. Success story. Is there a principle to arch any here? I guess I would argue that jade was dead upstream and wasn't really inherently unportable -- it just had some character width assumptions and build problems with other arches. So if there's a principled answer, I guess it would be that I would say that just because the software has some 32-bit vs 64-bit int problems, that doesn't mean it has deep inherent porting issues, and thus it should be ported. * cmucl Inherently unportable (the underlying engine that translates lisp to assembly code, called "python", is very unportable, is not even in ANSI C). Moreover, the porting effort for this has forked into a different project, SBCL. Current Debian package is Architecture: any. I think this is questionable. This will always only be available for i386. I think it's worthwhile to have the architecture line reflect this so the porters don't see this as a pending problem. Of course, they probably already ignore this one. * sbcl A fork of cmucl rewritting in ANSI C and reworked to be more portable. Even so, requires *serious* effort to port to different CPU instruction sets. Current Arch line: Architecture: alpha i386 sparc powerpc mips mipsel In this case, you see, the maintainer is tracking the set of ports explicitly supported upstream, until upstream adds support for the other arches. I think this is fine. The maintainer is basically telling users of the 'ARM' arch, e.g., to work with upstream to get patches integrated if they want to see this supported. I think it would also be fine to set Architecture: any, in the expectation that sbcl will eventually support all architectures. I'll hold off on any conclusion with this until people respond to my cases here, agreeing or disagreeing with my logic. -- ...Adam Di Carlo..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/>
