Ion3 license violation
philip at freebsd.org
Thu Dec 13 03:07:23 PST 2007
On 2007-12-13 10:54:47 (+0000), Tuomo Valkonen <tuomov at iki.fi> wrote:
> On 2007-12-13, Philip Paeps <philip at freebsd.org> wrote:
> > I have not gone awol. I replied to your email about the port being out of
> > date the day after you sent it.
> Closer to two days...
> > It is not particularly difficult to comply with the licence. It just
> > takes a bit of time (which I'm happy to spend) to keep up with new
> > releases. Of course, sometimes new releases will coincide with ports
> > freezes.
> This time the thaw came quite in time (or did I cause it?-), and maybe the
> period could have been even a bit longer if people would communicate about
> such things.
I'm fairly sure you didn't cause the thaw. :-)
> However, there's still the problem of binary packages ending up in the
> release snapshots without prominent notices of obsoleteness.
The FreeBSD ports tree is not "pegged" to releases as in other systems. So if
a -release user downloads a ports tree, he gets the same tree as someone who
is using -current.
You do have a point that "obsolete" versions will end up on the snapshots of
the ports tree on cds. We have a perfectly good mechanism for dealing with
this, it's called NO_CDROM. I would be happy to add this to the Makefile.
> I don't think RCs and development snapshots should end up there at all.
I don't share your opinion about RCs. Regarding development snapshots,
however, the port was named 'ion3-devel' until the first RC - indicating quite
clearly that building it gave you software in development. The only reason I
did the rename at RC-time was because I thought a release would happen 'real
soon' after. It didn't. Note that I'm not complaining about your release
schedule. I should have waited with the repocopy until after the release. My
> That's the problem with distros' megafreezes: you can't sync the development
> of thousands of packages. And as for stable releases, even they should get
> bugfixes promptly. Maybe the 28 day limit can be relaxed in such cases a
> bit, but even half a year may be too long -- two years like with Debian is
> certainly too long.
I don't think there has ever been a FreeBSD ports freeze which lasted as long
as six months, let alone two years. Generally a month or so is the order of
> It depends on the bug at hand: segfaults should be fixed very promptly,
> whereas minor glitches are not that big deal.
During ports freezes, approval from portmgr can be saught to fix things like
Philip Paeps Please don't Cc me, I am
philip at freebsd.org subscribed to the list.
BOFH Excuse #180:
More information about the freebsd-ports