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

Re: management of debian/salsa-ci.yml (Was: Why is the team standard to use two-file includes for Salsa CI?)



On Saturday, August 16, 2025 11:52:55 AM Mountain Standard Time Lucas Nussbaum 
wrote:
> On 16/08/25 at 09:57 -0700, Soren Stoutner wrote:
> > On Friday, August 15, 2025 10:08:09 PM Mountain Standard Time Lucas 
Nussbaum
> > 
> > wrote:
> > > On 15/08/25 at 15:11 -0700, Soren Stoutner wrote:
> > > > On Thursday, August 14, 2025 11:11:08 PM Mountain Standard Time Lucas
> > > > Nussbaum>
> > > > 
> > > > wrote:
> > > > > I wonder if the should centralize CI configuration, using something
> > > > > like:
> > > > > ------------------------>8
> > > > > ---
> > > > > 
> > > > > include:
> > > > >   - https://salsa.debian.org/ruby-team/meta//raw/master/salsa-ci.yml
> > > > > 
> > > > > ------------------------>8
> > > > > 
> > > > > This would allow us to use defaults that differ from salsa-ci-team's
> > > > > (centrally enable a job that is disabled by default) or add a 
custom,
> > > > > team-specific job. What do you think?
> > > > 
> > > > I would be fine with that.  However, up until the point that we have 
an
> > > > accepted, centralized Ruby Team CI configuration, I think we should
> > > > follow
> > > > the default recommended Salsa CI configuration unless there is a good
> > > > reason to make modifications.  As such, I would recommend reverting 
this
> > > > commit:
> > > > 
> > > > https://salsa.debian.org/ruby-team/redmine/-/commit/
> > > > d0af6274cf5cb42deb13a536ee0802fb64b01172
> > > 
> > > Hi Soren,
> > > 
> > > To make sure we are on the same page:
> > > Do you agree that this would not result in any change in the way the
> > > package is tested, given the content of
> > > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/
> > 
> > debian.yml
> > 
> > > ? And that it would only result in making redmine a special case again
> > > among Ruby packages, since it would be the only one with that CI config?
> > 
> > 1.  Yes, I agree that these are functionally the same, at least for now.
> > However, at some point in the future, the one-line include might diverge
> > from
> > the two-line include in terms of what it performs.
> > 
> > 2.  Point number 1 is part of the reason why I feel strongly that these
> > commits should not have been made in the first place.
> > 
> > 3.  The two-line include salsa-ci.yml was a previous Salsa CI recommended
> > default.  This is one of those cases where a bunch of packages were
> > following
> > a previous standard, many of the package maintainers didn’t notice that 
the
> > standard had changed, some of the package maintainers did notice and 
updated
> > their packages.  In this case, I think it would be best to convert all of
> > the
> > Ruby packages to the new standard, rather than downgrading those which 
have
> > been updated to the now-deprecated standard.
> > 
> > 4.  Because there is discussion about perhaps creating a team Salsa CI
> > default, I can see some wisdom in holding off on converting all salsa-
ci.yml
> > to a one-line include as long as the new Ruby Salsa CI is going to be
> > developed fairly soon.  Otherwise, I would be in favor of converting all 
of
> > Ruby’s default two-line includes to one-line includes now.
> > 
> > 5.  At a minimum I would recommend you revert all of your commits that
> > changed the current standard one-line includes to the deprecated two-line
> > includes.  I haven’t taken the time to find them all yet, but I would
> > appreciate you reverting the one I lined to above as well as this one
> > below.  Or, I can do it the next time I make an upload.
> > 
> > https://salsa.debian.org/ruby-team/ruby-with-advisory-lock/-/commit/
> > 71631a06e02c1396ac1ae86f1303c7078f8f2065
> 
> I would agree with you that it would have been better to move the
> remaining packages from the previous standard to the new standard if a
> large number of packages were already following the new standard.
> 
> In that case, it was more like:
> - about 1200 packages following the previous standard
> - about 10 packages following the new standard
> 
> So in that case, it was easier, as a first step, to move the 10 packages
> back to the previous standard and thus reduce heterogeneity among
> packaging practices and identify other kinds of outliers. I plan to work
> on moving to a team salsa-ci include, or to the recommended practice,
> after this first step.
> 
> I did not keep track of the packages where I made those changes, so I
> cannot easily revert them all, but if you care strongly about that, feel
> free to revert packages whether it matters to you to new standard in
> your next upload (unless the move to a team-standard practice is
> finished by then, which would remove the need for such a change).

Thank you for your work.  I look forward to the upcoming team-standard Salsa 
CI.

-- 
Soren Stoutner
soren@debian.org

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: