Hi, I am not even trying to comprehend where these rules come from, or what their sanity is. I am just going to accept whatever comes out of the Debian cabal as long as I can morally accept it.
At 16 Mar 2005 11:04:39 -0800, Thomas Bushnell BSG wrote: > 1. the architecture must be freely usable (i.e., without NDAs) Ok. > 2. the architecture must be able to run a buildd 24/7 sustained > (without crashing) Does this mean eternally, or only for one week? Who is going to verify this? If we use a slow machine with lots of memory, running for one week will be fine, if certain precautions are taken (enough disk space and ogi's ext2, or excluding certain packages that can't be built within 2 GB). If you use a fast machine, it won't work, because a fast machine hits the bugs and races faster. Mach just crashes at some point with zalloc failures. I have no information about this bug, and have no inclincation to collect it. > 3. the architecture must have an actual, running, working buildd We had this before, it's possible. People are working on setting it up again. > 4. the port must include basic unix functionality, e.g resolving > DNS names and firewalling The firewalling requirement was specifically put in there for us, I suppose. AJ was quite upset when I told him we don't have it (years ago). The people asking for this seem to think that having a working firewall is some kind of proof of something, I don't know what. They may or may not realize that the Hurd does not make any kinds of security claims at this point (the code base is not audited, and we actually know about some glaring security problems, so a firewall is pretty down the list for me). In any case, I guess it would be possible to enable ipchains or iptables or whatever we have in our pfinet and export the Linux ioctl interface to configure it in pfinet. Some coding work, for sure, but nothing substantial, unless ipchains/iptables needs some kind of magic we don't have in our glued pfinet. Nobdoy is working on it, though (and don't look at me ;). > 5. binary packages must be built from the unmodified Debian source > (required, among other reasons, for license compliance) That was always a requirement. > 6. binaries for the proposed architecture must have been built and signed > by official Debian developers Ditto. This says nothing about the hardware and where it is located. I am reasonably sure that many Debian machines are located at environments which are not exclusively controlled by Debian maintainers, but by trusted third parties. > 7. the architecture must have successfully compiled 50% of the archive's > source (excluding architecture-specific packages) This assumes a definition of "architecture-specific". I suspect it's going to be based on the Architecture: field of the packages, which would be wrong, as some packages may not be buildable yet but will be when we implemented a certain feature, or when it is ported. It doesn't help that Debian source packages suck in all the dependencies for every silly feature a package got. I suggest that this definition allows for the port maintainers to build their own "architecture-specific" exclusion list, and then base the numbers on that. But even then I suggest to just reject this rule. The software in Debian is heavily biased towards GNU/Linux. That said, last time I was doing the buildd stuff, I think we had something in the 30% range or so... > 8. 5 developers who will use or work on the port must send in > signed requests for its addition Trivial. We have many more than that (not all active all the time, but still). > 9. the port must demonstrate that they have at least 50 users Well, we surely can find 50 people who say they are using Debian GNU/Hurd. > These are not cast into stone, but we should expect something like > this to become reality I think. I am expecting everything from the Debian cabal. Nothing will surprise me. ;) Thanks, Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
