I do not follow why retirement is not necessary anymore. Retiring ursine packages consists of these steps/has the following consequences:

• adding a dead.package file to dist-git with the reason for retirement/removing the original contents to properly indicate that the package is not maintained anymore
• blocking the package in koji so that it is not distributed anymore in new Rawhide (Branched) releases
• if a package is retired for more than two weeks, a new review is required

At least the dead.package file and requiring the re-review should IMHO still be performed for package stream branches.

If a package stream branch is not used in any module anymore, does this really mean that the resulting RPM packages will be removed from the Fedora repository with the next update?

Also the package ownership is also important in ursine packages for bug reports - how is the bug ownership for module packages configured in Bugzilla? IMHO it is also important that if a stream branch is no longer maintained, that is is reflected in Bugzilla by assigning bugs to the orphan user.

And for ursine packages, orphan packages should be retired if they are orphaned for more than six weeks - does this orphan state exist for stream branches as well or are they either maintained or retired?

I do not follow why retirement is not necessary anymore. Retiring ursine packages consists of these steps/has the following consequences:

adding a dead.package file to dist-git with the reason for retirement/removing the original contents to properly indicate that the package is not maintained anymore
blocking the package in koji so that it is not distributed anymore in new Rawhide (Branched) releases
if a package is retired for more than two weeks, a new review is required

At least the dead.package file and requiring the re-review should IMHO still be performed for package stream branches.

I could get behind this if you consider it important.

If a package stream branch is not used in any module anymore, does this really mean that the resulting RPM packages will be removed from the Fedora repository with the next update?

Yes, it does.

Also the package ownership is also important in ursine packages for bug reports - how is the bug ownership for module packages configured in Bugzilla? IMHO it is also important that if a stream branch is no longer maintained, that is is reflected in Bugzilla by assigning bugs to the orphan user.
And for ursine packages, orphan packages should be retired if they are orphaned for more than six weeks - does this orphan state exist for stream branches as well or are they either maintained or retired?

The proposal doesn't state this explicitly but it implies stream branches are orphaned and maintainers of modules that include them share the responsibility for the package.

If the package is also ursine, I think it will technically be owned by the ursine maintainer, from Bugzilla's perspective. For stream branch-only packages, those would appear as ursine.

What would you propose?

We will discuss this in the FESCo meeting on Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

I think I understand one motivation here - when packages are being maintained in a essentially modular fashion, it's annoying to have multiple layers of ownership to deal with.

But I do wonder about the scenario:

• Application maintainer realizes that there application can't handle the latest version of libfoo
• They put a reference to stream branch libfoo-1.4 into their modulemd
  <time passes>
• The application maintainer is now the owner of libfoo-1.4 stream branch without realizing it

When a package has an active maintainer, I'd expect that maintainer to be making the decisions about what is supported and supportable. Maybe instead of having implicit delegation for all stream branches, there should be an explicit mechanism to delegate a stream branch to a module with matching streams - and use that data to detect when another module wants to "tag along" with a stream branch and might need to pick up maintainership.

Please remember to read the proposal and vote in ticket.

From the meeting:

ACTION: @asamalik will update the proposal with 1) mechanics to define branch ownership and 2) explicit module branch ownership as well as explicit package branch ownership

Deferring further discussion to the next meeting

Hence I keep the meeting tag for the further discussion.

Nothing actionable on https://pagure.io/modularity/issue/115

Should we close this ticket due to inactivity?