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
Several teams would appreciate being notified they were next in line (or soon to be) for maintaining a package whose dependency another team (so far the maintainer) had dropped. This would ideally be achieved via some automated means based on CR data.
For example: team A is the 3rd in the line of succession to maintain a package. Team Z is the current maintainer and has dropped the dependency. Accordingly, team A is now the 2nd in the line of succession for maintaining the package. Team Y is the likely new maintainer as soon as team Z negotiates it (which probably was already underway).
As such, a notification should be sent to team A alerting it of the new status quo, including the possibility of team Y also looking forward to dropping its dependency and thus request team A to own the package. Team A would then be advised to prepare for that possible state, which could encourage a possible elimination of the dependency as well.
The text was updated successfully, but these errors were encountered:
I have a similar RFE which would be for maintainers to be notified when a package that they don't want is added to the compose. Examples would included alternative runtime libraries like musl, dietlibc, libc++, etc.
Several teams would appreciate being notified they were next in line (or soon to be) for maintaining a package whose dependency another team (so far the maintainer) had dropped. This would ideally be achieved via some automated means based on CR data.
For example: team A is the 3rd in the line of succession to maintain a package. Team Z is the current maintainer and has dropped the dependency. Accordingly, team A is now the 2nd in the line of succession for maintaining the package. Team Y is the likely new maintainer as soon as team Z negotiates it (which probably was already underway).
As such, a notification should be sent to team A alerting it of the new status quo, including the possibility of team Y also looking forward to dropping its dependency and thus request team A to own the package. Team A would then be advised to prepare for that possible state, which could encourage a possible elimination of the dependency as well.
The text was updated successfully, but these errors were encountered: