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

Re: RfD: Preparing Debian 2.1r3



Adam Di Carlo wrote:
> >If you could provide us with a makedev for slink, fixing only this
> >one, I guess it would be easier to include.
> >
> >However, the Security Team is not responsible for updating stable with
> >non-security updates.  We did this now as an exception because no
> >Stable Release Manager was acting.  While working on this I was told
> >that Vincent Renardias got this job, so you should probably get in
> >touch with him.
> 
> I'm CC'ing the debian-release mail list.  I didn't understand that you
> were only acting on behalf of the security team.  Admittedly the
> makedev changes are only required to solve some rather nasty problems
> in Debian/SPARC, and thusly, fall outside of your authority as an
> agent of the security team.

I'm sorry if I haven't emphasized that.  My main concern were our
security updates that were lost in proposed-updates.  Only since
there was nobody taking care of it Wichert and myself considered
some major updates as well.  This is not our job and we don't
want to fiddle with it. 

> All bureacracy aside, I very much *would* like to see an updated
> boot-floppies including this makedev fix and a new version of
> boot-floppies from the 2.1.11 version from the slink branch of the
> boot-floppies CVS.  This fixes a number of documentation and
> installation problems which ought to not wait for 2000.  However,
> there is no pressing reason to delay 2.1r3 (the security fixes you are
> doing) by waiting for a new boot-floppies.

Dropping the Security hat now.  I don't think that this bug justifies
an update.  I have installed systems that are headless without trouble.
On the first gpm was selected by accident causing some error messages.
Still I don't think this justifies an updated set of boot-floppies but
proper documentation on the release web page on the Debian web server.

Now setting the Security hat on again.  I have proposed a policy for
the Security Team.  This covers regular updates of stable every one
or two months depending on the amount of security updates.  We're
getting quite a lot of security alerts these days, so I guess that
I'll propose the next stable subrelease by next months.  This should
give you time to discuss the issue with Vincent and prepare new
floppies without the need to hold 2.1r3 from being released.

Regards,

	Joey

-- 
The good thing about standards is that there are so many to choose from.
	-- Andrew S. Tanenbaum

Please always Cc to me when replying to me on the lists.


Reply to: