Re: Unretire surf
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
