#115 Discussion: Stream branch ownership for packages & modules
Opened 3 months ago by asamalik. Modified 18 days ago

Traditional package ownership

In the traditional model, packages are built out of release branches (i.e. f28, f29, ...) directly by submitting package builds.
There is just one person owning the package and building it.

Modular package & module ownership

With Modularity, packages are being built indirectly by submitting a module build which automatically spins package builds for all package stream branches the module includes.

One module can include multiple packages, and one package can be included in multiple modules.
How do we deal with ownership?

Proposal

Update 2019-01-19: We've discussed an approach involving implicit, collaborative package ownership based on who builds it in their module. However, we felt that an explicit branch ownership would be a much better approach. So here's an update:

We need to be able to define owners for individual stream branches as opposed to the whole component. That goes for both modules and packages.

Because we expect different motivations behind having different module/package streams, we need to enable different packagers to own different streams independently on each other.

The ownership needs to be reflected in DistGit and Bugzilla.

But what would be the authoritative source of this information?


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

(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.

Login to comment on this ticket.

Metadata