Yep, +1.

I don't get the branch ownership part.

If we have a repo with multiple branches owned by different people, who should be able to change/assign ownership for branches?

If we have a repo with multiple branches owned by different people, who should be able to change/assign ownership for branches?

I'd assume the main admin would.

I don't get the branch ownership part.
If we have a repo with multiple branches owned by different people, who should be able to change/assign ownership for branches?

The branch owner should be able to reassign or if the branch is orphaned, every package should be able to claim it.

Not sure if pkgdb supported it but if it did, group ownership for packages would be nice as well.

The branch owner should be able to reassign or if the branch is orphaned, every package should be able to claim it.

It is not the same as Miro said.

And generally what does it mean to own a branch? Commit rights in Pagure? Build rights in Koji? Maintainer status in FAS? Subscription to BZ issues for a certain version?

Am I digging to deep so it is out of scope of current proposal?

Am I digging to deep so it is out of scope of current proposal?

Yes :)

One note on the technical/content:

The fedpkg request-repo and fedpkg request-branch commands currently involve humans doing the heavy lifting.
This needs to be automated. Packagers cannot wait until a human is available to request a repo or a branch.

We have always had a final step of having a scm admin look at new package requests and block/not process things that are 'wrong' in any way. I have no idea how much this happens anymore, we would have to ask @limb but the several years I was doing all of them I stopped various illegal/non distributable/trademarked/very poorly reviewed things. If we want to do away with this now, we should keep in mind that we may need increased work from releng to clean up after such packages are in and need to be removed.

That said, I want all the rest of these things. I think everyone involved wants them. IMHO if these are important, everyone should press the council to make the 'packager experence' an objective. I don't think this statement is going to do much.Hopefully soon we will have taiga setup and can look at the big projects and what the priorities are and then perhaps fesco saying 'we want these pkgdb/packager things more than A B C that you have higher on your list, we are willing to wait on those for this, will be good input to decide what things are worked when.

We have always had a final step of having a scm admin look at new package requests...

Makes sense. I can amend the proposal to take that into account.

I don't think this statement is going to do much.

I think it can help if/when we approach the Council.

everyone should press the council to make the 'packager experence' an objective

I'm worried that there still needs to be somebody willing to "implement" such objective.

I've amended to proposal to say:

Packagers cannot wait until a human is available to request a branch. As an exception, it is reasonable to wait for a human to sanity check a request if we want additional checks to happen (such as when requesting new repo).

Formal +1 from me (the original statement had a +1 from me too ☺)

The branch owner should be able to reassign or if the branch is orphaned, every package should be able to claim it.

It is not the same as Miro said.

He did not say who would be permitted. My idea was something like this:

a) No bugzilla overrides: All admins can change it
b) Bugzilla override to specific person: That person can change it
c) Bugzillla overrride to orphan user: Everyone can claim it

Not sure if admins should always be able to change it and everyone who can be a bugzilla override probably also needs to be an admin (or at least committer, if there is this distinction).

The proposal intentionally skips such details. They can be determined later if the proposal makes it.

+1 on generic idea, and +1 to concerns on what we can actually do about it

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

Correction: the meeting will be in #fedora-meeting.

We realize that FESCo cannot make somebody do this.

True, but that doesn't explain why services are retired before new systems reach feature parity? Who is making this decision?

APPROVED (+6, 0, -0).

https://meetbot.fedoraproject.org/fedora-meeting/2019-04-26/fesco.2019-04-26-15.00.html

ACTION: mhroncok will file a council ticket

I will leave this open and assigned to @churchyard as a reminder to file the council ticket.

So we have recently within the CPE team started to create small "tiger team" (3-4 people) that would focus on a defined objective until it is done.

For example we had a tiger team migrating key applications to fedora-messaging, we currently have a tiger team working on Bodhi changes needed for rawhide gating.

If you want this to be done by the CPE team you should put together a specification that explain why we should put some effort on this and also the scope of the work.
That will give the CPE team enough information to make a call (ie should we do that instead of X Y Z other stuff ).

Example of a specification https://fedoraproject.org/wiki/Infrastructure_2020/Rawhide_Gating and https://fedoraproject.org/wiki/Infrastructure_2020/Fedora_Messaging.

At the beginning the most important would be to define the WHY and WHAT then I think we can help with the HOW.

cc @lgriffin

