Merging needs_review tickets in alphas
Jeroen Demeyer
I would like to open a discussion on merging needs_review tickets in
alpha versions of Sage. Since alpha versions are meant for testing, I
think tickets can be tested earlier if they are merged in an alpha. I'm
certainly not saying we should be doing this for all tickets, but in
certain cases (especially for "big" tickets) it would help. For
example, for the PARI upgrade #9343, I have made several "prealphas" for
testing. I think these could have been "true" alphas. Another example
is ticket #9896.
We have to be careful not to do this to too many tickets otherwise we
lose track of what's happening, but for a few tickets each release I
think it can be justified.
So my concrete proposal would be: any author of a needs_review ticket
can ask the release manager to merge his ticket in the next alpha
release, the release manager then decides which needs_review tickets to
merge. If the ticket does not get a positive_review by the time the
release candidate comes out, it gets removed again.
As a side effect of this, it might also be easier to find reviewers for
these tickets, because they can test it simply by downloading the latest
alpha.
I'm completely open for your opinions on this matter.
Jeroen.
William Stein
(1) Whether or not to do this should be up to the release manager of
the day. (That would be you for the next release...)
(2) I see no good reason not to do this, assuming the release
manager can manage. The only constraint with tickets should be that
the official releases don't have code that still "needs_review".
(3) I have in the past usually included needs_review tickets when
making releases myself, and just made sure they all got reviewed
before making the release.
William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
leif
> So my concrete proposal would be: any author of a needs_review ticket
> can ask the release manager to merge his ticket in the next alpha
> release, the release manager then decides which needs_review tickets to
> merge. If the ticket does not get a positive_review by the time the
> release candidate comes out, it gets removed again.
>
> As a side effect of this, it might also be easier to find reviewers for
> these tickets, because they can test it simply by downloading the latest
> alpha.
finally merged) *solely* by "blind" testing, i.e., the *code* /
sources should also still get properly reviewed by at least one
person.
But I agree it seems often the case a mature ticket doesn't get a
positive review early (and therefore not merged) just because the
reviewer hesitates due to a lack of resources (accessible test
platforms or simply time to test on a wider range of systems).
Also, in case an already merged "needs review" ticket requires further
changes, it should be well-documented on the ticket which patch(es)
went into which alpha. An alternative for larger tickets is of course
to open follow-ups.
If not too many tickets get tested this way, there shouldn't be much
trouble with rebasing other tickets that were based on a later
unmerged "volatile" one.
2ct,
-Leif