git for packages were moved from cgit to pagure. However links are not redirected properly. And result is that users cannot find them easily.
How to reproduce: open https://apps.fedoraproject.org/packages/sssd click on SCM link (which points to https://pkgs.fedoraproject.org/cgit/sssd.git)
// As you can see 1st step is not necessary. You can try to directly open link https://pkgs.fedoraproject.org/cgit/sssd.git
Expected: opened web interface for git got sssd dist-git
Note: FYI there are two dist-git links for sssd (rpms and modules). Which is very likely related https://src.fedoraproject.org/rpms/sssd https://src.fedoraproject.org/modules/sssd
Metadata Update from @pingou: - Issue tagged with: src.fp.o
This has already been reported to https://github.com/fedora-infra/fedora-packages/issues/282 and is being fixed in https://github.com/fedora-infra/fedora-packages/issues/283
So I'm going to close this ticket as upstream.
Thanks for the report though! :)
Metadata Update from @pingou: - Issue close_status updated to: Upstream
How will I be informed that feature is deployed?
I do not want to end in the same situation as in https://pagure.io/fedora-infrastructure/issue/6089. Ticket was closed as upstream and it is not fixed even after 5 months after closed fixed upstream.
Therefore opening this ticket.
Metadata Update from @lslebodn: - Issue status updated to: Open (was: Closed)
Track the issue upstream, we're trying to keep this bug tracker on topic, so sorry but closing this again, it's being worked on and tracked upstream.
@pingou it does not answer my question in previous comment?
If this ticket is out of topic for this "bug tracker". Then where it should be tracked? I would really like to be informed when fix fro upstream is deployed to production. Otherwise it woudl be the same situation as with ticket https://pagure.io/fedora-infrastructure/issue/6089. I was not informed when fix from upstream was deployed to production So I could not test whether my use-case is fixed. Therefore i had to reopen ticket after 5 months.
This is a reason why BZ has states POST/MODIFIED/FIXED. One means fixed in upstream another built in koji and last that updated package is available in repositories.
I'd ask this upstream :)
Maybe if possible when next upstream release happens there should be some way to mark the fixed issues with the next upstream release version as a comment.
Upstream is not responsible for deploying changes to production. From my POV upstream is only git. Nothing else. If sb uses some project in production then it is already downstream. And I cannot expect that person person responsible for upstream and deploying to production is not the same. Therefore it would be good to separate these two actions.
BTW usually there is also difference between releasing something in upstream and deploying to production.
@pingou May I know who will be responsible for deploying upstream fix to production? I would like to ask him/her where such issue should be tracked.
Fix has not been deployed to production yet. And it looks like comments are added to issue only if it is opened :-)
I would appreciate answer to question in comment https://pagure.io/fedora-infrastructure/issue/6206#comment-455698
Metadata Update from @pingou: - Issue untagged with: src.fp.o
In the ideal world I agree with you.
Again agreed.
Our very small overworked team of sysadmins.
In the ideal world things would look like:
Normally, most of the upstreams we work with do regular releases, so it's much easier for us to get reports/fixes upstream and then just pick up the next release when it comes and people who are interested in that fix can verify that it's fixed or not. You know something is deployed when upstream has a release (or shortly thereafter).
Steps 6 and 8 mean a bunch more work for our team as some upstreams don't refer to specific downstream bugs or have good changelogs that allow us to know what exactly was fixed. Also sometimes bugs are minor and not a priority for upstreams and then our downstream bugs pile up and sit there forever with no activity.
packages is somewhat of a pathalogical case from our apps as well, as it's not really very maintained upstream (there's been no releases in a while).
We are exploring a move to openshift for many/some of our applications and in such a world we could redeploy as soon as fixes are committed, which would help this problem a lot. Thats down the road however.
So, basically it is easier for us to not try and track a mapping of upstream to downstream bugs vs deployments, and I am not sure how to solve that without causing additional burden on our already busy sysadmins. Open to ideas...
I know you are a small team and I appreciate your work. You do awesome job.
Regular releases are fine; but I still do not understand why people should follow whole upstream project if they are interested just in one particular bug. If you prefer to close tickets as "UPSTREAM" and solve everything on github that fine; that's your workflow. BTW (dogfooding-- :-)
But I think it would not be very complicated to mention these(pagure.io/fedora-infra...) tickets in upstream commit messages. Then you would be able mass update closed tickets after release/deploy to production. (extracting links + adding comments to tickets is not a rocket science and faster then manual work).
You will not have many opened ticket here and people would be informed about new release by mails.
(Note: some of our apps are on github and we intend to move them to pagure someday... their presence there predates the existance of pagure. Also some other upstreams of apps we use we don't control at all, so they will be at github or whatever as long as they choose to)
Yes, we could for projects we have close ties to. Many we don't... like say askbot or mediawiki. We can't control what they put in commits. :smile:
This has landed with the new packages version now.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.