Christoph Egger wrote: > Steven Chamberlain <ste...@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 ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141111013015.gc13...@squeeze.pyro.eu.org
