When you should block a stabilization

Many times in the past, a lot of people found bugs for packages actually in a STABLEREQ.

Every time my answer was: make it as a block only if is a regression; and every time the next question was: “What is a regression?”.

Well, seems that word is not familiar for all, let me explain this concept.; first, see the word regression as a synonymous of worsening.

I guess, for this concept, an example should give you ‘the basic idea’

Imagine we are testing app-arch/tar-1.26-r1 (at this moment it is really ~arch).

During the testing we find 4 issue:

1)the CFLAGS variable is not respected.
2)there is a sed failure in the ebuild.
3)there is a test failure.
4)tar fails to extract some archives in a specific mode.

I chose these four problems as an example for a reason. The regressions must block the stabilization, independently of the type of problem.
Each of them represents a problem of a “different nature”.

1)means builsystem issue
2)means ebuild issue
3) and 4) means specific software problem

What you should do now? You should test the last stable version of tar (1.26 in this case) and check if you are able to reproduce these problems.

From the subsequent tests, you can see that tar-1.26 fails to respect CFLAGS(1), fails to sed one or more files(2), there are no test failures, and you can reproduce the extract issue.

Now, go to our bugzilla, and check if there are open bugs about these problems. If not, please open the bugs but pay attention about the blocks.

Since the first is reproducible in the last stable, is not a regression, it means no block.
Since the second is reproducible in the last stable, is not a regression, it means no block.
Since the third is not reproducible in the last stable, is a regression, it means block.
Since the fourth is reproducible in the last stable, is not a regression, it means no block.

For this case, you should open a new bug about the test failures and make it as a block for the current stabilization. Obviously, if there are open bugs that need a block, do it instead of open new(duplicate) bugs.

Now, apart the test failures and ignoring the failures 1 and 2, the obvious question is: “Why we should mark stable tar-1.26-r1 if it fails to extract stuff?”.
Here you should learn the regression concept; imagine you are an user, you are using tar-1.26 and you can’t extract some archives; we mark stable 1.26-r1 and you can’t do it too. There are no changes for you and no worsening. You can’t do before and you can’t do now again.

Probably this post is documented elsewhere, but I hope that can helps.

This entry was posted in arch testing, gentoo. Bookmark the permalink.

One Response to When you should block a stabilization

  1. Mark Reiche says:


    thanks for these explanations. This helped a lot!



Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.