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
itetcu at people.tecnik93.com
Mon Sep 19 00:26:04 PDT 2005
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"
More information about the cvs-all
mailing list