Hello,
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.
Cheers
jonas
Attachment:
signature.asc
Description: OpenPGP digital signature