[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vancouver revisited


> > 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

> > > - 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.


Peter (p2).

Attachment: signature.asc
Description: Digital signature

Reply to: