Andreas Barth <[EMAIL PROTECTED]> writes:
> Hi all,
>
> It has been discussed for a while already. While we have release
> criteria for packages, up until now we don't have any for the
> architectures. However, decisions made about an architecture affect
> both our users (and developers) and the release cycle much more than
> decisions about an individual package.
>
> For that reason, we discussed in multiple meetings, together with porters,
> ftp-masters and other people more than once how the criteria should
> look. Also, there was more than one discussion on debian-devel. [1, 2]
Before you talk about the color of the car could we maybe first say
what kind of car we are building?
What I mean is that there are several issues overlapping here and you
are attacking the last and least urgent issue first.
Here is how I see the current urgencies:
1. split the mirror system into required and optional archs.
Specify what criteria an arch has to meat to be required on all
mirrors. This seems to be nearly exclusivly an "how many downloads
does the arch generate" criteria.
The split must be implemented for the archive and the mirror
infrastructure has to adapt to this. The reason amd64 wasn't added to
sid over a year ago was that mirrors are running out of bandwith,
mirror pusles take too long and are too expensive for some. With the
growth of Debian in the last year this must be even more of a problem
now than ever.
2. Define criteria for scc archs
Define what levels of archs there will be, e.g.:
- new ports with just unstable (could be hosted as alioth projects)
- ports that don't have stable (no releases)
- slow/incomplete ports that don't block testing but are release
candidates if they can catch up during freeze
- full ports
Implement this in the archive software.
Will ports that don't block testing have their own britney runs or
just be continiously out of sync unless the port can keep up?
3. Define criteria for releases
This should realy be done after 2 is implemented and some experience
has been made. There is hardly a point in deciding what gets released
and then having to delay etch for 2 years till the archive implements
the infrastructure to make that even possible.
Also who makes the release and what makes it official?
For sarge amd64 basicaly was in the "doesn't block testing" section
from above and did the unofficial release with a small delay to the
official sarge and only minimal deviation from sarge source where
absoluetly neccessary. I think there should be some criteria for the
porting team to pull of a release like that and declare it
official. The work for this should fall to the porting team and they
should organize security for that port as well (like amd64 did).
So I suggest 2 release criteria:
a) this is needed for the RM team to include the arch
b) this is needed if the port team wants to make a release (and call
it official)
As for what exactly each criteria should be keep fighting.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
