Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Dec 2002 15:13:39 +0200
From:      Maxim Sobolev <sobomax@FreeBSD.ORG>
To:        Akinori MUSHA <knu@iDaemons.org>
Cc:        portmgr@FreeBSD.ORG, ports@FreeBSD.ORG
Subject:   Re: Thoughts about ports freeze
Message-ID:  <20021220131339.GB11573@vega.vega.com>
In-Reply-To: <86lm2ls3ei.wl@archon.local.idaemons.org>
References:  <20021220001529.GC9963@vega.vega.com> <86lm2ls3ei.wl@archon.local.idaemons.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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? 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021220131339.GB11573>