[cut-team] Rethinking CUT
Anthony Towns
aj at erisian.com.au
Fri Sep 17 11:37:47 UTC 2010
On Mon, Sep 13, 2010 at 08:43, Joey Hess <joeyh at debian.org> wrote:
> It gets the ball rolling, and make no mistake, there is considerable
> inertia to overcome.
Speaking of intertia...
Where are we at on the snapshots implementation? AFAIK there are at
least two unsettled "objections" to the current plan on the wiki --
(1) what frequency it should be, one month, three, six, other? (2) are
official snapshots needed, given Michael's script -- what benefits
over that are official snapshots trying to achieve?
I'm a bit concerned that we're not really on the same page, and I
guess to some extent I think we haven't really established a clear
idea on who we're trying to help. As far as I can see, CUT's maybe
possibly going to help some/all of the following groups of people who
are being under-served by Debian at the moment:
(1) people who could be running testing right now, but aren't
because of non-technical issues (misplaced concern about security,
fear from the name, insufficient publicity, negative reactions from
DDs)
(2) people who want to run testing right now, but find it
technically difficult because of the installation and upgrade path
(both the initial install stable, upgrade to testing; and the daily
upgrades of testing forever after)
(3) people who already run testing, but find their systems aren't
usable in the way they need it to be (from a quality perspective, ie
packages are there but don't install/work at an acceptable standard)
(4) people who already run testing and want newer software from
unstable (that would be fine on their machine, but is blocked by
britney for other reasons -- eg transitions, issues on other
architectures, etc)
(5) people who already run testing/unstable/experimental and want
newer software from upstream (that is unavailable to them because of
release concerns rather than stability concerns)
(6) the installer team, who find it overly difficult to do beta
releases against testing and get useful feedback (because it takes too
long to update the beta to fix bugs due to britney delays; because
betas get rendered obsolete automatically by testing updates)
(7) the release team, who have to worry simultaneously about
people using testing/unstable wanting new software (cases 4 and 5), at
the same time they're trying to stabilise the collection of packages
for a stable release
I think official snapshots would help with (2) and (6), and possibly
(1) since if more people beat the technical problems and enjoy the
experience, they'll pass on good recommendations.
My feeling is that the point of "rolling" is to address (4), (5) and
(7) (and maybe (3)), and I think that's a much more challenging set of
problems.
Personally, I'm most interested in seeing improvements in (2) and (5)
-- they're the itches I'd like scratched. On the other hand, I'm not
worried much at all about (3) and (4) -- I think they're mostly pretty
well handled already. Obviously, YMMV.
If others think the above makes sense, it might also be a useful way
to help keep us from talking at cross-purposes when we miss the issues
someone else is talking about because we're focussing on the ones we
care about.
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
More information about the cut-team
mailing list