pkgsrc-Users archive

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

Re: pkgsrc-2013Q4 freeze started



On Thu, Dec 19, 2013 at 11:30:22PM +0900, Izumi Tsutsui wrote:
> wiz@ wrote:
> 
> > On Wed, Dec 18, 2013 at 12:22:14AM +0900, Izumi Tsutsui wrote:
> > > > pkgsrc is now frozen in preparation for the 2013Q4 branch.
> > > 
> > > Could you please mention more specific what kind of changes
> > > needs prior approval during freeze?
> > > 
> > > There was a vague complaint in the previous freeze
> > > and it discouraged certain developers.
> > 
> > Ok, I'll try again.
> > 
> > Not allowed:
> > 
> > * no updates to infrastructure (mk/) without PMC approval
> > * no updates to non-leaf packages with PMC approval
> > 
> > Allowed:
> > 
> > * patching packages to fix build breakage -- but please take care to
> >   not break other platforms. In case of any doubt, send patches for
> >   review first.
> > * security updates -- but be careful here as well
> > 
> > If necessary, leaf package updates are ok, but not recommended --
> 
> Well, "ok but not recommended" seems more confusing than before.

I trust most NetBSD developers to be able to decide for themselves if
an update is likely to break stuff and if it is important to go in
before the branch. Not every package update is really that important
that it can't wait until the next branch.

> > let's try fixing stuff instead, we can update all packages again in ~2
> > weeks.
> 
> Please consider stable branch users and binary packages users.
> 
> If no updates are committed during these two weeks, they won't be
> able to get new versions for three months, while small breakages
> in leaf packages can be easily fixed by pullups in any time.

True, but pullups are also work, for releng. Better to not break stuff :)

> I wonder if we can have simple but defined rules for leaf packags like:
> - no updates are allowed in the last two (or three) days of freeze

That sounds good.

> - "minor" updates is allowed
> - "major" updates require prior approval (by MAINTAINER or PMC)

But then you have the same issue as above: you have to trust the
developer to decide what is a minor update and what is a major one.
How is that different from 'ok, but not recommended.'?

>  - all updates must have "complete changes list" in the commit log

That's not special for the freeze, that should always happen.

> - any update that breaks build will be reverted silently

Well, I'd even give people a day to fix stuff.

> etc.

So you agree that no list will ever clarify all cases :)

> > Is that clear enough? If not, please mention which cases you want
> > stated more explicitly.
> 
> I have following changes in the queue:
> 
> qemu-1.7.0:
>  All changes are almost mechanical, but I've tested it only on
>  NetBSD/i386 6.1, and it's a "major" release (bumped from 1.6.1).
>  https://gist.github.com/tsutsui/7975864

qemu is not a leaf package, and is in particular used by the NetBSD
testing framework (py-anita), so if there is no critical bug fix, I'd
delay this update until after the branch, where we have more time for
testing it.

> mlterm-3.3.2 (will be released in this year):
>  Most changes are bug fixes from 3.3.1, but it will also contain
>  new features for 4bpp framebuffers on NetBSD/luna68k and OpenBSD/luna88k.
>  (it's so annoying to build pkgsrc-HEAD on slower machine)

That's a leaf package and I don't see any problems with updating that.
 Thomas


Home | Main Index | Thread Index | Old Index