On Wed, Mar 16, 2005 at 12:09:08PM +1000, Anthony Towns wrote:
> Ola Lundqvist wrote:
> >>- the release architecture must have N+1 buildds where N is the number
> >> required to keep up with the volume of uploaded packages
> >Sane.
> >>- the value of N above must not be > 2
> >Testing related. I do not really understand why this is a problem but
> >somebody may be able to tell.
>
> Uh, no, it's not testing related at all. By the time packages are
> considered for testing, it's completely irrelevant how or where they
> were built.
Thanks for the information. I picked that up from some other thread of
this discussion. And I should have put a '?' after testing related. :)
> The reason for the N = {1,2} requirement is so that the buildds can be
> maintained by Debian, which means that they can be promptly fixed for
> system-wide problems, and which means access to them can be controlled,
> rather than opening up users of that architecture to exploits should a
> random disgruntled non-developer have access to the machine and decide
> to abuse it, eg.
Sounds reasonable.
> >>- the Debian System Administrators (DSA) must be willing to support
> >> debian.org machine(s) of that architecture
> >I assume people can help with this too, or?
>
> Doing DSA work involves more than having root on a random box on the
> internet. It's a specific task, not something that every developer is
> already doing under a different title.
I can understand this, but I still think that people may be able to help
here. I think there are quite a lot of experienced developers/system admins
out there that can help with this. But you probably already know that.
> >>We project that applying these rules for etch will reduce the set of
> >>candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
> >>and amd64 -- which will be added after sarge's release when mirror space
> >>is freed up by moving the other architectures to scc.debian.org).
> >I'm missing sparc here, but that is only me... But even if that one is
> >included the drop will probably help some.
>
> Personally, I'd like to see sparc, alpha and/or potentially arm and s390
> stick around as release architectures too; mostly that would require
> them to be actively maintaining their architecture and trying to compete
> with i386 for being better supported, which isn't something I've seen
> happen for years now. Which is disappointing, because sparc at least was
> beating the pants off everyone else (though still behind i386) a while ago.
>
> I haven't seen much evidence of hppa, mips, mipsel or m68k coming
> anywhere near balancing the cost/benefit tradeoff for sticking around in
> the release; but there are listed criteria now, if they're the
> architectures are that valuable, I don't see any reasons for porters to
> be complaining instead of demonstrating they can meet or surpass all of
> them, or mitigate any concerns anyone might have for the others.
>
> >>- there must be a sufficient user base to justify inclusion on all
> >> mirrors, defined as 10% of downloads over a sampled set of mirrors
> >This as stated before, probably a too tight limit. I think 10% of the
> >downloads if i386 is excluded is a better metric. :)
>
> 10% of downloads if i386 is excluded is about 0.5% of downloads. So, uh,
> no. powerpc's pretty consistently around 2%, ia64 and others are at 1%
> or below.
I may misunderstand the criteria here, or you misunderstood me.
If we do not calculate the downloads from i386, which I assume is the major
part ( like 90-95% ? ). The total amount of downloads is decresed with
about 90-95%. Ahh this is really tricky to explain. Math is better. :)
T := total downloads for all arches
I := total downloads for i386 arch
D := total downloads for all arches except i386 := T - I
i := total downloads for some other arch
If i/D > 0.1 then arch is accepted
if i/D < 0.1 then not
This rule is probably better than i/T as i386 is such a major portion of
the downloads. I do not think that any arch (more than i386) can pass
a 10% limit if i/T is used as measure.
I hope this was a bit more clear. :)
> >>- binary packages must be built from the unmodified Debian source
> >> (required, among other reasons, for license compliance)
> >This is a bit vauge. Is porting uploads possible?
>
> I don't understand why people are confused on this. If you want to
> upload a binary to the archive, you upload the source you used to build
> it as well. If you needed to modify the upstream source, your patch is
> included in the .diff.gz. If the package was already in the archive, you
> mail the patch to the maintainer, and if it's urgent, do an NMU.
>
> It's not anything subtle.
I think people may (at least I do) think about the possibility to upload
arch specific source uploads. I do not really think that is a perfect
solution but it may help in some specific circumstances. But ...
on the other hand it will cause a lot of problems with the current
structure. I'm not sure how to solve that either.
> >With these comments I will happily second this proposal.
>
> IMO, intelligent comments are far more useful than seconds.
Agreed. I just wanted to express my thoughts and tell that there are people
that actually like the basic ideas in the proposal. I think that was
lost in the discussion somewhere.
Best regards,
// Ola
> Cheers,
> aj
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
