[Piuparts-devel] jessie-rcmd ?

[Andreas Beckmann]

On 2015-01-23 13:17, Holger Levsen wrote:
> Hi Andreas,
> 
> thanks for your patches as always and sorry for the late reply!
> 
> On Sonntag, 18. Januar 2015, Andreas Beckmann wrote:
>> I think it's better to add a testing-rcmd, ${stable}-rcmd will be
>> covered by ${stable}2${testing}-rcmd.
> 
> I rather not use stable+testing but wheezy+jessie instead.

I think for a selected set of tests "stable" and "testing" can be useful
- if they are more useful as moving targets than with fixed codenames,
i.e. we would just delete/rename/readd then after each stable release.
In this category fall testing2sid, stable2sid,stable2testing2sid (these
yould catch upgrade errors before a package migrates to testing (that
are not found by testing2sid and friends), but will bring some false
positives (especially if a package is not in testing for a reason)),
${(old)+stable}222testing (ending in unstable would be too messy)

${foo} means static codename of foo, not moving target foo itself

>>       p.conf: add [testing-rcmd] (with --install-recommends)
> 
> NACK on this.

Right now we have wheezy2jessie-rcmd tests.
What benefit would we get from an additional wheezy-rcmd test? That
could catch remove/purge errors that occur only if there were more
packages installed than in a plain wheezy test. I have a sid-rcmd
running locally, but that's not too helpful since unstable contains
quite some uninstallable cruft. Therefore I thought designing it as a
moving target testing-rcmd would be more useful. I expect we will add
jessie2stretch and jessie2stretch-rcmd quite early which would make
jessie-rcmd not that much useful either.

But if you prefer, I can turn it into jessie-rcmd.

>>       piuparts_issue: transient apt-cache failures
>>       piuparts_issue: remove empty logfiles

these two I had removed because of a quoting error, fixed version was
included in recent batch

> 2e37e88 detect_archive_issues: move archive_issues.txt to master/

That's a statefile and therefore is better located in master/ than in
htdocs/, also we should have a backup of it since it contains historic
information.


Andreas