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 EspieTo: 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)
By Ray Lai (ray) ray@cyth.net on http://cyth.net/~ray/
Comments
By Maxime DERCHE (maxime) on http://www.mouet-mouet.net/maxime/blog/
Fixed, thanks.
By Ted Walther (TedWalther) ted@reactor-core.org on http://reactor-core.org/
Comments
By Ted Walther (TedWalther) on http://reactor-core.org/
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
By phessler (phessler) on http://theapt.org
>
> 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.
By phessler (phessler) on http://theapt.org
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.
By Marc Espie (espie) 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
By Ted Walther (TedWalther) on http://reactor-core.org/
Do the locks come off before release? On the day the iso images are shipped to the CD manufacturing plant?
Comments
By phessler (phessler) on http://theapt.org
>
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.
By Janne Johansson (jj) on http://www.inet6.se
>
> 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.