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

Re: Plan B for kfreebsd

Hi all!

First, I do not really know enough about release workflow I guess to
know what -release@ does not want to do for kfreebsd apart from stamping
it as an official release so some of my whishes may be totally
reasonable or way of -- please tell me!

Steven Chamberlain <steven@pyro.eu.org> writes:
> Andreas Barth wrote:
>> > If we don't stay in testing, we'd at least want to archive off the
>> > last-built kfreebsd packages before they are deleted...
>> That sounds sensible. As you want to do an unofficial release, I think
>> we should coordinate so that this doesn't create unnecessary
>> additional efforts.

My hope here would be to keep a kfreebsd-* in testing -- without the RC
severity of bugs and without blocking transition due to out-of-dateness
-- I think release tools have the support for that. It would also just
automatically continue to improve the non-freebsd-specific packages
untill a release happens.

>> > 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.

> 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. Plus everywhere we
diverge from the "normal" release process we need to stay atop of these
deltas for the whole time.

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.

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. Guess we need someone to handle build failures and
problems there ourselves but that's way more managable.



9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Attachment: signature.asc
Description: PGP signature

Reply to: