Once upon a time, Kevin Fenzi said:
> On Fri, 20 Jan 2012 17:15:57 -0600
> Chris Adams wrote:
> > I would think that making it release based rather than time based
> > should be okay. If there have been N released shipped without
> > package foo, then foo needs to be re-reviewed (with N being on
On Fri, 20 Jan 2012 17:15:57 -0600
Chris Adams wrote:
> Once upon a time, Kevin Fenzi said:
> > b) unretirement
> >
> > This could be pretty massive changes. If something was retired years
> > ago, the entire spec could be very different. Or it could have been
> > yesterday. But making the time
Once upon a time, Kevin Fenzi said:
> b) unretirement
>
> This could be pretty massive changes. If something was retired years
> ago, the entire spec could be very different. Or it could have been
> yesterday. But making the time variable for re-review makes it much
> more complex. Last time we l
On Thu, 19 Jan 2012 18:50:50 -0500
Stephen Gallagher wrote:
> On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote:
> > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
...snip...
> > > (And now with my packager hat on, fixing and/or updating a
> > > package in the repo also requires
On Tue, 17 Jan 2012 02:20:15 +0100
Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > We talked about, but never finished implementing a timeout on acl
> > requests.
> >
> > The way this would work is that maintainer would have some time.. 3
> > weeks or something to reject a acl request. If they did
On 19 January 2012 23:23, David Tardon wrote:
> On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote:
>> On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote:
>> > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
>> > > Kevin Fenzi wrote:
>> > > > Keeping packages around wit
On Thu, Jan 19, 2012 at 03:30:50PM -0800, Adam Williamson wrote:
> On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
> > Kevin Fenzi wrote:
> > > Keeping packages around with no maintainers or people handling their
> > > bugs is poor for everyone.
> >
> > Why? If I, as a user, really need a c
On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote:
> On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote:
> > On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
> > > Kevin Fenzi wrote:
> > > > Keeping packages around with no maintainers or people handling their
> > > > bug
On 01/19/2012 11:50 PM, Stephen Gallagher wrote:
Yes, I agree with this completely. If something is not being maintained
in Fedora, it's better to retire it. Then a user who wants that piece of
software will have two options:
1) They can build it and maintain it themselves on their own system(s)
On 01/19/2012 11:30 PM, Adam Williamson wrote:
This is an important point: I think it would be much less of a problem
to retire packages if the process for unretiring them were not so
painful. I_do_ think the unretiring process is an excellent example of
unnecessary bureaucracy (as is the renami
On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote:
> On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
> > Kevin Fenzi wrote:
> > > Keeping packages around with no maintainers or people handling their
> > > bugs is poor for everyone.
> >
> > Why? If I, as a user, really need a certain
On 01/19/2012 04:30 PM, Adam Williamson wrote:
On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
Kevin Fenzi wrote:
Keeping packages around with no maintainers or people handling their
bugs is poor for everyone.
Why? If I, as a user, really need a certain piece of software, I'd rather
ha
On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Keeping packages around with no maintainers or people handling their
> > bugs is poor for everyone.
>
> Why? If I, as a user, really need a certain piece of software, I'd rather
> have an unmaintained package than non
On 01/17/2012 09:54 AM, Stephen Gallagher wrote:
On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote:
While that makes some sense, it was not my point. My point was that even if
the package has NO maintainer, as long as it works, it's still better than
no package at all!
Not true. A package
* Ralf Corsepius [17/01/2012 20:34] :
>
> It's not uncommon to Fedora users to confronted with /dev/null style
> answers. It's just that they are called "FIXED RAWHIDE", "FIXED
> UPSTREAM" or "no reply" and not explicitly labeled "/dev/null" ;)
Nitpick: There is no status "FIXED" in Fedora's bug
On 01/17/2012 06:31 PM, Ralf Corsepius wrote:
Well, you leave me no other choice but to pronounce something you
probably don't want to hear:
It's not uncommon to Fedora users to confronted with /dev/null style
answers. It's just that they are called "FIXED RAWHIDE", "FIXED
UPSTREAM" or "no
On 01/17/2012 05:26 PM, Michael Schwendt wrote:
On Tue, 17 Jan 2012 09:54:39 -0500, SG (Stephen) wrote:
On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote:
While that makes some sense, it was not my point. My point was that even if
the package has NO maintainer, as long as it works, it's st
On Tue, 17 Jan 2012 09:54:39 -0500, SG (Stephen) wrote:
> On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote:
> > While that makes some sense, it was not my point. My point was that even if
> > the package has NO maintainer, as long as it works, it's still better than
> > no package at all!
>
On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote:
> While that makes some sense, it was not my point. My point was that even if
> the package has NO maintainer, as long as it works, it's still better than
> no package at all!
Not true. A package that appears to work, has people using it, bu
On 01/17/2012 01:21 AM, Kevin Kofler wrote:
While that makes some sense, it was not my point. My point was that even if
the package has NO maintainer, as long as it works, it's still better than
no package at all!
I disagree packages without maintainers should not be shipped in the
distributio
Kevin Fenzi wrote:
> We talked about, but never finished implementing a timeout on acl
> requests.
>
> The way this would work is that maintainer would have some time.. 3
> weeks or something to reject a acl request. If they did not do so,
> pkgdb would automatically approve it at the end of the t
Brendan Jones wrote:
> I agree! If a package is orphaned, can't we automatically escalate
> ownership to the next co-maintainer (when there is one - perhaps the one
> with the most commits for example).
>
> If a package is being orphaned for legitimate reasons, the owner should
> announce the inte
Mattia Verga wrote:
> For the second point, I don't know if a new review should be really
> necessary only to verify the presence of "obsoletes and provides": in my
> opinion if someone is a package maintainer he/she MUST already know how
> to rename a package and that this requires "obsoletes and
On Mon, 16 Jan 2012 05:01:29 +0100
Ralf Corsepius wrote:
> On 01/16/2012 03:20 AM, Kevin Fenzi wrote:
> > On Sat, 14 Jan 2012 18:28:15 +0100
> > Kevin Kofler wrote:
> >
> >> Michael Schwendt wrote:
> >>> However, with the current features of pkgdb, each member of such a
> >>> group would need to
Yes, with skychart I made some confusion: after a discussion on a forum
I thought I can use a request for updating a package as a review ticket,
but I soon realize that this wasn't possible. So I became a maintainer
in the correct way and after that I asked privileges in pkgdb to become
a co-ma
On 01/16/2012 03:20 AM, Kevin Fenzi wrote:
On Sat, 14 Jan 2012 18:28:15 +0100
Kevin Kofler wrote:
Michael Schwendt wrote:
However, with the current features of pkgdb, each member of such a
group would need to "subscribe to" the package in pkgdb. Not just
for "commit" access, but also for some
On Sun, 15 Jan 2012 20:37:16 +0100
Mattia Verga wrote:
> I'm just entered the world of Fedora packagers and I see a few points
> that can be optimized in my opinion.
Welcome by the way. ;)
> 1. I saw a package that need to be upgraded. I opened a bug in
> bugzilla, after some time whit no res
On Sun, 15 Jan 2012 18:39:48 +0100
Michael J Gruber wrote:
...snip...
(Please trim you emails...)
> Took bibexport.
>
> mathmap seems to be dead upstream as a Gimp plugin, unfortunately.
> (It's supposed to be turned into a web service...)
>
> While it's a pitty to see it go away, pampering t
On Sat, 14 Jan 2012 18:28:15 +0100
Kevin Kofler wrote:
> Michael Schwendt wrote:
> > However, with the current features of pkgdb, each member of such a
> > group would need to "subscribe to" the package in pkgdb. Not just
> > for "commit" access, but also for someone to monitor bugzilla and
> > t
On Sun, 15 Jan 2012 20:37:16 +0100, MV (Mattia) wrote:
> I'm just entered the world of Fedora packagers and I see a few points
> that can be optimized in my opinion.
>
> 1. I saw a package that need to be upgraded. I opened a bug in bugzilla,
> after some time whit no response from the maintain
I'm just entered the world of Fedora packagers and I see a few points
that can be optimized in my opinion.
1. I saw a package that need to be upgraded. I opened a bug in bugzilla,
after some time whit no response from the maintainer I asked in pkgdb
permissions for that package: I'm still wait
Bill Nottingham venit, vidit, dixit 13.01.2012 17:11:
> Each release, before branching, we block currently orphaned packages.
> It's that time again for Fedora 17.
>
> New this go-round is that we are also blocking packages that have
> failed to build since before Fedora 15.
>
> The following pac
On Sun, Jan 15, 2012 at 2:46 PM, Bruno Wolff III wrote:
> On Sun, Jan 15, 2012 at 11:48:35 +0100,
> Brendan Jones wrote:
>> On 01/14/2012 07:12 PM, Kevin Kofler wrote:
>> I agree! If a package is orphaned, can't we automatically escalate
>> ownership to the next co-maintainer (when there is one
On Sun, Jan 15, 2012 at 11:48:35 +0100,
Brendan Jones wrote:
> On 01/14/2012 07:12 PM, Kevin Kofler wrote:
> I agree! If a package is orphaned, can't we automatically escalate
> ownership to the next co-maintainer (when there is one - perhaps the
> one with the most commits for example).
>
> If
On 01/14/2012 07:12 PM, Kevin Kofler wrote:
Kevin Fenzi wrote:
Keeping packages around with no maintainers or people handling their
bugs is poor for everyone.
Why? If I, as a user, really need a certain piece of software, I'd rather
have an unmaintained package than none at all! Worst case, I
* Kevin Kofler [14/01/2012 22:06] :
>
> That's exactly why we need proper support for group ownership in pkgdb.
I believe that this isn't going to happen unless the people who want it
actually submit patches for pkgdb to implement it. Should it be none the less
implemented by other people, there's
Kevin Fenzi wrote:
> Thats your preference. Some people would be better off with another
> supported package that does something similar, or even a package from
> an upstream thats more up to date or functional.
That assumes such a package exists. I have no problems with packages getting
retired
Am 14.01.2012 19:12, schrieb Kevin Kofler:
> Kevin Fenzi wrote:
>> Keeping packages around with no maintainers or people handling their
>> bugs is poor for everyone.
>
> Why? If I, as a user, really need a certain piece of software, I'd rather
> have an unmaintained package than none at all!
b
On Sat, 14 Jan 2012 18:45:28 +0100, KK (Kevin) wrote:
> Michael Schwendt wrote:
> > Why must it be the opposite? Arbitrary access to packages, possibly
> > sporadic or random upgrades (as time permits), with no one taking care of
> > the packages normally.
>
> Because it's a much more effective u
On Sat, 14 Jan 2012 19:12:58 +0100
Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Keeping packages around with no maintainers or people handling their
> > bugs is poor for everyone.
>
> Why? If I, as a user, really need a certain piece of software, I'd
> rather have an unmaintained package than no
Kevin Fenzi wrote:
> Keeping packages around with no maintainers or people handling their
> bugs is poor for everyone.
Why? If I, as a user, really need a certain piece of software, I'd rather
have an unmaintained package than none at all! Worst case, I can't use the
package at all, in which cas
Jóhann B. Guðmundsson wrote:
> What I'm trying to say here is that there is a magic number ( it might
> be 8 it might be more but most likely it's less ) to how many packages
> single individual can properly and reliably maintain in the distribution.
>
> The rules become somewhat different with r
Michael Schwendt wrote:
> Why must it be the opposite? Arbitrary access to packages, possibly
> sporadic or random upgrades (as time permits), with no one taking care of
> the packages normally.
Because it's a much more effective use of our limited manpower. Everyone
does what they currently have
Michael Schwendt wrote:
> However, with the current features of pkgdb, each member of such a group
> would need to "subscribe to" the package in pkgdb. Not just for "commit"
> access, but also for someone to monitor bugzilla and the package-owner
> mail alias, which is convenient for team-work, too
2012/1/14 "Jóhann B. Guðmundsson" :
> On 01/14/2012 12:10 PM, Iain Arnell wrote:
>>
>> Then you can't blindly work the averages and apply hard limits. Just
>> because some packages are high maintenance, doesn't mean that can't
>> cope with dozens of low maintenance packages.
>>
>
> That hard limit
...snip..
FWIW, I largely agree with Michael Schwendt here.
Keeping packages around with no maintainers or people handling their
bugs is poor for everyone.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mai
On Sat, 14 Jan 2012 14:03:32 +
"Jóhann B. Guðmundsson" wrote:
> On 01/14/2012 12:10 PM, Iain Arnell wrote:
> > Then you can't blindly work the averages and apply hard limits. Just
> > because some packages are high maintenance, doesn't mean that can't
> > cope with dozens of low maintenance p
On 01/14/2012 12:10 PM, Iain Arnell wrote:
Then you can't blindly work the averages and apply hard limits. Just
because some packages are high maintenance, doesn't mean that can't
cope with dozens of low maintenance packages.
That hard limit is based on an guestimated time it takes to fix a si
2012/1/14 "Jóhann B. Guðmundsson" :
> On 01/14/2012 10:44 AM, Iain Arnell wrote:
>>
>> You've got to be kidding. In a little over three years, I've picked up
>> more than 300 packages and only 81 bugs - most of which are from
>> upstream release monitoring. I've got no problem at all keeping up
>>
On Sat, 14 Jan 2012 09:12:06 +0100, KK (Kevin) wrote:
> > Even in the scenario of project-wide write-access to
> > packages, there must be someone to decide when to perform an upgrade.
>
> Not if we make it a project-wide policy to upgrade whenever there isn't a
> strong reason not to (as I've b
On 01/14/2012 10:44 AM, Iain Arnell wrote:
You've got to be kidding. In a little over three years, I've picked up
more than 300 packages and only 81 bugs - most of which are from
upstream release monitoring. I've got no problem at all keeping up
with the work.
Nope no kidding with my example ab
On Sat, 14 Jan 2012 06:10:48 +0100, RC (Ralf) wrote:
> > Even in the scenario of project-wide write-access to packages,
> > there must be someone to decide when to perform an upgrade.
>
> ... but this someone doesn't have to be an individual nor does it have
> to be the package maintainer. It can
2012/1/14 "Jóhann B. Guðmundsson" :
[snip]
> Agreed with the added point that we also need to put limits on how many
> packages an single individual can own/maintain/co-maintain regardless of the
> nature of the package ( high maintenance/low maintenance).
>
> Finding that magic number should not p
On Sat, Jan 14, 2012 at 6:14 AM, Ralf Corsepius wrote:
> On 01/13/2012 10:10 PM, Bill Nottingham wrote:
>>
>> Sérgio Basto (ser...@serjux.com) said:
The script that generated this page can be found at
https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py
>>
On 01/13/2012 09:51 PM, Michael Schwendt wrote:
On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote:
When we're in danger of losing so many packages, it's a sign that our
processes are broken:
That's a dubious conclusion.
Agreed the current process only highlights the underlying cause.
The
Bruno Wolff III wrote on 2012-01-14:
> On Sat, Jan 14, 2012 at 03:54:08 +,
> "Wei, Gang" wrote:
>> If I pick up tboot package successfully asap, will it still be
>> possible to be kept
> in F-17?
>
> Another message had the date the packages needed to be picked up by.
> I think it was Febru
- Original Message -
> From: "Kevin Kofler"
> To: devel@lists.fedoraproject.org
> Sent: Saturday, January 14, 2012 10:12:06 AM
> Subject: Re: [ACTION REQUIRED] Retiring packages for F-17
>
> Michael Schwendt wrote:
> > Are you trying to say the Fedora
Ralf Corsepius wrote:
> Do you realize that such "demands for more people" often are symptoms of
> a failing system?
>
> The common alternatives are to "improve efficency" and to "improve
> productivity" using those resources you have available. Approaches into
> this direction would be "teaming u
Michael Schwendt wrote:
> Are you trying to say the Fedora Project has made it much too easy for
> them to leave and have their account disabled, too?
I'm saying that it's the ever-increasing bureaucracy which causes us to lose
maintainers, that's all.
> No, it isn't. Even in the scenario of pro
On Fri, 2012-01-13 at 21:51 -0600, Bruno Wolff III wrote:
> On Sat, Jan 14, 2012 at 03:47:47 +,
> "Wei, Gang" wrote:
> > Login as gwei3, and enter tboot package
> > url(https://admin.fedoraproject.org/pkgdb/acls/name/tboot), press "take
> > ownership" buttons for Fedora devel/15/16, wait f
On 01/13/2012 10:10 PM, Bill Nottingham wrote:
Sérgio Basto (ser...@serjux.com) said:
The script that generated this page can be found at
https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py
This script is supposed to run on my laptop , if I have a fas account
and keys to
On 01/13/2012 10:51 PM, Michael Schwendt wrote:
On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote:
When we're in danger of losing so many packages, it's a sign that our
processes are broken:
That's a dubious conclusion.
I concur with Kevin.
* The whole concept of packages being "owned",
On 01/13/2012 06:49 PM, Jon Ciesla wrote:
On Fri, Jan 13, 2012 at 11:23 AM, Ralf Corsepius wrote:
Note2: How to remove oneself as co-maintainer in the packagedb?
For those packages, I already was co-maintainer, I am now enrolled as both
maintainer and co-maintainer.
I think you just change
On Sat, Jan 14, 2012 at 03:54:08 +,
"Wei, Gang" wrote:
> If I pick up tboot package successfully asap, will it still be possible to be
> kept in F-17?
Another message had the date the packages needed to be picked up by.
I think it was February 7th.
--
devel mailing list
devel@lists.fedora
On Sat, Jan 14, 2012 at 03:47:47 +,
"Wei, Gang" wrote:
> Login as gwei3, and enter tboot package
> url(https://admin.fedoraproject.org/pkgdb/acls/name/tboot), press "take
> ownership" buttons for Fedora devel/15/16, wait for a while then the buttons
> keeps as grayed, refresh the page, th
If I pick up tboot package successfully asap, will it still be possible to be
kept in F-17?
> > Each release, before branching, we block currently orphaned packages.
> > It's that time again for Fedora 17.
> >
> > New this go-round is that we are also blocking packages that have
> > failed to bui
> Each release, before branching, we block currently orphaned packages.
> It's that time again for Fedora 17.
>
> New this go-round is that we are also blocking packages that have
> failed to build since before Fedora 15.
>
> The following packages are currently orphaned, or fail to build. If
> y
Michael Schwendt writes:
What doesn't work is that we're supposed to "sponsor" people, who dump
packages into the collection without really trying to take care of them
afterwards. With no other users of those packages joining the team that
tries to maintain the packages. With bug reports being i
Dne 13.1.2012 21:03, Kevin Kofler napsal(a):
time to pick them up first, e.g. in one case (avl), your mail threatens to
retire a package less than 97 minutes (!) after it got orphaned. The time
This is purely my fault ... nobody uses avl to the best of my knowledge,
and I have just forgot to o
Wes Hardaker wrote:
> I agree; I fail to see why a package should be removed if it is still
> compiling (and testing if a test suite is part of it) properly in the
> build system. Sure, it could be out of date but that's better than
> non-existent.
>
> Now, if it fails to build then yes: there is
On 01/13/2012 11:11 AM, Bill Nottingham wrote:
Each release, before branching, we block currently orphaned packages.
It's that time again for Fedora 17.
New this go-round is that we are also blocking packages that have
failed to build since before Fedora 15.
The following packages are currently
On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote:
> When we're in danger of losing so many packages, it's a sign that our
> processes are broken:
That's a dubious conclusion.
> * The forced password and SSH key change caused us to lose many maintainers,
> not all of whom would have become
> On Fri, 13 Jan 2012 21:03:09 +0100, Kevin Kofler
> said:
KK> Any package which is removed from Fedora is a package our users will
KK> no longer be able to use. Removing a package should only be a last
KK> resort if it cannot be made to work at all.
I agree; I fail to see why a package
Sérgio Basto (ser...@serjux.com) said:
> > The script that generated this page can be found at
> > https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py
>
> This script is supposed to run on my laptop , if I have a fas account
> and keys to login on koji ?
You can do that,
On Fri, 2012-01-13 at 11:11 -0500, Bill Nottingham wrote:
> Each release, before branching, we block currently orphaned packages.
> It's that time again for Fedora 17.
>
> New this go-round is that we are also blocking packages that have
> failed to build since before Fedora 15.
>
> The followin
I took GREYCstoration.
On Fri, Jan 13, 2012 at 3:03 PM, Kevin Kofler wrote:
> Bill Nottingham wrote:
>> Due to the orphaning of packages due to inactive maintainers, this list
>> is a little longer than normal.
>
> When we're in danger of losing so many packages, it's a sign that our
> processes
Bill Nottingham wrote:
> Due to the orphaning of packages due to inactive maintainers, this list
> is a little longer than normal.
When we're in danger of losing so many packages, it's a sign that our
processes are broken:
* The forced password and SSH key change caused us to lose many maintaine
I have taken these packages:
avalon-framework
avalon-logkit
bcel
bsf
jakarta-commons-httpclient
On Fri, Jan 13, 2012 at 2:37 PM, Bill Nottingham wrote:
> Bill Nottingham (nott...@redhat.com) said:
>> Each release, before branching, we block currently orphaned packages.
>> It's that time again fo
Bill Nottingham (nott...@redhat.com) said:
> Each release, before branching, we block currently orphaned packages.
> It's that time again for Fedora 17.
If these packages are not claimed, they will be retired before we branch off
of rawhide on February 7.
Bill
--
devel mailing list
devel@lists.
On Fri, Jan 13, 2012 at 11:11:13 -0500,
Bill Nottingham wrote:
>
> The following packages are currently orphaned, or fail to build. If
> you have a need for one of these packages, please pick them up.
I have taken ownership of the following packages:
fortune-firefly
nethack-vultures
sear
sear-
On Fri, 13 Jan 2012 11:11:13 -0500
Bill Nottingham wrote:
> Each release, before branching, we block currently orphaned packages.
> It's that time again for Fedora 17.
>
> New this go-round is that we are also blocking packages that have
> failed to build since before Fedora 15.
>
> The followi
I took qbrew.
Rich
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Jan 13, 2012 at 11:23 AM, Ralf Corsepius wrote:
> On 01/13/2012 05:11 PM, Bill Nottingham wrote:
>>
>> Each release, before branching, we block currently orphaned packages.
>> It's that time again for Fedora 17.
>>
>> New this go-round is that we are also blocking packages that have
>> fai
On 01/13/2012 05:11 PM, Bill Nottingham wrote:
Each release, before branching, we block currently orphaned packages.
It's that time again for Fedora 17.
New this go-round is that we are also blocking packages that have
failed to build since before Fedora 15.
The following packages are currently
I took libxdg-basedir for xmoto.
-J
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 13 Jan 2012 11:11:13 -0500, BN (Bill) wrote:
> Orphan eiciel
Taken since I've kept it alive last year, too.
> Orphan xmms-pulse
This will need active development rather than just packaging, because
it is still old code that causes problems meanwhile. Inspiration for
changes that will b
86 matches
Mail list logo
