OpenBSD Journal

Ports tree locked for 4.8

Contributed by maxime on from the one-girl-in-every-port dept.

On the 1st of August, Marc Espie (espie@) announced on the ports@ mailing list that the ports tree has been locked, meaning that users are welcome to test and report bugs. Please read on for Marc's message:

From: Marc Espie 
To: ports@openbsd.org
Subject: ports lock
Date: Sun, 1 Aug 2010 19:28:28 +0200

We're moving towards lock. I assume Naddy will back me up on this.

No new ports. Only updates that fix things (if minitube/youtube-dl
are not yet in, they should be).

Eric tells me the py* updates will unbreak some architectures.

mplayer's ogg/ogm is apparently broken. Please fix this, and this only.
No need for a brand new mplayer that will break things.

Marc also posted a message on the same list to explain what fixes may or may not be commited, and what users need to do if they are willing to help:

Commit after approval by espie@, naddy@, sthen@

Try to filter stuff so that we don't have to reject everything.

What is appropriate ?

- actual fixes that fix actual problems
- compilation fixes for specific architectures
- license issue fixes (those are ALWAYS appropriate)
- careful WANTLIB fixes (missing WANTLIB that need to be there)
- update fixes (missed @pkgpath and whatnot).

If you really want to help:
- complete patches are a plus (especially, not just the patch, but
also needed infrastructure changes such as REVISION bumps).
- don't assume "we know". Explain what the patch does, why it's needed,
etc.

So, people wanting to help are invited to test as much as ports they can, and to report any bug they might find on the ports@ mailing list. As always, patches are more than welcome.

(Comments are closed)

Comments

  1. By Ray Lai (ray) ray@cyth.net on http://cyth.net/~ray/

    Bug reports should go to ports@, not through sendbug.

    Comments

  2. By Ted Walther (TedWalther) ted@reactor-core.org on http://reactor-core.org/

    I wish there would be some advance notice before the lock goes on.

    Comments

    1. By Ted Walther (TedWalther) on http://reactor-core.org/

      I missed the new-ports lock. Again. Here is the port for anyone that needs newlisp:

      http://dpkg.reactor-core.org/port/newlisp-port.tgz

      newLISP is a small, extremely fast LISP interpreter that supports inline assembler. It has been extensively tested on 32bit and 64bit platforms, i386, amd64, sparc, ppc, AIX, VAX, OS/2, and so on.

      The port is current for newlisp-10.2.10.

      To use it, untar it inside the /usr/ports directory, cd to /usr/ports/lang/newlisp, and make install.

      Comments

      1. By phessler (phessler) on http://theapt.org

        > I missed the new-ports lock. Again. Here is the port for anyone that needs newlisp:
        >
        > http://dpkg.reactor-core.org/port/newlisp-port.tgz
        >
        > newLISP is a small, extremely fast LISP interpreter that supports inline assembler. It has been extensively tested on 32bit and 64bit platforms, i386, amd64, sparc, ppc, AIX, VAX, OS/2, and so on.
        >
        > The port is current for newlisp-10.2.10.
        >
        > To use it, untar it inside the /usr/ports directory, cd to /usr/ports/lang/newlisp, and make install.


        Please re-submit this after we unlock.

    2. By phessler (phessler) on http://theapt.org

      > I wish there would be some advance notice before the lock goes on.

      That is part of the point. There *is* no advanced notice before lock. We don't want broken things shoved into the tree just before lock, and have to spend weeks unborking everything.

    3. By Marc Espie (espie) on

      > I wish there would be some advance notice before the lock goes on.

      tried that, doesn't work at all.
      at some point, we did play "nice" and told people lock was going to happen, to slow down. Instead, what usually happens is that things speed up ! all kinds of people wake up, and start pushing all kinds of new trivial stuff at the developers, thus ensuring a hefty load of work.

      I can understand them: when you're young, and new to OpenBSD, 6 months between releases seems like an awfully long time and your pet project MUST make it into the next release, or you'll die. ;-)

      So we decided (heck, who am I kidding, THEO decided) to spring the lock as a "surprise" on people. The exact timing varies, a lot based on how Theo perceives the tree (if people keep shovelling IMPORTANT, UNSTABLE diffs right next to release, he's very prone to lock earlier).

      In ports, we have VERY little advance warning. The schedule being what it is, locks tend to happen at roughly the same period each year, but hey, this release, Theo told us "now would be a good time to slow down", and 12 hours later we're in lock.

      How so ? because, again, as soon as I started hinting "slow down", I saw things "speed up", with people trying to cram as much shit to fuck us before the release, as usual...

      In the end, I guess I finally understand why we do things our way: because it works. Yes, it hurts people feelings. And yes, we won't allow "exceptions for stuff that MUST go in now". Because it makes our job simpler. Because we can filter IMPORTANT stuff, and still get VERY COMPLICATED FIXES in at the last minute or so.

      We want OpenBSD development to be as smooth as possible. You have important new stuff that missed the release ? Hey, there's another one six months down the road. Meanwhile, you can help testing the current release, sending useful bug-reports, play with current.

      Also note that 4.8 is very sexy, and contains a LOT of difficult changes. People will comment on the kernel parts, but there are lots of acpi changes, changes to the way processes behave (in preparation for our Nessie: rthreads), improvements to utf8, and THE GCC4 COMPILER for quite a few architectures... this does mean a lot of fixes, probably more so than usual.

      Comments

      1. By Ted Walther (TedWalther) on http://reactor-core.org/

        That is very astute. The same thing happened in Debian, that is why they take so long between releases. Every time they try to lock, people start pushing stuff in. Without a strong leader like Theo, the battles between developers make things drag out.

        Do the locks come off before release? On the day the iso images are shipped to the CD manufacturing plant?

        Comments

        1. By phessler (phessler) on http://theapt.org

          > Do the locks come off before release? On the day the iso images are shipped to the CD manufacturing plant?
          >

          The tree is unlocked after the CDs are shipped to the plant, but before the CDs are shipped to you. You'll also see commits that reference the ports unlock. Additionally, all hackathons happen during full unlock.

      2. By Janne Johansson (jj) on http://www.inet6.se

        > > I wish there would be some advance notice before the lock goes on.
        >
        > tried that, doesn't work at all.
        > at some point, we did play "nice" and told people lock was going to happen, to slow down. Instead, what usually happens is that things speed up ! all kinds of people wake up, and start pushing all kinds of new trivial stuff at the developers, thus ensuring a hefty load of work.
        >

        The obvious /.-style car analogy would be redlights. If you show yellow light when moving from green to red, then people will speed up even though the yellow light is supposed to mean "now is a good time to plan to stop".

        If you ALSO have a procedure where "as long as there is a car in the crossing, dont go from yellow to red", then you will have a very long yellow time. So telling people "we will soon freeze" causes more (crazy) stuff to go in, instead of less.

        Sweden for instance, gives people fines for running against yellow lights (when avoidable) which basically means yellow is the new red. The slack when running a red light is more or less zero now.

        I guess the motivation was more or less the same, we must do this in order to actually have people stand still on red lights.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]