Unretire surf

[Neal Gompa]

Hello,

I'd like to take over maintenance of the surf package for Fedora.

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Neal Gompa]

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(a)gmail.com&gt; wrote:
>  Hello,
>
>  I'd like to take over maintenance of the surf package for Fedora.
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth! 


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Alexander Ploumistos]

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

[Neal Gompa]

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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]
>  


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Alexander Ploumistos]

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.

[Neal Gompa]

On Mon, Apr 18, 2016 at 4:54 PM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com&gt; 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! :)



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Alexander Ploumistos]

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

[Neal Gompa]

On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
<alex.ploumistos(a)gmail.com&gt; 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}`).


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Dmitrij S. Kryzhevich]

>  On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
>  <alex.ploumistos(a)gmail.com&gt; 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

[Alexander Ploumistos]

On Tue, Apr 19, 2016 at 6:14 AM, Dmitrij S. Kryzhevich <kryzhev(a)ispms.ru&gt;
wrote:

>  On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
> > <alex.ploumistos(a)gmail.com&gt; 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.

[Sérgio Basto]

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 
/home/sergio/FedoraReview/try-fedora-review '-x CheckOwnDirs' -n libprojectM

Best regards,
-- 
Sérgio M. B.

[Zbigniew Jędrzejewski-Szmek]

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 
>  /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

[Raphael Groner]

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

Just not care about guidelines is no solution to fix the broken process. In such a case,
we wouldn't need any guidelines.

[Zbigniew Jędrzejewski-Szmek]

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

[Kevin Fenzi]

On Tue, 19 Apr 2016 01:20:51 +0100
Sérgio Basto <sergio(a)serjux.com&gt; 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

[Sérgio Basto]

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(a)serjux.com&gt; 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(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail].
>  org 
-- 
Sérgio M. B.

[Matthew Miller]

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.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

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

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 is still there, blowing in
the wind...that was the last one.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Fenzi]

On Tue, 19 Apr 2016 11:36:54 -0700
Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote:
>  
>  For the record, we do in fact have a policy on this:
>  
>  https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_...
>  
>  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

[Adam Williamson]

On Tue, 2016-04-19 at 12:47 -0600, Kevin Fenzi wrote:
>  On Tue, 19 Apr 2016 11:36:54 -0700
>  Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote:
>  > 
>  > 
>  > For the record, we do in fact have a policy on this:
>  > 
>  > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_...
>  > 
>  > 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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

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_...
>  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 is 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. :)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

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_...
>  > 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 is
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
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthew Miller]

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.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Christopher Meng]

On 4/17/16, Neal Gompa <ngompa13(a)gmail.com&gt; 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

-- 

Yours sincerely,
Christopher Meng

http://awk.io

[Neal Gompa]

On Tue, Apr 19, 2016 at 10:59 AM, Christopher Meng <i(a)cicku.me&gt; wrote:
>  On 4/17/16, Neal Gompa <ngompa13(a)gmail.com&gt; 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
>  
Ugh, a permanent delta forever...

-- 
真実はいつも一つ！/ Always, there's only one truth!