On 21 Apr 2006, at 06:49, Geert Hendrickx wrote:

> On Thu, Apr 20, 2006 at 08:25:18PM -0700, Garrett D'Amore wrote:
>> Actually, what this really sounds to me like, is we need some kind of
>> automatic regression test suite that picks up nightlies and runs  
>> them.
>> If a test suite passes for a build, it could auto-tag them.
>>
>> A website listing regression failures would be helpful, too.
>>
>> You wouldn't be able to cover everything this way (e.g. kind of hard
>> to test all the different hardware combos), but it would be a good
>> start, at least.
>
> This seems overkill for what I was looking for.  These tags shouldn't
> occur weekly or even mothly.  Maybe they should just be feature-based.
> Imagine a user who would want to experiment with tmpfs, or needs some
> new driver from -current.  He wouldn't want to use an "arbitrary"
> checkout of -HEAD which could be unstable, or even not build,  
> because of
> an unrelated problem.  He just would like to checkout some tag  
> which was
> set after the commit of the feature/driver/fix he wants/needs, and use
> that.

Couldn't he just extract the source for that day? Would that not work?

> Of course there would be no guarantees for for this tag being
> "good" (it's -current after all), it would just be an indication, to
> help/stimulate the testing community.

I think if we make a known to-be-good-head it needs to be relatively
tested, not just a quick indiction of 'Oh well, it doesnt contain  
this new
feature so its possibly stable'. At the same time it also needs to  
contain
features that need to be tested further (which is why most people run
CURRENT for the project, to find new problems). One solution could be
the possibility of having a known-to-be-ok tag a few days/weeks
after a major feature is committed. This allows people to test it  
further
but still know it's relatively 'OKish'.

		---
		Liam J. Foy
		<liamfoy@sepulcrum.org>
		BSDPortal.org