+1 on what @cverna has mentioned. Finite availability means that we need a well bounded spec, with clear aims, goals & objectives to help us understand the WHAT & WHY. At that point we can help flesh out the HOW and get an estimate on how long this work would take. That puts it up for consideration Vs other things in our queue and we can make an informed call in a transparent manner.

Given @cverna's comment, I don't think a Council ticket is appropriate at this point.

@cverna Would you mind if we do a call about this sometimes next week? I'd ping you on IRC for time details.

Sorry for not responding earlier.

Given @cverna's comment, I don't think a Council ticket is appropriate at this point.
@cverna Would you mind if we do a call about this sometimes next week? I'd ping you on IRC for time details.

Sure

Sorry for not responding earlier.

Not a problem at all

Any update on this, @cverna and @churchyard ?

Yes. We met (@cverna @pingou and me) and we drafted a Google Document. For technical limitations, we cannot share the document, but IIRC the next step is to turn it to a wikipage.

@churchyard OK, once that summary is available, please link to it in this ticket.

The document is available here --> https://hackmd.io/s/HyBmoE3hN

Thank you.

I was just coming to give this link, thanks @cverna :)

@cverna @pingou any update on the proposal from your team and/or management?

@cverna @pingou any update on the proposal from your team and/or management?

The overall proposal hasn't been reviewed yet, we're still in the phase about
figuring out how to free to cycles to be able to work on such ideas.
However, some of the work has/was already done and is part of pagure 5.6 and
pagure-dist-git, so we will likely turn this on in staging sometime soon so we
can adjust and test the-new-hotness before looking at production.

Thanks.

Unorphaning packages and Configuring Release Monitoring is now ready at staging. Thanks.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/S6XEW26DS2QW7FSCP7QGLKLLQQWBXVPL/

@cverna @pingou any ETA on when is the Unorphaning packages and Configuring Release Monitoring from the above comment to be deployed to src.fp.o? Does it require more extensive testing?

Announcing new anitya integration and de-orphaning process

Out of the original list:

Requesting Repositories and Branches

For packagers, the request is very easy to make, and it usually is handled fairly quickly. But there's still a human at the other end IIUC.

Unorphaning and unretiring packages

Unorphaning is now automatic. Unretiring requires a ticket and a human to handle it.

Branch ownership

Not implemented and not in any plans IIUC.

Configuring Release Monitoring

Enabling/disabling of release monitoring is easy. But it is still necessary to configure it, and there's no hint whatsoever on src.fp.o where to do it. And in fact there's no hint whatsoever that the configuration is missing on release-monitoring.org: people can happilly flip the switch on src.fp.o w/o it having any effect.

Things are much better than when this ticket was opened, but we've still got a ways to go.

Branch ownership

As of today, there are Bugzilla default overrides for Fedora and EPEL available on src.fp.o

Branch ownership

As of today, there are Bugzilla default overrides for Fedora and EPEL available on src.fp.o

:tada:

There's also a WIP pull-request for adding collaborators on projects with specific per-branch access:

https://pagure.io/pagure/pull-request/4786

Just for completeness, pretty powerful per-branch ACLs (with the ability to set regular expressions for the branches a collaborator has access to, e.g. epel*) are now also implemented for pagure and on src.fp.o.

Both unorphaning and setting release-monitoring status have also been implemented and deployed.

So, the last two remaining items are:

• Packagers cannot wait until a human is available to request a branch.
• Packagers cannot wait until a human is available to unretire a package.

@churchyard with the most recent status, is this more of a working to do list for infrastructure or a statement to amend and then FESCo vote on?

I don't understand your question, sorry.

So, the last two remaining items are:

• Packagers cannot wait until a human is available to request a branch.
• Packagers cannot wait until a human is available to unretire a package.

Sorry, from your comment from 6 days ago. I know this is an old ticket, but the opening reads "we'd like to vote on the following..." but then the items appear to be fixed over the course of the year and now there are these two remaining items.

Are your going to update the statement and we [FESCo] vote on it or is this no longer a thing we want to vote on and just wait for those items to be implemented?

Oh. In my opinion, the original statement is still valid, however this remains open until all the remaining items are fixed. I don't think a new FESCo vote is necessary.

Packagers cannot wait until a human is available to request a branch.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LJ3WJLKWES25HVUY2MWU374RB5CBPEKA/
"Automation of Fedora SCM requests"

It seems we'll be down to just one item when this graduates out of staging.

This works now. Thanks to everybody who made it happen.

<joke>Time to replace pagure with gitlab?</joke>