Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, 14 Mar 2005 19:59:43 +0000, Alastair McKinstry wrote:
> On Luan, 2005-03-14 at 16:16 +0100, David Schmitt wrote:
>> On Monday 14 March 2005 12:05, Robert Lemmen wrote:
>> > - there must be a way for a scc arch to get a stable release. why don't
>> > we either keep testing for scc archs but not do releases, so the
>> > porters can do their own stable releases of their arch or have
>> > per-arch testing? (the latter might lead to a source package explosion
>> > i think)
>>
>> AFAI can tell, anybody can host an archive of packages built from stable
>> sources for a scc or unofficial port. And - if I read the conditions on
>> becoming a fully supported Debian arch right - then having security support
>> for an external pool of this arch is a good indicator that it should be a
>> fully supported stable release (amongst other things).
>
> The plan as proposed is that the Debian scc ports are purely builds of
> unstable. Hence this build out of the last release (e.g. etch) becomes a
> subproject of a second-class project of Debian. It effectively has
> little credibility.
>
>
I agree 100%; if this were to be made to work, there would need to be a
way for a release done based on etch to be officially blessed by Debian.
That does not mean security updates by Debian; but an announcement and
documentation stating that the official Debian $ARCH team has released
$ARCH for etch, and it can be grabbed from $URL, and security fixes can
be grabbed from $URL. Ditto for future updates. Otherwise, you run into
the situation where (due to the internal conflicts we all know will
happen sooner or later) there are two $ARCH releases for Debian, done by
different people, but both called "Debian".
>> If on the other hand nobody can be found to
recompile packages after
>> DSAs are released for this arch, I believe the arch shouldn't be
>> released for Debian as stable.
>
> This is the important part. The point of a release is that (1) it works
> (2) A promise that it _will be maintained_ ; that there will be security
> fixes, and eventually an upgrade path.
>
One of the major points of this proposal is that Debian does not want to
*promise* security updates for an architecture which is not widely used.
Instead, it is up to the porters to promise such a thing. This relies on
having the proper manpower on the architecture's team (shouldn't be a
problem for any architecture which people actually use), as well as having
an organizational structure that allows for consistent, quality security
updates (ie, by having one or two people do the security updates), while
at the same time allowing for other people to step in if the main security
people become MIA (for reasons of work, real life, etc).
Reply to: