You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've got a great practice of creating OS support issues that track progress on supporting new distros. I'm a user of these issues and believe that they could be more discoverable.
There are three key tasks that are relevant to me:
Which distro versions are "incoming", about to be supported?
Which distros are "outgoing", on their last legs?
Where are the os-support issues for the last few versions for a given distro?
I was recently looking at devcontainers/images#90. I was able to answer the question I had by just looking at that issue. It's an interesting approach to two out of the three tasks I raised. I'm not a fan of every-growing issues, so don't propose that we adopt this approach wholesale. It is, however, good inspiration. I also noticed that this issue is pinned in devcontainers/images. I like that. That's very good for discoverability.
I'd propose we do the following:
Create and pin an "on-deck" issue that lists both incoming and outgoing distro versions, in two aptly named tables. For example, Alpine 3.22 would be added to the "incoming" table when we first became aware of it and would be removed from it after all release and product work was completed (and users were supported). The same would be true in reverse as Alpine 3.22 went EOL.
Create an index issue for each distro, with a link to each of the relevant os-support issues. Links to each of the distro indexes could be listed in another issue, references from the "on-deck" issue and any other relevant places.
I think this would be similar to what the dev container folks are doing, with a slightly improved scheme. I guess that this proposal is a small bit of additional work, with significant benefit. I suspect it would help the team a lot with the task of adding support for multiple distros at once. The "on deck" issue would be very amenable for being reviewed as a single artifact in the .NET Tactics meeting.
The text was updated successfully, but these errors were encountered:
We've got a great practice of creating OS support issues that track progress on supporting new distros. I'm a user of these issues and believe that they could be more discoverable.
There are three key tasks that are relevant to me:
I was recently looking at devcontainers/images#90. I was able to answer the question I had by just looking at that issue. It's an interesting approach to two out of the three tasks I raised. I'm not a fan of every-growing issues, so don't propose that we adopt this approach wholesale. It is, however, good inspiration. I also noticed that this issue is pinned in
devcontainers/images
. I like that. That's very good for discoverability.I'd propose we do the following:
os-support
issues. Links to each of the distro indexes could be listed in another issue, references from the "on-deck" issue and any other relevant places.I think this would be similar to what the dev container folks are doing, with a slightly improved scheme. I guess that this proposal is a small bit of additional work, with significant benefit. I suspect it would help the team a lot with the task of adding support for multiple distros at once. The "on deck" issue would be very amenable for being reviewed as a single artifact in the .NET Tactics meeting.
The text was updated successfully, but these errors were encountered: