Date: Fri, 20 Dec 2002 15:19:16 +0000 (GMT) From: 520023893678-0001@t-online.de (P. U. Kruppa) To: Maxim Sobolev <sobomax@FreeBSD.ORG> Cc: Akinori MUSHA <knu@iDaemons.org>, <portmgr@FreeBSD.ORG>, <ports@FreeBSD.ORG> Subject: Re: Thoughts about ports freeze Message-ID: <20021220144255.S934-100000@small.pukruppa.de> In-Reply-To: <20021220131339.GB11573@vega.vega.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Dec 2002, Maxim Sobolev wrote: > Well, all this is fine, but doesn't answer one of my main points: why > do we shift responsibility for our inability to encourage fellow developers > to pay attention to CURRENT not only to stable to our end users? Why should any developer care for a system which is not used and tested by end users? I - a typical non developing end user - cannot use CURRENT because I will not get any support if things don't work. So I have to track STABLE . If you whish to get things going, 5.0 should be pushed into STABLE (and into this list). Uli. > And I > doubt that such tactic will bring anything but users' dissatisfaction, > because even a year-long freeze will not help to encourage reluctant > developer, who doesn't have 5.0 and therefore doesn't care about it, > to fix something. The only things that can push him into doing it > are (a) if he will use 5.0 on day-to-day basis or (b) he will be > flooded with problem reports from angry users running 5.0. The current > freeze won't lead to neither (a), nor (b), instead it (from my own > experience) leads to: (c) user makes a conclusion that FreeBSD > release-engineering process sucks. > > > Also I really can't understand why there is a ban on introducing new > ports into the tree - by the very definition new ports can't increase > overall breakage on -current, i.e. if after addition the port is broken > on -current it means that number of the ports that do build on -current > remains unchanged. > > -Maxim > > On Fri, Dec 20, 2002 at 01:47:01PM +0900, Akinori MUSHA wrote: > > At Fri, 20 Dec 2002 02:15:29 +0200, > > sobomax wrote: > > > Personally I think, that while pushing 5.0 out of the door is very > > > important thing to do, but having it stumbled on the way of STABLE/RELEASE > > > users is not good at all. Personally I've heard many complains from the > > > > I thought about that some time ago, but I came to think that taking > > the time to fix ports for 5.x now is a good thing. > > > > See the list of those broken ports. Ports committers haven't payed > > much attention to ports that are broken on CURRENT. They (including > > me) keep saying "My port builds just fine on STABLE. It's CURRENT > > that's broken." However, the 4.x -> 5.x update introduces a lot of > > incompatibility and we must get developer communities out there to fix > > their software to support FreeBSD 5.x before 5.x becomes the main > > stream. Or we'll just lose developers' attention. > > > > > local community about popular ports not being updated in time, as > > > they used to. And I don't have a single good argument to reply to those > > > complains with - users usually don't care about 5.0, but they do care > > > about their 4.x production machines receiving latest updates and fixes, > > > and the current situation pisses them off. > > > > Complaints are hard to deal with. We deal with them based on requests > > and patches for approval. We didn't say we are not upgrading ports at > > all, but we can update ports with mandatory review so we don't > > introduce any more breakage. Their, and our frustration could be > > resolved if we portmgr work harder to review their patches. > > > > > > Well, I don't think we are going to take this long freze period in the > > 4.8 release cycle nor in the 5.1 release cycle, but only this time. > > The C/C++ compiler is major upgraded and many source files need > > changes, we now comply much more with the standards and many configure > > scripts and headers need changes. > > > > > Perhaps we could just branch out current state of the tree and unlock > > > it for normal use, while allow to commit onto the RE branch only after > > > getting portmgr's approval. What we are currently trying to do is > > > to mimic techiques used for src tree (long freeze), but IMO this > > > approach is inappropriate for ports, because they are fundamentally > > > different - the former is slow moving-target, while the latter is > > > fast-moving one. > > > > When we have much less broken ports, we can consider tagging and > > unfreezing the ports tree for 5.0-RELEASE earlier than the actual > > release, leaving the chance to slide tags for some ports that are > > found to have security vulnerabilities or be seriously broken after > > the unfreeze. > > > > -- > > / > > /__ __ Akinori.org / MUSHA.org > > / ) ) ) ) / FreeBSD.org / Ruby-lang.org > > Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp > > > > "I believe in what I see, I believe in what I hear, > > I believe that what I'm feeling changes how the world appears." > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message > *-----------------------------------* * Peter Ulrich Kruppa * * - Wuppertal - * * Germany * *-----------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021220144255.S934-100000>