On Wed, 3 Mar 2010, Kevin Kofler wrote:
Mike McGrath wrote:
You can't assume that people are only using software we ship. If someone
is using software they've custom developed (think a webapp). We've now
forced them to do work. There's several use cases here, people building
and
Mike McGrath wrote:
I know they do. I'm saying they shouldn't. Yes, we'll fail sometimes.
That's not to say it shouldn't be a goal. I updated KDE just today and it
left my taskbar all messed up [1]
While definitely annoying, I don't think that's what's going to keep you
from doing your
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
Adam Williamson wrote:
you can try and cherry-pick security updates, but then you get the
problem where initial release has Foobar 1.0, then Foobar 3.5 gets
shipped in updates, then a security problem emerges and Foobar 3.5-2
with
James Antill wrote:
On Wed, 2010-03-03 at 01:54 +0100, Kevin Kofler wrote:
Well, I see where you're getting to now, but this is really not what
updates-testing is for! Updates-testing is for TESTING updates, not for
being used as production by some users, even those who want more updates.
James Antill wrote:
This isn't a hard problem, 3.0 should then be marked as a security
update.
But the case we're discussing is that 3.0 was pushed long before it was
known that it happens to fix a security vulnerability. We're not going to
arbitrarily push another update and call it
On Tue, 2010-03-02 at 17:52 -0800, Jesse Keating wrote:
On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
But the problem is what to do if the testing ALREADY failed. Then the best
strategy is to fix the problem ASAP, bypassing testing this time, to get
the
regression out of the
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
We've made a mess and as a member of fesco I'd expect you to be helping in
cleaning up the mess, not making it worse b/c fesco HAS to be about the
long term growth and sustainability of fedora.
I'm starting to think this thread needs a
On 01/03/10 00:06, Kevin Kofler wrote:
(Sorry, I reordered the replies a bit so I can reply to them without
referring back and forth.)
It's also called political licence
Frank Murphy wrote:
On 02/27/2010 04:30 PM, Mail Lists wrote:
an
1:
I do want updates. Kernel updates, for
On Friday 26 February 2010 16:22:37 Kevin Kofler wrote:
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
On 3/1/2010 10:44 AM, Jaroslav Reznik wrote:
One problem of updates-testing is - it takes so much time to be pushed and
then mirrored. More rawhide approach should be used here. Users who are really
interested in testing usually downloads from Koji directly.
It is not so simple. When I am
Le Dim 28 février 2010 17:24, Adam Williamson a écrit :
On Sun, 2010-02-28 at 11:43 +0100, Nicolas Mailhot wrote:
There are things only packagers can fix. Everything else should be
handled by tools so packagers can focus on the parts where they add real
value. If a process change puts more
James Antill wrote:
Mike didn't say that, Mike said that if a user was intentionally not
updating to Fedora 12 due to the newer KDE ... you've just removed that
choice from them. And for no real gain, as anyone who wanted to the KDE
update could easily move to Fedora 12 to get it.
That
Frank Murphy wrote:
It's also called political licence
No, it's not really the same thing. ;-)
I didn't try to distort your viewpoint, just highlight the contradictions.
But this time I'm replying in order. :-)
If you mean these points from Mail Lists then yes.
Yes, that's what I mean.
Alexander Boström wrote:
It could install a file in /etc/foo.d that causes something that
loads /etc/foo.d/* to break.
That's not automatic breakage, you'd still have to install the package (or
get it installed through one of the already discussed mechanisms: Obsoletes,
Provides collision,
On 01/03/10 11:17, Kevin Kofler wrote:
Frank Murphy wrote:
It's also called political licence
No, it's not really the same thing. ;-)
I didn't try to distort your viewpoint, just highlight the contradictions.
But this time I'm replying in order. :-)
If you mean these points from Mail
On Mon, 2010-03-01 at 11:47 +0100, Kevin Kofler wrote:
Jon Masters wrote:
One thing I would suggest being considered in an alternative proposal is
a compromise policy for specific stacks or non-critical path packages.
For example, if the standard policy affecting me as a GNOME user is that
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 Sat, 2010-02-27 at 02:52 +0100, Kevin Kofler wrote:
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
On Mon, Mar 1, 2010 at 4:44 PM, Richard W.M. Jones rjo...@redhat.com 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
On 02/26/2010 08:55 AM, Kevin Kofler wrote:
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
On 03/01/2010 11:52 AM, Peter Jones wrote:
If you think this isn't the right way
to provide a safety net for package maintainers - what is?
With the understanding that you're not specifically asking me that
question, I'd say that I'd prefer to first try to automate checks for
the most frequent
On 03/01/2010 05:52 PM, Peter Jones wrote:
On 02/26/2010 08:55 AM, Kevin Kofler wrote:
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
On 03/01/2010 11:57 AM, Tom spot Callaway wrote:
On 03/01/2010 11:52 AM, Peter Jones wrote:
If you think this isn't the right way
to provide a safety net for package maintainers - what is?
With the understanding that you're not specifically asking me that
question, I'd say that I'd prefer
Peter Jones pjo...@redhat.com writes:
[...] You weren't elected FESCo Monitor; the guy who comes and
tells the mailing list whenever FESCo is discussing something you
think is scary. [...]
One need not be elected to do that. Anyone reading the public
fesco irc logs may do the same without
On 03/01/2010 12:52 PM, Frank Ch. Eigler wrote:
Peter Jones pjo...@redhat.com writes:
[...] You weren't elected FESCo Monitor; the guy who comes and
tells the mailing list whenever FESCo is discussing something you
think is scary. [...]
One need not be elected to do that. Anyone reading
On 03/01/2010 12:48 PM, Peter Jones wrote:
I'd also like a policy in place to help us avoid situations like the
recent dnssec unpleasantness.
Sure. I'm just not at all convinced that if those packages had sit in
testing for $ARBITRARY_PERIOD_OF_TIME that they would have been tested
and fixed.
On Mon, 1 Mar 2010, Will Woods wrote:
* Has ABI/API change (and is a Critical Path package)
This should be handled by the current rpmguard test:
https://fedorahosted.org/autoqa/wiki/rpmguard
since changing the ABI/API should generally change the soname/version,
thus changing the package
On Fri, 26 Feb 2010 16:59:40 -0500 (EST)
Paul Wouters p...@xelerance.com wrote:
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
On Mon, 2010-03-01 at 13:01 -0500, Tom spot Callaway wrote:
On 03/01/2010 12:48 PM, Peter Jones wrote:
I'd also like a policy in place to help us avoid situations like the
recent dnssec unpleasantness.
Sure. I'm just not at all convinced that if those packages had sit in
testing for
On Mon, Mar 01, 2010 at 01:30:18PM -0500, Seth Vidal wrote:
On Mon, 1 Mar 2010, Will Woods wrote:
So I think it would be shortsighted for FESCo to refuse to even discuss
a policy about what manual testing is currently required, since any plan
for improving the quality of the
On Mon, 1 Mar 2010 12:11:20 -0600 (CST)
Mike McGrath mmcgr...@redhat.com wrote:
On Mon, 1 Mar 2010, Tom spot Callaway wrote:
On 03/01/2010 12:48 PM, Peter Jones wrote:
I'd also like a policy in place to help us avoid situations like
the recent dnssec unpleasantness.
Sure. I'm just
On Sat, 27 Feb 2010 22:45:12 +0100
Michael Schwendt mschwe...@gmail.com wrote:
On Sat, 27 Feb 2010 13:17:43 -0800, Adam wrote:
On Sat, 2010-02-27 at 20:18 +0100, Michael Schwendt wrote:
Three times Could. Let's talk about it when you know something
definite, please, but before it
On Mon, 1 Mar 2010, Till Maas wrote:
On Mon, Mar 01, 2010 at 01:30:18PM -0500, Seth Vidal wrote:
On Mon, 1 Mar 2010, Will Woods wrote:
So I think it would be shortsighted for FESCo to refuse to even discuss
a policy about what manual testing is currently required, since any plan
for
On Mon, Mar 01, 2010 at 13:16:09 -0500,
Will Woods wwo...@redhat.com wrote:
That's an interesting test case, actually. I'm not sure we currently
check packages against the corresponding versions *other* releases.
You'd want to also check obsoltess.
Packages that are dropped without be
Tom spot Callaway (tcall...@redhat.com) said:
* Causes broken deps
* Breaks clean upgrade path between releases
* Has ABI/API change (and is a Critical Path package)
Actually, I'd say that any ABI change should block a stable push until it's
fixed, period - critical path or not.
If someone
On Mon, 1 Mar 2010, Bill Nottingham wrote:
Kevin Kofler (kevin.kof...@chello.at) said:
For most bugfixes, the user doesn't notice at all. When a user gets a
bugfix on something they've hit, they think oh, that's nice, Fedora fixed
it, but they don't really care whether it cam Monday or
On 03/01/2010 11:46 AM, Seth Vidal wrote:
One thing to consider: while from a psychological standpoint, a regression
is indeed perceived as much worse than an unfixed bug, from a technical /
practical standpoint it's actually the smaller issue: you can rollback to
the version of the package
James Antill wrote:
The current state of play is (taking a random kde example):
kdeutils F11 GA 4.2.2-4.fc11
kdeutils F11 Updates 4.4.0-1.fc11
kdeutils F12 GA 4.3.2-1.fc12
kdeutils F12 Updates 4.4.0-1.fc12
...so if someone tries to update from F11 (with updates) using an F12 GA
Kevin Kofler wrote:
1. upgrades which disrupt, regress or break things. Those can only be
pushed to Rawhide, if at all.
Such as KDE 4.4, just to pick a recent example. I had to log out and log in
again before I could start Kmail again. That can be quite disruptive if I have
long-running
On Mon, 2010-03-01 at 12:06 -0800, Josh Stone wrote:
But for rolling back an update, yum requires that the old package is
still available. We only keep the very latest version in the updates,
so unless your previous version was from the initial release, you're out
of luck. My last
On Mon, 1 Mar 2010, James Antill wrote:
On Mon, 2010-03-01 at 12:06 -0800, Josh Stone wrote:
But for rolling back an update, yum requires that the old package is
still available. We only keep the very latest version in the updates,
so unless your previous version was from the initial
On Mon, 1 Mar 2010, Bill Nottingham wrote:
Seth Vidal (skvi...@fedoraproject.org) said:
Given that we don't provide an easily accessible user-friendly rollback
mechanism, I don't know that that's actually applicable to the general case,
though.
yum history undo works pretty well. Not
Björn Persson wrote:
Kevin Kofler wrote:
1. upgrades which disrupt, regress or break things. Those can only be
pushed to Rawhide, if at all.
Such as KDE 4.4, just to pick a recent example. I had to log out and log in
again before I could start Kmail again. That can be quite disruptive if I
On 02/26/2010 08:00 PM, Jesse Keating wrote:
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
On 02/26/2010 08:52 PM, Kevin Kofler wrote:
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
On Mon, 2010-03-01 at 16:51 -0500, Doug Ledford wrote:
To be pedantic, Fedora is what it is. What the leadership has to say
doesn't really matter in terms of what Fedora *is*, only in terms of
what Fedora is *supposed to be*. In order to know what Fedora really
is, a person would need to
On Sat, 2010-02-27 at 10:16 -0700, Orion Poplawski wrote:
On 2/27/2010 5:05 AM, Kevin Kofler wrote:
Orion Poplawski wrote:
There is plenty of room for something in between your vision of Fedora
and CentOS.
But that room is filled by other distros, such as Ubuntu. Why do we
On Mon, 2010-03-01 at 09:44 +0100, Jaroslav Reznik wrote:
One problem of updates-testing is - it takes so much time to be pushed and
then mirrored. More rawhide approach should be used here. Users who are
really
interested in testing usually downloads from Koji directly.
We do pushes
On Mon, 2010-03-01 at 01:27 +0100, Kevin Kofler wrote:
Adam Williamson wrote:
It seems like extra work for packagers, but in the end it kinda takes the
pressure off: you only *have* to ship the important fixes to /updates,
/backports is optional,
That's already a bad thing, users can no
On Mon, 2010-03-01 at 08:07 +0100, Ralf Corsepius wrote:
So yeah, I agree it's not a perfect system - detailed suggestions for
improving it would be welcome, I'm sure.
Alternatives:
* Abandon it (I don't think this would change anything wrt. to QA in Fedora)
Um. Hard to put this
On Mon, 2010-03-01 at 12:17 +0100, Kevin Kofler wrote:
It doesn't take a mind reader to realize that an upstream BUGFIX release,
well, FIXES BUGS! ;-)
They also often shovel in entirely non-related changes on the basis that
they're perfectly obvious and trivial and simple changes that Can't
On Mon, 2010-03-01 at 11:57 -0500, Tom spot Callaway wrote:
On 03/01/2010 11:52 AM, Peter Jones wrote:
If you think this isn't the right way
to provide a safety net for package maintainers - what is?
With the understanding that you're not specifically asking me that
question, I'd say that
On Mon, 2010-03-01 at 18:33 +0100, Ralf Corsepius wrote:
Right now, the only proposal for doing so is to restrict what can be
released
without spending some time in testing.
The issues that at least I have been trying to point out:
* Is testing an adequate safety net?
* Is karma an
On Mon, 2010-03-01 at 00:58 +0100, Kevin Kofler wrote:
1. upgrades which disrupt, regress or break things. Those can only be pushed
to Rawhide, if at all. (Sometimes it might be better to not push a change
even to Rawhide.)
2. upgrades which do none of the above. Those are what adds value to
On Mon, 2010-03-01 at 16:16 -0500, Seth Vidal wrote:
in exchange for an arseload of diskspace.
just in the interest of complete disclosure. :)
Would that be 'an arseload of diskspace in /var, which everyone always
forgets to make big enough'?
:)
--
Adam Williamson
Fedora QA Community
On Mon, 2010-03-01 at 14:27 -0800, Adam Williamson wrote:
* Replace it by a free text comment system
Well, right now you have the choice of looking at the numbers or just
ignoring them and reading the text (whether to auto-push a release with
a given positive karma is a decision made by
On 03/01/2010 05:01 PM, Jesse Keating wrote:
On Mon, 2010-03-01 at 16:51 -0500, Doug Ledford wrote:
To be pedantic, Fedora is what it is. What the leadership has to say
doesn't really matter in terms of what Fedora *is*, only in terms of
what Fedora is *supposed to be*. In order to know what
On Tue, 2 Mar 2010, Nicolas Mailhot wrote:
Le lundi 01 mars 2010 à 14:46 -0500, Seth Vidal a écrit :
Given that we don't provide an easily accessible user-friendly rollback
mechanism, I don't know that that's actually applicable to the general case,
though.
yum history undo works pretty
On 10-03-01 15:06:21, Josh Stone wrote:
On 03/01/2010 11:46 AM, Seth Vidal wrote:
...
yum history undo works pretty well. Not flawless, to be sure - but
it's not bad for the simple-ish cases.
...
But for rolling back an update, yum requires that the old package is
still available. We
Matthias Clasen wrote:
GNOME has bug-fix releases (e.g. 2.28.1, 2.28.2, etc) and we do package
those as updates for Fedora releases.
I know, but my question was, are there still any 2.28.x bugfix releases
after 2.30.0 gets released? (With KDE, there aren't, so it's either
upgrading or no more
Björn Persson wrote:
Such as KDE 4.4, just to pick a recent example. I had to log out and log
in again before I could start Kmail again.
That's normal and not considered disruptive.
That can be quite disruptive if I have long-running processes that
shouldn't be interrupted.
You should not
Jesse Keating wrote:
And without using some sort of repository for users to test things and
provide feedback, how do you propose we distinguish between the two sets
of updates there?
Hey, this is a strawman! I'm not saying updates-testing should go away. I'm
just saying there are valid
Jesse Keating wrote:
Ubuntu is not the first to pick up technology in their releases either.
They generally wait for Fedora to ship with it first and work out all
the kinks, then they snap it run with it. So I really don't buy the
but then we'd be Ubuntu argument, at all.
It's true that
On Fri, 2010-02-26 at 09:41 -0500, Tom Lane 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:
You forgot security fixes. The proposed policy is insane.
+1.
I almost always push my
On Sun, Feb 28, 2010 at 01:23:21AM +0100, Dominik 'Rathann' Mierzejewski wrote:
Speaking as someone who is still on F11, I want the latest software as
long
as it doesn't break anything, because most often there are new useful features
in it.
I think one of the problems is precisely that new
On Fri, Feb 26, 2010 at 08:04:55AM -0600, Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
You clearly want to be able to push whatever, whenever (see massive KDE
updates in supposedly stable releases). Others have shown that
playing fast and loose with updates
Dominik 'Rathann' Mierzejewski wrote:
I want the latest software as long as it doesn't break anything,
Right, that's exactly what stable releases should be like, and I don't see
why the previous stable release should not get the same treatment as the
current stable. It's still supported, so it
Mike McGrath wrote:
Then lets fix that. Rolling updating everything isn't the answer to any
problem.
1. I don't propose to rolling update everything, but everything which
doesn't break or disrupt things. That's a subtle, but important distinction
(which you seem to be missing)!
2. You're
Mike McGrath wrote:
Bingo, in this world we'd basically not have F-11 right now. And as soon
as F13 comes out we'd no longer support F-12. We'd force users to upgrade
immediately and not give them any options to plan for updates, etc, etc.
I think the divide in this discussion is along
Till Maas wrote:
No, because there are updates that, e.g. require manual intervention, or
are more likely to break a lot of stuff. These would make the difference
between the releases.
Right. (And thanks for your replies further up this subthread, you left me
nothing more to add. ;-) )
E.g.
Mike McGrath wrote:
So when Fedora 12 came out, we allowed users 7 months to upgrade because
the latest version of stuff is too unstable for them. At the same time
we're also forcing them to upgrade to the latest versions of those
packages in F-11 anyway? I hope you can at least acknowledge
Adam Williamson wrote:
It seems like extra work for packagers, but in the end it kinda takes the
pressure off: you only *have* to ship the important fixes to /updates,
/backports is optional,
That's already a bad thing, users can no longer expect anything, it depends
on the maintainer being
Adam Williamson wrote:
Yeah, it's not perfect: there are cases where we have, say, a complex
kernel update which works fine for most people but causes a significant
regression for some particular bit of hardware. We wouldn't want to put
that update out, but it's easy for it to get five +1s
Ville Skyttä wrote:
Whether the provided name is existing or not is irrelevant, a dependency
on it can spring to life any time, including at a time when it causes the
package containing the name to be installed without being explicitly
asked.
If the provided name did not exist before, nothing
Paul Frields wrote:
Turns out my actual text was a bit less stark:
https://bugzilla.redhat.com/show_bug.cgi?id=543278#c53
The sooner we receive feedback, the sooner we'll know whether we can
release
this update to the stable distribution. Thanks for participating.
Wow, so you already had
On Sunday, 28 February 2010 at 11:44, Dodji Seketeli wrote:
On Sun, Feb 28, 2010 at 01:23:21AM +0100, Dominik 'Rathann' Mierzejewski
wrote:
Speaking as someone who is still on F11, I want the latest software
as long as it doesn't break anything, because most often there are
new useful
Kevin Kofler said the following on 02/28/2010 03:41 PM Pacific Time:
Till Maas wrote:
My proposal: If it passes all AutoQA tests and matches the criteria by
Kevin Koffler[0], then the update is ok, except that critical path
packages should be inspected more carefully.
[0]
On Mon, 2010-03-01 at 00:58 +0100, Kevin Kofler wrote:
Mike McGrath wrote:
So when Fedora 12 came out, we allowed users 7 months to upgrade because
the latest version of stuff is too unstable for them. At the same time
we're also forcing them to upgrade to the latest versions of those
lör 2010-02-27 klockan 15:26 +0200 skrev Ville Skyttä:
there are several ways new
installed packages can break existing systems, the combined results is that
it
is very much possible for newly introduced packages to automatically break
existing systems.
It could install a file in
On Sat, Feb 27, 2010 at 12:52 AM, James Antill wrote:
On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote:
My point is that there are plenty of users who want the current updates or
even more updates.
Citation needed
Just a few out of so many:
On Sat, Feb 27, 2010 at 6:12 AM, Adam Williamson awill...@redhat.com wrote:
this is a *terrible* idea. We may see users as a 'resource', but they
don't see themselves this way. We should not interrupt their usage of
their computer to try and exploit them to our ends.
What if it was an opt-in
On Sat, Feb 27, 2010 at 12:52:53AM -0500, James Antill wrote:
On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote:
, those users have very few choices
And, again, you are wrong.
Rawhide and Debian unstable are both the obvious choices, Gentoo is
still used by some I think. A little
On 26 February 2010 19:25, Kevin Kofler wrote:
[..]
Well, as I wrote, the packager should have tested the package he's pushing
out, of course! Especially for a new package, it's the only way to know it
works. Something that doesn't work at all has no business being pushed to
anywhere, even
On 26 February 2010 19:58, Orcan Ogetbil wrote:
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
Chris Adams wrote:
IMHO you're developing the wrong distro. It is statements like yours
that contribute to the Fedora is a rolling beta perception (and I
don't think that's a good perception to have). If you want to target
rawhide with rolling releases of KDE, have fun. Once a release is
James Antill wrote:
And, again, you are wrong.
Rawhide and Debian unstable are both the obvious choices, Gentoo is
still used by some I think. A little more work with a little more
stability then gives you Debian testing and now moving to the latest
Fedora pre-releases.
Yes, those options
Orion Poplawski wrote:
There is plenty of room for something in between your vision of Fedora
and CentOS.
But that room is filled by other distros, such as Ubuntu. Why do we need to
be another Ubuntu?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Oh, and by the way:
Orion Poplawski wrote:
There is plenty of room for something in between your vision of Fedora
and CentOS.
There is plenty of room for something in between your vision of Fedora
and Rawhide. :-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Rakesh Pandit wrote:
About new package point, what about the negative impact of newly
pushed package on distribution as a whole if it breaks to launch or
crashes in some event(produced in some essential functionality) and
was missed by packager/reviewer (2 people) ?
It won't automatically
Paul W. Frields wrote:
How'd it happen? I commented directly in the Bugzilla bugs with the
link and told the subscribers to the bugs that the package would not
be issued until some of them tested it and posted feedback to tell me
their bugs were fixed.
I see why you're doing it, but still,
Chris Adams wrote:
Once upon a time, Bruno Wolff III br...@wolff.to said:
P.S. I don't use enablerepo. I'll yum install a local copy of the rpm and
see what it needs if it doesn't install successfully.
That seems like extra and unnecessary work. You doesn't do anything
without telling
On Saturday 27 February 2010, Kevin Kofler wrote:
Rakesh Pandit wrote:
About new package point, what about the negative impact of newly
pushed package on distribution as a whole if it breaks to launch or
crashes in some event(produced in some essential functionality) and
was missed by
On 02/27/2010 02:08 AM, Kevin Kofler wrote:
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. :-(
Also does not apply to
* sporadic bugs.
*
On Sat, 27 Feb 2010, Kevin Kofler wrote:
Chris Adams wrote:
IMHO you're developing the wrong distro. It is statements like yours
that contribute to the Fedora is a rolling beta perception (and I
don't think that's a good perception to have). If you want to target
rawhide with rolling
On Sat, Feb 27, 2010 at 09:44:11AM -0600, Mike McGrath wrote:
On Sat, 27 Feb 2010, Mike McGrath wrote:
On Sat, 27 Feb 2010, Kevin Kofler wrote:
Chris Adams wrote:
IMHO you're developing the wrong distro. It is statements like yours
that contribute to the Fedora is a rolling beta
On Sat, Feb 27, 2010 at 02:55:41PM +0100, Kevin Kofler wrote:
New packages which don't Obsolete existing packages or Provide existing
provided names cannot cause any of the above. (They may technically trigger
Special care should be given to the auto-generated Provides. I remember
a
On Sat, 2010-02-27 at 08:45 +, Camilo Mesias wrote:
On Sat, Feb 27, 2010 at 6:12 AM, Adam Williamson awill...@redhat.com wrote:
this is a *terrible* idea. We may see users as a 'resource', but they
don't see themselves this way. We should not interrupt their usage of
their computer to
On Sat, 2010-02-27 at 10:57 +0100, Ralf Corsepius wrote:
Sorry, I was replying in haste. I should've made clear that I was
talking more in general, and don't have any specific direct knowledge of
the dnssec case. I know of multiple cases where updates have been pushed
hastily, but I don't
On 02/27/2010 03:13 AM, Orcan Ogetbil wrote:
On Sat, Feb 27, 2010 at 12:52 AM, James Antill wrote:
On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote:
My point is that there are plenty of users who want the current updates or
even more updates.
Citation needed
Just a few out of so
On Sat, 2010-02-27 at 11:41 +0100, Till Maas wrote:
Ok, maybe the question should be then: How much does AutoQA support me
writing these tests? E.g. this test is pretty simple, but afaics there
is no easy support for the common tasks that are needed to run the test,
but not really part of the
101 - 200 of 357 matches
Mail list logo
