Hi all you folks who have exercised your fingers and eyes because of
'vancouvor',
In my quest to see how things work, I have made some major revision to
my diagram.
http://debian.home.pipeline.com/
the new diagram is newdebian2.png
any comment appreciated (before the whole shebang is outdated)
Also, in lieu of the recent events, I have my own 2 yen.
*reducing mirroring of archs reduces cost and load on mirrors but
this does not remove load on debian ftpmasters,security or release teams:
arch support decisions can not be based upon downloads or availability:
*there are few s390 built compared to x86 by many orders of magnitude.
This goes for m68k,sparc,alpha and other.
*some folks use apt-proxy and such which makes non-i386 counts far less
accurate beside the fact of woody popcon.
*there is stuff to get on ebay or things like the trenton computer fair
that will be available for many years
*people in NPO,school, or the 3rd world will have i386,i486,P I,P
II, P III, P IV while IBM or HP will buy/lease 64 engines. so do we
drop x86-32bit? Most of the x86 packages are i386 based but we could
bump it up to i686 for etch or 64bit for etch+1 making many folks happy.
but then what about the other folks?
*embedded arch -
# packages in each arch is not the same. e.g. silo will
never be built for x86,lilo will not be build for sparc: This
is part of the release process!
ways to reduce load on release team:
all archs do not have 100% of the packages for i386, so
why can't we make some less used packages not be RC for
the slower arch
maybe not build some resource-problematic packages for
slower arch.
Also, if an arch is mostly server or embedded, why build
all non-(server|embedded) packages for it (gnome-arm,kino-mips).
And for my last piece de resistance: communication improvement through
email and documentation:
add virtual packages in the BTS for:
maintainer, teams, developers, buildd people
USE CASES:
a maintainer notice a buildd is down, makes a bug report on
'arm-buildd' which is sent to that person and maybe
other folks - release manager, dpl, etc
maintainer is not responding to patches, so user files
bug on $MAINTAINER and is forwarded to DPL or DAMs
arch needs buildd and no response from release team,
so add a bug on RELASE-team and forward to DPL
maintainer is not responding to security announcement
or the package is not keeping up with upstream
and a NMU is needed, a bug is filed because of the
non-responiveness. many NUM bug's should lead to a
maintainer being asked why s/he can't keep up.
which may lead to packakge being abandoned, removed,
co-maintained.
a packages is stuck in NEW, the maintainer is not
getting any answers, so files a bug against FTPmaster
and this is forwarded to DPL
etc.
anyway. I cant wait for sarge, thanks to everyone who made it possible!
may Debian live long and prosper! (funny trekie hand expression here)
-Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
_, _, ,'`.
`$$' `$$' `. ,'
$$ $$ `'
$$ $$ _, _
,d$$$g$$ ,d$$$b. $$,d$$$b.`$$' g$$$$$b.`$$,d$$b.
,$P' `$$ ,$P' `Y$. $$$' `$$ $$ "' `$$ $$$' `$$
$$' $$ $$' `$$ $$' $$ $$ ,ggggg$$ $$' $$
$$ $$ $$ggggg$$ $$ $$ $$ ,$P" $$ $$ $$
$$ ,$$ $$. $$ ,$P $$ $$' ,$$ $$ $$
`$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$ $$
`Y$$P'$$. `Y$$$$P',$$$$P"' ,$$. `Y$$P'$$.$$. ,$$.
Attachment:
signature.asc
Description: Digital signature