cvs commit: ports/devel/portmk/Mk ports/devel/portmk/scripts ...

Mark Linimon linimon at
Sun Sep 18 18:11:28 PDT 2005

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  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,, and hopefully, lie in the
near future).

In addition, after reading through the PRs myself just
yesterday, I have rediscovered that there was significant effort to create, 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: .

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 (
   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


More information about the cvs-ports mailing list