Re: Proposal to replace/extend current armhf builders
> > I think we need to bash out some criteria for deciding during the
> > mini-debconf. i.e deciding how we decide (or just make a decision if
> > possible).
> Better to decide now rather than wait for the perfect solution next
> year (which might have other problems other than price). Better is
> Good's worst enemy.
Wearing my armel buildd maintainer hat, I don't feel the same urgency
as you seem to have - perhaps that's because the armel buildd'd are less
ram-starved than the locos?
> > e.g hold out for server-grade kit for a while - if so how long? (0
> > months, 3 months, 6months, longer?)
> If it was a vote, I'd say get some cheap hardware now to replace the
> current builders, say costing under an absolute limit of 1000GBP
> (total: disks, boards, cases, PSU, multiserial terminals, etc). That
> might even get lower if we accept the Nitrogen6X offer. And reevaluate
> the situation in 12 months when arm server class becomes available
> (arm64 or arm32).
One thing I'd like to avoid is growing the diversity of buildd's we
have. If we have many different buildd hardware, each of buildd
classes needs different kind of maintainence. So when add a new type
of hw for buildd's, it should go in tandem of getting rid of another
type of hw.
So if we go with nitrogenx 2GB, are we ready to get rid of locos?
> > Is debian kernel an absolute requirement, or are we prepared to risk a
> > custom kernel if we think it'll only be for 6 months?
> If DSA absolutely requires kernel support then I don't think there is
> much we can do. And I don't think that's a promise anyone could actually
> make, that we expect mainline support to be fixed in the next 6 months.
It's not just DSA, it is also in our porters best interests. We don't
want to end up in the situtation where glibc/udev/systemd/ruby needs
features from a new kernel version, while we are stuck in a old kernel.
Riku
Reply to: