cvs commit: ports/devel/portmk/Mk bsd.apache.mk bsd.database.mk bsd.java.mk bsd.port.mk bsd.port.post.mk bsd.port.pre.mk bsd.port.subdir.mk bsd.tcl.mk ports/devel/portmk/scripts distfiles.sh options.pl options.sh ranksites-fping.pl ...

[Mark Linimon]

On Sun, Sep 18, 2005 at 11:47:14PM +0300, Ion-Mihai Tetcu wrote:
> >   - Remove temporarily all eik's work. We'll try to find a decent way
> > to deal with major changes. Of course we'll reuse his good ideas
> 
> The ranksites* part would be very useful.

The problem with eik's changes was that he combined refactoring with
rewriting and this practice always makes it problematic to figure out
exactly what has changed.  So if some obscure problem showed up during
testing (or worse, in production) -- and that is almost guaranteed with
several thousands of lines of make/sh/awk/sed/ perl magic -- it would
have been problematic to track it down.

Since eik's last update to portmk just less than a year ago, a lot of
infrastructure has changed -- we've committed a number of changes to
bsd.port.mk.  In particular, moving out particular pieces related to
specific subsets of ports will IMHO help us to figure out what future
changes ought to be.  (Some of these we've already done; some, like
bsd.database.mk, bsd.apache.mk, and hopefully bsd.x11.mk, lie in the
near future).

In addition, after reading through the bsd.port.mk PRs myself just
yesterday, I have rediscovered that there was significant effort to create
bsd.perl.mk, which foundered due to ongoing problems regression-testing
against a number of perl ports that were not compliant with the assumptions
built into it.  I'd like to hope that we can restart that process as part
of this rework of devel/portmk.  (From the PR, it seems like the original
submitter of it abandoned the idea in frustration.  While I feel bad about
this, there's no way to go back into the past and change that.)  For those
interested: http://www.freebsd.org/cgi/query-pr.cgi?pr=55515 .

There are two major factors that I'm hoping will make a difference in
the adoption of ports infrastructure changes going forwards, as opposed
to a year ago:

 - It should now be much easier for individuals to do regression testing
   using the Marcuscom tinderbox code (http://tinderbox.marcuscom.com).
   This should make it much easier for many people to be testing proposed
   patches, and thus require less stopped and restarted runs across the
   whole set of buildenvs when they are tested on pointyhat.

 - We (the Project as a whole) now have a much better understanding of
   how FreeBSD ought to do Release Engineering in the future, including
   the effect that src QA (since it effectively determines the length of
   ports thaws) has on the ports tree development cycle.  Hopefully this
   will lead to the tree being in freeze and/or slush much less of the
   time.  To see how much this has hurt us in the past, see the last graph
   in http://people.freebsd.org/~linimon/schedule.html.

mcl