at POT is up-to-date with latest strings.
Please note that this applies ONLY to packages translated by the Fedora
Localization Project. Upstream projects have different translation schedules
and string freezes.
Kevin Kofler
--
devel mailing list
devel@lists.fedorapr
-lived the "no default xorg.conf" idea was, now we get
default xorg.conf.d snippets. :-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
For
GNOME, the touchpad UI has been installed by default for a while now.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
tatic repos pointed to the right location.
Why not use dist-f14?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
d!
> I think we still need to be able to treat F-13 different than in the
> released branches, at least before beta freeze. If we need to do things
> in rawhide first and only push these changes to F-13 afterwards, a
> feature with a tight schedule like Xfce 4.8 is lost. That's ju
> to stable, because a qt override is in the buildroot.
The solution there is to talk to us, we can get the Qt 4.6 stuff off the
buildroot for a while so he can build his bugfix update. That's what
#fedora-kde is for. (IRC is the best communication method for this stuff
because it's r
ey were required to fix a bug, API change in something like kdebase-
workspace which doesn't have a guaranteed API/ABI (requiring e.g. kdeplasma-
addons to be built against the latest kdebase-workspace) etc.
XFCE may be similar.
Kevin Kofler
--
devel mailing list
devel@lists.fe
13 branch existing. But I guess the decision has already
been made.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
changes! Please only push updates if you have actual user-visible
changes.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
hat said, if the SVN snapshot fixes some important bug, I'd consider
pushing it, depending on how long it is until the release.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
zones.
I think that'd be a good idea. My tag requests for buildroot overrides
usually only get processed when rdieter is up, even if I file them in the
rel-eng Trac. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
n different special tags. Depending
on which of the builds "wins", one or the other dependency will be broken)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
same time,
we coordinate builds and buildroot overrides on IRC and then I end up going
to sleep an hour or two *after* him. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it use wildcards to select the files to copy in,
e.g. libntfs-3g.so.*, instead of hardcoding the exact names? That way you
wouldn't have to care about this kind of file deps at all, it'd just work
always.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
en it can't be avoided.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
much better than having the package
uninstallable every other day as it is now).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ave a similar format and same permissions but do
> not create this warning.
>
> What am I doing wrong?
Check the library's DT_SONAME field, it should be libxmlrpc.so.3, not
libxmlrpc.so (which I suspect it is).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ce*, or else
> they have said that they want to be nagged.
I also think that makes sense, but the PolicyKit 1 developers don't. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
.
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I'd suspect a parallel make race.
Try building without smp_mflags.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
message was
not clear enough. Please double-check before you hit that "push to stable"
button! Thanks in advance.
We will look into using some less dangerous process (special build tags?) for
future Qt updates as this is just not working, but for now please be careful.
Ke
ou aren't building against a newer Qt from a buildroot override!), Qt
4.6.2 is now queued for the stable updates (it was decided in today's KDE
SIG meeting to push the big Qt 4.6.2 / KDE 4.4.0 / SIP 4.10 update set out),
so this particular version bump should no longer be a sour
the modified update for the next push.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
should just go directly to stable. :-)
20:52:34 Kevin_Kofler: In the rest of the world, it takes longer than a
week for fixes to appear on users' systems
20:52:43 It turns out that there's a reason fr that
20:52:48 Kevin_Kofler: lets stop doing releases and just make
everyone use ra
and we may well try out this approach with KDE 4.4.1.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
es
> * Debian, Ubuntu, SuSE use man-db
> As the first step I want to add man-db to fedora cvs.
> Comments welcomed.
I think this is a good idea.
This would of course need to be a new package that would either not
conflict with or simply obsolete/replace the existing man-db package,
ones is)
looks quite sensible to me.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Kevin Fenzi wrote:
> This would of course need to be a new package that would either not
> conflict with or simply obsolete/replace the existing man-db package,
> right?
I'd say Obsoletes/Provides is the best solution.
Kevin Kofler
--
devel mailing list
devel@lists.fed
F12, but not F13. As
F13 is frozen, it will NOT automatically pick up a build, you need to push
it through Bodhi as well (and stuff pushed at this time will end up in the
F13 release, not in updates). So you're breaking the upgrade path. Please
also push this to F13 in Bodhi.
Kevin
issues, or get more features when rebuilt against a newer Qt.
But as you did not include a Bugzilla reference nor any other form of
rationale, I can't figure out why you rebuilt this particular application.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraprojec
y to
rebuild anything. Sadly, binary compatibility has been lackluster in recent
times. :-( )
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Matthew Garrett wrote:
> What do those numbers mean?
They're documented in the specs.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
st agree with
me, please reply so the other FESCo members don't think it's just me!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.fedoraproj
s
>> very low.
>
> The possibility to publish hot-fixes is most important.
+1. Not being able to push those out quickly would really suck.
>> * A trivial bugfix (like a one-line diff), tested and confirmed to fix
>> the bug by at least one person. The risk of breakage is
identical.
Well, I'm not sure this is a big factor in this particular case. The
conflict of interest is more apparent in other situations, e.g. good luck
getting a broken upstream default fixed if upstream is also the Fedora
packager. (See e.g. spatial Nautilus, for which it took years for
, then why should the fix have to go
through testing? It can't make things worse if the app is already broken,
and clearly nobody is using both updates-testing and that app.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
g an update if nobody cares?
Because the people who don't run updates-testing care and complained about
the issue? Because you don't know how many more users are having the issue
and not bothering to report it (and of course if they don't even bother
reporting the issue, they
table anyway. For a one-line fix, that's usually
more than enough (and when it's not, the maintainer knows why, e.g. if that
one line enabled a 1-line feature).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
r
even FESCo as long as 1 FESCo member is enough to approve it, not a vote.
And no, I wouldn't blanket-approve everything as I have been accused of in
the meeting, please quit the paranoia!)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapr
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 people.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
drago01 wrote:
> On Fri, Feb 26, 2010 at 1:43 PM, Michael Schwendt
> 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 faile
ly
> haven't done enough packaging -- though seeing who is in FESCo, it looks
> quite strange to me since some members are seasoned packagers and some
> even were here before bodhi.
Yeah, it quite surprised me that I was the only one seeing a need for this
feature in FESCo!
stalled).
That won't solve the problem that people aren't using updates-testing in the
first place. We can't force them to.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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" whic
. Only the
newer Plague setups (EPEL, RPM Fusion) included a testing repo.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
erent target audience, they're conservative
users who resist change and who are used to bugs staying unfixed for a very
long time if they're not considered critical enough. What works for that
audience does NOT work for Fedora's user base.
Kevin Kofler
-
ree that banning direct stable pushes even for security updates
would be even more insane.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.
kagers could be talked to.
Yes, there too, it's a people problem, it needs a social solution. Technical
"solutions" will cause both false positives and false negatives and just
cause more trouble.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it, you have to, we voted it through already" is
not transparent.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
omewhat more likely to be affected than bugfixes to existing ones.) Most
often what works on Fedora n also works on Fedora m. It's not like the
reviewer tested on Slackware or OS X. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
now
> after seeing so many policies and rules for maintaining packages for
> Fedora releases.
This is not policy yet, we still have a hope of stopping the madness!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, 26 Feb 2010 16:40:46 +0100
Kevin Kofler 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 meeti
n?
>
> Thank you for your feedback.
Well, I would suggest if you can get it setup so it continues to work
as expected on upgrade it should be fine. If thats a symlink or
whatever it should be ok.
Perhaps make and test a version, then post the spec diff for
comment/feedback if you like?
k
On Fri, 26 Feb 2010 15:53:14 +0100
Till Maas wrote:
> On Thu, Jan 21, 2010 at 02:51:46PM -0700, Kevin Fenzi wrote:
> > On Thu, 21 Jan 2010 17:34:50 +0100
> > Till Maas wrote:
>
> > > Maybe the meetbot could be patched to only accept a topic change
> > >
oiding all the nasty clicking and selecting).
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 good enough t
ners clearly cannot do it
> themselves.
No, it means we need to educate our maintainers better so they can make the
right judgement on a case by case basis (as they're getting it wrong in some
rare occasions), not overzealously ban everything.
Kevin Kofler
--
deve
RA-2010-0968
> (since 2010-01-24)
IMHO you've waited way too long on these already, I hit "push to stable"
after a week of no negative feedback on my updates. If nobody complains,
that's probably because it's working fine.
Kevin Kofler
-
ey'd use something
else. There are plenty of conservative or semi-conservative (à la Ubuntu:
new stuff in releases, few to no updates to releases) distros out there. Why
should we be another one?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedor
people should use a more conservative distribution. Try CentOS maybe.
Frequent updates are an integral part of the Fedora experience.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
g out the baby with the bathwater by dropping that. If we blow up
our niche, we have no place to live anymore. But enough metaphors, the point
is that if we do everything the same way as Ubuntu, there will be no reason
for people to use Fedora over Ubuntu.
Kevin Kofler
--
devel mail
to be a reason to push something. Updates for a new
upstream release of the "fix crash on OS X" type have no business being
pushed (duh). But most often, those updates DO fix bugs which affect Fedora.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
want.
Anyhow I think this thread is mostly hot air unless there are specific
proposals or concrete feedback. Please write up a detailed proposal, or
wait and provide feedback when we have such? Or at least post new
ideas... not 'he said, she said' back and forths.
kevin
signature.asc
make sure future updates of the same type can get
closer scrutiny. (Apparently one characteristic was touching config files,
which seems to be a flag to me, config files by definition vary from system
to system.) But banning all direct stable pushes surely isn't the answer.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
broken and which also doesn't
break things for users, e.g. cause surprise backwards-incompatible changes
to config file formats, data formats etc. Except for the occasional (very
rare) screwup, our stable updates are like that. Even updates-testing is
already too bleeding-edgy.
between us and Ubuntu. (I know there's also the
licensing stuff, like Ubuntu bundling proprietary drivers, but that's not
that big a difference in practice, it's not like those drivers cannot be
easily removed (or added, yuck!).)
Kevin Kofler
--
devel ma
ular package is even just empty. Updates-testing is not a silver
bullet.
> Please don't skip the fact that fixes themselves might be broken too,
> even the most trivial ones.
The more trivial the fix, the less likely this is.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Subbing in the changelog at the "submit the
> update" stage is just inappropriately covering for lazy maintainers.)
KPackageKit even always displays the changelog, no matter whether the update
notes are empty or not.
Kevin Kofler
--
devel mailing list
devel@lists.fedorapro
propriate change summary for the update notes! (And
sadly, that's what the ChangeLog in %doc often contains, if it even exists
at all, summaries are often only provided on some website.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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.o
from happening.
Bad stuff DOES slip through testing occasionally. In a perfect world,
updates-testing would be a magic oracle to the question "Does this update
introduce any regressions?" In practice, such a magic oracle doesn't exist.
Kevin Kofler
--
devel m
bug, from a technical /
practical standpoint it's actually the smaller issue: you can rollback to
the version of the package before the regression, you can't rollback an
unfixed bug as there's nothing to roll back to!
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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 a
going to require GPG-signing every single Bugzilla comment
because we don't trust Bugzilla's authentication (like Fedora Legacy)???
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
point, the vote got deferred for 1 week, but after almost half of
that time elapsed, I still haven't seen any draft policy, request for
feedback etc.
Isn't it natural that this leaves me really worried about what's going to
happen on Tuesday?
Kevin Kofler
--
devel maili
new soname of some core library which in turn
required everything else to be upgraded to match the new soname. And of
course they won't understand what happened and why. --enablerepo=rawhide is
extremely dangerous and should NEVER be used, especially not by users who
don't know EXACTLY
in the software stack and how some code necessarily looks like (hardware
drivers in particular are always scary stuff). The average leaf package is
much less propice to breakage induced by minimal changes.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
estroy hardware!" fix (and that's just if the
hardware is really infrequent; you could end up with a lot more broken
machines in a week even with frequencies which may still elude testing).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
it's expected to work as well as it always
did.)
For KPDF, it has been replaced by Okular which is a perfectly fine
replacement for me. Is there any specific KPDF feature you're missing in
Okular?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https:/
If you want to discuss this further, please
use the fedora-kde list. :-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
also
not a nice thing to do. ;-)
Personally, I'm not convinced that not upgrading is a good idea (e.g. I used
F9 until EOL and 4.2 was really great there, then I went to F10 and used
that until its EOL with 4.3 and that also worked great), but this option IS
being evaluated in KDE SIG.
lease-based, partly rolling), and IMHO this compromise
is working great. We get the advantages from a rolling release model, but
with a lot less surprise breakage as in a true rolling model because
disruptive changes like libata go only into new releases.
Kevin Kofler
--
devel maili
does something cool, at worst that new
menu entry might not work perfectly, but it shouldn't affect anything else).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
ckup patches or packages and try them in
> their use-cases, but they will not regularily pull the "testing repos".
Indeed, only few people systematically use updates-testing. If it were
suitable for general consumption, it would be called "stable". :-)
So once again we're
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.fedoraproje
pushing out something that doesn't work at all is a bad idea, but
normally a new package which gets pushed was tested by at least 1 or 2
people (the submitter and/or the reviewer).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
're doing it, but still, this is essentially blackmailing
users, I'm not sure it's a good plan to follow.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
ing, but to a lesser extent.
On the other hand, X might not be tested with the old version of Y. So there
are drawbacks to everything. Selective updates are necessarily unreliable.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
o I'm also not a fan of the suggestion to only push KDE upgrades to the
current stable release and not the previous stable one.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
gger, like "delete everything if somebody installs package foo", then we
have a much bigger problem than update stability!)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
dates "at the discretion of the upstream brand"?
Why should it be upstream's business what updates we push in our
distribution?
Sorry, but as I already said back when this was originally proposed, that
proposal makes no sense whatsoever to me.
Kevin Kofler
--
devel mailin
or not.
Indeed, that's exactly why Rawhide is not suitable for the average user,
even those who want frequent updates.
> Nobody is forcing updates on me. I like things the way they are now.
+1
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
h you seem to be missing)!
2. You're claiming things with no arguments, whereas I provided a rationale
for my claims.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
o use Rawhide and those who want upgrades which DO NOT
BREAK ANYTHING pushed to stable releases so users get BOTH the advantages of
a rolling release AND those of numbered releases.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Michael Schwendt wrote:
> Where to start and where to stop with upgrade madness? What may be
> feasible for Gtk, would be a much bigger task for GNOME and other
> frameworks.
So what? We can pull it off for KDE, why would it not be possible for GNOME?
Kevin Kofler
--
devel mai
d updates somewhere in the
> thread, I can try to find it again if you want.
I posted those. :-) You already found them, but I think versions in earlier
threads may be more complete, I may have forgotten something this time as I
didn't have much time to think of all the details nor to
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]
> [http://lists.fedoraproject.org/pipermail/devel/2010-February/13
901 - 1000 of 8611 matches
Mail list logo
