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.