[boost] Re: Regression report for Releases?

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-03-21 07:57:58

David Abrahams writes:
> Agreed, it's too hard, but that shouldn't stop us from talking about
> what we would be doing in an ideal world.  Accordingly:
>
>   - A health report for the latest release should always be available
>     on the website.  

Meaning user-oriented report showing whether she can use a specific
library on a specific platform, or something else?

>
>   - Regressions from the previous release are nice to know but less
>     important.  

I disagree. The are crutial for current Boost users, in particular in
deciding whether to upgrade or not.

>     I realize we show both in one report, but this may
>     help us adjust our emphasis or coloring 

? We didn't establish yet that we _want_ to adjust our emphasis.

>     (maybe it's already
>     perfect in the user report; I don't know)

I'm sure it's not perfect (and the user reports are currently in
flux), but it's our current understanding that the needs of developers
and users are different enough to warrant different
emphasis/coloring/etc.

>
>   - A health report for the current state of the repository should
>     always be available on the website.

I submit that a "health report" without regressions/explicit markup
information is useless. What's your use case for it?

>
>   - Regressions from the previous release are crucial to know also

Yes.

>
>   - When we branch for a release, we absolutely must track the release
>     branch, but we also should be continuing to display the health of
>     the trunk

Right now it's impractical, but may be with enough resource donations
this is going to change.

>
>   - We ought to have a system for automatically notifying anyone who
>     checks in a regression, and displaying information about the
>     change responsible for the regression on the status page.

Agreed 100%.

>
>   - There should be a way for a developer to request testing of a
>     particular branch/set of revisions

This can easy get out of control, though. How do we ensure that not
all our resources are used to test something on some branch and the
main trunk still gets what it needs to be tested on a regular basis?

>
>   - There should be enough computing power to handle all these tests
>     in a timely fashion.

Right, and some mechanism to make sure that when it's not the case,
the mainstream testing gets priority.

-- 
Aleksey Gurtovoy
MetaCommunications Engineering