Re: policy proposal: updating packages with many dependencies

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Mar 19, 2025 at 08:39:32AM -0400, Greg Troxel wrote:
 > > Seems reasonable, with one suggestion: when we finally boot cvs, we
 > > should use branches for this rather than wip. Fewer things to mess up,
 > > can merge atomically (might be necessary for lockstep updates of
 > > certain things), a lot easier to capture the state with more bulk
 > > builds, etc.
 > 
 > Sure, but if a depending package can be fixed to work with both old and
 > new, that's better, and can be committed as the fixes happen.

Right. But that isn't always the case, especially with things like
boost. And having the branch makes test runs a lot easier.

 > > (long-running-style development branches, I'd think, not the rebase or
 > > merge-squash kind.)
 > 
 > I agree not squash, but I generally favor rebasing for clarity and I
 > don't think we should have a norm to avoid it.  That's VCS religion
 > territory and there's no need to agree for this proposal.

It is and it isn't. Rebasing a branch that multiple people have been
committing to (which is the the point here) is into "not recommended"
territory, even in the git world.

But we don't need to get into that right now.

 > We already have a group norm, not expressed as policy, that we discuss
 > before changing the default version of versioned lanaguages.  I think it
 > would be good to formalize that, and add pgsql/mariadb and a few other
 > things.   But, because discusssion as ~always happened, that's more
 > housekeeping than addressing problems.

Right.

-- 
David A. Holland
dholland%netbsd.org@localhost