[Re-sending as the autopkgtest list on Alioth has ceased to exist. Sorry
for the dup.]

Hi Niels,

On 15-04-18 12:50, Niels Thykier wrote:
> Ok, a few remarks:
> 
> 
> AutopkgtestPolicy.__init__:
>> self.pending_tests_file = os.path.join(self.options.state_dir, 
>> 'pending.json')
>> self.results_cache_file = os.path.join(self.options.state_dir, 
>> 'results.cache')
> 
> The basenames ("pending.json" and "results.cache") are rather generic
> and state_dir is reused between all policies.  I think we should
> namespace these files somehow (E.g. either put them in a subdir or name
> them "autopkgtests-<original-name>").

I am not at all attached to the names. They come straight from the
Ubuntu code, so I see no problem changing them.

> AutopkgtestPolicy.apply_policy_impl:
>>                 # Keep track if this source package has tests of its own for 
>> the
>>                 # bounty system, but only if at least one arch has something 
>> else than
>>                 # running or alwaysfail
>>                 if testsrc == source_name and r - {'RUNNING', 
>> 'RUNNING-ALWAYSFAIL', 'ALWAYSFAIL'}:
>>                     src_has_own_test = True
> 
> How difficult would it be to make the bouncy only apply if the tests are
> successful on all architectures (i.e. no "ALWAYSFAIL")?  If it is a
> trivial matter, then I would prefer to only give bonus to packages that
> are a good example on all architectures.

I'll think about it. I don't know by heart. I expect this to be no
problem. Please be aware though that currently ci.debian.net only runs
amd64. I don't know the details of what would be needed to add other
architectures, but I expect that to be: hardware. ci.debian.net
currently runs on Amazon EC2 instances, I think there is no other
hardware available there. We had some arm flavor in the past, but I
believe that couldn't keep up or the setup was buggy, or something. In
principle this is no issue, and there have been hardware offers. They
just haven't materialized.

> AutopkgtestPolicy.tests_for_source:
>>         # Hardcode linux-meta →  linux, lxc, glibc, systemd triggers until 
>> we get a more flexible
>>         # implementation: https://bugs.debian.org/779559
>>         if src.startswith('linux-meta'):
>>             for pkg in ['lxc', 'lxd', 'glibc', src.replace('linux-meta', 
>> 'linux'), 'systemd', 'snapd']:
>>                 if pkg not in reported_pkgs:
>>                     # does this have any image on this arch?
>>                     for pkg_id in srcinfo.binaries:
>>                         if pkg_id.architecture == arch and '-image' in 
>> pkg_id.package_name:
>>                             try:
>>                                 tests.append((pkg, 
>> self.britney.sources['unstable'][pkg].version))
>>                             except KeyError:
>>                                 try:
>>                                     tests.append((pkg, 
>> sources_info[pkg].version))
>>                                 except KeyError:
>>                                     # package not in that series? *shrug*, 
>> then not
>>                                     pass
>>                             break
> 
> Is this piece still relevant?   AFAICT, #779559 is fixed in stable.  (I
> admit having a feeling of deja vu about this - apologies if I asked
> about this case earlier and simply forgot the answer).

Coincidentally, I investigated last night and removed the code already
locally. Debian doesn't even have a linux-meta package, that is
something Ubuntu specific. In my opinion, the Ubuntu linux-meta package
should just start do the right thing now.

> Beyond that: I also committed some changes for some nits things I
> discovered while reviewing the code.

Ack. And thanks for those. I am not fluent yet in Python to catch any of
these issues.

>> Secondly, assuming we can come to deployment of the new britney policy,
>> I started a gobby document³ to draft an announcement to d-d-a.

[...]

> My "quick" fix would be removing the emphasis and inject a bit longer
> explanation:
> """
> There is one important note to make here on how to go about regressions
> in test cases from reverse dependencies.  We recommend communication
> between the maintainers of the involved packages as one party has
> insight in what changed and the other party insight in what is being
> tested. More information is available in the britney documentation
> [britney].
> """

Ack, will take over.

> On another note: Would you be open for getting hint permissions for
> dealing with autopkgtest policy issues (at least in the initial phase of
> the deployment)?

I recon you already know the answer: yes.

I have an additional note. There is one commit to debci pending review
and deployment that I like to get landed before going live with the
official britney checking autopkgtest: the retrigger link currently only
works with a POST http request with a special debci key; the commit will
add a functional GET request option and optionally works with Debian SSO
certificates. Apart from that, my experience over the last week is very
positive. Just for reference, I started collecting relevant bugs in the
bts with the ci-t...@tracker.debian.org user¹ in the bts (bunk and
ginggs added a couple using the right usertags as well).

Paul

¹
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ci-t...@tracker.debian.org



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to