I think the proposal should be reworded to be:

Package stream branches don't have explicit owners. The ownership is defined implicitly by the following:

• Module stream branches do have explicit owners. These owners are also responsible for all package stream branches they include in their module.
• If one package stream is included in multiple modules owned by multiple people, they would collectively maintain the package stream.
• If there is a package stream branch that is not being built in any module or package, it's unmaintained. It can be optionally retired, but doesn't have to be, because it's not being built. If someone decides to include this stream branch into their module, they'll become the owner.

@james I think the FPC should probably review this ticket

@langdon Thanks! I've changed the proposal to include your edit which is much better than what I wrote!

well, this has been put in the way that only modular version exists, however there might be package which is built traditionally and in a module.

@ignatenkobrain Are you referring to the potential use of stream branches for ursine builds? I don't think that's currently the case anywhere or am I wrong?

Not sure if this is an FPC matter but I think an ack from FESCo would be welcome. I'll file the ticket.

we'll discuss this one with FESCo

https://pagure.io/fesco/issue/2028

(in Traditional package ownership)

There is just one person owning the package and building it.

This is wrong assumption. There is generally N persons owning a package and even more building it. (That said, it shouldn't really affect the rest of the proposal.)

What is forgotten here is that people actually need access to maintain something. Unless you are a provenpackager, I guess you need to be listed explicitly in the src.fp.o rpms/xxx repo to be bale to push into the stream branch. And as long as this is not automatically happening by checking who maintains the module that uses a particular stream branch, this will get complicated. Having a direct branch <-> maintainer(s) mapping would be much more transparent.

One thing that concerns me is "stealing" maintainership.

(In an ideal world with unicorns and rainbows everybody is good and nothing can go wrong I don't see a big problem with your proposal. Well in that world, dist-git could be a wiki and everybody would "own" everything.)

However, in the real world I've seen that people tend to be very possessive about their packages. Also, people have their packaging opinions and of course their opinions are superior to the opinions of others. Traditionally, if somebody wanted access, they needed to ask for it. Now they only need to create a stream / module / whatnot and they get access automatically. I can imagine a situation where this could generate conflict in opinions and a sense of injustice. Today, packagers get angry if provenpackagers push to their sacred specs. Now imagine if somebody could just steal their precious. Also, everything here happens in a transitive (not very transparent) manner, so it's very hard to see who owns what and the situation can be very hard to untangle.

tl;dr I think explicit ownership information beats all this. All that's needed is owners per branch. EPEL could benefit from this as well.

if somebody wanted access, they needed to ask for it

Yep. No matter how much I like the loose ownership that SIGs and PPs provide, I still think that for many packages (and some packagers), specific ownership is needed, and any proposal has to keep this.

I think explicit ownership information beats all this. All that's needed is owners per branch.

Agreed.

So the general feeling from the last FESCo meeting I got:

• The group feels that an explicit package branch ownership would work better
• We should look into the mechanics of branch ownership as opposed to package/module ownership

I have updated the the proposal. I left one question there we need to discuss.

I don't really see that as a proposal to vote on. It just says what we need.

I don't really see that as a proposal to vote on. It just says what we need.

Yeah, this is not actionable. We need a concrete proposal what component will contain the authoritative information, what this will be propagated to other components, and how packager will interact/update it.

Proposal:

• ownership for any component in dist-git (including rpms and modules) is tracked per branch
• the authoritative source of branch ownership is FPDC
• dist-git queries FPDC to determine who should be able to push to given branch
• a cron job is used to sync ownership from FPDC to Bugzilla
• any person with any ACL on any branch of given component is added to default CC list in Bugzilla for that component
• owner of master branch is additionally set as default assignee in Bugzilla
• packagers can query or update branch ownership by interacting with FPDC, either using fedpkg wrapper or using FPDC API directly

• src.fp.o displays the ownership info from FPDC
• who can change the ownership info in FPDC?
• who i responsible for doing all this? are they aware?

any person with any ACL on any branch of given component is added to default CC list in Bugzilla for that component

Tried this, doesn't work, many packagers want to have the ability to commit on a package without being added to the CC list of every bugs (think: kernel or gnome developers)

owner of master branch is additionally set as default assignee in Bugzilla

Maintainers not wanting to maintain packages in EPEL will disagree to become the default assignee on the Fedora EPEL component.

We can't fix this with significant changes to Pagure.

Does that mena we should attempt to do that?

Sorry, with more detail: Pagure is likely being replaced by another solution. We will open new tickets once the replacement is selected.

Wait, what? I did not see any discussion about that anywhere on devel/infra lists.

Pagure is likely being replaced by another solution

This is not the first time I've heard that. Could you please point me to a place where this was decided?

@sgallagh I'm aware that the infrastructure team is looking at future requirements for git forge support, and whether the team has the resources to meet them in-house. No decisions have been made about this to date, and if there's a proposal to be made, it will most definitely be made in the community.

Sorry, I must have gotten my wires crossed on that. Apologies for the fire drill!

Also, if anyone's curious, the reason I'm looking at this ticket is I'm sitting in with the modularity folks on a ticket sweep this morning, so @sgallagh asked me about the above. ;-)

Can we please keep this open before the replacement tickets exist?