Hi, > > > Bogus requirement. At the moment we have less then 1 s390 buildd for example. > > "machine" translates with partition btw - though the two different > partitions should be in different physical locations, for obvious > reasons. Yes, we want a redundancy for good reasons. > Which is very arbitrary to me, machine to me means physical box with hardware and software doing stuff. So this requirement is very much arbitrary and without any reasonable foundation. > > > > Overall: > > > - must have successfully compiled 98% of the archive's source > > > (excluding arch-specific packages) > > > Useless requirement. Less then 98% of the archive may be useful for the > > architecture > > > (excluding arch-specific packages) > that's there for a reason > Except that arch-specific package has always meant 'contains arch specific code', not 'does not make sense to run on this arch'. So this clause doesn't cover all cases. > > and it cannot be the porters problem that packages violate > > language rules and therefore fail to compile or work on some arch. > > 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. > > > - must have a working, tested installer > > > Trivial. debootstrap does that. > > How do you boot the system to run debootstrap? (Note: the answer > "gentoo" or "Windows" is not what I want to hear :) It is agreed that > this isn't a too high barrier, but - well, we should still require it. > If no (potential) port has an issue with that, it's even better. > You boot from an existing rootfs image, just like you boot from your existing install media. > > > > - security team, DSA, and release team must not veto inclusion > > > Arbitrary veto power. This requirement is unacceptable for me. Noone > > should be allowed to just ignore other peoples work within the project. > > Please read Wouter's explanation. There was really very much discussion > on exactly this. > I did. And I still consider it unacceptable. I see no reason for having this sort of far reaching veto powers. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature