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

Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting

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 debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact 
> listmaster@lists.debian.org

 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Annebergsslingan 37      \
|  opal@lysator.liu.se                 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 /

Reply to: