On Thu, Feb 25, 2010 at 05:05:38PM -0500, James Antill wrote:
$releasever just changes the variable, so the URLs are all the same ...
just with different variables. Specifically:
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releaseverarch=$basearch
...is never going
Hi.
On Thu, 25 Feb 2010 22:29:21 +0100, Thomas Spura wrote:
Here is the snipped, I intend to use:
%{_mpich2_load}
# create ~/.mpd.conf, if it does not yet exist
if [ -e ~/.mpd.conf ]; then
# working locally, don't delete ~/.mpd.conf
DONT_DEL=TRUE
else
DONT_DEL=FALSE
On Fri, Feb 26, 2010 at 13:16, Kevin Kofler kevin.kof...@chello.at wrote:
Some situations where I and others have used direct stable pushes in the
past and where I think they're really warranted and should be used:
* A new package which doesn't replace anything, and which I verified to work
On Fri, Feb 26, 2010 at 1:36 PM, Christof Damian chris...@damian.net wrote:
On Fri, Feb 26, 2010 at 13:16, Kevin Kofler kevin.kof...@chello.at wrote:
Some situations where I and others have used direct stable pushes in the
past and where I think they're really warranted and should be used:
* A
On Fri, 26 Feb 2010 13:16:43 +0100, Kevin wrote:
Hi,
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
wanting to disable the possibility to queue updates directly to stable in
Bodhi.
That would be a ridiculous decision. It would be much better to disable
that
On 02/26/2010 01:16 PM, Kevin Kofler wrote:
Hi,
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
wanting to disable the possibility to queue updates directly to stable in
Bodhi. The only reason this was not decided right there (with no outside
feedback) is that Matthew
On Fr, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:
[...]
We really need more transparency in decision making!
[...]
If you can think of more, please post them! But even if you just agree with
me, please reply so the other FESCo members don't think it's just me!
+1
--
devel mailing list
Am Freitag, den 26.02.2010, 11:14 +0100 schrieb Ralf Ertzinger:
Hi.
On Thu, 25 Feb 2010 22:29:21 +0100, Thomas Spura wrote:
Here is the snipped, I intend to use:
%{_mpich2_load}
# create ~/.mpd.conf, if it does not yet exist
if [ -e ~/.mpd.conf ]; then
# working locally,
On Fri, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:
I think banning stable pushes is the right idea. None of your reasons is
very convincing.
* A regression which causes big breakage at least for some people slipped
through testing for whatever reason. We urgently want the fix to get out
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 discouraging direct stable pushes for some specific
types of
On Fri, Feb 26, 2010 at 8:14 AM, Marcela Maslanova wrote:
- Matthias Clasen wrote:
I think banning stable pushes is the right idea. None of your reasons
is
very convincing.
+1
Another annoying issue is updates with no explanations. There is a
Notes field in bodhi that many people
On Fri, Feb 26, 2010 at 4:21 AM, Jesse Keating jkeat...@redhat.com wrote:
On Fri, 2010-02-26 at 03:59 +, Colin Walters wrote:
So here's what I propose. We create a spin, hosted in
spin-kickstarts.ks, called fedora-virt-server.ks, which simply
reflects @base from comps, plus
- Josh Boyer jwbo...@gmail.com wrote:
On Fri, Feb 26, 2010 at 08:14:13AM -0500, Marcela Maslanova wrote:
- Matthias Clasen mcla...@redhat.com wrote:
On Fri, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:
I think banning stable pushes is the right idea. None of your
reasons
On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote:
Hi,
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
wanting to disable the possibility to queue updates directly to stable in
Bodhi. The only reason this was not decided right there (with no outside
feedback)
On Fri, Feb 26, 2010 at 4:26 AM, Garrett Holmstrom
gho...@fedoraproject.org wrote:
The Cloud SIG is working on that type of thing right now, kickstart and
all. (Actually we already have a proposed kickstart that's more minimal
than that if you want to take a look at it.) I recommend
On Fri, Feb 26, 2010 at 08:20:10AM -0500, Josh Boyer wrote:
On Fri, Feb 26, 2010 at 08:14:13AM -0500, Marcela Maslanova wrote:
My packages are rarely tested and I forget them in testing phase for a
long time. Also fixing BR don't need testing. I simply need push
immediately the new/fixed
On Fri, Feb 26, 2010 at 1:43 PM, Michael Schwendt mschwe...@gmail.com wrote:
[...]
Unconvincing, though. History has shown that some packagers still managed
to push new packages that suffered from broken deps [..]
Well than the review process failed ...
--
devel mailing list
Christof Damian wrote:
Will there be a minimum number of days a package has to stay in testing?
I have no idea. I'm against any minimum number of days, but I'm against the
whole proposal anyway.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
On Fri, Feb 26, 2010 at 08:36:41AM -0500, Josh Boyer wrote:
On Fri, Feb 26, 2010 at 02:23:33PM +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
Michael Schwendt wrote:
That would be a ridiculous decision. It would be much better to disable
that feature only for those update submitters who really have been
dilettantish enough to use it inappropriately more than once.
Yeah, that's a good idea. We really need to avoid punishing everyone
On Friday 26 February 2010 14:32:16 Marcela Maslanova wrote:
- Josh Boyer jwbo...@gmail.com wrote:
On Fri, Feb 26, 2010 at 08:14:13AM -0500, Marcela Maslanova wrote:
- Matthias Clasen mcla...@redhat.com wrote:
On Fri, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:
I think
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
Do you really see _everything_ as FESCo (or the world) vs. Kevin Kofler?
I read over the FESCo logs from time to time, and your repeated
foot-stomping on the DSO
Ralf Corsepius wrote:
* Many (most) packages get pushed without testing. I consider people who
believe package to see tested in testing, to be in error.
To me, testing isn't much more but a delay queue.
Good point.
* Some maintainers ignore feedback on packages in testing.
Indeed, and the
On Fri, 26 Feb 2010, Josh Boyer wrote:
On Fri, Feb 26, 2010 at 08:14:13AM -0500, Marcela Maslanova wrote:
- Matthias Clasen mcla...@redhat.com wrote:
On Fri, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:
I think banning stable pushes is the right idea. None of your reasons
is
On Fri, 26 Feb 2010 08:26:59 -0500, Orcan 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 characters
(~40) in the Notes should also be banned.
On Fri, Feb 26, 2010 at 9:24 AM, Michael Schwendt wrote:
On Fri, 26 Feb 2010 08:26:59 -0500, Orcan 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 08:04:55AM -0600, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL is very different. Packages in EPEL have been tested in fedora and so
will very rarely need hotfixes aor regression fixes (except for security
fixes, which
Kevin Kofler wrote:
at the FESCo meeting on Tuesday, everyone except me seemed to be set
on wanting to disable the possibility to queue updates directly to
stable in Bodhi.
As you say, there are quite a lot of situations where direct stable
update is needed.
This proposal is probably inspired
On Fri, 26 Feb 2010 14:07:05 +0100, Patrice wrote:
I may be remebering wrong, but an argument for bodhi against those who
wanted a simpler push mechanism (like wwhat was in the fedora extra days)
and argued that bodhi will add more unecessary delays was that there
always was the possibility
Once upon a time, Patrice Dumas pertu...@free.fr said:
On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL is very different. Packages in EPEL have been tested in fedora and so
will very rarely need
Kevin Kofler kevin.kof...@chello.at writes:
Some situations where I and others have used direct stable pushes in the
past and where I think they're really warranted and should be used:
You forgot security fixes. The proposed policy is insane.
regards, tom lane
--
On Fri, 26 Feb 2010 14:49:18 +0100, Till 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 but
Matthias Clasen wrote:
But presumably we still want to test the fix, to avoid introducing yet
another regression ?!
[snip]
Just go up to your first argument: the breage slips through. That is
exactly what happens if your judgement of 'low risk' turns out to be
wrong. And it will...
[snip]
On Fri, 26 Feb 2010 14:42:29 +0100, drago01 wrote:
History has shown that some packagers still managed
to push new packages that suffered from broken deps [..]
Well than the review process failed ...
Sometimes, not always. Don't forget that reviewers don't review builds
for all dists,
On Fri, Feb 26, 2010 at 09:41:34AM -0500, Tom Lane wrote:
Kevin Kofler kevin.kof...@chello.at writes:
Some situations where I and others have used direct stable pushes in the
past and where I think they're really warranted and should be used:
You forgot security fixes. The proposed policy is
On Thu, Jan 21, 2010 at 02:51:46PM -0700, Kevin Fenzi wrote:
On Thu, 21 Jan 2010 17:34:50 +0100
Till Maas opensou...@till.name wrote:
Maybe the meetbot could be patched to only accept a topic change
after a #agreed command was used (or some other command except the
#action command, that
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 characters
(~40) in the Notes should also be banned.
That's a completely unrelated
On Fri, 2010-02-26 at 14:55 +0100, Kevin Kofler wrote:
The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
What sucks more is recent hot-fixes which were even more broken than
the issue they were trying to fix. They were
Josh Boyer wrote:
Nobody said disallow direct-to-stable pushes completely, entirely, with no
exceptions. That would indeed be absurd.
But the proposed exception procedures which were floated were so burdensome
and slow that they made the entire exception procedure effectively useless.
For
Till Maas wrote:
Imho it takes too long to get packages into updates-testing, if people
are really interested in testing packages, they often seem to get
packages directly from Koji, e.g. on this update I got 3 positive Karma
points (one of them was anonymous) within 76 minutes after
On Fri, Feb 26, 2010 at 03:35:58PM +0100, Michael Schwendt wrote:
On Fri, 26 Feb 2010 14:07:05 +0100, Patrice wrote:
I may be remebering wrong, but an argument for bodhi against those who
wanted a simpler push mechanism (like wwhat was in the fedora extra days)
and argued that bodhi will
drago01 wrote:
On Fri, Feb 26, 2010 at 1:43 PM, Michael Schwendt mschwe...@gmail.com
wrote:
[...]
Unconvincing, though. History has shown that some packagers still managed
to push new packages that suffered from broken deps [..]
Well than the review process failed ...
Indeed.
On Fri, Feb 26, 2010 at 08:39:19AM -0600, Chris Adams wrote:
Once upon a time, Patrice Dumas pertu...@free.fr said:
On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL is very different. Packages in
Patrice Dumas wrote:
I may be remebering wrong, but an argument for bodhi against those who
wanted a simpler push mechanism (like wwhat was in the fedora extra days)
and argued that bodhi will add more unecessary delays was that there
always was the possibility to push to stable for packagers.
On Fri, 2010-02-26 at 15:59 +0100, Kevin Kofler wrote:
I can't see a reason to make exceptions.
What about the many valid reasons that have been brought up? E.g. if a
package is destroying people's hardware, wouldn't you want the fix to go out
BEFORE your hardware is dead?
I'd want it
On Fri, 26 Feb 2010, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL does not have a 6 month release cycle :)
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 2010-02-26 at 16:09 +0100, Kevin Kofler wrote:
Good point. Indeed, packages are often tested sufficiently before they even
enter updates-testing. Even if pushes become more frequent, it can still
happen if testing is called for on a fast medium like IRC and the fix
touches many
Jaroslav Reznik wrote:
Maybe some package rating included in PackageKit would be nice - for
stable packages it's indicator that this package is worth to install, for
testing package it would mean it's working (but again - who's going to
rate it in pkgkit once installed).
That won't solve the
On Fri, 2010-02-26 at 10:28 -0500, Paul Wouters wrote:
On Fri, 26 Feb 2010, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL does not have a 6 month release cycle :)
The 6 month release cycle means you need to hurry to get your stuff into
On Fri, 2010-02-26 at 13:16 +0100, Kevin Kofler wrote:
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
wanting to disable the possibility to queue updates directly to stable in
Bodhi. The only reason this was not decided right there (with no outside
feedback) is
On Fri, Feb 26, 2010 at 09:53:16AM +0100, Till Maas wrote:
On Thu, Feb 25, 2010 at 05:05:38PM -0500, James Antill wrote:
$releasever just changes the variable, so the URLs are all the same ...
just with different variables. Specifically:
Jesse Keating wrote:
On Fri, 2010-02-26 at 14:55 +0100, Kevin Kofler wrote:
The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
What sucks more is recent hot-fixes which were even more broken than
the issue they were
Michael Schwendt wrote:
Doesn't sound right. FE could push to stable always and much more quickly,
too. What was missing was a convenient interface for packagers which they
could use to decide between testing and stable or whether not to push a
build at all. It was necessary to submit special
Chris Adams wrote:
Every time a package is built, it is susceptible to new bugs. Packaging
bugs, build requirement changes, and software bugs all creep in, and not
trying to ram things out the door as fast as possible seems like a good
idea.
But EPEL has a completely different target
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 go through testing in EPEL! But Fedora is another
thing.
The
On Fri, 26 Feb 2010 06:59:59 -0800, Jesse wrote:
On Fri, 2010-02-26 at 14:55 +0100, Kevin Kofler wrote:
The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
What sucks more is recent hot-fixes which were even more
Tom Lane wrote:
You forgot security fixes.
They'd probably be excepted. But that leaves (among other things) the
problem of regressions caused by security fixes (see the D-Bus and
Thunderbird fiascos, and several less fatal ones), fixes for those need to
go out ASAP.
But I agree that banning
On Fri, 2010-02-26 at 16:20 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
On Fri, 2010-02-26 at 14:55 +0100, Kevin Kofler wrote:
The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
What sucks more is recent
Josh Boyer wrote:
There is no proposed policy yet. What you are replying to is Kevin's take
on a discussion that was supposed to lead to a policy being drafted.
Yet it would almost have been voted with no clear policy, it was just mjg59
pointing that out which stopped that.
Kevin
On Fri, Feb 26, 2010 at 14:49:18 +0100,
Till Maas opensou...@till.name 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
Michael Schwendt wrote:
Sometimes, not always. Don't forget that reviewers don't review builds
for all dists, but packagers often publish mass-builds for multiple dists
without prior testing.
In practice that is not often a source of trouble. (Though new packages are
somewhat more likely to
On Fri, Feb 26, 2010 at 04:40:46PM +0100, Kevin Kofler wrote:
That was my suggestion. All I got was negative comments (AIUI, nobody else
wanted anything less than a majority of FESCo to be able to approve direct
stable pushes, at least nobody said otherwise in the meeting), and even
On Thu, Feb 25, 2010 at 04:29:31PM -0500, Bill Nottingham wrote:
New:
yum --releasever=next upgrade
Am I missing something? Do people think this would be better, or worse?
Is the releasever option a yum F13 feature? On F12 it complains that
it is not a valid option.
Also repoquery
On Fri, Feb 26, 2010 at 10:29:00 -0500,
Matthias Clasen mcla...@redhat.com wrote:
On Fri, 2010-02-26 at 10:28 -0500, Paul Wouters wrote:
On Fri, 26 Feb 2010, Chris Adams wrote:
EPEL has run this way for a while, and it doesn't seem to be a problem.
EPEL does not have a 6 month
On Fri, 2010-02-26 at 16:40 +0100, Kevin Kofler wrote:
Transparency means asking for feedback BEFORE writing the policy. The sooner
you involve the community, the better. Putting out a policy as take it or
leave it, or worse take it, you have to, we voted it through already is
not
On Fri, 26 Feb 2010 16:40:46 +0100
Kevin Kofler kevin.kof...@chello.at wrote:
Josh Boyer wrote:
The time period is mere speculation on your part.
It's not just mere speculation, the idea has been brought up by
nirik, citing EPEL as precedent:
[begin quote (from the meeting log)]
Feb 23
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 good enough to throw potential crap at
users. Our os most often works. Don't worry
On Fri, 2010-02-26 at 16:49 +0100, Michael Schwendt wrote:
Could happen also with security updates. E.g. the recent gnome-screensaver
security update visually corrupted the Fedora and GNOME screensavers. Rather
harmless, but in other cases (e.g. kernel upgrades) a trade-off is made
between
On 2/26/2010 6:16, Kevin Kofler wrote:
at the FESCo meeting on Tuesday, everyone except me seemed to be set on
wanting to disable the possibility to queue updates directly to stable in
Bodhi. The only reason this was not decided right there (with no outside
feedback) is that Matthew Garrett
On Fri, 26 Feb 2010 08:26:47 -0800, Jesse wrote:
I think this conversation is derailed by the must go into
updates-testing first aspect. This isn't the intention. The intention
as I see it is that updates must be tested before they go to stable.
Can you expand on must be tested?
Some test
Jesse Keating (jkeat...@redhat.com) said:
On Thu, 2010-02-25 at 16:29 -0500, Bill Nottingham wrote:
Am I missing something? Do people think this would be better, or
worse?
I muffed up fedora-release on rawhide, but here was my plan.
rawhide:
fedora-release requires
Till Maas (opensou...@till.name) said:
Is the releasever option a yum F13 feature? On F12 it complains that
it is not a valid option.
Also repoquery returns F12 results but accepts --releasever:
$ repoquery --releasever=rawhide --repoid=fedora kernel
kernel-0:2.6.31.5-127.fc12.x86_64
OK,
On Fri, Feb 26, 2010 at 10:20:00AM -0600, Bruno Wolff III wrote:
While people using Fedora may want the latest stuff, I doubt that most of
them care about time scales less than a month (I assume I am an exception)
unless there is a bug they care about. In which case they can use the bug
On Fri, Feb 26, 2010 at 9:59 AM, Kevin Kofler wrote:
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 characters
(~40) in the Notes
On Sun, Feb 21, 2010 at 09:29:51PM -0500, Jon Masters wrote:
On Sun, 2010-02-21 at 15:36 -0500, Luke Macken wrote:
On Fri, Feb 19, 2010 at 11:40:42PM -0500, Tom Lane wrote:
Luke Macken lmac...@redhat.com writes:
A large number of updates currently suffer from duplicate IDs, and I
On Fri, Feb 26, 2010 at 11:34 AM, 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, 2010-02-26 at 11:42 -0500, Bill Nottingham wrote:
Jesse Keating (jkeat...@redhat.com) said:
On Thu, 2010-02-25 at 16:29 -0500, Bill Nottingham wrote:
Am I missing something? Do people think this would be better, or
worse?
I muffed up fedora-release on rawhide, but here was
On Fri, 2010-02-26 at 17:39 +0100, Michael Schwendt wrote:
Can you expand on must be tested?
Some test updates just don't get any testing.
Audacity 1.3.10-beta
https://admin.fedoraproject.org/updates/F12/FEDORA-2009-13139
(2009-12-09 to 2010-01-26)
Audacity 1.3.11-beta
On 2/26/2010 10:55, Orcan Ogetbil wrote:
On Fri, Feb 26, 2010 at 11:34 AM, 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
Patrice Dumas (pertu...@free.fr) said:
I may be remebering wrong, but an argument for bodhi against those who
wanted a simpler push mechanism (like wwhat was in the fedora extra days)
and argued that bodhi will add more unecessary delays was that there
always was the possibility to push to
On 2/26/2010 11:07, Jesse Keating wrote:
It'll require some enhancements to how bodhi is used for people
consuming testing updates, and it may require a more active role on part
of the maintainer to seek out somebody to at least give the update a
smoke test. Instead of treating
Jesse Keating (jkeat...@redhat.com) said:
I muffed up fedora-release on rawhide, but here was my plan.
rawhide:
fedora-release requires fedora-release-rawhide
All repos except for rawhide disabled. Rawhide enabled.
This state never changes, the only thing that changes is
On Fri, 26 Feb 2010, Garrett Holmstrom wrote:
On 2/26/2010 11:07, Jesse Keating wrote:
It'll require some enhancements to how bodhi is used for people
consuming testing updates, and it may require a more active role on part
of the maintainer to seek out somebody to at least give the update
On Fri, 2010-02-26 at 12:18 -0500, Bill Nottingham wrote:
Mainly, it removes the repository definitions in rawhide that don't make
sense - the release, updates, updates-testing, etc. repos won't work anyway
unless you change $releasever in some way.
It would help making the transition from
On Fri, 2010-02-26 at 11:16 -0600, Garrett Holmstrom wrote:
On 2/26/2010 11:07, Jesse Keating wrote:
It'll require some enhancements to how bodhi is used for people
consuming testing updates, and it may require a more active role on part
of the maintainer to seek out somebody to at least
On Fri, Feb 26, 2010 at 6:27 PM, Mike McGrath mmcgr...@redhat.com wrote:
[...]
Though, in theory, fewer updates means a higher percentage of them can be
tested which means quality goes up.
Even if this might start another flamewar ... I like the idea of
having less updates.
The the version
On Fri, 26 Feb 2010 12:14:41 -0500, Bill wrote:
tested. Every fix carries a risk of regression.
To phrase a strawman differently:
No update is pushed to users without verification and testing from entities
other than the packager.
No, thanks. The popular/high profile packages will get
On Fri, 2010-02-26 at 18:51 +0100, Michael Schwendt wrote:
Fedora Legacy, aka the barrel burst. More mandatory stuff, not enough
free resources = failure.
Legacy took it way too far, with much fewer resources, and a complete
lack of tools.
--
Jesse Keating
Fedora -- Freedom² is a feature!
On Fri, Feb 26, 2010 at 05:07:24PM +, Jesse Keating wrote:
direct relationship. Maybe something in the Fedora Engineering Services
initiative could be to spend some time smoke testing updates-testing
stuff.
Something I am dreaming about is to have some infrastructure to
automatically
On Fri, 26 Feb 2010 12:46:27 -0500, Orcan wrote:
On Fri, Feb 26, 2010 at 12:12 PM, Garrett Holmstrom wrote:
On 2/26/2010 10:55, Orcan Ogetbil wrote:
On Fri, Feb 26, 2010 at 11:34 AM, Garrett Holmstrom wrote:
On 2/26/2010 7:26, Orcan Ogetbil wrote:
Another annoying issue is updates with
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 that first and
then write tests for packages.
The AutoQA project is in full swing, developing just that, a framework
to
On Fri, Feb 26, 2010 at 02:03:49AM +, Colin Walters wrote:
So recently I found myself desiring to update a .spec file for a
snapshot of a git tree in an automated fashion. As you may or may not
know, this actually has a surprising number of flaming hoops through
which you must jump.
On Fri, Feb 26, 2010 at 05:07:24PM +, Jesse Keating wrote:
It'll require some enhancements to how bodhi is used for people
consuming testing updates, and it may require a more active role on part
of the maintainer to seek out somebody to at least give the update a
smoke test.
For many
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 of them can be
tested which means quality goes up.
Even if this might start another flamewar ... I like the idea of
having
On Fri, Feb 26, 2010 at 07:42:16PM +0100, Patrice Dumas wrote:
On Fri, Feb 26, 2010 at 05:07:24PM +, Jesse Keating wrote:
It'll require some enhancements to how bodhi is used for people
consuming testing updates, and it may require a more active role on part
of the maintainer to seek
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
Compose started at Fri Feb 26 09:15:15 UTC 2010
Broken deps for i386
--
balsa-2.4.6-3.fc13.i686 requires libgmime-2.4.so.2
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
doodle-0.6.7-5.fc12.i686 requires
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
https://bugzilla.redhat.com/show_bug.cgi?id=460168
https://bugzilla.redhat.com/attachment.cgi?id=396645action=diff
https://bugzilla.redhat.com/attachment.cgi?id=396645action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
1 - 100 of 161 matches
Mail list logo
