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

Re: vancouver revisited



Hi,

* Peter 'p2' De Schrijver (p2@mind.be) [050821 22:39]:
> Some comments :
> > - must include basic UNIX functionality

> Whatever that may mean

there are processes. there is dns name resolution. there is networking.
there is chroot. etc. Just really basic things (and, of course, none of
the ports currently in testing fails this).


> > - 5 developers must send in a signed request for the addition
> > - must demonstrate to have at least 50 users
> > - must be able to keep up with unstable with 2 buildd machines, and must
> >   have one redundant buildd machine

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


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

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


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


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



Cheers,
Andi



Reply to: