|
Home > Archive > Debian Developers > March 2005 > How to define a release architecture
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to define a release architecture
|
|
| Matthew Garrett 2005-03-21, 6:04 pm |
| Ok. I've written this based on the original d-d-a posting from Steve,
and from information cribbed from various other posts. The idea is to
focus consideration on the problems that the release team view as
needing to be solved, rather than just criticising the conclusions
reached.
To start with, here are the original criteria required for an
architecture to be considered releasable, followed by the justification
for each:
FOR AN ARCHITECTURE TO BE RELEASED
* it must first be part of (or at the very least, meet the criteria for)
scc.debian.org (see below)
Sets the base level of technical requirements. If an architecture can't
reach the scc (ports, whatever) requirements, it shouldn't be considered
releasable.
* the release architecture must be publicly available to buy new
Avoids a situation where Debian is keeping an architecture alive. This
isn't intended to result in an architecture being dropped part way
through a release cycle or once it becomes hard to obtain new hardware.
* the release architecture must have N+1 buildds where N is the number
required to keep up with the volume of uploaded packages
This is to ensure that all unstable packages are built in a timely
manner, and that there is adequate redundancy to prevent a single buildd
failure from delaying packages.
* the value of N above must not be > 2
This effectively sets an upper limit on the length of time a single
package may take to build, which helps ensure that doing things like
security fixes for Openoffice doesn't become a problem.
* the release architecture must have successfully compiled 98% of the
archive's source (excluding architecture-specific packages)
A fairly arbitrary figure, but intended to prevent situations where
packages are held back from testing by an architecture not being able to
build them.
* the release architecture must have a working, tested installer
It's not acceptable to release without a working installer, for fairly
obvious reasons.
* the Security Team must be willing to provide long-term support for
the architecture
All releases require security updates, again for obvious reasons.
* the Debian System Administrators (DSA) must be willing to support
debian.org machine(s) of that architecture
This is in order to ensure that developer-accessible machines exist.
* the Release Team can veto the architecture's inclusion if they have
overwhelming concerns regarding the architecture's impact on the
release quality or the release cycle length
A get out clause - it must be possible for something to be refused if it
would break the release, even if it meets all the other criteria.
* there must be a developer-accessible debian.org machine for the
architecture.
Developers must be able to test their code on a machine running that
architecture.
So, we can effectively rephrase that in terms of a set of basic issues
that need to be addressed:
1) A single architecture must not be allowed to hold back other
architectures by being unable to keep up with building unstable, or
taking too long to build individual packages.
2) The benefit to Debian for supporting the architecture must outweigh
the costs to Debian.
3) Releases must be supportable over the course of a release.
4) It must be possible for developers to be able to test and debug code
on every release architecture.
5) If it would cause other problems, it must be possible to prevent an
otherwise conforming architecture from becoming a release candidate.
6) ? (I /think/ I've covered everything - if there are other fundamental
issues then please add them here)
The Vancouver proposals satisfy all of these, potentially at the cost of
removing some architectures from the set released by Debian. If we want
to avoid that cost, can we come up with another proposal that solves the
same problems in a way that satisfies the release team?
--
Matthew Garrett | mjg59@srcf.ucam.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Falk Hueffner 2005-03-21, 6:04 pm |
| Matthew Garrett <mjg59@srcf.ucam.org> writes:
> * the release architecture must be publicly available to buy new
>
> Avoids a situation where Debian is keeping an architecture alive.
I don't understand this. What is the problem with Debian is keeping an
architecture alive? What problem are you trying to solve here?
> * the value of N above must not be > 2
>
> This effectively sets an upper limit on the length of time a single
> package may take to build, which helps ensure that doing things like
> security fixes for Openoffice doesn't become a problem.
If the point is to set an upper limit on the length of time a single
package may take to build, why not take that directly as a criterion?
It is even more objective. It might also encourage people to split
unreasonably large packages.
--
Falk
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter 'p2' De Schrijver 2005-03-21, 6:04 pm |
| > * the release architecture must be publicly available to buy new
>
> Avoids a situation where Debian is keeping an architecture alive. This
> isn't intended to result in an architecture being dropped part way
> through a release cycle or once it becomes hard to obtain new hardware.
>
What problem does this rule solve ?
> * the release architecture must have N+1 buildds where N is the number
> required to keep up with the volume of uploaded packages
>
> This is to ensure that all unstable packages are built in a timely
> manner, and that there is adequate redundancy to prevent a single buildd
> failure from delaying packages.
>
> * the value of N above must not be > 2
>
> This effectively sets an upper limit on the length of time a single
> package may take to build, which helps ensure that doing things like
> security fixes for Openoffice doesn't become a problem.
>
A far more acceptable alternative would be to not have openoffice on those
archs.
> * the release architecture must have successfully compiled 98% of the
> archive's source (excluding architecture-specific packages)
>
> A fairly arbitrary figure, but intended to prevent situations where
> packages are held back from testing by an architecture not being able to
> build them.
>
In which case those packages can simply be not available for the
architecture in question.
> * the release architecture must have a working, tested installer
>
> It's not acceptable to release without a working installer, for fairly
> obvious reasons.
>
> * the Security Team must be willing to provide long-term support for
> the architecture
>
> All releases require security updates, again for obvious reasons.
>
This requirement can be satisfied by stating that some one must be
willing to support the security team.
> * the Debian System Administrators (DSA) must be willing to support
> debian.org machine(s) of that architecture
>
> This is in order to ensure that developer-accessible machines exist.
>
This requirement can be satisfied by stating that some one must be
willing to support debian.org machine(s) of that architecture.
> * the Release Team can veto the architecture's inclusion if they have
> overwhelming concerns regarding the architecture's impact on the
> release quality or the release cycle length
>
> A get out clause - it must be possible for something to be refused if it
> would break the release, even if it meets all the other criteria.
>
This is unacceptable. It would for example allow archs to be refused
because their names starts with an 'A'.
> * there must be a developer-accessible debian.org machine for the
> architecture.
>
> Developers must be able to test their code on a machine running that
> architecture.
>
>
> The Vancouver proposals satisfy all of these, potentially at the cost of
> removing some architectures from the set released by Debian. If we want
> to avoid that cost, can we come up with another proposal that solves the
> same problems in a way that satisfies the release team?
Yes. See above. Most problems can be solved by other means then just
throwing out lots of people's work. Some are actually not a problem but
are probably invented to articifially limit the amount of archs.
Cheers,
Peter (p2).
| |
| Henrique de Moraes Holschuh 2005-03-21, 6:04 pm |
| On Mon, 21 Mar 2005, Peter 'p2' De Schrijver wrote:
>
> What problem does this rule solve ?
IMHO, if one cannot buy one new, it is a mostly stale architecture that is
taking effort from the post-release teams (security, release manager,
DSA...). This is *not* an acceptable criteria for not-to-be-released(-yet)?
arches ("scc"), but it certainly makes a lot of sense for release ones.
If Debian is keeping an arch alive so much that one can still buy it new, I
certainly can't see why we should not continue releasing for that arch,
however. So I'd say Matthew's explanation is not perfect. But the
reasoning behind it is not difficult to spot.
Throwing out this requirement makes sense, if and only if there is another
way to get sure a released arch will not be left stranded. So, let's work
on these alternate ways, so that this rule can be removed.
>
> A far more acceptable alternative would be to not have openoffice on those
> archs.
IMHO you are quite right. If we can agree on that one, we should make it so
that packages that are effectively blocked from an arch count as an
arch-specific (of another arch) for that arch. I.e., they do not lower the
number-of-packages-built rating. So, they do not bother that arch at all.
Add a hard limit that at least the entire set of non-arch-specific standard,
required and essential packages have to be supported (or a minimum of 90% of
them, maybe?), plus at least 50% of optional and 50% of extra (again,
non-arch-specific) to avoid abuse, and that would do it.
DO note that we could also decide to accept that a buildd is something that
has the latencies of a [fast enough] single unit, so, e.g., a distcc farm
would count as one buildd. Makes a lot of sense to me, since it addresses
the latency problem... but you WOULD need N+1 *farms* in different
locations, etc. to address the reliability problem.
Let the porter teams release an *official* list of not-for-us packages for
their arch, which get permanently excluded from that arch's release, and
does not cause any sort of problems *at* *all* for the maintainer of said
packages (such as annoying problems with the testing scripts if the arch
drops the package after it had made it to testing for that arch), and I
don't see how that could be a bad thing.
>
> In which case those packages can simply be not available for the
> architecture in question.
Yes, IMHO. This would take care of it, as long as we have the proper
infrastructure in place to make it easy to manage.
>
> This requirement can be satisfied by stating that some one must be
> willing to support the security team.
No. This requirement can be satisfied by having someone IN THE SECURITY
team willing to support the arch. There are various ways to make sure the
security team is willing to support one arch, and I believe the most
effective one is to get your hands dirty and go help them like crazy right
now, so that they trust they will have help for that arch should they need
it.
I'd suppose a damn good way to start is to make sure there are at least two
porters of every arch (and I *do* count i386, amd64, powerpc and other
popular arches here) *active* in the testing security team.
>
> This requirement can be satisfied by stating that some one must be
> willing to support debian.org machine(s) of that architecture.
My guess is that it would need to be a machine under the DSA control to make
sure the security team and stable maintainership is never left out in the
cold.
Is this actually a problem for any current arch (either released or not)?
>
> This is unacceptable. It would for example allow archs to be refused
> because their names starts with an 'A'.
Let's be very realistic here. If for some weird reason, any of the
post-release teams (security, DSA, release manager) will not touch any archs
whose name start with an 'A', how exactly can we keep these archs working as
a Debian stable arch must be?
We would have to do a parallel release or something like that, using
unofficial mirrors, etc... or to drop a released stable arch in the middle
of a stable release. This is *unacceptable*. Regardless of wether it is
acceptable or not that a post-release team refuses to work with a given
arch, as that problem does not have a solution in a volunteer-driven
project.
So, since "Get that team to work on that arch by force" is not possible,
this requirement is actually quite sane. And if you could get whatever team
is refusing to work with a given arch to actually work with that arch, then
you could have gotten them to stop objecting to that arch being released in
the first place.
Again, is that a problem for any current or prospective archs to be released
with etch?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter 'p2' De Schrijver 2005-03-21, 6:04 pm |
| > If Debian is keeping an arch alive so much that one can still buy it new,I
> certainly can't see why we should not continue releasing for that arch,
> however. So I'd say Matthew's explanation is not perfect. But the
> reasoning behind it is not difficult to spot.
>
> Throwing out this requirement makes sense, if and only if there is another
> way to get sure a released arch will not be left stranded. So, let's work
> on these alternate ways, so that this rule can be removed.
>
It's not because you can't buy a new machine, the arch suddenly stops
being useful.
>
> IMHO you are quite right. If we can agree on that one, we should make itso
> that packages that are effectively blocked from an arch count as an
> arch-specific (of another arch) for that arch. I.e., they do not lower the
> number-of-packages-built rating. So, they do not bother that arch at all.
>
Marking them arch specific would be a good starting point IMO.
> Add a hard limit that at least the entire set of non-arch-specific standard,
> required and essential packages have to be supported (or a minimum of 90%of
> them, maybe?), plus at least 50% of optional and 50% of extra (again,
> non-arch-specific) to avoid abuse, and that would do it.
>
You need something here yes, but by not as stringent as what has been
proposed up to now.
> DO note that we could also decide to accept that a buildd is something that
> has the latencies of a [fast enough] single unit, so, e.g., a distcc farm
> would count as one buildd. Makes a lot of sense to me, since it addresses
> the latency problem... but you WOULD need N+1 *farms* in different
> locations, etc. to address the reliability problem.
>
> Let the porter teams release an *official* list of not-for-us packages for
> their arch, which get permanently excluded from that arch's release, and
> does not cause any sort of problems *at* *all* for the maintainer of said
> packages (such as annoying problems with the testing scripts if the arch
> drops the package after it had made it to testing for that arch), and I
> don't see how that could be a bad thing.
>
Seems to make sense yes.
>
> Yes, IMHO. This would take care of it, as long as we have the proper
> infrastructure in place to make it easy to manage.
>
The current Architecture: list should do ?
> No. This requirement can be satisfied by having someone IN THE SECURITY
> team willing to support the arch. There are various ways to make sure the
> security team is willing to support one arch, and I believe the most
> effective one is to get your hands dirty and go help them like crazy right
> now, so that they trust they will have help for that arch should they need
> it.
>
> I'd suppose a damn good way to start is to make sure there are at least two
> porters of every arch (and I *do* count i386, amd64, powerpc and other
> popular arches here) *active* in the testing security team.
>
Except that this requires NDAs to be signed which people might not be
willing to do.
>
> My guess is that it would need to be a machine under the DSA control to make
> sure the security team and stable maintainership is never left out in the
> cold.
>
> Is this actually a problem for any current arch (either released or not)?
>
AFAIK not, but you never know.
>
> Let's be very realistic here. If for some weird reason, any of the
> post-release teams (security, DSA, release manager) will not touch any archs
> whose name start with an 'A', how exactly can we keep these archs workingas
> a Debian stable arch must be?
>
> We would have to do a parallel release or something like that, using
> unofficial mirrors, etc... or to drop a released stable arch in the middle
> of a stable release. This is *unacceptable*. Regardless of wether it is
> acceptable or not that a post-release team refuses to work with a given
> arch, as that problem does not have a solution in a volunteer-driven
> project.
>
No. There needs to be some override procedure like we have for maintainers not
doing their job. But that's beyond the scope of this discussion.
Cheers,
Peter (p2).
| |
| Henrique de Moraes Holschuh 2005-03-21, 6:04 pm |
| On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote:
>
> It's not because you can't buy a new machine, the arch suddenly stops
> being useful.
Let's not waste time debating stuff like this. Let us work on alternate
ways, or that rule might just remain, bad as it is. You know that, and so
do I.
>
> Marking them arch specific would be a good starting point IMO.
No. Maintainers use the arch specifications to trim down archs where the
package is meaningless or would not work. If a porter team deams an arch
should not have a package that is otherwise arch: all or arch: any, it
should not result in the maintainer getting bug reports or messing with the
arch spec in the package.
The not-for-us lists, plus a channel to get rid of any previous notions the
archive and testing scripts had for a package in a given arch would work
just fine, I think.
>
> You need something here yes, but by not as stringent as what has been
> proposed up to now.
Agreed. I gave some of-the-top-of-my-head sample thresholds. If you have
better ones, go right ahead...
>
> The current Architecture: list should do ?
See above. IMHO we need something a little better.
>
> Except that this requires NDAs to be signed which people might not be
> willing to do.
Not for the testing security team.
Anyway, if people are not going to accept the security NDAs to keep a port
supported, and nobody who HAS signed the NDAs is willing to support the
port, that port has to go. There is no way around THIS one.
>
> AFAIK not, but you never know.
So lets not turn this point into yet another contention point, unless there
is a damn good reason to. There is a good reason why it exists, after all.
>
> No. There needs to be some override procedure like we have for maintainers not
> doing their job. But that's beyond the scope of this discussion.
In this case, there is nothing to override, because the overrides are
actually changing something in the teams so that the team changes their mind
(that might actually mean there is nobody who opposed the change in the team
anymore, in a worst-case scenario).
So, this should not be a point of contention in this sphere at all. It
belongs in some other level. Let's drop this point as a contention point,
then?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-03-21, 8:47 pm |
| On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
[vbcol=seagreen]
[vbcol=seagreen]
> I don't understand this. What is the problem with Debian is keeping an
> architecture alive? What problem are you trying to solve here?
Given that there are architectures that have been end-of-lifed (but *are*
still available for purchase new) that we've had problems keeping our
autobuilders running for, I think it's a fair guess that hardware that truly
is no longer available for purchase is going to be costly for the project to
continue to support for a stable release. Aside from concerns about the
availability and cost of replacement hardware, it's likely that new systems
will continue to be sold for some time after the chip manufacturers stop
designing new (faster, better) chips, so such systems are not going to be
keeping up with the increase in CPU demands of compiling the archive.
This adds up to a lot of effort for a dead-end architecture. Do you believe
that such ports are going to command enough interest to be able to keep up
with Debian's stable support requirements for more than 2 1/2 years (18mo.
release cycle + 1 year support for oldstable) after being discontinued as a
product?
Furthermore, do you believe that the limited resources of DSA (which will
*always* be limited, no matter how big you say you want the team to be,
because there's *always* more to do than there are people to do it) should
be spent keeping stable security buildds for such architectures running,
instead of on tasks that are useful to users of living architectures?
[vbcol=seagreen]
[vbcol=seagreen]
> If the point is to set an upper limit on the length of time a single
> package may take to build, why not take that directly as a criterion?
> It is even more objective. It might also encourage people to split
> unreasonably large packages.
Wouldn't this also be an arbitrary penalty on slower architectures, though?
The porters don't control the size of the largest packages in the archive;
and package sizes do continue to go up, just like everything else.
Build time for a single package is also only one of the concerns; the other
big one being that it's much more likely to get security wrong for one out
of ten buildds, rather than for one out of three.
--
Steve Langasek
postmodern programmer
| |
| Matthew Garrett 2005-03-21, 8:47 pm |
| Peter 'p2' De Schrijver <p2@mind.be> wrote:
> This is unacceptable. It would for example allow archs to be refused
> because their names starts with an 'A'.
Personally, I'd prefer to delegate that sort of decision to the
technical committee rather than have the release team have a veto. Even
so, if a group of people produce a port of Debian that'll only ever be
used by 50 or so people, then that really doesn't justify the amount of
effort taken to support a release. There are other reasons why it might
be worth failing to release an architecture even if it does reach the
defined criteria.
> Yes. See above. Most problems can be solved by other means then just
> throwing out lots of people's work. Some are actually not a problem but
> are probably invented to articifially limit the amount of archs.
So write a concrete proposal that solves the problems you believe need
solving, and then see what people think. It's fairly clear that we're
not going to have consensus on this issue before Sarge is released, so
there's no great rush about it.
People are far too busy picking on small details of proposals they don't
like instead of coming up with a decent and comprehensive set of
solutions. If you don't like what's been proposed, produce something
better. For the most part, that's how Debian works.
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sven Luther 2005-03-22, 2:51 am |
| On Mon, Mar 21, 2005 at 08:39:58PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 22 Mar 2005, Peter 'p2' De Schrijver wrote:
>
> In this case, there is nothing to override, because the overrides are
> actually changing something in the teams so that the team changes their mind
> (that might actually mean there is nobody who opposed the change in the team
> anymore, in a worst-case scenario).
>
> So, this should not be a point of contention in this sphere at all. It
> belongs in some other level. Let's drop this point as a contention point,
> then?
No, this is the main problem, that there is no counter power or limitation to
what they can decide. We saw this already in the amd64 GR issue, and we can
either accept their decission or have them resign in masse and be prepared to
replace them.
There is no accountability, and altough the DPL supposedly mandated them, he
has no actual power to do anything about it.
Sven Luther
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sven Luther 2005-03-22, 2:51 am |
| On Tue, Mar 22, 2005 at 09:12:45AM +0100, Benjamin Mesing wrote:
> Hello,
>
>
> There was a proposal first made by Marc 'HE' Brockschmidt [1] and than
> (independently) made by me [2] where we proposed to freeze testing even
> if some architectures are not ready yet, and use
> testing-proposed-updates to make the architectures release ready later.
> As I have elaborated in [2] this approach has the potential to solve the
> points addressed in the Vancoover proposal. As these proposals where
> nearly not discussed and especially there were no objections/arguments
> against it I want to bring up this proposal again as it might have been
> lost in the noise because the posts were located in the original "Bits
> (Nybbles?)..." thread.
Except Steve said his criteria's where non-negotiable, so ...
Sven Luther
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Benjamin Mesing 2005-03-22, 2:51 am |
| Hello,
> The Vancouver proposals satisfy all of these, potentially at the cost of
> removing some architectures from the set released by Debian. If we want
> to avoid that cost, can we come up with another proposal that solves the
> same problems in a way that satisfies the release team?
There was a proposal first made by Marc 'HE' Brockschmidt [1] and than
(independently) made by me [2] where we proposed to freeze testing even
if some architectures are not ready yet, and use
testing-proposed-updates to make the architectures release ready later.
As I have elaborated in [2] this approach has the potential to solve the
points addressed in the Vancoover proposal. As these proposals where
nearly not discussed and especially there were no objections/arguments
against it I want to bring up this proposal again as it might have been
lost in the noise because the posts were located in the original "Bits
(Nybbles?)..." thread.
For the sake of discussion I have attached my proposal (it is a little
more detailed than Marcs) at the end of this message.
If this is total rubbish please tell me why and refrain from using the
rough tone that has become so common in this list recently. As most
developers I would like to keep this place a friendly one and I want to
enjoy reading the list instead of bristling about it.
Greetings Ben
[1] http://lists.debian.org/debian-deve...3/msg01372.html
[2] http://lists.debian.org/debian-deve...3/msg01647.html
--- my original post ---
Hello,
as a non-DD I am not so tuned into the Debian project as many of you
are. However I would like to make a proposal about the "hot topic".
As I have noticed, most people ojecting against dropping architecures
feared for the coherence of the systems. They wanted to be able to have
the *same* debian on all there machines and wanted security support and
all this stuff for *all* archs.
The persons in favour for dropping archs noticed that they delayed the
release of sarge and caused a lot of extra work.
So I have given this some thought and come with a proposal quite simple:
Why not freeze the archive at a given time and make a release for all
architectures ready until then. As this code is frozen, the porters can
continue to work on the frozen codebase where only patches are allowed
which are needed fix the packages for the different architectures. This
seems to be the same the security team currently does. The ported
architectures would become available as soon as a new revision is
released (of course this should happen as soon as a new arch has caught
up).
This would allow a fast release and keep the burden of the arch support
mainly with the porters who would be responsible for making there arch
ready for release. It would allow to support each archs as long as there
are sufficient developers available who can keep up with porting. The
security infrastructure can be shared by all archs. Porters may even
decide to skip one release if they are not up to it - this is not that
bad if the release cylcle is around 12 month.
This is the rough plan, now I will list some details or afterthought
(skip them if you are totally annoyed by this proposal anyway):
* as there already is, the possibility to exclude packages from
archs is always possible making debian a little less uniform -
but why should debian fix the issues not properly adressed by
the upstream author anyways - if he does not care about the bugs
he receives from the debian package it should simply not be
relased for this arch
* there is no way to *force* the developers to accept the porters
patches or care for their concerns any more, but come on -
developers are not a community of assholes who want to keep your
architectures out of debian
* it is even possible to release with a subset of the packages
(only the important ones and increase each step
* People missing their arch in the first release will likely
complain, but the other option would have been to delay all the
other archs until this arch keeps up (which might indeed have
happened faster if the whole release was delayed because
everyone would press the obstacles - but I think that is unfair
against the archs which are release ready...)
* I intentionally disregarded the problem of the mirror size and
buildd because the mirror problem received a lot of good
suggestions and I believe the buildd problem could be solved
with additional hardware and if not architectures not up to date
could simply be considered release ready and will have to wait
another round...
Of course there is much to think about and to fine tune but it is a
proposal trying to combine the request of all users.
This might be totally unrealistic as I said I have no deep insight into
the debian architecture but _I_ think it is a good proposal.
Please let me know what you think about this proposal!
Greetings Ben
PS. it is only now that I've noted that a similar proposal was made at
http://lists.debian.org/debian-deve.../msg01372.html, so you can
consider this a more elaborate version of this suggestion. And please
forgive me if there are others who have made this proposal, its hard to
keep up with this thread
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Falk Hueffner 2005-03-22, 2:51 am |
| Steve Langasek <vorlon@debian.org> writes:
> On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote:
>
>
>
>
> Given that there are architectures that have been end-of-lifed (but
> *are* still available for purchase new) that we've had problems
> keeping our autobuilders running for, I think it's a fair guess that
> hardware that truly is no longer available for purchase is going to
> be costly for the project to continue to support for a stable
> release.
This is too vague for me.
> Aside from concerns about the availability and cost of replacement
> hardware,
Has this really been a problem for Debian?
> it's likely that new systems will continue to be sold for some time
> after the chip manufacturers stop designing new (faster, better)
> chips, so such systems are not going to be keeping up with the
> increase in CPU demands of compiling the archive.
There's already another criterion for this, which captures this far
better.
> This adds up to a lot of effort for a dead-end architecture. Do you
> believe that such ports are going to command enough interest to be
> able to keep up with Debian's stable support requirements for more
> than 2 1/2 years (18mo. release cycle + 1 year support for
> oldstable) after being discontinued as a product?
Given that you'll probably not be able to buy an i386 box in a few
years anymore, I'd say "yes". But I see little point in trying to
guess here. Ports that cannot keep up should be filtered by the other
criterions.
> Furthermore, do you believe that the limited resources of DSA (which
> will *always* be limited, no matter how big you say you want the
> team to be, because there's *always* more to do than there are
> people to do it) should be spent keeping stable security buildds for
> such architectures running, instead of on tasks that are useful to
> users of living architectures?
This is again pretty vague. You basically say that we need to drop
architectures, and we should drop those that are "not living".
Firstly, this particular criterion is not effective at dropping
architectures: currently, all of our architectures can be bought new.
Secondly, it doesn't seem like a good criterion for determining
"livingness": arm, mips, and m68k are basically immune to this for the
next 10 years or so, since they are used in embedded systems and can
be produced very cheaply. I already mentioned i386 as a contrast.
In summary, it seems like this criterion isn't trying to solve some
particular problem, but it just generally targeted towards cutting
down the number of architectures. I already have doubts as to whether
this is a reasonable premise, but even if I accept it, it seems
neither effective nor particularly well-motivated.
>
>
>
> Wouldn't this also be an arbitrary penalty on slower architectures,
> though?
Of course it would. But if the point is to set an upper limit on build
time, that would be a good thing and not arbitrary.
> Build time for a single package is also only one of the concerns;
> the other big one being that it's much more likely to get security
> wrong for one out of ten buildds, rather than for one out of three.
What do you mean by "getting security wrong"? Can you give an example?
Is there evidence that this is a problem for the architectures that
currently have many buildds?
--
Falk
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-03-22, 7:52 am |
| On Tue, Mar 22, 2005 at 09:36:46AM +0100, Falk Hueffner wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> This is too vague for me.
<sigh> Does the release team now have to do price shopping on replacement
parts for buildds before it can say that it doesn't want to support dying
platforms?
[vbcol=seagreen]
> Has this really been a problem for Debian?
One of the delays affecting getting lully.d.o back on line, AIUI, was a dead
power supply that was non-trivial to replace. This is a case of scarce
hardware impacting a port even *before* it has ceased to become available
for sale.
[vbcol=seagreen]
> Given that you'll probably not be able to buy an i386 box in a few
> years anymore, I'd say "yes". But I see little point in trying to
> guess here. Ports that cannot keep up should be filtered by the other
> criterions.
Really? You can still buy 486 chips new for use in embedded applications
(or so we've been told in previous threads about C++ ABI breakage); but you
think that x86 as a class will cease to become available in a matter of a
few years?
[vbcol=seagreen]
> This is again pretty vague. You basically say that we need to drop
> architectures, and we should drop those that are "not living".
> Firstly, this particular criterion is not effective at dropping
> architectures: currently, all of our architectures can be bought new.
> Secondly, it doesn't seem like a good criterion for determining
> "livingness": arm, mips, and m68k are basically immune to this for the
> next 10 years or so, since they are used in embedded systems and can
> be produced very cheaply. I already mentioned i386 as a contrast.
You didn't answer the question I asked. Do you believe that DSA should be
spending its limited resources keeping hardware running for dead
architectures?
And given that none of our current architectures are "dead", why is it
important to argue this point?
[vbcol=seagreen]
> What do you mean by "getting security wrong"? Can you give an example?
> Is there evidence that this is a problem for the architectures that
> currently have many buildds?
Is reason dead? Do I really have to have proof of past buildd compromises
to argue that it's betting against the odds to not consider sheer number
of machines a security concern? Do you really think that if there *was*
proof of past buildd compromises in Debian, anyone would give a damn about
whether we have "security" support for etch?
--
Steve Langasek
postmodern programmer
| |
| Adrian Bunk 2005-03-22, 7:52 am |
| On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote:
> On Mon, Mar 21, 2005 at 09:51:25PM +0100, Falk Hueffner wrote:
>
>
>
>
> Given that there are architectures that have been end-of-lifed (but *are*
> still available for purchase new) that we've had problems keeping our
> autobuilders running for, I think it's a fair guess that hardware that truly
> is no longer available for purchase is going to be costly for the project to
> continue to support for a stable release.
>...
The only sarge architectures that are likely of being affected by your
"must be publicly available to buy new" rule during the next 10 years
are hppa and alpha (dunno about s390).
Both architectures had a long lifespan during which many machines were
produced and damned fast machines are likely being produced until the
last day when they'll be produced.
For both of these architectures, HP still offers servers today.
And if HP one day stops with this, they will still have to offer
replacement parts for their costumers for _many_ years.
Debian has good connections with HP.
Wouldn't an arrangement with HP of getting hardware plus some years of
support being an alternative to your announcement that you plan to drop
the hppa and alpha architectures from Debian releases?
> Steve Langasek
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Alastair McKinstry 2005-03-22, 7:52 am |
| On Máirt, 2005-03-22 at 00:11 +0100, Peter 'p2' De Schrijver wrote:
>
> It's not because you can't buy a new machine, the arch suddenly stops
> being useful.
I think the point of this requirement is to support it we need buildds
in the future for security fixes. Hence while I might like my mips box,
etc. it would be irresponsible for us to do a release that we could not
support in e.g. two years time when the motherboards of our buildds die.
Perhaps this clause could be refined, though: should it be a sub-arch
requirement and not just an arch one; or could we specify that its OK to
release if we have a given stock of replacement hardware available
(e.g. given our good relationship with HP, its likely we could get
sufficient Alpha hardware for several years after HP finally stop
shipping Alphas).
> Cheers,
>
> Peter (p2).
Regards
Alastair McKinstry
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2005-03-22, 7:52 am |
| On Tue, Mar 22, 2005 at 07:45:00AM +0000, Alastair McKinstry wrote:
>
> I think the point of this requirement is to support it we need buildds
> in the future for security fixes. Hence while I might like my mips box,
> etc. it would be irresponsible for us to do a release that we could not
> support in e.g. two years time when the motherboards of our buildds die.
Mips is extremely alive and it was a huge surprise if new mips-based
products weren't available ten years from now.
> Perhaps this clause could be refined, though: should it be a sub-arch
> requirement and not just an arch one; or could we specify that its OK to
> release if we have a given stock of replacement hardware available
> (e.g. given our good relationship with HP, its likely we could get
> sufficient Alpha hardware for several years after HP finally stop
> shipping Alphas).
The release team's announcement affects only hppa and alpha in the
forseeable future.
And in both cases an arrangement with HP could erase the problems.
> Regards
> Alastair McKinstry
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter 'p2' De Schrijver 2005-03-22, 7:52 am |
| On Tue, Mar 22, 2005 at 07:45:00AM +0000, Alastair McKinstry wrote:
> On Máirt, 2005-03-22 at 00:11 +0100, Peter 'p2' De Schrijver wrote:
>
>
> I think the point of this requirement is to support it we need buildds
> in the future for security fixes. Hence while I might like my mips box,
> etc. it would be irresponsible for us to do a release that we could not
> support in e.g. two years time when the motherboards of our buildds die.
>
The arch should still be available, but a big enough collection of
existing machines will do here IMO. Not that this holds for mips as
there are new MIPS based systems available. Both broadcom and PMC
announced new MIPS based chips for example. And there is AMD (Alchemy)
and a bunch of others using MIPS as well.
Cheers,
Peter (p2).
| |
| Henrique de Moraes Holschuh 2005-03-22, 7:52 am |
| On Tue, 22 Mar 2005, Sven Luther wrote:
> On Mon, Mar 21, 2005 at 08:39:58PM -0300, Henrique de Moraes Holschuh wrote:
>
> No, this is the main problem, that there is no counter power or limitation to
> what they can decide. We saw this already in the amd64 GR issue, and we can
> either accept their decission or have them resign in masse and be prepared to
> replace them.
Then start another thread in -project about the accountability issue.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Peter 'p2' De Schrijver 2005-03-22, 7:52 am |
| >
> The only sarge architectures that are likely of being affected by your
> "must be publicly available to buy new" rule during the next 10 years
> are hppa and alpha (dunno about s390).
>
Given IBM's track record in backwards compatibility I don't expect s390
to die at all  Even the latest zSeries can still run IBM 360 code
afaik.
Cheers,
Peter (p2).
| |
| Wouter Verhelst 2005-03-22, 7:52 am |
| On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote:
> This adds up to a lot of effort for a dead-end architecture. Do you believe
> that such ports are going to command enough interest to be able to keep up
> with Debian's stable support requirements for more than 2 1/2 years (18mo.
> release cycle + 1 year support for oldstable) after being discontinued as a
> product?
I'm assuming you're talking about m68k here. If not, please correct me.
m68k has been EOLed in desktop hosts for about 10 years now. There are
still people interested in it, who install Linux on their old hardware
for the first time, even today.
I think that pretty much translates to an answer of 'yes' to the above
question.
> Furthermore, do you believe that the limited resources of DSA (which will
> *always* be limited, no matter how big you say you want the team to be,
> because there's *always* more to do than there are people to do it) should
> be spent keeping stable security buildds for such architectures running,
> instead of on tasks that are useful to users of living architectures?
There is some overlap between the groups of 'DSA' and 'buildd admins',
but a) that overlap is not absolute, and b) that overlap is not
necessary.
If the DSA people do not have enough time to spend in keeping stable
security buildds for old architectures running, they are welcome to hand
over buildd maintenance to other people; there are enough experienced
people to take over, if required.
If you're also talking about m68k here, then your point is moot; there
are no people involved with DSA that maintain any m68k buildd host.
>
>
>
> Wouldn't this also be an arbitrary penalty on slower architectures, though?
Yes.
In the specific case of OpenOffice.org, the point is moot.
OpenOffice.org requires some assembly glue, so needs to be ported to
every architecture it runs on; currently, there are OpenOffice.org
packages for i386, powerpc, sparc, and s390; none for any of the slower
architectures, and doing them wouldn't be possible without someone
spending their time on it anyway.
In the general case, as I have said before, I don't think anyone would
take offense at a security announcement being sent out containing
MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390,
with a message like 'packages for m68k, mips, mipsel, arm, and hppa will
be announced when ready' if the delay would become unacceptable, or so.
> The porters don't control the size of the largest packages in the archive;
> and package sizes do continue to go up, just like everything else.
Not just that; package build times for equally-sized packages continue
to go up as well, because of increased optimisation.
> Build time for a single package is also only one of the concerns; the other
> big one being that it's much more likely to get security wrong for one out
> of ten buildds, rather than for one out of three.
Are there any specific concerns, or is this just a general feeling that
we m68k people might not know what we're doing, security-wise?
If the latter, spelling out a security policy that we have to follow
might be another alternative.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adrian Bunk 2005-03-22, 7:52 am |
| On Mon, Mar 21, 2005 at 11:13:40PM +0000, Matthew Garrett wrote:
>...
> People are far too busy picking on small details of proposals they don't
> like instead of coming up with a decent and comprehensive set of
> solutions. If you don't like what's been proposed, produce something
> better. For the most part, that's how Debian works.
My proposal is:
Change the release process to a release process without testing.
Rationale:
The whole release team plus Anthony Towns who's the main developer of
testing signed the following statement:
<-- snip -->
We project that applying these rules for etch will reduce the set of
candidate architectures from 11 to approximately 4 ([...]).
This will drastically reduce the architecture coordination required in
testing, giving us a more limber release process and (it is hoped) a
much shorter release cycle on the order of 12-18 months.
<-- snip -->
If your release process has problems with the current number of
architectures, you have two choices:
- announce that you plan to drop two third of the architectures
- change the release process
I'd prefer the second choice.
Testing has it's advantages.
You know that all packages have there dependencies fulfilled [1], were
built on all architectures, and some kinds of bugs are less likely to
make it into testing.
But testing also has it's costs (read e.g. what Steve listed as three
points that "probably account for more of my release management time
than anything else" [2] - they are testing specific tasks).
Testing helps with some problems like ensuring that all dependencies are
fulfilled and that packages have been built on all architectures - but
this information is also available elsewhere.
What instead?
What about the simple pre-testing release process:
- announce a freeze date
- freeze unstable at the announced date
- work a few months on improving frozen until it's in a releasable state
I do believe that such a simple release process would allow releasing
once a year with a dozen architectures.
And if the buildd on an architecture wasn't able to keep up with
unstable it wasn't nice - but it wasn't a problem for the release
management since it was enough if the buildd started to keep up with
frozen after the freeze (and the number of daily uploads to frozen
should be much smaller than the number of daily uploads to frozen).
This would therefore make (at least from a release management point of
view) all discussions regarding the required speed of buildds obsolete.
cu
Adrian
[1] but build dependencies are still not tracked
[2] http://lists.debian.org/debian-deve...3/msg02334.html
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-03-22, 7:52 am |
| On Tue, Mar 22, 2005 at 01:11:32AM -0800, Steve Langasek wrote:
> On Tue, Mar 22, 2005 at 09:36:46AM +0100, Falk Hueffner wrote:
>
> <sigh> Does the release team now have to do price shopping on replacement
> parts for buildds before it can say that it doesn't want to support dying
> platforms?
Paying for m68k buildd hardware has generally been the responsability of
the buildd maintainers, with a few notable exceptions (maxing out the
RAM of all our buildd hosts was one). In general, paying for buildd
hardware most certainly has never been the release team's
responsability, so I fail to see why they should worry about it.
>
>
> One of the delays affecting getting lully.d.o back on line, AIUI, was a dead
> power supply that was non-trivial to replace. This is a case of scarce
> hardware impacting a port even *before* it has ceased to become available
> for sale.
If this problem even exists with hardware that is still available to buy
new, then how would a criterion of 'must be available to buy new' help
aleviate the the problem?
[...]
> You didn't answer the question I asked. Do you believe that DSA should be
> spending its limited resources keeping hardware running for dead
> architectures?
No. They never did, and they never should. The fact that some people are
involved with both DSA and buildd maintenance doesn't mean DSA, as a
group, has anything to do with buildd maintenance.
> And given that none of our current architectures are "dead", why is it
> important to argue this point?
Because the criterion of 'must not require more than two buildd hosts'
would effectively kill off some of our architectures, for no real
reason.
>
>
> Is reason dead? Do I really have to have proof of past buildd compromises
> to argue that it's betting against the odds to not consider sheer number
> of machines a security concern?
Yes. We've had buildd hosts ever since Debian 2.0, which is ages old
now, and restricted buildd hosts have apparently not ever become
compromised, while some of our non-restricted hosts have. This makes me
think that the security on buildd hosts is better than those on general
developer-accessible machines, and that, thus, we should not look at
restricted hosts rather than the general accessible machines. Right?
If there are concerns regarding security, I think it's best to name them
and deal with them, rather than imposing arbitrary limits which do
nobody any good.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2005-03-22, 7:52 am |
| * Wouter Verhelst (wouter@debian.org) [050322 13:05]:
> In the general case, as I have said before, I don't think anyone would
> take offense at a security announcement being sent out containing
> MD5sums for packages for i386, sparc, powerpc, alpha, ia64 and s390,
> with a message like 'packages for m68k, mips, mipsel, arm, and hppa will
> be announced when ready' if the delay would become unacceptable, or so.
I have heared that the current scripts used on security.debian.org do
not really support this.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-03-22, 7:52 am |
| On Tue, Mar 22, 2005 at 01:28:18PM +0100, Andreas Barth wrote:
> * Wouter Verhelst (wouter@debian.org) [050322 13:05]:
>
> I have heared that the current scripts used on security.debian.org do
> not really support this.
Implementing whatever will come out of this will require some extra
coding anyway; it won't hurt to have to add the security.d.o scripts to
the list of 'things that need changes'. Sorry, but that's not a valid
argument.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2005-03-22, 7:52 am |
| * Wouter Verhelst (wouter@grep.be) [050322 13:35]:
> On Tue, Mar 22, 2005 at 01:28:18PM +0100, Andreas Barth wrote:
[vbcol=seagreen]
> Implementing whatever will come out of this will require some extra
> coding anyway; it won't hurt to have to add the security.d.o scripts to
> the list of 'things that need changes'. Sorry, but that's not a valid
> argument.
It was not meant as "we can't do it", but as "we need to put time into
that if we decide to do it".
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-03-22, 7:52 am |
| On Tue, Mar 22, 2005 at 01:13:15PM +0100, Wouter Verhelst wrote:
> On Tue, Mar 22, 2005 at 01:11:32AM -0800, Steve Langasek wrote:
[vbcol=seagreen]
> No. They never did, and they never should. The fact that some people are
> involved with both DSA and buildd maintenance doesn't mean DSA, as a
> group, has anything to do with buildd maintenance.
- the Debian System Administrators (DSA) must be willing to support
debian.org machine(s) of that architecture
- there must be a developer-accessible debian.org machine for the
architecture.
Who maintains crest.debian.org?
--
Steve Langasek
postmodern programmer
| |
| Wouter Verhelst 2005-03-22, 8:47 pm |
| On Tue, Mar 22, 2005 at 05:31:58AM -0800, Steve Langasek wrote:
> On Tue, Mar 22, 2005 at 01:13:15PM +0100, Wouter Verhelst wrote:
>
>
>
> - the Debian System Administrators (DSA) must be willing to support
> debian.org machine(s) of that architecture
>
> - there must be a developer-accessible debian.org machine for the
> architecture.
>
> Who maintains crest.debian.org?
Uh, sorry, I was confused there; I thought you were only talking about
maintaining buildd machines for architectures.
In any case, the burden to maintain one (or two) hosts as general
developer-accessible machines is far lighter than to impede DSA with
having to maintain all buildd hosts...
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Rob Browning 2005-03-25, 6:03 pm |
| Peter 'p2' De Schrijver <p2@mind.be> writes:
> The arch should still be available, but a big enough collection of
> existing machines will do here IMO. Not that this holds for mips as
> there are new MIPS based systems available. Both broadcom and PMC
> announced new MIPS based chips for example. And there is AMD
> (Alchemy) and a bunch of others using MIPS as well.
Similarly, though I've never actually used one, this seemed like it
might be an interesting router:
http://www.routerboard.com/rb500.html
and if I *were* to use one, I'd certainly prefer to run Debian on it
if I could.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-03-26, 2:48 am |
| On Tue, Mar 22, 2005 at 01:01:24PM +0100, Wouter Verhelst wrote:
> On Mon, Mar 21, 2005 at 05:28:51PM -0800, Steve Langasek wrote:
[vbcol=seagreen]
> I'm assuming you're talking about m68k here. If not, please correct me.
Hmm, not particularly. I don't really have any preconception/prejudice that
the processors need to be in ongoing use in new *desktop* products; Debian
obviously runs the gamut from mainframe to server/desktop to embedded.
If the m68k architecture is still being used in new systems capable of
running Debian, then I think this requirement is met.
> m68k has been EOLed in desktop hosts for about 10 years now. There are
> still people interested in it, who install Linux on their old hardware
> for the first time, even today.
> I think that pretty much translates to an answer of 'yes' to the above
> question.
Possibly, but I'm not convinced that potential userbase size ever guarantees
a viable port just by numbers alone. I don't know if the liveliness of the
m68k community is related to the continued availability of new m68k
processors (which are still available, based on the general response I've
gotten that this requirement doesn't affect any of our current ports? Even
though I don't know where to find a new m68k myself). I would be inclined
to suspect that it is.
[vbcol=seagreen]
> There is some overlap between the groups of 'DSA' and 'buildd admins',
> but a) that overlap is not absolute, and b) that overlap is not
> necessary.
> If the DSA people do not have enough time to spend in keeping stable
> security buildds for old architectures running, they are welcome to hand
> over buildd maintenance to other people; there are enough experienced
> people to take over, if required.
If they choose to do so, that's fine with me; however, particularly for
buildds for stable-security, I think it's important that the machines be
under the de facto authority of DSA -- even though they might delegate a
particular machine's administration to someone who doesn't have authority
over Debian machines in general.
[vbcol=seagreen]
[vbcol=seagreen]
> Yes.
> In the specific case of OpenOffice.org, the point is moot.
> OpenOffice.org requires some assembly glue, so needs to be ported to
> every architecture it runs on; currently, there are OpenOffice.org
> packages for i386, powerpc, sparc, and s390; none for any of the slower
> architectures, and doing them wouldn't be possible without someone
> spending their time on it anyway.
The OOo example was not mine; much better examples, I think, would be some
of the math processing packages (quantlib, axiom -- fairly unlikely to
require security updates, after all), X, KDE, or the mozillae.
[vbcol=seagreen]
> Not just that; package build times for equally-sized packages continue
> to go up as well, because of increased optimisation.
Indeed. So eventually, all architectures will be able to run the code, but
none will be able to build it. ;)
[vbcol=seagreen]
> Are there any specific concerns, or is this just a general feeling that
> we m68k people might not know what we're doing, security-wise?
It is a general comment on mitigation of security risks.
> If the latter, spelling out a security policy that we have to follow
> might be another alternative.
I think that's also a good idea.
--
Steve Langasek
postmodern programmer
| |
| Steve Langasek 2005-03-26, 7:57 am |
| Benjamin,
On Tue, Mar 22, 2005 at 09:12:45AM +0100, Benjamin Mesing wrote:
> Why not freeze the archive at a given time and make a release for all
> architectures ready until then. As this code is frozen, the porters can
> continue to work on the frozen codebase where only patches are allowed
> which are needed fix the packages for the different architectures. This
> seems to be the same the security team currently does. The ported
> architectures would become available as soon as a new revision is
> released (of course this should happen as soon as a new arch has caught
> up).
For examples of why allowing release-candidate architectures to catch up
with the archive *after* freezing is a potential problem, please see the
following RC bugs in base packages that are going to result in the sarge
freeze period being the one and only testing cycle for detecting (possibly
architecture-specific) regressions:
292673 297769 284961 291386 294404
--
Steve Langasek
postmodern programmer
| |
| Anthony DeRobertis 2005-03-28, 7:57 am |
| Steve Langasek wrote:
> One of the delays affecting getting lully.d.o back on line, AIUI, was a dead
> power supply that was non-trivial to replace. This is a case of scarce
> hardware impacting a port even *before* it has ceased to become available
> for sale.
Well, N+1 redundancy is already required. Maybe a requirement for N+2 or
more for architectures where replacement parts are hard to find?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2005-03-28, 7:57 am |
| On Sat, Mar 26, 2005 at 12:38:05AM -0800, Steve Langasek wrote:
> On Tue, Mar 22, 2005 at 01:01:24PM +0100, Wouter Verhelst wrote:
>
>
> Hmm, not particularly. I don't really have any preconception/prejudice that
> the processors need to be in ongoing use in new *desktop* products; Debian
> obviously runs the gamut from mainframe to server/desktop to embedded.
>
> If the m68k architecture is still being used in new systems capable of
> running Debian, then I think this requirement is met.
That is the case. The BVM VME modules are capable of running Debian (and
did so with woody); the q60 machines should be, too (although they are
not supported with bootfloppies and not very well tested with d-i)
>
>
> Possibly, but I'm not convinced that potential userbase size ever guarantees
> a viable port just by numbers alone. I don't know if the liveliness of the
> m68k community is related to the continued availability of new m68k
> processors (which are still available, based on the general response I've
> gotten that this requirement doesn't affect any of our current ports? Even
> though I don't know where to find a new m68k myself).
http://www.bvm.co.uk/vmeprods.html
http://www.q40.de/
These are systems that can be bought new today, and are supported under
Debian. The VME requires one to have a VME case, but it should (in
theory) work in a new VME case as well (the VME technology is a single
board computer bus architecture that is an industry standard, somewhat
comparable in function to the blade system).
http://www.czuba-tech.com/CT60/english/welcome.htm
for the CT60 and CT63, which are expansion boards for the Atari Falcon.
The CT60 was designed only one or two years ago, while the CT63 is even
more recent. They both allow one to upgrade a Falcon to a 68060-based
system that would run at 100Mhz. There are some Debian/m68k porters that
own one of the CT60 boards, and we're working on getting them supported.
Since the board requires one to already own an Atari Falcon, however,
I'm not sure whether this satisfies your requirement; but it sure does
show that the m68k community is far from dead (else there wouldn't be
any interest in such a board design, let alone two of them).
> I would be inclined to suspect that it is.
[related to availability of the processor]
So would I; but as it is still available (and still quite often used in
embedded situations), I would think that this is not currently a
problem.
>
> If they choose to do so, that's fine with me; however, particularly for
> buildds for stable-security, I think it's important that the machines be
> under the de facto authority of DSA
They already are. If a machine would not satisfy a requirement set by
DSA, they can remove that machine's SSH key from the wanna-build
authorized_keys file.
> -- even though they might delegate a particular machine's
> administration to someone who doesn't have authority over Debian
> machines in general.
So what would be the difference with today?
>
> The OOo example was not mine;
I know, but I found it necessary to explain this bit.
[...]
>
>
> Indeed. So eventually, all architectures will be able to run the code, but
> none will be able to build it. ;)
Heh
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|