rodent%NetBSD.org@localhost writes: > It's not my intention to break the tree, but to get these updates in which i > didn't have time for earlier in the quarter. pypi isn't auto-indexing their > directories anymore and the script i made to check for new package updates > wasn't working with it. There maybe 12 more small python packages i'd like to > update tonight if there's time. Certainly nobody thinks you're trying to break things. The freeze is intended to be a time where we look at build results (manual or bulk) and fix things that are broken (meaning packages don't build or don't work). Something being out of date is not a big deal, unless there's a security advisory, and even then there's the choice of applying the patch vs updating. The basic issue is that every change runs the risk of breakage, especially given that no one can test on all platforms. This has been fuzzy in the freeze guidance; leaf updates early on has been ok, and near the end gradually less so. So stepping back from detailed rules, updating a dozen packages just before the branch hits is not consistent with the goal of producing a branch lacking problems. This is definitely taking the view that if a package didn't really need to be updated on 3/1, it's ok for it to stay that way in Q1 until 7/1 when Q2 hits, but that's the way I see it. Given that we have 3 month branches w/o updates, I think it's fine for this to be 3.5 or even 4. I intend to bring up changing the freeze rules to be much more of a updates for security only plus fixes for identifiable problems. That's not because of anything you did - I was already thinking this over the freeze.
Attachment:
pgpUmZUcv9WfB.pgp
Description: PGP signature