4:54 a.m.
Hi guys,
I've started working to identify packages with missing upstream test suites or
not running the tests in %check. Having a list of hundreds of packages now I
need to prioritize them somehow. This will help in later steps when spec files
need to be fixed or somebody wants to start working with upstream on writing a
test suite.
My idea is to take all bugs against Fedora in the last few years (or releases).
Packages with bigger number of bugs receive higher priority than those with
less. Then based on this prioritize.
How long should the time frame be? I'm thinking 3 to 5 years.
Where low/medium/high priority boundaries are ? (could be 30%, 60%, 90% for
example).
Do you have other ideas how to calculate priority of these items?
Thanks,
Alex
5:13 a.m.
----- Original Message -----
From: "Alexander Todorov" <atodorov(a)redhat.com>
To: "For testing and quality assurance of Fedora releases"
<test(a)lists.fedoraproject.org>
Sent: Tuesday, February 25, 2014 12:54:42 PM
Subject: How to calculate priority for missing tests or %check
Hi guys,
I've started working to identify packages with missing upstream test suites
or
not running the tests in %check. Having a list of hundreds of packages now I
need to prioritize them somehow. This will help in later steps when spec
files
need to be fixed or somebody wants to start working with upstream on writing
a
test suite.
My idea is to take all bugs against Fedora in the last few years (or
releases).
Packages with bigger number of bugs receive higher priority than those with
less. Then based on this prioritize.
How long should the time frame be? I'm thinking 3 to 5 years.
Where low/medium/high priority boundaries are ? (could be 30%, 60%, 90% for
example).
Do you have other ideas how to calculate priority of these items?
My starting point would be from dependency POV. Packages with more dependencies (repoquery
is your friend) can break more things if broken thus deserve more testing.
Alexander Kurtakov
Red Hat Eclipse team
Thanks,
Alex
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
5:14 a.m.
----- Original Message -----
From: "Aleksandar Kurtakov" <akurtako(a)redhat.com>
To: "For testing and quality assurance of Fedora releases"
<test(a)lists.fedoraproject.org>
Sent: Tuesday, February 25, 2014 1:13:25 PM
Subject: Re: How to calculate priority for missing tests or %check
----- Original Message -----
> From: "Alexander Todorov" <atodorov(a)redhat.com>
> To: "For testing and quality assurance of Fedora releases"
> <test(a)lists.fedoraproject.org>
> Sent: Tuesday, February 25, 2014 12:54:42 PM
> Subject: How to calculate priority for missing tests or %check
>
> Hi guys,
> I've started working to identify packages with missing upstream test suites
> or
> not running the tests in %check. Having a list of hundreds of packages now
> I
> need to prioritize them somehow. This will help in later steps when spec
> files
> need to be fixed or somebody wants to start working with upstream on
> writing
> a
> test suite.
>
> My idea is to take all bugs against Fedora in the last few years (or
> releases).
> Packages with bigger number of bugs receive higher priority than those with
> less. Then based on this prioritize.
>
>
> How long should the time frame be? I'm thinking 3 to 5 years.
>
>
> Where low/medium/high priority boundaries are ? (could be 30%, 60%, 90% for
> example).
>
>
> Do you have other ideas how to calculate priority of these items?
My starting point would be from dependency POV. Packages with more
dependencies (repoquery is your friend) can break more things if broken thus
deserve more testing.
To clarify ordering based on the number of packages depending on the given one.
Alexander Kurtakov
Red Hat Eclipse team
>
>
> Thanks,
> Alex
> --
> test mailing list
> test(a)lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
5:32 a.m.
On Tue, 25 Feb 2014 12:54:42 +0200, Alexander Todorov wrote:
Hi guys,
I've started working to identify packages with missing upstream test suites
You will need to have a clear idea about _what to test_ in a test-suite
(and how to implement it). Else it would be a waste of time to even think
about filing bugs at Fedora or upstream.
or not running the tests in %check. Having a list of hundreds of
packages now I
need to prioritize them somehow. This will help in later steps when spec files
need to be fixed or somebody wants to start working with upstream on writing a
test suite.
My idea is to take all bugs against Fedora in the last few years (or releases).
Packages with bigger number of bugs receive higher priority than those with
less. Then based on this prioritize.
Same as above. Only if there is an idea how to decrease the number of bug
reports by avoiding runtime problems via the results of a test-suite, that
could become productive.
4:41 p.m.
On Tue, 2014-02-25 at 12:54 +0200, Alexander Todorov wrote:
Hi guys,
I've started working to identify packages with missing upstream test suites or
not running the tests in %check. Having a list of hundreds of packages now I
need to prioritize them somehow. This will help in later steps when spec files
need to be fixed or somebody wants to start working with upstream on writing a
test suite.
My idea is to take all bugs against Fedora in the last few years (or releases).
Packages with bigger number of bugs receive higher priority than those with
less. Then based on this prioritize.
How long should the time frame be? I'm thinking 3 to 5 years.
Where low/medium/high priority boundaries are ? (could be 30%, 60%, 90% for
example).
Do you have other ideas how to calculate priority of these items?
Anything on critpath -
https://fedoraproject.org/wiki/Critical_path_package - should probably
go straight to high priority.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:07 a.m.
On Tue, Feb 25, 2014 at 5:41 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Tue, 2014-02-25 at 12:54 +0200, Alexander Todorov wrote:
> Hi guys,
> I've started working to identify packages with missing upstream test suites or
> not running the tests in %check. Having a list of hundreds of packages now I
> need to prioritize them somehow. This will help in later steps when spec files
> need to be fixed or somebody wants to start working with upstream on writing a
> test suite.
>
> My idea is to take all bugs against Fedora in the last few years (or releases).
> Packages with bigger number of bugs receive higher priority than those with
> less. Then based on this prioritize.
>
>
> How long should the time frame be? I'm thinking 3 to 5 years.
>
>
> Where low/medium/high priority boundaries are ? (could be 30%, 60%, 90% for
> example).
>
>
> Do you have other ideas how to calculate priority of these items?
Anything on critpath -
https://fedoraproject.org/wiki/Critical_path_package - should probably
go straight to high priority.
Except the kernel. Please exclude it from all of this.
josh
9:19 a.m.
On Wed, 2014-02-26 at 09:07 -0500, Josh Boyer wrote:
Except the kernel. Please exclude it from all of this.
Also: xorg-x11-server, xorg-x11-drv-*, libdrm, libpciaccess, mesa. Any
reasonable amount of testing on those is going to require more hardware
access than is feasible at rpmbuild time.
- ajax
8:03 a.m.
На 26.02.2014 17:19, Adam Jackson написа:
On Wed, 2014-02-26 at 09:07 -0500, Josh Boyer wrote:
> Except the kernel. Please exclude it from all of this.
Also: xorg-x11-server, xorg-x11-drv-*, libdrm, libpciaccess, mesa. Any
reasonable amount of testing on those is going to require more hardware
access than is feasible at rpmbuild time.
Adam,
just for completeness - libpciaccess doesn't seem to have a test suite. Do you
mean to exclude it from the effort of creating one as well, or only exclude
reports for missing %check?
Btw the URL field in the spec file should be updated to
http://cgit.freedesktop.org/xorg/lib/libpciaccess/
--
Alex
10:24 a.m.
On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
Adam,
just for completeness - libpciaccess doesn't seem to have a test suite. Do you
mean to exclude it from the effort of creating one as well, or only exclude
reports for missing %check?
The latter.
Btw the URL field in the spec file should be updated to
http://cgit.freedesktop.org/xorg/lib/libpciaccess/
Oh yes, another useless rpm feature, I'll be sure to make that my top
priority.
- ajax
10:50 a.m.
On 27.02.2014 17:24, Adam Jackson wrote:
On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
...
> Btw the URL field in the spec file should be updated to
> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
Oh yes, another useless rpm feature, I'll be sure to make that my top
priority.
Care to elaborate why it is so for you?
poma
11:46 a.m.
On Thu, 2014-02-27 at 17:50 +0100, poma wrote:
On 27.02.2014 17:24, Adam Jackson wrote:
> On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
...
>> Btw the URL field in the spec file should be updated to
>> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
>
> Oh yes, another useless rpm feature, I'll be sure to make that my top
> priority.
Care to elaborate why it is so for you?
Are you seriously asking this.
1) There's a URL field in the spec file.
2) Apparently, it's wrong.
3) SOMEHOW, Alexander was able to find the right one.
How do you think he was able to do that? And, having just come to the
obvious conclusion that he typed it into a freaking search engine like
anyone else who's ever used an internet, why do you think there's any
value in a field that could just as easily be, in every spec file:
URL: http://lmgtfy.com/?q=%{name}
Next I expect I'll be taken to task for not using ExclusiveOS. How
lucky we don't have any actual bugs to work on so we can spend all this
time on useless busywork.
- ajax
12:57 p.m.
On 27.02.2014 18:46, Adam Jackson wrote:
On Thu, 2014-02-27 at 17:50 +0100, poma wrote:
> On 27.02.2014 17:24, Adam Jackson wrote:
>> On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
> ...
>>> Btw the URL field in the spec file should be updated to
>>> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
>>
>> Oh yes, another useless rpm feature, I'll be sure to make that my top
>> priority.
>
> Care to elaborate why it is so for you?
Are you seriously asking this.
1) There's a URL field in the spec file.
2) Apparently, it's wrong.
3) SOMEHOW, Alexander was able to find the right one.
How do you think he was able to do that? And, having just come to the
obvious conclusion that he typed it into a freaking search engine like
anyone else who's ever used an internet, why do you think there's any
value in a field that could just as easily be, in every spec file:
URL: http://lmgtfy.com/?q=%{name}
Next I expect I'll be taken to task for not using ExclusiveOS. How
lucky we don't have any actual bugs to work on so we can spend all this
time on useless busywork.
- ajax
One man's trash is another man's treasure.
Roughly speaking.
I do not see it as surplus, sorry. ;)
But then again, I am not you.
poma
1:31 p.m.
----- Original Message -----
From: "poma" <pomidorabelisima(a)gmail.com>
To: "For testing and quality assurance of Fedora releases"
<test(a)lists.fedoraproject.org>
Sent: Thursday, February 27, 2014 8:57:34 PM
Subject: Re: How to calculate priority for missing tests or %check
On 27.02.2014 18:46, Adam Jackson wrote:
> On Thu, 2014-02-27 at 17:50 +0100, poma wrote:
>> On 27.02.2014 17:24, Adam Jackson wrote:
>>> On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
>> ...
>>>> Btw the URL field in the spec file should be updated to
>>>> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
>>>
>>> Oh yes, another useless rpm feature, I'll be sure to make that my top
>>> priority.
>>
>> Care to elaborate why it is so for you?
>
> Are you seriously asking this.
>
> 1) There's a URL field in the spec file.
> 2) Apparently, it's wrong.
> 3) SOMEHOW, Alexander was able to find the right one.
>
> How do you think he was able to do that? And, having just come to the
> obvious conclusion that he typed it into a freaking search engine like
> anyone else who's ever used an internet, why do you think there's any
> value in a field that could just as easily be, in every spec file:
>
> URL: http://lmgtfy.com/?q=%{name}
>
> Next I expect I'll be taken to task for not using ExclusiveOS. How
> lucky we don't have any actual bugs to work on so we can spend all this
> time on useless busywork.
>
> - ajax
>
One man's trash is another man's treasure.
Roughly speaking.
I do not see it as surplus, sorry. ;)
But then again, I am not you.
I have similar feelings as ajax. It's not whether it's useless of treasure. If
someone says "give me commit rights as I want to make tests build|fix url|fix
formatting|improve BRs|etc. in package A you're maintainer" I would be more than
happy to welcome him/her as co-maintainer but just showing me such things as something to
be improved is not something that I would hurry to even look at as I'm aware of way
more problems that affect even runtime behaviour of the package and until these more
important things get fixed the rest is smth that the one identifing should come with a fix
otherwise it will stay for the bright future when we have endless time and resources.
Alexander Kurtakov
Red Hat Eclipse team
poma
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
1:49 p.m.
On 27.02.2014 20:31, Aleksandar Kurtakov wrote:
I have similar feelings as ajax. It's not whether it's
useless of treasure. If someone says "give me commit rights as I want to make tests
build|fix url|fix formatting|improve BRs|etc. in package A you're maintainer" I
would be more than happy to welcome him/her as co-maintainer but just showing me such
things as something to be improved is not something that I would hurry to even look at as
I'm aware of way more problems that affect even runtime behaviour of the package and
until these more important things get fixed the rest is smth that the one identifing
should come with a fix otherwise it will stay for the bright future when we have endless
time and resources.
OK, do you need help with a URLs?
poma
7:56 a.m.
На 27.02.2014 21:31, Aleksandar Kurtakov написа:
I have similar feelings as ajax. It's not whether it's
useless of treasure. If someone says "give me commit rights as I want to make tests
build|fix url|fix formatting|improve BRs|etc. in package A you're maintainer" I
would be more than happy to welcome him/her as co-maintainer but just showing me such
things as something to be improved is not something that I would hurry to even look at as
I'm aware of way more problems that affect even runtime behaviour of the package and
until these more important things get fixed the rest is smth that the one identifing
should come with a fix otherwise it will stay for the bright future when we have endless
time and resources.
So you mean somewhere around Fedora 100 when we enter the Singularity :).
>>> On 27.02.2014 17:24, Adam Jackson wrote:
>>>> On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
>>> ...
>>>>> Btw the URL field in the spec file should be updated to
>>>>> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
>>>>
>>>> Oh yes, another useless rpm feature, I'll be sure to make that my
top
>>>> priority.
>>>
Indeed I run a small test and from 2574 RPMs on the source DVD there is around
40% of "something different than HTTP 200 OK".
The majority (30%) are responses in the 3XX range and only less than 10% are
actual errors (4XX, 5XX, missing URLs or connection errors).
I'm not sure what purpose does the URL field serve nowadays but it looks like it
can be removed from the spec file (and RPM for that matter)!
--
Alex
8:25 a.m.
----- Original Message -----
From: "Alexander Todorov" <atodorov(a)redhat.com>
To: "For testing and quality assurance of Fedora releases"
<test(a)lists.fedoraproject.org>
Cc: "Alexander Kurtakov" <akurtakov(a)redhat.com>, "Discussion of RPM
packaging standards and practices for Fedora"
<packaging(a)lists.fedoraproject.org>
Sent: Friday, February 28, 2014 3:56:43 PM
Subject: Re: How to calculate priority for missing tests or %check
На 27.02.2014 21:31, Aleksandar Kurtakov написа:
> I have similar feelings as ajax. It's not whether it's useless of treasure.
> If someone says "give me commit rights as I want to make tests build|fix
> url|fix formatting|improve BRs|etc. in package A you're maintainer" I
> would be more than happy to welcome him/her as co-maintainer but just
> showing me such things as something to be improved is not something that I
> would hurry to even look at as I'm aware of way more problems that affect
> even runtime behaviour of the package and until these more important
> things get fixed the rest is smth that the one identifing should come with
> a fix otherwise it will stay for the bright future when we have endless
> time and resources.
>
So you mean somewhere around Fedora 100 when we enter the Singularity :).
Or even 1000 :). Whenever people start fixing the problems is the right answer.
"Talk is cheap, show me the code."
The time spent on these discussions could have ended in 10+ fixed packages if summed.
Alexander Kurtakov
Red Hat Eclipse team
>>>> On 27.02.2014 17:24, Adam Jackson wrote:
>>>>> On Thu, 2014-02-27 at 16:03 +0200, Alexander Todorov wrote:
>>>> ...
>>>>>> Btw the URL field in the spec file should be updated to
>>>>>> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
>>>>>
>>>>> Oh yes, another useless rpm feature, I'll be sure to make that
my top
>>>>> priority.
>>>>
Indeed I run a small test and from 2574 RPMs on the source DVD there is
around
40% of "something different than HTTP 200 OK".
The majority (30%) are responses in the 3XX range and only less than 10% are
actual errors (4XX, 5XX, missing URLs or connection errors).
I'm not sure what purpose does the URL field serve nowadays but it looks like
it
can be removed from the spec file (and RPM for that matter)!
--
Alex
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
1:24 p.m.
On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote:
I'm not sure what purpose does the URL field serve nowadays but
it looks like it
can be removed from the spec file (and RPM for that matter)!
No, please. It could be made *optional*. But there are certainly cases
where the upstream is non-discoverable - the generic-release one is a
fun one, for instance. There are cases where a project has forked, and
Google does not make it particularly obvious which side of the fork is
which. It's not a useless field.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:54 p.m.
On Fri, Feb 28, 2014 at 11:24:48AM -0800, Adam Williamson wrote:
On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote:
> I'm not sure what purpose does the URL field serve nowadays but it looks like it
> can be removed from the spec file (and RPM for that matter)!
No, please. It could be made *optional*. But there are certainly cases
where the upstream is non-discoverable - the generic-release one is a
fun one, for instance. There are cases where a project has forked, and
Google does not make it particularly obvious which side of the fork is
which. It's not a useless field.
I'd vote for optional, but there are plenty of other useless fields in spec
files. Group, for instance. Considering we don't even use those groupings.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
2:13 p.m.
On Fri, 2014-02-28 at 14:54 -0500, David Cantrell wrote:
On Fri, Feb 28, 2014 at 11:24:48AM -0800, Adam Williamson wrote:
> On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote:
>
> > I'm not sure what purpose does the URL field serve nowadays but it looks
like it
> > can be removed from the spec file (and RPM for that matter)!
>
> No, please. It could be made *optional*. But there are certainly cases
> where the upstream is non-discoverable - the generic-release one is a
> fun one, for instance. There are cases where a project has forked, and
> Google does not make it particularly obvious which side of the fork is
> which. It's not a useless field.
I'd vote for optional, but there are plenty of other useless fields in spec
files. Group, for instance. Considering we don't even use those groupings.
IIRC the guidelines pretty much explicitly state that.
Again IIRC, the reason we can't just go dropping stuff is that some
tools go wonky if some fields aren't present. The specfile format is an
API, to some extent.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:57 p.m.
On 02/28/2014 09:54 PM, David Cantrell wrote:
On Fri, Feb 28, 2014 at 11:24:48AM -0800, Adam Williamson wrote:
> On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote:
>
>> I'm not sure what purpose does the URL field serve nowadays but it looks like
it
>> can be removed from the spec file (and RPM for that matter)!
>
> No, please. It could be made *optional*. But there are certainly cases
> where the upstream is non-discoverable - the generic-release one is a
> fun one, for instance. There are cases where a project has forked, and
> Google does not make it particularly obvious which side of the fork is
> which. It's not a useless field.
I'd vote for optional, but there are plenty of other useless fields in spec
files. Group, for instance. Considering we don't even use those groupings.
URL is and has always been optional. Group used to be mandatory but has
been optional for about five years by now. Fedora policies could of
course differ with the technical side.
And FWIW no, I dont follow the "there are some packages with incorrect
URL, thus the field must be useless and should be removed" logic here.
Upstream project website does not change twice a week, more like perhaps
twice a decade if even that. If the package maintainers role is not to
save all the users from the trouble of doing the same job, then why are
we packaging stuff in the first place. Just google it up!
- Panu -
6:08 p.m.
On Fri, 2014-02-28 at 23:57 +0200, Panu Matilainen wrote:
And FWIW no, I dont follow the "there are some packages with
incorrect
URL, thus the field must be useless and should be removed" logic here.
Just to puree the horse further: I never said that.
I do believe that the most valuable URL that an rpm could point to would
in fact be procedurally generated, probably to something persistent like
what's on packages.debian.org, thus simultaneously solving the problems
of build recipe being intermingled with user metadata and
eventually-stale URLs forever burned into the rpm once built.
But, as with the original point about %check, the thing I'm
fundamentally irritated about is the apparent inability to distinguish
how things are from how they ought to be. In both cases it seems the
things we ought to be doing are ignored because they're not what's
currently in front of us. %check is a toy, but because it's there we
don't work on a test setup that's any good. URL is haphazard at best,
but because it's currently manual we don't work on the automation that
would make it reliably useful.
I expect better.
- ajax
6:14 p.m.
On Fri, 2014-02-28 at 19:08 -0500, Adam Jackson wrote:
%check is a toy, but because it's there we
don't work on a test setup that's any good.
Heh. Different perspectives, I suppose, but all I seem to see at the
moment is people working on test setups all over the place. Fedora QA is
working on Taskotron, which is certainly scoped to include the execution
of upstream test suites at appropriate points of the Fedora package
and/or distribution cycles (as well as lots of other things). Colin's
working on ostree. The GNOME folks have a QA effort coming together
which they've been kind enough to invite me and Tim into -
https://mail.gnome.org/mailman/listinfo/gnome-qa-list is the new mailing
list for that. Anaconda team is working on unit testing ATM, I believe,
which will help our installer quality a whole lot.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:52 p.m.
On Fri, Feb 28, 2014 at 11:57:38PM +0200, Panu Matilainen wrote:
On 02/28/2014 09:54 PM, David Cantrell wrote:
>On Fri, Feb 28, 2014 at 11:24:48AM -0800, Adam Williamson wrote:
>>On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote:
>>
>>>I'm not sure what purpose does the URL field serve nowadays but it looks
like it
>>>can be removed from the spec file (and RPM for that matter)!
>>
>>No, please. It could be made *optional*. But there are certainly cases
>>where the upstream is non-discoverable - the generic-release one is a
>>fun one, for instance. There are cases where a project has forked, and
>>Google does not make it particularly obvious which side of the fork is
>>which. It's not a useless field.
>
>I'd vote for optional, but there are plenty of other useless fields in spec
>files. Group, for instance. Considering we don't even use those groupings.
URL is and has always been optional. Group used to be mandatory but
has been optional for about five years by now. Fedora policies could
of course differ with the technical side.
Sorry, yes, I was specifically referring to packaging policy.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
12:27 p.m.
On Thu, 27 Feb 2014, Adam Jackson wrote:
> Btw the URL field in the spec file should be updated to
> http://cgit.freedesktop.org/xorg/lib/libpciaccess/
Oh yes, another useless rpm feature, I'll be sure to make that my top
priority.
sneer at it if you wish, but this is a feature of RPM that I
use often. Being able to have at least a hint to the web
presence of the upstream variant in play, and so to be able to
find a security mailing list and such is MUCH easier than
trawling through search engine clutter ( the old: .LSM files
having fallen out of favor )
-- Russ herrold
3745
days inactive
3751
days old
23 comments
10 participants
participants (10)
-
Adam Jackson -
Adam Williamson -
Aleksandar Kurtakov -
Alexander Todorov -
David Cantrell -
Josh Boyer -
Michael Schwendt -
Panu Matilainen -
poma -
R P Herrold