sillsdev
KeymanLegacyBundle package should be SIL-controlled
Probably the first choice would be to see if Keyman team wants to "own" them under their organization. If not, then sillsdev would be the next most logical place.
@darcywong00, do you want any part of the legacy bundle hosted on Nuget?
It is for sure not the case that we would expect all of our dependencies to be SIL-owned. We can definitely rely on third-party DLLs. But it probably is the case that any packages developed by SIL people with SIL resources (funding, computers, etc.) that are primarily or fundamentally for SIL use should be owned/published by SIL. If the individual programmer(s) move on and we later need to update something, it would require a fork and package dependency change, which would then be a breaking change. We've all seen cases with popular packages where the original publisher stops maintaining it, and someone else (or sometimes multiple people) fork it, and go on to maintain it, but this almost always leads to some confusion, so if we can avoid setting ourselves up for that, it would be preferable. At this point, perhaps the argument could be made since it has already been released this way that it is a moot point and not worth another breaking change.
At risk of being overly clear, this is certainly not the only package whose owner is an SIL employee. It's safe to say that Eberhart is a top offender here (https://www.nuget.org/profiles/ermshiperete). For example, NDesk.Dbus is owned by him and referenced in libpalaso.
I am more than happy to add whatever user or replace myself with them, but keep in mind that if this an actual issue, then we'll need to fix more than just this package.
Great case in point. For example, the NDesk.DBus package lists a project website on bitbucket, so it's a 404. No guarantee that something like that could slip through the cracks if owned by SIL, but hopefully less likely.
Right. I just requested sillsdev and sil-lsdev to be owner for this package.
Sure enough. It's a breaking change: https://build.palaso.org/buildConfiguration/Transcelerator_TransceleratorWinDefaultPullRequestsSilPackagesFromNuGet/550897
Nice. I'm glad we labeled it. I'm also not sure why it actually disappeared. I do notice that the packages.config change adds a line for Keyman, so that's different. It also references it as net48, which would be wrong (maybe not enough to break it). Is this something we should look into?
Not sure, but maybe. Transcelerator targets 4.7.2, so it's just possible that the mismatched framework reference is what caused the change.