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

Re: Release team to utilize Salsa CI for Forky quality assurance?



On 2026-01-14 23:07:44 +0200, Adrian Bunk wrote:
> On Wed, Jan 14, 2026 at 09:21:31AM -0800, Otto Kekäläinen wrote:
> > Hi!
> 
> Hi Otto!
> 
> >...
> > 1. If the package has Vcs-* field as a sign that it is using VCS (93%
> > Salsa), but the uploaded packages has extra contents not pushed to
> > VCS, delay the migration by 10 days. The uploader can easily notice
> > they forgot to 'git push' and get the delay down by simply pushing
> > their commits.
> >...
> 
> ~99% of my uploads are for packages where I am not a maintainer.
> The vast majority are NMUs for release critical bugs.
> 
> How can I do "simply pushing" when I do not have write access to
> the repository?
> 
> When I do have write access but there are already commits on the branch 
> I do not want to include in my NMU, what am I supposed to do?
> There is a large diversity of preferences how maintainers want NMUs 
> integrated into Salsa when unrelated commits are already on the branch.
> 
> For me it is a real problem with Salsa that most discussions seem to 
> forget that many uploads are NMUs.
> 
> 
> And I do not understand why you are you so insisting on getting testing 
> migration delays as stick for Salsa.
> 
> Each of Tracker, DDPO and the Maintainer dashboard already shows when the
> git tree is not up to date, if a maintainer is interested in information
> it's already there.[1]
> 
> Maintainers who care already see this information no matter where they
> check.
> 
> Many maintainers will anyway not notice any issue with testing migration 
> until Paul submits a "fails to migrate to testing for too long" RC bug 
> after 30 days.

ACK, information that the CI is failing or that repos are not up to
date is already displayed in enough places. I also fail to see how
adding delays on outdated repos or failing CI captures a useable form of
regression compared to testing. If builds fail, the are not a candidate
for migration. If autopkgtests fail, they are not a candiate for
migraton. If piuparts fail, they are not a candidate for regression,
etc.

An as Adrian noted, this completely discourages NMUs and pushes more
work on the release team to make sure that NMUs that we actually want
to migrate and get penalized by this proposal migrate in a sensible time
frame.

I am sure that salsa CI has it values, but I don't see how the salsa CI
status would catch anything in addition to the tools that we already
have integrated in britney to catch regressions.

Cheers
-- 
Sebastian Ramacher


Reply to: