On 19 January 2012 23:23, David Tardon dtar...@redhat.com 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
On Tue, 17 Jan 2012 02:20:15 +0100
Kevin Kofler kevin.kof...@chello.at 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.
On Thu, 19 Jan 2012 18:50:50 -0500
Stephen Gallagher sgall...@redhat.com 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
Once upon a time, Kevin Fenzi ke...@scrye.com 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
On Fri, 20 Jan 2012 17:15:57 -0600
Chris Adams cmad...@hiwaay.net wrote:
Once upon a time, Kevin Fenzi ke...@scrye.com 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
Once upon a time, Kevin Fenzi ke...@scrye.com said:
On Fri, 20 Jan 2012 17:15:57 -0600
Chris Adams cmad...@hiwaay.net 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
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
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 none at
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
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 piece of
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
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 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
bugs is poor for
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 certain piece
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
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, but
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!
Not
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
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
* 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 bugzilla
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
On Mon, 16 Jan 2012 05:01:29 +0100
Ralf Corsepius rc040...@freenet.de wrote:
On 01/16/2012 03:20 AM, Kevin Fenzi wrote:
On Sat, 14 Jan 2012 18:28:15 +0100
Kevin Koflerkevin.kof...@chello.at wrote:
Michael Schwendt wrote:
However, with the current features of pkgdb, each member of such
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
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 intention
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 time.
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
On Sun, Jan 15, 2012 at 11:48:35 +0100,
Brendan Jones brendan.jones...@gmail.com 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
On Sun, Jan 15, 2012 at 2:46 PM, Bruno Wolff III br...@wolff.to wrote:
On Sun, Jan 15, 2012 at 11:48:35 +0100,
Brendan Jones brendan.jones...@gmail.com 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
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 packages
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
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 maintainer I
On Sun, 15 Jan 2012 18:39:48 +0100
Michael J Gruber michaeljgruber+gm...@fastmail.fm 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
On Sun, 15 Jan 2012 20:37:16 +0100
Mattia Verga mattia.ve...@tiscali.it 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
On 01/16/2012 03:20 AM, Kevin Fenzi wrote:
On Sat, 14 Jan 2012 18:28:15 +0100
Kevin Koflerkevin.kof...@chello.at 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
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
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 up, less
- Original Message -
From: Kevin Kofler kevin.kof...@chello.at
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 Project has made
Bruno Wolff III wrote on 2012-01-14:
On Sat, Jan 14, 2012 at 03:54:08 +,
Wei, Gang gang@intel.com 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
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.
On Sat, Jan 14, 2012 at 6:14 AM, Ralf Corsepius rc040...@freenet.de 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
2012/1/14 Jóhann B. Guðmundsson johan...@gmail.com:
[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
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 be a
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
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 been
2012/1/14 Jóhann B. Guðmundsson johan...@gmail.com:
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
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
On Sat, 14 Jan 2012 14:03:32 +
Jóhann B. Guðmundsson johan...@gmail.com 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
...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
2012/1/14 Jóhann B. Guðmundsson johan...@gmail.com:
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
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.
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
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
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 case
On Sat, 14 Jan 2012 19:12:58 +0100
Kevin Kofler kevin.kof...@chello.at 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
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 use of
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!
be
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
* 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
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 be
I took libxdg-basedir for xmoto.
-J
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
On Fri, Jan 13, 2012 at 11:23 AM, Ralf Corsepius rc040...@freenet.de 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
I took qbrew.
Rich
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 13 Jan 2012 11:11:13 -0500
Bill Nottingham nott...@redhat.com 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.
On Fri, Jan 13, 2012 at 11:11:13 -0500,
Bill Nottingham nott...@redhat.com 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
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
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 nott...@redhat.com wrote:
Bill Nottingham (nott...@redhat.com) said:
Each release, before branching, we block currently orphaned packages.
It's that
I took GREYCstoration.
On Fri, Jan 13, 2012 at 3:03 PM, Kevin Kofler kevin.kof...@chello.at 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
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 following
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, yes.
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
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
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
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 build since
On Sat, Jan 14, 2012 at 03:47:47 +,
Wei, Gang gang@intel.com 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
On Sat, Jan 14, 2012 at 03:54:08 +,
Wei, Gang gang@intel.com 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
On 01/13/2012 06:49 PM, Jon Ciesla wrote:
On Fri, Jan 13, 2012 at 11:23 AM, Ralf Corsepiusrc040...@freenet.de 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
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 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
79 matches
Mail list logo
