Re: Plan B for kfreebsd
Christoph Egger wrote:
> Steven Chamberlain <steven@pyro.eu.org> writes:
> >> > But certainly for unofficial releases, a supplemental repository would
> >> > be great for us. We can bypass usual freeze policy to fix bugs we think
> >> > are important, which may not have got an unblock.
>
> I guess we need that in some way -- we need to do some uploads that do
> not concern the "normal" release process like a last kernel upload.
Also, between now and release there is a risk of kfreebsd regressions
introduced into testing that we want to hold back / revert.
I've had opinions for a while that Debian freeze policy has some flaws,
concerning not just kfreebsd but the rest of the distro. An unfortunate
consequence of having a fixed freeze date, is that many big changes
are rushed in at the last moment.
(c.f. http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp00005.html)
Then during freeze, when most testing happens, we discover the trivial,
annoying bugs that accumulate to make user experience less than ideal -
but by then we can't fix them, because in the Debian BTS they only
qualify as 'important' or lower severity, and likely not eligible for
unblocks.
You and I probably have made dozens of tiny changes on our own kfreebsd
systems to make them work smoothly. For other, especially new users,
those could be a total roadblock and I want to avoid that if we can at
all. I've seen examples of users get frustrated by already-known issues
like that and give up on using kfreebsd, and it's sad to see.
> > I don't think it's limited to that; in making an unofficial release,
> > we become our own release managers, and can try to apply our own...
> > personal taste here. I'll discuss that on -bsd@ rather than here.
>
> Which also needs we need to do that. For almost all of debian, the
> normal release procedures should really work fine for us as well and the
> more we can get automatically the better IMHO.
There may at least be some short-cuts we can take, things we can do to
make the unofficial release easier for just a few of us to support. We
could declare some packages unsupported perhaps.
This is another rant coming, sorry, but I think it's relevant when
we're talking about doing an unofficial release:
I do feel many Debian procedures take way too much time and involve
many people to fix trivial issues. A major usability problem might
be fixable with just a one-line config file edit, but often there'd
be a bug report, perhaps patch submitted by someone else or picked from
upstream where it was fixed already; maintainer commits it to a
packaging repo, uploads, it's built and waits for dinstall, and then
testing migration.
So for users running testing it could be 7-14 days for fixes to reach
their machines. Arguably some of that time is meant for QA, but some
of it is really just waiting around for some next step to happen. (And
there are other good ways to supplement QA besides this).
For stable, there might need to be a separate upload prepared, debdiff
sent to -release@ and reviewed, approved then uploaded, built, queued
for many weeks until next point release. In that case there may have
been at least 4 people each do some amount of work for that obvious
change, probably one of hundreds in the stable release lifetime.
Or it may not meet the criteria and have to wait *2 years* or so for
the next release.
Imagine this was a problem faced in a corporate IT deployment. It
wouldn't be acceptable to have such a workflow; work time is scarce,
and the issues could be affecting others' work until fixed. Surely the
same constraints or goals apply to a volunteer software distribution?
> Plus everywhere we
> diverge from the "normal" release process we need to stay atop of these
> deltas for the whole time.
That's a good point I will try to bear in mind when I get carried away!
In sid, by the way, I'd prefer things to stay totally in keeping with
Debian practices so that maintainers can still, if they wish, build and
maintain their packages for kfreebsd as they do already. Changes we
make should ideally go into sid and not just stay in an unofficial repo.
> There's also stable updates and security we need to think of. I guess
> stable updates can be handled without problem manually as it's punctual
> and not so time critical.
Yes, the stable-pu queue has debdiffs, we can somehow build updated
packages based on those and update an unofficial stable repo, in sync
with point releases.
> security is actually what worries me most. Guess ideally we can still
> source from security on wanna-build so builds "just happen" whenever
> there's a update.
For the kfreebsd core packages (kernel and such) it's actually easier
that we don't have to involve the security team and can update those
directly in an unofficial repo.
For the rest of the archive, we can try and do similar to the above;
we might have to wait for updated source packages to become public, due
to the embargo around security issues and the private security buildds.
But otherwise we can try to create a system to quickly build security
updates, mostly automated.
> Guess we need someone to handle build failures and
> problems there ourselves but that's way more managable.
I think build failures affecting only kfreebsd, for security updates,
will be extremely rare. I only recall it happening once or twice
(e.g. torque package) in squeeze and wheezy. They got summarised at
https://release.debian.org/stable/missing-security.html
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: