Hello,
I'd like to take over maintenance of the surf package for Fedora.
I've submitted a review request for unretiring surf: https://bugzilla.redhat.com/show_bug.cgi?id=1327911
Could someone spare some time to review?
On Sat, Apr 16, 2016 at 1:44 PM, Neal Gompa ngompa13@gmail.com wrote:
Hello,
I'd like to take over maintenance of the surf package for Fedora.
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi Neal,
The link to the source rpm in rhbz seems broken. If nobody else comes forward by tonight, I'll pick up the review.
Best Regards
Alexander,
It should be fine now. I forgot to move it to the correct location. Silly me.
On Mon, Apr 18, 2016 at 3:15 AM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Hi Neal,
The link to the source rpm in rhbz seems broken. If nobody else comes forward by tonight, I'll pick up the review.
Best Regards
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs: * dnf repoquery --resolve is extremely slow #1279538 * fedora-review queries too many times for same thing #1275275
I'll try to stay up until it finishes and if that takes too long, I'll let it run all night and check up on it in the morning. If it fails, I'll go through the items on the checklist manually... Really sorry for the delay.
On Mon, Apr 18, 2016 at 4:54 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
- fedora-review queries too many times for same thing #1275275
I'll try to stay up until it finishes and if that takes too long, I'll let it run all night and check up on it in the morning. If it fails, I'll go through the items on the checklist manually... Really sorry for the delay.
No worries. Thanks for taking it on! :)
Well, after almost three hours, fedora-review came through.
I am a little confused by the beginning of the %install section, could you please explain the syntax of the first line? (%make_install INSTALL="install -p")
On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Well, after almost three hours, fedora-review came through.
I am a little confused by the beginning of the %install section, could you please explain the syntax of the first line? (%make_install INSTALL="install -p")
It essentially expands out to: %{__make} install DESTDIR=%{buildroot} INSTALL="install -p"
Previously, it was set to `make install INSTALL="install -p" DESTDIR=%{buildroot}`, which is essentially the same thing. I just chose to use the %make_install macro to be consistent with my usage of %make_build (which is `%{__make} %{?_smp_mflags}`).
On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos alex.ploumistos@gmail.com wrote:
Well, after almost three hours, fedora-review came through.
I am a little confused by the beginning of the %install section, could you please explain the syntax of the first line? (%make_install INSTALL="install -p")
It essentially expands out to: %{__make} install DESTDIR=%{buildroot} INSTALL="install -p"
Previously, it was set to `make install INSTALL="install -p" DESTDIR=%{buildroot}`, which is essentially the same thing. I just chose to use the %make_install macro to be consistent with my usage of %make_build (which is `%{__make} %{?_smp_mflags}`).
I'm sorry but may be the corresponding Bugzilla ticket is a better place for this conversation?
Dmitrij S. Kryzhevich
On Tue, Apr 19, 2016 at 6:14 AM, Dmitrij S. Kryzhevich kryzhev@ispms.ru wrote:
On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
alex.ploumistos@gmail.com wrote:
I am a little confused by the beginning of the %install section, could you please explain the syntax of the first line? (%make_install INSTALL="install -p")
It essentially expands out to: %{__make} install DESTDIR=%{buildroot} INSTALL="install -p"
Previously, it was set to `make install INSTALL="install -p" DESTDIR=%{buildroot}`, which is essentially the same thing. I just chose to use the %make_install macro to be consistent with my usage of %make_build (which is `%{__make} %{?_smp_mflags}`).
I'm sorry but may be the corresponding Bugzilla ticket is a better place for this conversation?
I thought at the time that it would make more sense to ask on the mailing list, given the nature of the question.
Anyway, thank you all for your input.
On Seg, 2016-04-18 at 23:54 +0300, Alexander Ploumistos wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
I already change priority and severity of #1279538 to urgent
- fedora-review queries too many times for same thing #1275275
I'll try to stay up until it finishes and if that takes too long, I'll let it run all night and check up on it in the morning. If it fails, I'll go through the items on the checklist manually... Really sorry for the delay.
you need do (as an example in my home) : cd /home/sergio/ git clone http://git.fedorahosted.org/git/FedoraReview.git%C2%A0 /home/sergio/FedoraReview/try-fedora-review '-x CheckOwnDirs' -n libprojectM
Best regards,
On Tue, Apr 19, 2016 at 01:20:51AM +0100, Sérgio Basto wrote:
On Seg, 2016-04-18 at 23:54 +0300, Alexander Ploumistos wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
I already change priority and severity of #1279538 to urgent
- fedora-review queries too many times for same thing #1275275
I'll try to stay up until it finishes and if that takes too long, I'll let it run all night and check up on it in the morning. If it fails, I'll go through the items on the checklist manually... Really sorry for the delay.
you need do (as an example in my home) : cd /home/sergio/ git clone http://git.fedorahosted.org/git/FedoraReview.git%C2%A0 /home/sergio/FedoraReview/try-fedora-review '-x CheckOwnDirs' -n libprojectM
Actually simply specifying '-x Check OwnDirs' as an argument to any fedora-review call also seems to work.
Zbyszek
On Tue, Apr 19, 2016 at 01:20:51AM +0100, Sérgio Basto wrote:
Actually simply specifying '-x Check OwnDirs' as an argument to any fedora-review call also seems to work.
Zbyszek
Please explain how to validate manually the ownership guidelines, without the help from (slow) dnf repoquery. https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Owner...
Just not care about guidelines is no solution to fix the broken process. In such a case, we wouldn't need any guidelines.
On Tue, Apr 19, 2016 at 01:00:56PM -0000, Raphael Groner wrote:
On Tue, Apr 19, 2016 at 01:20:51AM +0100, Sérgio Basto wrote:
Actually simply specifying '-x Check OwnDirs' as an argument to any fedora-review call also seems to work.
Zbyszek
Please explain how to validate manually the ownership guidelines, without the help from (slow) dnf repoquery. https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Owner...
Just not care about guidelines is no solution to fix the broken process. In such a case, we wouldn't need any guidelines.
Run rpmls, and look at the list ;) Most files can be crossed off immediately, e.g. stuff like /usr/lib/pythonX.Y/site-packages/foobar, or /usr/share/foobar, /usr/share/doc/foobar, etc., assuming that there's no other foobar package. What remains is usually nothing or a few files that can be checked by hand using dnf repoquery -f.
Zbyszek
On Tue, 19 Apr 2016 01:20:51 +0100 Sérgio Basto sergio@serjux.com wrote:
On Seg, 2016-04-18 at 23:54 +0300, Alexander Ploumistos wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
I already change priority and severity of #1279538 to urgent
Just as a side note, I don't know anyone who actually uses or cares about these fields in Fedora land. IMHO you are much better off just explaining why the bug is important or what it blocks.
kevin
On Ter, 2016-04-19 at 10:53 -0600, Kevin Fenzi wrote:
On Tue, 19 Apr 2016 01:20:51 +0100 Sérgio Basto sergio@serjux.com wrote:
On Seg, 2016-04-18 at 23:54 +0300, Alexander Ploumistos wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
I already change priority and severity of #1279538 to urgent
Just as a side note, I don't know anyone who actually uses or cares about these fields in Fedora land.
we need it for fedora-review
IMHO you are much better off just explaining why the bug is important or what it blocks.
because is a dnf bug , that is not acceptable , IMHO .
time dnf repoquery -q -C --requires glibc (...) real 0m1.335s user 0m1.084s sys 0m0.110s
time dnf repoquery -q -C --requires --resolve glibc (...) real 4m24.474s user 4m22.064s sys 0m2.130s
with CPU usage in 100% !
kevin
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. org
On Tue, Apr 19, 2016 at 10:53:39AM -0600, Kevin Fenzi wrote:
On Seg, 2016-04-18 at 23:54 +0300, Alexander Ploumistos wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
I already change priority and severity of #1279538 to urgent
Just as a side note, I don't know anyone who actually uses or cares about these fields in Fedora land. IMHO you are much better off just explaining why the bug is important or what it blocks.
These fields are effectively useless because they can be changed by anybody. Even leaving aside the cynical thought that most people would put their own problems as top priority / worst severity, everyone has their own sense of what the scale ought to mean. For example, to one person, "extremely slow" might be top-tier, but to another, that should be only used for data-loss issues. For some people, it's should mean prioritizion of _all effort_; for other people, it might just be "of all bugs in this single package, this is the most urgent currently".
This kind of prioritization only really works when everyone using it is in alignment about... well, _priorities_.
Right now, our only real method for prioritizing bugs at the distro level is the blocker and freeze exception process at release time. It *would* be nice to have some _other_ general method, but no one has put the time or effort into figuring out what one would be like (let alone making or maintaining it).
So for now and the foreseeable future, the process for weeding out issue urgency is: bring it to the devel list, and see where the discussion goes.
On Tue, 2016-04-19 at 14:17 -0400, Matthew Miller wrote:
On Tue, Apr 19, 2016 at 10:53:39AM -0600, Kevin Fenzi wrote:
On Seg, 2016-04-18 at 23:54 +0300, Alexander Ploumistos wrote:
It's been a little over two hours since I started fedora-review and it seems I'm hitting these two bugs:
- dnf repoquery --resolve is extremely slow #1279538
I already change priority and severity of #1279538 to urgent
Just as a side note, I don't know anyone who actually uses or cares about these fields in Fedora land. IMHO you are much better off just explaining why the bug is important or what it blocks.
These fields are effectively useless because they can be changed by anybody. Even leaving aside the cynical thought that most people would put their own problems as top priority / worst severity, everyone has their own sense of what the scale ought to mean. For example, to one person, "extremely slow" might be top-tier, but to another, that should be only used for data-loss issues. For some people, it's should mean prioritizion of _all effort_; for other people, it might just be "of all bugs in this single package, this is the most urgent currently".
This kind of prioritization only really works when everyone using it is in alignment about... well, _priorities_.
For the record, we do in fact have a policy on this:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Sev...
I wouldn't exactly claim that it's universally followed, but it *is* there. I do still follow those rules for 'severity' when dealing with bugs, for whatever it's worth.
It is not in fact true that they "can be changed by anybody" (unless the BZ config has been changed in the last few years and I missed it, which is entirely possible). Only people with 'editbugs' privileges can change them. Lots of people have 'editbugs' privileges one way or another, though.
Right now, our only real method for prioritizing bugs at the distro level is the blocker and freeze exception process at release time. It *would* be nice to have some _other_ general method, but no one has put the time or effort into figuring out what one would be like (let alone making or maintaining it).
Yes they have. Several times! Unfortunately, no-one has ever stuck to it for very long.
https://fedoraproject.org/wiki/BugZappers%C2%A0is still there, blowing in the wind...that was the last one.
On Tue, 19 Apr 2016 11:36:54 -0700 Adam Williamson adamwill@fedoraproject.org wrote:
For the record, we do in fact have a policy on this:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Sev...
I wouldn't exactly claim that it's universally followed, but it *is* there. I do still follow those rules for 'severity' when dealing with bugs, for whatever it's worth.
Well, it also doesn't make as much sense with 'triager' in there and no triagers around. ;)
It is not in fact true that they "can be changed by anybody" (unless the BZ config has been changed in the last few years and I missed it, which is entirely possible). Only people with 'editbugs' privileges can change them. Lots of people have 'editbugs' privileges one way or another, though.
Yep. Pretty easy to get that access...
Also note that with no privs you can set the Severity on any bug you file (but cannot change it after that).
IMHO, setting these fields just represents noise and more emails generated and doesn't really end up getting you anything other than maintainers who say "yes yes, we know, thanks for some more emails".
Back to this case, I am not a DNF developer/maintainer, but I can think of lots of things I would personally prioritze over a slowness issue in fedora-review (data loss bugs, bugs that prevent people from getting updates, crashing bugs, bugs that stop releng from doing things they need to do, etc). In any case, priority/severity should be left to the maintainers to decide (if they want to use them at all).
kevin
On Tue, 2016-04-19 at 12:47 -0600, Kevin Fenzi wrote:
On Tue, 19 Apr 2016 11:36:54 -0700 Adam Williamson adamwill@fedoraproject.org wrote:
For the record, we do in fact have a policy on this:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Sev...
I wouldn't exactly claim that it's universally followed, but it *is* there. I do still follow those rules for 'severity' when dealing with bugs, for whatever it's worth.
Well, it also doesn't make as much sense with 'triager' in there and no
triagers around. ;)
A triager is one who triages. I still triage things sometimes. I'm like the triage ninja. You never see me coming. ;)
Back to this case, I am not a DNF developer/maintainer, but I can think of lots of things I would personally prioritze over a slowness issue in fedora-review (data loss bugs, bugs that prevent people from getting updates, crashing bugs, bugs that stop releng from doing things they need to do, etc). In any case, priority/severity should be left to the maintainers to decide (if they want to use them at all).
I think the distinction in the policy is a sensible one: 'severity' is something vaguely objectively quantifiable, which we can attempt to have a universal policy for. 'priority' is entirely at the responsible maintainer/team's discretion and shouldn't be set by anyone else.
On Tue, Apr 19, 2016 at 11:36:54AM -0700, Adam Williamson wrote:
For the record, we do in fact have a policy on this: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Sev... I wouldn't exactly claim that it's universally followed, but it *is* there. I do still follow those rules for 'severity' when dealing with bugs, for whatever it's worth.
Isn't bugzappers officially defunct? It does seem like a reasonable enough policy, for whatever that's worth.
It is not in fact true that they "can be changed by anybody" (unless the BZ config has been changed in the last few years and I missed it, which is entirely possible). Only people with 'editbugs' privileges can change them. Lots of people have 'editbugs' privileges one way or another, though.
Just checked, and while that's true, anyone can set the _initial_ state, which is almost the same case.
Right now, our only real method for prioritizing bugs at the distro level is the blocker and freeze exception process at release time. It *would* be nice to have some _other_ general method, but no one has put the time or effort into figuring out what one would be like (let alone making or maintaining it).
Yes they have. Several times! Unfortunately, no-one has ever stuck to it for very long.
Well, that's why I put the "maintaining it" part in there.
https://fedoraproject.org/wiki/BugZappers%C2%A0is still there, blowing in the wind...that was the last one.
Yeah, looks like the last meeting was five years ago. It had a pretty good run, though. :)
On Tue, 2016-04-19 at 16:24 -0400, Matthew Miller wrote:
On Tue, Apr 19, 2016 at 11:36:54AM -0700, Adam Williamson wrote:
For the record, we do in fact have a policy on this: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Sev... I wouldn't exactly claim that it's universally followed, but it *is* there. I do still follow those rules for 'severity' when dealing with bugs, for whatever it's worth.
Isn't bugzappers officially defunct? It does seem like a reasonable enough policy, for whatever that's worth.
Yeah, the group is. We can have an exciting debate about whether we consider that to mean the bug status workflow page is no longer 'in effect', but since it never had any enforcement mechanism or anything it seems a tad pointless =) I just wanted to point out we did at least formulate a policy for this at one time, and the policy isn't really particularly tied to the Bugzappers group, it just happens to live there.
There are a few other 'living pages' in the Bugzappers wiki space, FWIW, though jkurik and I have talked a bit about moving the relevant material somewhere else. Most obviously, https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers%C2%A0is still valid and updated every cycle and the policy and process documented there are current and active.
It is not in fact true that they "can be changed by anybody" (unless the BZ config has been changed in the last few years and I missed it, which is entirely possible). Only people with 'editbugs' privileges can change them. Lots of people have 'editbugs' privileges one way or another, though.
Just checked, and while that's true, anyone can set the _initial_ state, which is almost the same case.
Well, at least if you tend the states for your component's bugs, it means not any old Marlon Rando[1] can change them back again. I'm not sure whether a non-editbugs person who reports a bug can change the statuses after filing.
When BZ was active we used to discuss this quite a bit, and there were various ideas for tightening down the permissions, but it's restricted by the fact that we share RHBZ with many other projects, and there was also a general feeling that as so few maintainers seem to actually want to use the statuses anyway, it wasn't really that important (though of course there's a chicken/egg element there).
[1] https://www.penny-arcade.com/comic/2016/01/20/martin-randau
On Tue, Apr 19, 2016 at 02:26:27PM -0700, Adam Williamson wrote:
Isn't bugzappers officially defunct? It does seem like a reasonable enough policy, for whatever that's worth.
Yeah, the group is. We can have an exciting debate about whether we consider that to mean the bug status workflow page is no longer 'in effect', but since it never had any enforcement mechanism or anything it seems a tad pointless =) I just wanted to point out we did at least formulate a policy for this at one time, and the policy isn't really particularly tied to the Bugzappers group, it just happens to live there.
Well, it's less about "in effect" in a legal sense and more about "completely lost in the deadzone of the wiki".
There are a few other 'living pages' in the Bugzappers wiki space, FWIW, though jkurik and I have talked a bit about moving the relevant material somewhere else.
+1 yeah this.
On 4/17/16, Neal Gompa ngompa13@gmail.com wrote:
Hello,
I'd like to take over maintenance of the surf package for Fedora.
Good luck with the name collision...Someone asked me to rename it to surf-browser[1].
[1]---https://bugzilla.redhat.com/show_bug.cgi?id=554101
On Tue, Apr 19, 2016 at 10:59 AM, Christopher Meng i@cicku.me wrote:
On 4/17/16, Neal Gompa ngompa13@gmail.com wrote:
Hello,
I'd like to take over maintenance of the surf package for Fedora.
Good luck with the name collision...Someone asked me to rename it to surf-browser[1].
Ugh, a permanent delta forever...
-
Adam Williamson -
Alexander Ploumistos -
Christopher Meng -
Dmitrij S. Kryzhevich -
Kevin Fenzi -
Matthew Miller -
Neal Gompa -
Raphael Groner -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek