#2115 Missing PkgDB features should be implemented
Opened 4 months ago by churchyard. Modified a month ago

We'd like FESCo to vote on the following statement:

(statement starts)


Certain missing features after the PkgDB retirement are currently causing contributing to Fedora to be harder than it used to be. The following features should be implemented in an automated fashion, without humans (other than the packager requesting a thing) involved.

Requesting Repositories and Branches

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

Unorphaning and unretiring packages

Currently unorphaning or unretiring a package requires a ticket in the releng issue tracker and awaits manual action by a human. This needs to be automated. Packagers cannot wait until a human is available to unorphan or unretire a package.

Branch ownership

As of today, it is not possible to own a branch in the package repository. This is bad for Bugzilla assignment and clear responsibility boundaries. Currently it is possible to override Bugzilla owner for Fedora/EPEL branches via manually reviewed Pull Request to a specific Pagure repo - the ability to assign particular branches (including Bugzilla default assignee) to different users needs to be automated. Packagers cannot wait until a human is available to review the Pull Request; packages should not need to use a separate Pagure repo to track this kind of information.

Configuring Release Monitoring

The same situation applies for Release Monitoring configuration. Packagers cannot wait until a human is available to review their Pull Request when they want to change the Release Monitoring config; packagers need to be able to do it themselves, without human interaction.


(statement ends)

We realize that FESCo cannot make somebody do this. Yet a statement like this can be brought into attention when certain other things are proposed to be implemented instead.
We also feel that a statement like this might help assigning Red Hat paid developers to do the task (by their managers).

The points were highly inspired by https://fedoraproject.org/wiki/Objectives/Packager_Experience#Pkgdb.2FPagure

The statement is a draft, we can of course shape it better as we receive other FESCo members feedback.

(Proposed by @churchyard and @bowlofeggs. Consider us +2.)


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 ☺)

Metadata Update from @churchyard:
- Issue tagged with: meeting

4 months ago

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.

Metadata Update from @bowlofeggs:
- Issue assigned to churchyard

4 months ago

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.

Metadata Update from @jforbes:
- Issue untagged with: meeting

3 months ago

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

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.

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.

Metadata Update from @sgallagh:
- Issue tagged with: stalled

a month ago

Login to comment on this ticket.

Metadata