From time to time I have to submit a ticket with 'fedpkg request-repo' or 'fedpkg request-branch', and I have feeling that I have to regenerate the API key very often (since 2018-02-17 I have 5th key already?!).
How do you work-around this requirement to re-generate the key all the time? Is this necessary requirement for 'fedpkg' to work if when we have gssapi support in Fedora?
Pavel
On Mon, 2018-12-10 at 17:20 +0100, Pavel Raiskup wrote:
From time to time I have to submit a ticket with 'fedpkg request-repo' or 'fedpkg request-branch', and I have feeling that I have to regenerate the API key very often (since 2018-02-17 I have 5th key already?!).
How do you work-around this requirement to re-generate the key all the time? Is this necessary requirement for 'fedpkg' to work if when we have gssapi support in Fedora?
As in, do 'kinit praiskup@FEDORAPROJECT.ORG' or so?
Yeah, it's been like that for several months for me. At one point it was not. I believe the ticket is meant to last for 24 hours but be auto-renewable for up to 7 days; at some point, for me, auto-renew was happening, for the last while it is not.
I have never had time to look into this more deeply, though, so I never filed any bugs. I'm not sure if it depends on GNOME keyring integration, or if the fact that my systems are *also* members of my personal FreeIPA domain is related.
On Mon, Dec 10, 2018 at 5:22 PM Pavel Raiskup praiskup@redhat.com wrote:
Is this necessary requirement for 'fedpkg' to work if when we have gssapi support in Fedora?
This is something that's been annoying me too. It would be a huge packager quality of life improvement (IMO) if we didn't have to request pagure keys and could instead authenticate using GSSAPI/Kerberos for all interactions with Fedora infrastructure.
Sadly, Pagure does not support GSSAPI authentication.
I actually suggested this some time ago, when the migration from pkgdb2 first happened-- I don't *think* there was an opposition to the idea, there just wasn't enough time or person-power to do it: https://pagure.io/pagure/issue/2549
Ben Rosser
On Mon, Dec 10, 2018 at 05:56:00PM +0100, Ben Rosser wrote:
On Mon, Dec 10, 2018 at 5:22 PM Pavel Raiskup praiskup@redhat.com wrote:
Is this necessary requirement for 'fedpkg' to work if when we have gssapi support in Fedora?
This is something that's been annoying me too. It would be a huge packager quality of life improvement (IMO) if we didn't have to request pagure keys and could instead authenticate using GSSAPI/Kerberos for all interactions with Fedora infrastructure.
And if krb5 keys lasted longer than 8 hours or whatever short timeout it is. 30 days would be a good starting point.
Rich.
Sadly, Pagure does not support GSSAPI authentication.
I actually suggested this some time ago, when the migration from pkgdb2 first happened-- I don't *think* there was an opposition to the idea, there just wasn't enough time or person-power to do it: https://pagure.io/pagure/issue/2549
Ben Rosser _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, 2018-12-10 at 17:20 +0100, Pavel Raiskup wrote:
From time to time I have to submit a ticket with 'fedpkg request- repo' or 'fedpkg request-branch', and I have feeling that I have to regenerate the API key very often (since 2018-02-17 I have 5th key already?!).
I proposed that fedpkg could manage the API token here:
On Mon, Dec 10, 2018 at 6:58 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
On Mon, 2018-12-10 at 17:20 +0100, Pavel Raiskup wrote:
From time to time I have to submit a ticket with 'fedpkg request- repo' or 'fedpkg request-branch', and I have feeling that I have to regenerate the API key very often (since 2018-02-17 I have 5th key already?!).
I proposed that fedpkg could manage the API token here:
This would definitely be a huge improvement over the current situation too.
I guess what bothers me here is that it's been a year since I filed my ticket against pagure, and nine months since you filed yours against fedpkg, and it seems like nothing has been done to fix this. I know it's only a minor annoyance, and I know there are more important things to be worked on, but... this isn't the only minor annoyance that's cropped up since we've moved away from pkgdb2 that still exists today.
I don't know. I feel like we could do a lot to improve the experience of packaging by investing time into fixing these sorts of minor annoyances. (But here I am complaining on the devel list and not actually doing anything to help, so I guess I'm part of the problem too).
Ben Rosser
Hi Ben,
On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote:
I don't know. I feel like we could do a lot to improve the experience of packaging by investing time into fixing these sorts of minor annoyances. (But here I am complaining on the devel list and not actually doing anything to help, so I guess I'm part of the problem too).
you are right. I am thinking this, too. Would you maybe be interested in making this a Community Objective[0] such as "Packaging Contribution Experience"?
Kind regards Till
[0] https://docs.fedoraproject.org/en-US/project/objectives/
On Tue, Dec 11, 2018 at 4:07 PM Till Maas opensource@till.name wrote:
Hi Ben,
On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote:
I don't know. I feel like we could do a lot to improve the experience of packaging by investing time into fixing these sorts of minor annoyances. (But here I am complaining on the devel list and not actually doing anything to help, so I guess I'm part of the problem too).
you are right. I am thinking this, too. Would you maybe be interested in making this a Community Objective[0] such as "Packaging Contribution Experience"?
Kind regards Till
[0] https://docs.fedoraproject.org/en-US/project/objectives/
Hi Till,
Sure, I think it would be great to have packager quality of life as a community objective! Should I start by writing something up and sending an email to council-discuss?
Thanks, Ben Rosser
On 12/12/18 4:10 AM, Ben Rosser wrote:
On Tue, Dec 11, 2018 at 4:07 PM Till Maas opensource@till.name wrote:
Hi Ben,
On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote:
I don't know. I feel like we could do a lot to improve the experience of packaging by investing time into fixing these sorts of minor annoyances. (But here I am complaining on the devel list and not actually doing anything to help, so I guess I'm part of the problem too).
you are right. I am thinking this, too. Would you maybe be interested in making this a Community Objective[0] such as "Packaging Contribution Experience"?
Kind regards Till
[0] https://docs.fedoraproject.org/en-US/project/objectives/
Hi Till,
Sure, I think it would be great to have packager quality of life as a community objective! Should I start by writing something up and sending an email to council-discuss?
I'm not sure this really deserves the level of community objective... but perhaps I am wrong.
IMHO, it mostly needs people spending time and driving it. First, gathering a list of issues that are non ideal for maintainers, then finding out what it would take to solve each and helping create and land fixes for them, be that a pagure bugfix or a workflow change or whatever.
I'd love to help out, but just haven't had the time. If a group of folks could help by triaging and labeling things that might make it easier to know what needs work and where.
kevin
On Wed, Dec 12, 2018 at 6:50 PM Kevin Fenzi kevin@scrye.com wrote:
I'm not sure this really deserves the level of community objective... but perhaps I am wrong.
So, here's why a community objective sounds like a good idea to me (though other people should feel free to comment if they have different ideas):
Firstly, I would hope that "making sure the experience of packaging software in Fedora is a good one" is one of our goals, as a distribution. (An "objective" with a lower case "o").
Two of our current objectives are "Modularity" and "Rethink the Fedora lifecycle". I think it is very important that, as we move in the direction of these sorts of big, sweeping changes, we also make sure that the experience of packaging remains positive. I don't know what is necessary to make sure that this happens. But I worry that it won't happen on its own. I am worried because I feel like the experience packaging *already* has gotten a bit worse since we retired pkgdb2, and we haven't done anything to fix that yet.
So I would see the scope or mission statement of such a Community Objective as follows:
1. To identify parts of the packager workflow that are difficult or tedious, and to work with the maintainers of the relevant software components to resolve these issues. 2. In the short term, to identify things that pkgdb2 used to do that are now harder, or more difficult, for packagers to do today (and to try and improve things). 3. In the long term, to ensure that the core packager experience remains high as we continue to roll out Modularity and other future changes to come.
Maybe what I've just written is the mission statement for a SIG or a Working Group. But perhaps an Objective could lead to the creation of such a group?
IMHO, it mostly needs people spending time and driving it. First, gathering a list of issues that are non ideal for maintainers, then finding out what it would take to solve each and helping create and land fixes for them, be that a pagure bugfix or a workflow change or whatever.
I'd love to help out, but just haven't had the time. If a group of folks could help by triaging and labeling things that might make it easier to know what needs work and where.
Sure, I agree that this is what needs to be done. But I don't think it is going to happen on its own without some sort of organization to make it happen, and to try and organize/focus the work. I don't know if that organization requires an Objective to make happen, but I think it would be nice to enshrine this as one of our medium-term goals.
Cheers, Ben Rosser
On 12/13/18 2:34 AM, Ben Rosser wrote: ...snip...
Sure, I agree that this is what needs to be done. But I don't think it is going to happen on its own without some sort of organization to make it happen, and to try and organize/focus the work. I don't know if that organization requires an Objective to make happen, but I think it would be nice to enshrine this as one of our medium-term goals.
If an objective is what the folks organizing and doing this want, thats fine with me.
kevin
Le 2018-12-12 18:49, Kevin Fenzi a écrit :
On 12/12/18 4:10 AM, Ben Rosser wrote:
On Tue, Dec 11, 2018 at 4:07 PM Till Maas opensource@till.name wrote:
Hi Ben,
On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote:
I don't know. I feel like we could do a lot to improve the experience of packaging by investing time into fixing these sorts of minor annoyances. (But here I am complaining on the devel list and not actually doing anything to help, so I guess I'm part of the problem too).
you are right. I am thinking this, too. Would you maybe be interested in making this a Community Objective[0] such as "Packaging Contribution Experience"?
Kind regards Till
[0] https://docs.fedoraproject.org/en-US/project/objectives/
Hi Till,
Sure, I think it would be great to have packager quality of life as a community objective! Should I start by writing something up and sending an email to council-discuss?
I'm not sure this really deserves the level of community objective... but perhaps I am wrong.
Not treating it as a community objective is how we got in a situation, where upstreams (including @rh upstreams) want nothing to do with rpms and Fedora, and invent their own packaging tech to bypass Linux distributions completely. They're not doing it for lofty theoretical reasons. Those are added later as PC justifications. The root cause of why they behave like this, is that they feel, the packager experience Fedora (or Debian, or Ubuntu) sucks loads. It used not to suck, when it matched perfectly c/c++ autotools needs, and then it slowly degraded as things were not updated to match new needs and packagers were asked to fill in the gaps.
IMHO, it mostly needs people spending time and driving it. First, gathering a list of issues that are non ideal for maintainers,
That's quite easy to do and you'll find no end of volunteers to document their packaging roadblocks. And they're not limited to the pagure behavior…
then finding out what it would take to solve each and helping create and land fixes for them, be that a pagure bugfix or a workflow change or whatever.
… but only if there is an effort at the Fedora level to act on this list. That's means infra time, and that means Fedora leadership time to make sure infra has this time and actually uses it to fix the issues packagers reported.
Been there, done that, not interested in filling new issues no one wants to work on or look at. Already doing too much of that lately.
Regards,
On 12/13/18 3:14 AM, Nicolas Mailhot wrote:
Le 2018-12-12 18:49, Kevin Fenzi a écrit :
..snip...
IMHO, it mostly needs people spending time and driving it. First, gathering a list of issues that are non ideal for maintainers,
That's quite easy to do and you'll find no end of volunteers to document their packaging roadblocks. And they're not limited to the pagure behavior…
Thats not what I am asking for. A flood of untriaged issues is going to hinder rather than help.
then finding out what it would take to solve each and helping create and land fixes for them, be that a pagure bugfix or a workflow change or whatever.
… but only if there is an effort at the Fedora level to act on this list. That's means infra time, and that means Fedora leadership time to make sure infra has this time and actually uses it to fix the issues packagers reported.
Been there, done that, not interested in filling new issues no one wants to work on or look at. Already doing too much of that lately.
What I was asking for was a prioritized list of triaged issues. This would help greatly in fixing things that would have the most impact. If we can't fix everything, lets at least fix the most painful things first.
kevin
On Thu, 13 Dec 2018 at 06:15, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Le 2018-12-12 18:49, Kevin Fenzi a écrit :
On 12/12/18 4:10 AM, Ben Rosser wrote:
then finding out what it would take to solve each and helping create and land fixes for them, be that a pagure bugfix or a workflow change or whatever.
… but only if there is an effort at the Fedora level to act on this list. That's means infra time, and that means Fedora leadership time to make sure infra has this time and actually uses it to fix the issues packagers reported.
Having played this game also several times.. as soon as people aren't still able to do what they were doing already we get variations of the following:
"What do you mean we only have 4/5ths of the builders so you can work out how to make the new system work at scale.. I don't care, move it back" "What do you mean that I have to do these new steps because it will drop the amount of time rawhide or a release is broken. I don't give a crap about rawhide or the releases. I want my package built now because I have other things to do!" "When I said I wanted less breakage I didn't meant my packages, I meant those people using that <arch|development stack|toolset> which are always breaking things for my builds.
Those are the extremes which people remember, but all the little ones about "why do builds take so long?" "does infra actually do anything?" "ugh another packaging change, why are they making it so hard." adds up also. Eventually people working things (or the leadership) gets tired of 400 packagers grousing and says "that's enough.. just keep doing what you were doing.. we will try this again later."
So we like many middle aged communities, end up in a state where we have found a local minima of grumpiness. People dislike where we are, but every change seems to make things worse enough that people just want what they had more. We think that the reason no one wants to live around us anymore is because 'the other people' cause so much noise, without realizing that is our own constant low-level complaining about everything which people are tired of.
This is going to take more than infrastructure to fix. This is going to take more than our managers telling us to fix them. It is going to take everyone to not just list the problems, but go over them, triage them and come up with what level of pain they are willing to live with while it is getting worked on.
Been there, done that, not interested in filling new issues no one wants to work on or look at. Already doing too much of that lately.
Regards,
-- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Thu, Dec 13, 2018 at 4:14 AM Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
Not treating it as a community objective is how we got in a situation, where upstreams (including @rh upstreams) want nothing to do with rpms and Fedora, and invent their own packaging tech to bypass Linux distributions completely. They're not doing it for lofty theoretical reasons. Those are added later as PC justifications. The root cause of why they behave like this, is that they feel, the packager experience Fedora (or Debian, or Ubuntu) sucks loads. It used not to suck, when it matched perfectly c/c++ autotools needs, and then it slowly degraded as things were not updated to match new needs and packagers were asked to fill in the gaps.
The dynamic that you've described about upstreams matches my experience.
If we do have some kind of "packager experience" SIG, I would like to be a part of it.
I would love to help bring back the birds-eye view dashboard that pkgdb provided for things like "how many packages does X person maintain", or "who is on the watch list for X component in Bugzilla". Maybe we could build that into the fedora-packages application ? I know the Infra team doesn't need more new apps to run :)
- Ken
On 12/13/18 11:50 AM, Ken Dreyer wrote:
I would love to help bring back the birds-eye view dashboard that pkgdb provided for things like "how many packages does X person maintain",
https://src.fedoraproject.org/user/ktdreyer
You maintain 62 packages (or are co-maintainer, etc)
or "who is on the watch list for X component in Bugzilla".
https://src.fedoraproject.org/api/0/rpms/ansible/watchers
shows the users who are watching the 'ansible' package.
Maybe we could build that into the fedora-packages application ? I know the Infra team doesn't need more new apps to run :)
It could also be there and query pagure.
kevin
Dne 13. 12. 18 v 21:09 Kevin Fenzi napsal(a):
On 12/13/18 11:50 AM, Ken Dreyer wrote:
I would love to help bring back the birds-eye view dashboard that pkgdb provided for things like "how many packages does X person maintain",
https://src.fedoraproject.org/user/ktdreyer
You maintain 62 packages (or are co-maintainer, etc)
This does not says much. There is included tests namespace, there are apparently listed packages which I probably just watch or group I am in has commit bit.
For example this package:
https://src.fedoraproject.org/rpms/rubygem-acts-as-taggable-on
It was orphaned, but for some reason, I have watch on that package I cannot really get rid of and there is still commit bit for ruby-packagers-sig group. That doesn't make any sense.
Also, the latest design changes makes much harder to see who is actually maintainer of the package etc.
Vít
or "who is on the watch list for X component in Bugzilla".
https://src.fedoraproject.org/api/0/rpms/ansible/watchers
shows the users who are watching the 'ansible' package.
Maybe we could build that into the fedora-packages application ? I know the Infra team doesn't need more new apps to run :)
It could also be there and query pagure.
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Thu, Dec 13, 2018 at 2:11 PM Kevin Fenzi kevin@scrye.com wrote:
On 12/13/18 11:50 AM, Ken Dreyer wrote:
I would love to help bring back the birds-eye view dashboard that pkgdb provided for things like "how many packages does X person maintain",
https://src.fedoraproject.org/user/ktdreyer
You maintain 62 packages (or are co-maintainer, etc)
Just checked mine and apparently I have 98 packages now but one thing to note, it only shows the first 6 and has a link for "View all X packages" but it doesn't do anything.
Thanks, Richard
* Richard Shaw [03/01/2019 08:28] :
Just checked mine and apparently I have 98 packages now but one thing to note, it only shows the first 6 and has a link for "View all X packages" but it doesn't do anything.
I suspect that link should take you to https://src.fedoraproject.org/user/<fas-name>/projects which does list all projects (albeit in a paginated format).
Emmanuel
Dne 03. 01. 19 v 15:28 Richard Shaw napsal(a):
On Thu, Dec 13, 2018 at 2:11 PM Kevin Fenzi <kevin@scrye.com mailto:kevin@scrye.com> wrote:
On 12/13/18 11:50 AM, Ken Dreyer wrote: > I would love to help bring back the birds-eye view dashboard that > pkgdb provided for things like "how many packages does X person > maintain", https://src.fedoraproject.org/user/ktdreyer You maintain 62 packages (or are co-maintainer, etc)Just checked mine and apparently I have 98 packages now but one thing to note, it only shows the first 6 and has a link for "View all X packages" but it doesn't do anything.
I can confirm this issue.
Nevertheless it seems that the "packages" on the left side probably provides the intended functionality, judging by the same number displayed on both places.
Vít
Thanks, Richard
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, 2018-12-11 at 11:42 +0100, Ben Rosser wrote:
I guess what bothers me here is that it's been a year since I filed my ticket against pagure, and nine months since you filed yours against fedpkg, and it seems like nothing has been done to fix this. I know it's only a minor annoyance, and I know there are more important things to be worked on, but... this isn't the only minor annoyance that's cropped up since we've moved away from pkgdb2 that still exists today.
I share some similar feelings. I wish the effort to make the changes away from pkgdb hadn't stopped at a minimum viable product, but had continued until it had full feature parity with the old system.
-
Adam Williamson -
Ben Rosser -
Emmanuel Seyman -
Ken Dreyer -
Kevin Fenzi -
Nicolas Mailhot -
Pavel Raiskup -
Randy Barlow -
Richard Shaw -
Richard W.M. Jones -
Stephen John Smoogen -
Till Maas -
Vít Ondruch