Re: Unretire surf

[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

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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_Severity
> > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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_Severity
> 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

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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  wrote:
> > 
> > 
> > For the record, we do in fact have a policy on this:
> > 
> > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#Priority_and_Severity
> > 
> > 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Kevin Fenzi]

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



pgpvt1t0f89Fk.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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_Severity

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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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

Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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  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
(...)
real0m1.335s
user0m1.084s
sys 0m0.110s

time dnf repoquery -q -C --requires --resolve glibc
(...)
real4m24.474s
user4m22.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
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Kevin Fenzi]

On Tue, 19 Apr 2016 01:20:51 +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

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




pgpnY_SwG0Hv5.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Neal Gompa]

On Tue, Apr 19, 2016 at 10:59 AM, Christopher Meng  wrote:
> On 4/17/16, Neal Gompa  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!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Christopher Meng]

On 4/17/16, Neal Gompa  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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 19, 2016 at 01:00:56PM -, 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_Ownership
> 
> 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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_Ownership

Just not care about guidelines is no solution to fix the broken process. In 
such a case, we wouldn't need any guidelines.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Alexander Ploumistos]

On Tue, Apr 19, 2016 at 6:14 AM, Dmitrij S. Kryzhevich 
wrote:

> On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
>>  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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Dmitrij S. Kryzhevich]

On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
 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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

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

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Neal Gompa]

On Mon, Apr 18, 2016 at 6:02 PM, Alexander Ploumistos
 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!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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")
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[Neal Gompa]

On Mon, Apr 18, 2016 at 4:54 PM, 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
> * 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!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

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



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unretire surf

[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  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!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Unretire surf

[Neal Gompa]

Hello,

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

-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org