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

[Ion-Mihai Tetcu]

On Sun, 18 Sep 2005 20:11:25 -0500
linimon at lonesome.com (Mark Linimon) wrote:

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

I know, I've crashed my head against his wall a few times. BTW, I don't
think it makes any sense to keep ports/77444 open.

 [ ... ]

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

This is almost a no-op, else we'll end up being in slush/freeze half
the time. And as a side effect maybe we'll be able to tag the ports for
a release closer to the release data.


-- 
IOnut
Unregistered ;) FreeBSD "user"