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 -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.