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

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


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

> 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 :)


Reply to: