Many times in the past, a lot of people found bugs for packages actually in a STABLEREQ.<\/p>\n
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?”.<\/p>\n
Well, seems that word is not familiar for all, let me explain this concept.; first, see the word regression as a\u00a0synonymous of worsening.<\/p>\n
I guess, for this concept, an example should give you ‘the basic idea’<\/p>\n
Imagine we are testing\u00a0app-arch\/tar-1.26-r1 (at this moment it is really ~arch).<\/p>\n
During the testing we find 4 issue:<\/p>\n
1)the CFLAGS variable is not respected.
\n2)there is a sed failure in the ebuild.
\n3)there is a test failure.
\n4)tar fails to extract some archives in a specific mode.<\/p>\n
I chose these four problems as an example for a reason. The regressions must block the stabilization, independently of the type of problem.
\nEach of them represents a problem of a “different nature”.<\/p>\n
1)means builsystem issue
\n2)means ebuild issue
\n3) and 4) means specific software problem<\/p>\n
What you should do now? You should test the last<\/strong> stable version of tar (1.26 in this case) and check if you are able to reproduce these problems.<\/p>\n 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<\/strong> test failures, and you can reproduce the extract issue.<\/p>\n 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.<\/p>\n Since the first 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.<\/p>\n 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?”. Probably this post is documented elsewhere, but I hope that can helps.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading
\nSince the second is reproducible in the last stable, is not a regression, it means no block.
\nSince the third is not<\/strong> reproducible in the last stable, is a regression, it means block.
\nSince the fourth is reproducible in the last stable, is not a regression, it means no block.<\/p>\n
\nHere 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\u00a0no<\/strong> changes for you and no worsening. You can’t do before and you can’t do now again.<\/p>\n