Prev: Newer autoconf (2.63+)?
Next: Silent distfiles conflict between graphics/xface.el andmail/x-face-e21.
From: Matthias Andree on 30 Mar 2010 07:46
Am 30.03.2010 09:30, schrieb Garrett Cooper:

> If this is really slick and tinderbox / whatever tools is doing its
> job and no PRs have been reported for X number of days on a given port
> (would require tie-ins to GNATS, or whatever), perhaps it would be
> nice if ports were automatically `promoted' from HEAD to STABLE? I
> mean, why do something if a computer can do it for you, right :)?

It appears you're proposing the Debian style of management, which has a stable
branch, a testing branch and an unstable branch. Packages usually propagate from
unstable to testing under certain preconditions.

--
Matthias Andree
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Matthias Andree on 30 Mar 2010 07:55
Am 30.03.2010 09:18, schrieb Garrett Cooper:

> There is one important note to make:
>
> Many times you're forced to upgrade packages because of ABI breakages,
> etc. What would happen if there was a CVE assigned for PNG tomorrow
> (like there was for JPEG a year and change ago) where mass changes
> were required of 1k ports -- you could either have to bump the
> versions or patch _every_ single port like Dirk has been doing for the
> past week and a half (and is still doing... also with other folks'
> help thankfully -- poor guy).

Well, a security fix usually does not mean you're breaking ABI. The ABI break
would be caused by a design flaw in the application that cannot be fixed any
other way, or by lack of backports of the fix to the old ABI version, so you're
forced to use the new ABI. To complicate matters, using "stable" versions is
exactly the trigger for the latter situation: your using an older than the
latest version is what creates the need for backporting the fix to the "stable" API.

> Furthermore, people could check out packages with RELENG_* tags, and
> maintainers could use their best judgment to tag the files appropriate
> to the change being committed?

I don't think this proposal is useful. Technically it would work, but socially
it wouldn't. Why? RELENG_* tagging would require that port maintainers oversee
the implications for all supported FreeBSD releases, possibly run tinderboxen to
test (and thereabouts) and would likely scare away maintainers. Not exactly
what we need.

> Also, another idea that was briefly underscored that I (and other
> folks more importantly) like is that release branches should only be
> updated for security releases. I admit, this is a pain in the rear
> with large / sweeping commits (JPEG/PNG anyone :/?), but at least it
> would ensure that stability is largely maintained.

Basically you'd try to hold off on the "large/sweeping commits" for those
branches and backport.

How about if we create a new port if the ABI or API change in incompatible ways?
As in: jpeg.(N-1) is kept around for compatibility with ports that don't support
jpeg.N (either ABI or API wise) and slowly phased out later. This takes care of
the libraries. Open issue: how to handle includes.

This approach (remotely) resembles what the (regexp) database/db[34]. ports are
doing, with some magic in Mk/bsd.database.mk to allow for picking the incurred
DB version semi-automatically.

--
Matthias Andree
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Charlie Kester on 30 Mar 2010 12:36
On Tue 30 Mar 2010 at 04:55:01 PDT Matthias Andree wrote:
>
>I don't think this proposal is useful. Technically it would work, but socially
>it wouldn't. Why? RELENG_* tagging would require that port maintainers oversee
>the implications for all supported FreeBSD releases, possibly run tinderboxen to
>test (and thereabouts) and would likely scare away maintainers. Not
>exactly what we need.

Maintainers are already effectively forced to run tinderboxen when
commmitters respond to PR's with terse comments like "Build failed on
FreeBSD 6.x, here's the build log, please look into it." ;)

Not that I mind. I enjoy the debugging exercise. But if there's going
to be increased pressure to use tinderbox, perhaps something could be
done to streamline and speedup the creation of new jails?

I'm not sure what I think about this proposal, however, or whether my
relatively obscure ports will even be affected by it. So I'm following
the discussion with interest but don't know enough to contribute
anything useful.

-- Charlie
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Alexander Churanov on 30 Mar 2010 14:15
Hi folks,

* Updates which break shared libraries would not be allowed within such
> a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng,
> libjpeg, xorg).


The easiest way to accomplish this is to replace FreeBSD with Ubuntu. I'm
not sure we really want this.

Personally, among other things I like FreeBSD for the ability to have most
recent software on a box with relatively high reliability. I always make fun
of Linux users, who need a full OS upgrade to get new Emacs or httpd.

To be specific, I'm against having "frozen stable" branch with only security
updates and the "current unstable" branch. Most GNU/Linux distros already
work this way. Do you want the FreeBSD to "always just follow" or "go in
advance"?

I think, that the following is necessary for FreeBSD to be competitive :

1) Have a "frozen" branch for each release with only security fixes - for
conservative enterprise users, migrating from RedHat
2) Have the "current unstable" ports in head - only for maintainers
3) Provide a "quite-current stable" snapshot of ports from time to time, say
2-3 months.

4) The "quite-current stable" port releases should not be strict on
calendar, but tied to updates of "huge base" packages (kde, xorg, png).
Ports should be published when we succeeded with fixing them.

5) To minimize additional work on security issues I'd like to suggest using
GNU/Linux distros, specifically RedHat, - let them work for us! Of course,
brothers from OpenBSD should also be respected - they do much work in this
field.

The strategy above would have following effects:

1) People using "release" packages will have security fixes in them. Linux
will not be better in this respect.

2) Please using port snapshots will get more reliable software updates than
now. This will create a unique experience of having quite recent and at the
same time consistent applications. We win!

3) Less stresses in the life of maintainer. Now I have to think about ports
reliability every time, with the new strategy I would treat ports in "head"
as "experimental" and work on stability only for port releases. Easier
updates, more consistency!

Alexander Churanov,
maintainer of devel/boost-*
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Alex Dupre on 6 Apr 2010 10:35
Ivan Voras ha scritto:
> In some cases the burdens are obvious - the maintainer(s) would need to
> e.g. maintain three versions of the ports - a random example would be
> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
> (CURRENT/9.x) branch.

You are free to become the new PHP maintainer then ;-)

As a side note, I'm going to update it to 5.3.2 in the next days.

--
Alex Dupre
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

First  |  Prev  | 
Pages: 1 2 3
Prev: Newer autoconf (2.63+)?
Next: Silent distfiles conflict between graphics/xface.el andmail/x-face-e21.