Re: On (semi-)automated testing and improved workflow of LTS uploads
Hi,
On 11/07/2019 15:20, Jonas Meurer wrote:
>> 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).
I have my doubts about enforcing Git. Large packages such as Firefox can
take several GB once extracted and are time-consuming enough to handle
as-is, without an extra layer of storage, you see what I mean?
Beware that packages stored in Git may not use git-build-package.
TBH I don't understand much how Salsa-CI is to be used, are will it
(re)build massive packages from source, or will we commit pre-built
packages?
> We could use a dedicated private subgroup and move the working repos
> there whenever we need to handle embargoed issues.
Yes, embargoed issues are very rare and special-casing them sounds
better than making everything private (especially from a transparency PoV).
> 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.
Note that some issues are purely compilation-related (e.g. building the
source package with a more recent Debian release) and won't appear in a
Salsa source diff view.
debdiff is my authoritative source :)
Cheers!
Sylvain
Reply to: