On Fri, Feb 26, 2010 at 07:46:58AM -0800, Jesse Keating wrote:
On Fri, 2010-02-26 at 16:23 +0100, Patrice Dumas wrote:
Because EPEL has to be very stable, so additional time spent in testing is
even better, for example for reasons you highlight below. I never said
that packages should not
On 10-02-26 11:07:34, Michael Cronenworth wrote:
...
Yes, this functionality is available in bodhi-client and I use it
myself, but isn't it safe to say there are many Fedora users that
have no idea what bodhi-client is or even admin.fp.o?
...
The bodhi-client package could really use a
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the maintainer experienced/uses
If nobody is complaining about the bug, then fixing the bug can wait
until the next Fedora release.
2) As already told several times, not having people to test
On Fri, Feb 26, 2010 at 08:16:18PM +0100, Richard Zidlicky wrote:
On Fri, Feb 26, 2010 at 01:49:00PM -0500, Orcan Ogetbil wrote:
On Fri, Feb 26, 2010 at 12:34 PM, drago01 wrote:
On Fri, Feb 26, 2010 at 6:27 PM, Mike McGrath wrote:
[...]
Though, in theory, fewer updates means a higher
On Fri, Feb 26, 2010 at 2:16 PM, Richard Zidlicky wrote:
On Fri, Feb 26, 2010 at 01:49:00PM -0500, Orcan Ogetbil wrote:
On Fri, Feb 26, 2010 at 12:34 PM, drago01 wrote:
On Fri, Feb 26, 2010 at 6:27 PM, Mike McGrath wrote:
[...]
Though, in theory, fewer updates means a higher percentage
On Fri, Feb 26, 2010 at 07:18:58PM +, Matthew Garrett wrote:
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the maintainer experienced/uses
If nobody is complaining about the bug, then fixing the bug can wait
until the next Fedora release.
On Fri, 26 Feb 2010, Matthew Garrett wrote:
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the maintainer experienced/uses
If nobody is complaining about the bug, then fixing the bug can wait
until the next Fedora release.
Do you have the time
On Fri, Feb 26, 2010 at 08:41:07PM +0100, Till Maas wrote:
On Fri, Feb 26, 2010 at 07:18:58PM +, Matthew Garrett wrote:
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the maintainer experienced/uses
If nobody is complaining about the
On Fri, 26 Feb 2010 19:18:58 +, Matthew wrote:
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the maintainer experienced/uses
If nobody is complaining about the bug, then fixing the bug can wait
until the next Fedora release.
Brilliant
On Fri, Feb 26, 2010 at 07:56:02PM +, Matthew Garrett wrote:
On Fri, Feb 26, 2010 at 08:41:07PM +0100, Till Maas wrote:
On Fri, Feb 26, 2010 at 07:18:58PM +, Matthew Garrett wrote:
On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote:
1) to fix a bug or add a feature the
On Fri, Feb 26, 2010 at 11:36:41AM -0800, Jesse Keating wrote:
On Fri, 2010-02-26 at 20:26 +0100, Till Maas wrote:
First”) include
first.
I take this to mean the first to include something in a release, as we
develop it, not the first one to throw it over the wall at our users of
a
Till Maas (opensou...@till.name) said:
I just have another idea: Add the karma value to the repository
metadata and write a yum plugin to only install packages with a certain
amount of karma. I just checked that stable packages may still receive
karma, so then everyone can pre-select packages
On Fri, Feb 26, 2010 at 11:27:45AM -0600, Mike McGrath wrote:
Though, in theory, fewer updates means a higher percentage of them can be
tested which means quality goes up.
This does not take testing bugfixing at upstream and other
distributions into account. And I am pretty sure, that there
On Fri, Feb 26, 2010 at 9:43 PM, Till Maas opensou...@till.name wrote:
On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote:
I would like to collect feedback on this issue. If you want to disable
direct stable pushes, why? Could there be a less radical solution to that
problem (e.g. a
On Fri, 26 Feb 2010, Bill Nottingham wrote:
Till Maas (opensou...@till.name) said:
I just have another idea: Add the karma value to the repository
metadata and write a yum plugin to only install packages with a certain
amount of karma. I just checked that stable packages may still receive
Mike McGrath (mmcgr...@redhat.com) said:
I just have another idea: Add the karma value to the repository
metadata and write a yum plugin to only install packages with a certain
amount of karma. I just checked that stable packages may still receive
karma, so then everyone can
On Fri, 2010-02-26 at 21:43 +0100, Till Maas wrote:
On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote:
I would like to collect feedback on this issue. If you want to disable
direct stable pushes, why? Could there be a less radical solution to that
problem (e.g. a policy
2010/2/26 Bill Nottingham nott...@redhat.com:
Till Maas (opensou...@till.name) said:
I just have another idea: Add the karma value to the repository
metadata and write a yum plugin to only install packages with a certain
amount of karma. I just checked that stable packages may still receive
Jesse Keating wrote:
It is an issue with the process when the process allows for these types
of updates to go direct to stable without getting any karma along the
way. It clearly illustrates that we need a system that protects our
users from our maintainers, as our maintainers clearly cannot
On Fri, 26 Feb 2010, Kevin Fenzi wrote:
A quicker way of seeing if a bug report was alread made, and more
quickly being able to report bugs then spending 15-30 with bugzilla
would help me in reporting more bugs. I like the automated crash
reporting, though I'm not sure where they go, as I
Orcan Ogetbil wrote:
I didn't see many users complaining that there are too many updates.
But I saw many pissed off users because they don't have certain
updates and because they are told to wait 6 months.
+1.
Our users expect updates. If they didn't want them, they'd use something
else.
On Fri, 2010-02-26 at 22:51 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
On Fri, 2010-02-26 at 16:17 +0100, Kevin Kofler wrote:
Most
often what works on Fedora n also works on Fedora m. It's not like the
reviewer tested on Slackware or OS X. ;-)
Most often. Sure, that seems
On Fri, 26 Feb 2010, Kevin Kofler wrote:
Orcan Ogetbil wrote:
I didn't see many users complaining that there are too many updates.
But I saw many pissed off users because they don't have certain
updates and because they are told to wait 6 months.
+1.
Our users expect updates. If they
Kevin Kofler (kevin.kof...@chello.at) said:
Richard Zidlicky wrote:
lots of people. Some want to review changes manually and udpate only
important things,
Others don not have gigabit internet access all around the clock. I am
trying to update my Netbook over a mobile connection as I
drago01 wrote:
And a packagemaintainer should be able to judge whether the package is
worth pushing or not.
It has a higher version number can't be the reason for that. (and I
don't see how anyone can disagree with this but well ...)
Sure, there needs to be a reason to push something. Updates
On Fri, Feb 26, 2010 at 04:50:20PM -0500, Bill Nottingham wrote:
Patrice Dumas (pertu...@free.fr) said:
Bringinig down productivity of good packagers for a few bad ones, is,
in my opinion, not a good move.
Fedora doesn't exist for the productivity of packagers. It exists for
On Fri, Feb 26, 2010 at 04:14:37PM -0500, James Antill wrote:
...and as in all threads about this that I can remember, the obvious fix
to the above is having two repos. and let everyone who wants a giant
firehose of mostly working stuff can enable this second repo. if only we
could create
Patrice Dumas (pertu...@free.fr) said:
Not really. I use Fedora every day. The fact that I use it for packaging
things is a small small part of my usage of it. The extra 2 minutes or so
to twiddle an update differently is far far far outweighed by, say, X
exploding. Or thunderbird eating
On Fri, Feb 26, 2010 at 11:21:20PM +0100, Patrice Dumas wrote:
Regressions happen whatever policies are done. Imagine a specialized
package that hasn't any tester besides the maintainer (though it
has users), this was the case for most of the packages I maintained
in Fedora. A user wait for
On Fri, 2010-02-26 at 14:49 +0100, Till Maas wrote:
Imho it is more a perversion of how it is meant to be. This package was
tested before it went to updates-testing and therefore went straight to
stable. But the majority of packages goes to updates-testing and is not
tested by someone else
On Fri, 2010-02-26 at 23:06 +0100, Kevin Kofler wrote:
Richard Zidlicky wrote:
lots of people. Some want to review changes manually and udpate only
important things,
Others don not have gigabit internet access all around the clock. I am
trying to update my Netbook over a mobile
On Fri, 2010-02-26 at 10:34 -0600, Garrett Holmstrom wrote:
On 2/26/2010 7:26, Orcan Ogetbil wrote:
Another annoying issue is updates with no explanations. There is a
Notes field in bodhi that many people just ignore for an unknown
reason. Any update with less than a specified number of
On Fri, Feb 26, 2010 at 05:27:59PM -0500, Bill Nottingham wrote:
Regressions happen whatever policies are done. Imagine a specialized
package that hasn't any tester besides the maintainer (though it
has users), this was the case for most of the packages I maintained
in Fedora. A user
On Fri, 2010-02-26 at 14:56 -0600, Mike McGrath wrote:
Do we know how other distros deal with this?
I can speak for Mandriva. Mandriva has /main and /contrib repositories
(and a couple of others for non-free stuff, but that's not important in
this context). /main contains officially-supported
James Antill wrote:
Are you really arguing that you never make mistakes?
No, that's not at all what I'm saying! I'm arguing that problems of the
works on Fedora n, doesn't work on Fedora m type are extremely rare and
that it's usually safe to assume that testing on one version of Fedora is
Mike McGrath wrote:
Just so you can't ever use this argument again. I want fewer updates and
I'm a Fedora user.
IMHO you're really using the wrong distro. ;-)
My point is that there are plenty of users who want the current updates or
even more updates. And whereas the people like you have
Orcan Ogetbil wrote:
A package destroying people's hardware shouldn't be there in the first
place, because it should have stayed in testing for an extended period
of time. Thus this is not a valid reason, as the other ones that were
brought up were not.
What if nobody with that hardware was
Adam Williamson wrote:
(oh, and also, when that field is empty for an update, PackageKit tells
the user it's empty and shows them the changelog instead. Subbing in the
changelog at the show the user stage is a sensible approach when the
maintainer screwed up. Subbing in the changelog at the
On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote:
Mike McGrath wrote:
Just so you can't ever use this argument again. I want fewer updates and
I'm a Fedora user.
IMHO you're really using the wrong distro. ;-)
My point is that there are plenty of users who want the current
On Sat, 2010-02-27 at 01:40 +0100, Kevin Kofler wrote:
Bill Nottingham wrote:
While the ethos as defined on the wiki mentions staying close to upstream
and getting the latest software, there's nothing that says that it's done
via updates. I would not categorically state that your reading is
Orcan Ogetbil wrote:
That is the point I completely disagree. It is a packager's very job
to rehash upstream's changelogs. If a packager can't -at the very
least- give a brief report of what he has accomplished, then he should
reconsider his adequacy. At the minimal, a URL link to the upstream
On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote:
If I want lots of updates, I'd use rawhide.
That doesn't fit the requirements of the group of users I think we should
target (of which I'm part, but I can assure you I'm far from the only one in
that group). Rawhide is frequently
Matthew Garrett wrote:
At the point where you have a reported bug, you have a tester.
Not necessarily. Sadly, there are people who report bugs and then don't read
their bugmail, ever. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Bill Nottingham wrote:
Wait. You don't want policies designed to avoid pushing regressions, so
that you can push fixes for the regressions you've given to people faster?
That's... impressive.
The problem is that those policies don't prevent regressions from happening.
Bad stuff DOES slip
On Sat, 2010-02-27 at 01:54 +0100, Kevin Kofler wrote:
Orcan Ogetbil wrote:
A package destroying people's hardware shouldn't be there in the first
place, because it should have stayed in testing for an extended period
of time. Thus this is not a valid reason, as the other ones that were
Kevin Fenzi wrote:
I was saying the EPEL policy seemed to be working well for EPEL.
That wasn't a We should immediately do this now in fedora, but just a
datapoint.
I also didn't say that this would definitely be done. I just said the idea
was floated and MAY end up in the proposal (hopefully
On Fri, 2010-02-26 at 19:53 +0100, Till Maas wrote:
On Fri, Feb 26, 2010 at 10:01:56AM -0800, Jesse Keating wrote:
On Fri, 2010-02-26 at 18:56 +0100, Till Maas wrote:
Something I am dreaming about is to have some infrastructure to
automatically test packages, so mabye they could build
Adam Williamson wrote:
This is simply bad faith. I have seen absolutely no suggestion that the
policy would be put out in such a way, and I can't see any basis you
have to infer that. The suggestion that a draft version of the policy
would be provided for feedback is not at all the same thing
Bruno Wolff III wrote:
I'd say not even that. If you miss a release, there is one coming up in
the not too distant future and it isn't a big deal. And if a few hardy
soles want to look at your stuff early, it is often the case they can run
the rawhide package on stable releases without too
Adam Jackson wrote:
By my count, that's three misrepresentations in one paragraph. I
certainly hope they were not deliberate.
I'm not deliberately misrepresenting anything or anyone, I just stated my
perception of the facts. It may well be that I missed some details in the
hectic and chaotic
Adam Williamson wrote:
The good is not the enemy of the perfect. A 90% chance of noticing a
problem is still better than a 10% chance, even if it's not 100%.
That doesn't help when this takes a week and you break a dozen machines
while waiting for the don't destroy hardware! fix (and that's
Till Maas wrote:
I do not remember that I ever wanted to downgrade something except that I
am still missing kpdf/kprinter, but both went away in a distribution
upgrade.
kprinter is still available in the kdebase3 package. (Of course, it's still
the same old KDE 3 stuff, but it's expected to
On 2/26/2010 3:06 PM, Kevin Kofler wrote:
Richard Zidlicky wrote:
lots of people. Some want to review changes manually and udpate only
important things,
Others don not have gigabit internet access all around the clock. I am
trying to update my Netbook over a mobile connection as I write
On 02/27/2010 12:43 AM, Adam Williamson wrote:
On Fri, 2010-02-26 at 10:55 -0500, Paul Wouters wrote:
I requested a direct push to stable. Which was denied. I was unhappy that
we would not stop a DOS attack within weeks (my packages hardly ever get
any karma feedback despite their obvious
On Sat, Feb 27, 2010 at 02:38:07 +0100,
Kevin Kofler kevin.kof...@chello.at wrote:
Bruno Wolff III wrote:
I'd say not even that. If you miss a release, there is one coming up in
the not too distant future and it isn't a big deal. And if a few hardy
soles want to look at your stuff early,
On Sat, 2010-02-27 at 06:03 +0100, Ralf Corsepius wrote:
2) Recent dnssec-conf updates all did receive several -1, nevertheless
these updates were pushed.
This is indeed a problem. Obviously, relying on the judgment of
maintainers isn't working.
...which is why there's a proposal not to rely
On Sat, 2010-02-27 at 02:09 -0500, Paul Wouters wrote:
On Fri, 26 Feb 2010, Adam Williamson wrote:
On Sat, 2010-02-27 at 06:03 +0100, Ralf Corsepius wrote:
2) Recent dnssec-conf updates all did receive several -1, nevertheless
these updates were pushed.
This is indeed a problem.
301 - 357 of 357 matches
Mail list logo
