[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: On (semi-)automated testing and improved workflow of LTS uploads


Mike Gabriel:
>> In the internal discussions, the following vision for an improved upload
>> workflow arose:
>> 1. Upload packages targeted at LTS suites to some dedicated place for
>>    automated testing
>> 2. Run automatic tests (piuparts, autopkgtests, lintian?, ...)
> Maybe, probably not lintian. As the package maintainer, at the time
> (old)oldstable (meaning the current Debian LTS) turned from testing to
> stable, might not have had their packages in shape lintian-wise. Also
> only using an old lintian would be appropriate. A recent lintian on old
> packages just creates too much noise (which we won't fix anyway).

The Salsa-CI runs lintian from the target suite against the packages.
While I agree that we should not put any effort into fixing longstanding
lintian warnings, running lintian per default and providing the output
for review seems sensible to me.

>> 4. (Optionally?) demand acknowledgement by a second (different) LTS
>>    developer
> Although demanding a second ACK adds an extra delay to our workflow, I
> sense that such a second pair of eyes peering at security patches might
> greatly improve the quality of the LTS work. Even if we don't come up
> with some auto-test engine, we should consider "peer-"reviewed uploads.

I agree.

>> So far, two implementation approaches have been discussed:
>> */ Build an own service that provides a dedicated upload queue (e.g.
>>    'lts-proposed-updates') which accepts uploads targeted at LTS suites,
>>    and processes the uploaded packages according to the workflow
>>    described above.
>> */ Use Salsa-CI and their pipeline[2] for as much of the above proposal
>>    as possible.
>> What's your thoughts on this? Do you think that we could implement
>> most/all of the desired workflow using Salsa-CI/Gitlab-CI? Or would it
>> be better to build it entirely independently of Salsa - e.g. implement
>> it in dak?
> Personally, I think that using Salsa for this, adds an extra layer of
> complexity to the uploading workflow, because we have to pump all
> packages that we want to fix in LTS through GitLab.

We need a place to upload them to (for tests and reviews), anyway. So
what's the advantage of having a dedicated service (and use resources
there) compared to using some of Salsa's resources for it.

To be honest, I don't consider the expected extra CPU cylces for Salsa
that high. The amount of LTS security uploads by us (and if the Security
Team would use a similar solution: even the amount of security uploads
by us and them) isn't that high compared to the number of Debian
packages hosted on Salsa already.

> Many packages are packaged in Git already (probably on Salsa) and have a
> repo location of their own. With applying GitLab based CI to the
> workflow, the LTS team would add an extra Git repo, just for the LTS
> uploads done by the paid contributors.

Yeah, I agree that this is a downside. An ideal workflow would probably
look like this:

1a: for packages on salsa, fork the repo to lts-team/packages/<pkg>
1a.1: if repo doesn't provide a 'jessie' branch, 'gbp import-dsc' the
      jessie sources into a new branch
1b: for packages not on salsa, push the latest package version there
2: apply the package updating workflow, as discussed above
3a: file a merge request against the official package repo that asks
    to merge back the changes

99: whenever support for a LTS release ends, cleanup our team workspace
    and remove packages that no longer exist in the next LTS release(s).

> Some package uploads may even be
> embargoed, so generically, the LTS-team namespace on Salsa needs to be
> private (which excludes other contributors, also the usual package
> maintainers/uploaders, by default).

We could use a dedicated private subgroup and move the working repos
there whenever we need to handle embargoed issues.

> As our intention is to operate on packages (not on upstream code in
> Git), so I'd suggest deploying/extending some sort of
> setup/infrastructure that utilizes Debian means for auto-testing LTS
> package upload candidates. And I really love the idea of a review
> workflow for package uploads.

One advantage of Gitlab/Salsa is that reviewing changes is very
convenient in the Gitlab UI, especially if we used merge requests for
new security uploads and require a second developer to merge them.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: