Re: Some or all of your votes have been removed

[Kamil Paral]

- "Kevin Fenzi"  wrote:
> 
> I'll repost what I posted to devel just a few ago. 
> Sorry for any confusion. I didn't think it would be sending emails,
> and
> particularly with such a poor subject. ;( 
> 
> > Has it been disabled recently?  
> 
> Short answer: Yes. It has. 
> 
> Longer answer: 
> 
> FESCo looked at trying to use voting data to give us an idea on 'hot'
> bugs that we might be able to send more resources to fix. Sadly,
> voting
> isn't at all good for this, as people have many votes (100 or 1000, I
> forget which), so it's hard to tell if an issue affects 10 people or
> 100 by that. Many people didn't see the voting interface, so they
> wouldn't have used it even if the problem was severe or affected a
> lot
> of people. Some people were using the voting interface, even though
> no
> maintainers ever noticed it (ie, thinking this could help the bug get
> solved, but it's like the maintainer and voter were in seperate
> worlds
> without any communication). 
> 
> So, we decided it would be less confusing to just disable it. 
> 
> We decided to look into using CC or comments to tell when a bug had a
> lot of people affected or was 'very active'. Unfortunately, this also
> is proving to be difficult to implement. See: 
> https://fedorahosted.org/fedora-engineering-services/ticket/24
> any help there would be appreciated. 
> 
> kevin


Thanks for the explanation, Kevin. Just out of curiosity you may have a 
look at Launchpad interface how they solved this:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/345627
"This bug affects you and 45 other people  (Edit)"

You can also sort the bugs by "heat":
https://bugs.launchpad.net/ubuntu/+source/linux?orderby=-heat
(more explanation after clicking on heat icon)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: firefox always starts offline

[cornel panceac]

>
> If NetworkManager stops your network stops, period.  Firefox, Evolution
> and Empathy for sure depend on it and eventually everything will.  You
> can frob an undocumented option on Firefox's about:config screen but no
> known fix exists for the others.
>
> Solution: Troubleshoot your NetworkManager problem.  It isn't optional
> anymore.  Whether that is wise is a question best left to the
> philosophers.
>
> of course, to troubleshoot nm, it's best to update the system first ...
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[John Morris]

On Thu, 2010-09-02 at 14:17 +0200, Dennis J. wrote:

> What I would like to see is a distinction between regressions and other 
> bugs. There are a least two reasons why this might be worthwhile:
> 
> 1. Regressions break functionality that has been known to work previously 
> and the users already rely on. If new stuff gets added and has bugs that is 
> not as serious because users are not yet relying on this to work.
> 
> 2. Regressions can be easier to fix because you have a "known to work" case 
> you can use as a comparison. If bugs could be flagged as regression then 
> developers you potentially look at these first right after the regressions 
> occurred and probably identify the reason for the regression right away.

I'd like to suggest another reason regressions should get higher
priority.  Regressions hit people who already have Fedora installed and
running and puts us in a bad place.  Every install is less than a year
away from being unsupported and a serious regression leaves us unable to
stay on the upgrade treadmill.

In my case I reported #573135 back in March and stopped taking kernel
updates. In another month or so I'll boot a live USB stick of F14 and
see if the bug was fixed and just didn't get closed.  Then it is either
suck it up and run without security fixes or jump distros.

That is the difference, a bug in a bad place might stop a new user from
migrating to Fedora while a regression combines with the short support
cucle to force an existing user to migrate away if it exists across two
releases.

There really needs to be a change of attitude from "Ooh! Shiny!  Ship
it!" to not shipping new until it at least does everything the old did
and reverting when serious bugs appear and can't be quickly patched.
Yes I realize I'm suggesting something that will result in new stuff
taking longer to arrive.  At some point we really need to begin a shift
away from furious development of new features into a more quality driven
focus.


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: firefox always starts offline

[John Morris]

On Thu, 2010-09-02 at 08:50 +0300, cornel panceac wrote:
> something strange happens on one of my test pcs running f14 (updated).
> firefox always starts in offline mode. i uncheck work offline and
> eevrythings fine until i close and start again firefox, when it's in
> offline mode again. what could be the problem? NetworkManager is
> stopped because it's not working.

If NetworkManager stops your network stops, period.  Firefox, Evolution
and Empathy for sure depend on it and eventually everything will.  You
can frob an undocumented option on Firefox's about:config screen but no
known fix exists for the others.

Solution: Troubleshoot your NetworkManager problem.  It isn't optional
anymore.  Whether that is wise is a question best left to the
philosophers.


signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 14 Blocker Bug Review Meeting 2010-09-03 @ 16:00 UTC (12 PM EST)

[John Poelstra]

CORRECTION Friday, 2010-09-03


> When: Friday, 2010-09-02 @ 16:00 UTC (12 PM EST)
> Where: #fedora-bugzappers on irc.freenode.net
>
> Here are the current bugs listed as blocking the Beta release. We'll be
> discussing all of these to determine if they meet the criteria, should
> stay on the list, and are getting the attention they need:
>
> 629719 :: NEW :: anaconda :: Anaconda Maintenance Team ::
> FormatCreateError: ('invalid device specification', '/dev/md127p3') ::
> https://bugzilla.redhat.com/show_bug.cgi?id=629719
>
> 623524 :: NEW :: anaconda :: Anaconda Maintenance Team :: Err during
> filesystem check after upgrading bootloader ::
> https://bugzilla.redhat.com/show_bug.cgi?id=623524
>
> 624971 :: NEW :: anaconda :: Anaconda Maintenance Team :: Kernel
> argument with "UUID=" is not honored ::
> https://bugzilla.redhat.com/show_bug.cgi?id=624971
>
> 628239 :: NEW :: anaconda :: Anaconda Maintenance Team :: Fedora 14
> Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't
> blacklist nouveau :: https://bugzilla.redhat.com/show_bug.cgi?id=628239
>
> 618504 :: NEW :: xmlrpc-c :: Enrico Scholz :: Cannot submit abrt bugs ::
> https://bugzilla.redhat.com/show_bug.cgi?id=618504
>
> 621027 :: NEW :: fedora-logos :: Tom "spot" Callaway :: Graphical screen
> in anaconda shows F-13 :: https://bugzilla.redhat.com/show_bug.cgi?id=621027
>
> 565323 :: ASSIGNED :: selinux-policy :: Daniel Walsh :: SELinux is
> preventing /usr/bin/python "write" access  on sysctl.conf. ::
> https://bugzilla.redhat.com/show_bug.cgi?id=565323
>
> 622927 :: MODIFIED :: anaconda :: Radek Vykydal :: F14 Alpha RC2 -
> /etc/resolv.conf gets corrupted, cannot download packages ::
> https://bugzilla.redhat.com/show_bug.cgi?id=622927
>
>
> If you are the owner of any of these bugs, kindly update the comments
> with your feedback as to whether you believe it is a blocker and what
> your plans for fixing the bug are.
>
> Do you have an issue you believe should be fixed before the Fedora 14
> Beta ships?  Please consider the following criteria when escalating an
> issue: https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria
>
> Hope to see everyone tomorrow.
>
> John
>
> The command used to generate the list of bugs above is:
>
> $ bugzilla query --blocked=611991 \
>
> --bug_status=NEW,ASSIGNED,NEEDINFO,ON_DEV,MODIFIED,POST,ON_QA,FAILS_QA,PASSES_QA,REOPENED,VERIFIED,RELEASE_PENDING
> \
>   --outputformat="%{bug_id} :: %{bug_status} :: %{component} ::
> %{assigned_to} :: %{summary} :: %{url}"

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

[Test-Announce] Fedora 14 Blocker Bug Review Meeting 2010-09-02 @ 16:00 UTC (12 PM EST)

[John Poelstra]

When: Friday, 2010-09-02 @ 16:00 UTC (12 PM EST)
Where: #fedora-bugzappers on irc.freenode.net

Here are the current bugs listed as blocking the Beta release. We'll be 
discussing all of these to determine if they meet the criteria, should 
stay on the list, and are getting the attention they need:

629719 :: NEW :: anaconda :: Anaconda Maintenance Team :: 
FormatCreateError: ('invalid device specification', '/dev/md127p3') :: 
https://bugzilla.redhat.com/show_bug.cgi?id=629719

623524 :: NEW :: anaconda :: Anaconda Maintenance Team :: Err during 
filesystem check after upgrading bootloader :: 
https://bugzilla.redhat.com/show_bug.cgi?id=623524

624971 :: NEW :: anaconda :: Anaconda Maintenance Team :: Kernel 
argument with "UUID=" is not honored :: 
https://bugzilla.redhat.com/show_bug.cgi?id=624971

628239 :: NEW :: anaconda :: Anaconda Maintenance Team :: Fedora 14 
Alpha "reduced graphics" creates vesa-using xorg.conf but doesn't 
blacklist nouveau :: https://bugzilla.redhat.com/show_bug.cgi?id=628239

618504 :: NEW :: xmlrpc-c :: Enrico Scholz :: Cannot submit abrt bugs :: 
https://bugzilla.redhat.com/show_bug.cgi?id=618504

621027 :: NEW :: fedora-logos :: Tom "spot" Callaway :: Graphical screen 
in anaconda shows F-13 :: https://bugzilla.redhat.com/show_bug.cgi?id=621027

565323 :: ASSIGNED :: selinux-policy :: Daniel Walsh :: SELinux is 
preventing /usr/bin/python "write" access  on sysctl.conf. :: 
https://bugzilla.redhat.com/show_bug.cgi?id=565323

622927 :: MODIFIED :: anaconda :: Radek Vykydal :: F14 Alpha RC2 - 
/etc/resolv.conf gets corrupted, cannot download packages :: 
https://bugzilla.redhat.com/show_bug.cgi?id=622927


If you are the owner of any of these bugs, kindly update the comments 
with your feedback as to whether you believe it is a blocker and what 
your plans for fixing the bug are.

Do you have an issue you believe should be fixed before the Fedora 14 
Beta ships?  Please consider the following criteria when escalating an 
issue: https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria

Hope to see everyone tomorrow.

John

The command used to generate the list of bugs above is:

$ bugzilla query --blocked=611991 \
 
--bug_status=NEW,ASSIGNED,NEEDINFO,ON_DEV,MODIFIED,POST,ON_QA,FAILS_QA,PASSES_QA,REOPENED,VERIFIED,RELEASE_PENDING
 
\
 --outputformat="%{bug_id} :: %{bug_status} :: %{component} :: 
%{assigned_to} :: %{summary} :: %{url}"
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Kevin Fenzi]

On Thu, 2 Sep 2010 19:06:14 + (UTC)
Andre Robatino  wrote:

> Not that it matters now, but it probably would have been better to
> allow just one vote apiece, not an arbitrary number. Having said
> that, using CC or comments is probably a better way since it happens
> automatically. CC might be more useful, since people can inflate the
> comment number by posting multiple comments, but can only CC
> themselves once.

Well, they could sign up for a bunch of email addresses and add a bunch
of addresses to cc as well. Granted it would be more work... :)

kevin


signature.asc
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Fedora 12 updates-testing report

[updates]

The following builds have been pushed to Fedora 12 updates-testing

CVector-1.0.3-1.5Aug09.fc12
NetworkManager-0.8.1-6.git20100831.fc12
R-qtl-1.18.7-1.fc12
bdii-5.1.8-1.fc12
cherokee-1.0.8-2.fc12
cntlm-0.35.1-4.fc12
cryptopp-5.6.1-1.fc12
eclipse-3.5.1-23.fc12
fluidsynth-1.1.2-1.fc12
gthumb-2.10.12-2.fc12
gwibber-2.31.91-1.832bzr.fc12
libvpx-0.9.1-3.fc12
mc-4.7.3-2.fc12
perl-Net-Telnet-Cisco-1.10-3.fc12
perl-Test-Pod-1.44-1.fc12
python-slip-0.2.13-1.fc12
quagga-0.99.17-1.fc12
root-5.26.00d-2.fc12
ruby-cairo-1.8.5-1.fc12
wmfrog-0.2.2-1.fc12
xrootd-20100315-5.fc12

Details about builds:



 CVector-1.0.3-1.5Aug09.fc12 (FEDORA-2010-13975)
 ANSI C API for Dynamic Arrays

Update Information:

Initial release

References:

  [ 1 ] Bug #545046 - Review Request: CVector - ANSI C API for Dynamic Arrays
https://bugzilla.redhat.com/show_bug.cgi?id=545046




 NetworkManager-0.8.1-6.git20100831.fc12 (FEDORA-2010-14017)
 Network connection manager and user applications

Update Information:

This update fixes a security issue caused by dbus-glib (CVE-2010-1172), enhances
interaction with the /etc/hosts file, enables DHCPv6-only configurations,
ensures that connections will not fail is the DHCP lease unexpectedly expires
and is reacquired, works around unstable behavior of proprietary wireless
drivers, quiets annoying warning messages, fixes crashes when editing system and
WPA Enterprise connections, and hides mobile broadband PIN/PUK codes when asking
the user for them. This update fixes editing of system DSL connections when
using the keyfile plugin, works around inconsistent active AP reporting by
proprietary drivers, fixes a crash related to VPN passwords, suppresses WiFi
scans when connections are locked to a specific AP, fixes editor crashes
relating to PolicyKit permissions handling, and fixes remembering the "Ignore
missing CA certificate" preference when connecting to WPA Enterprise networks.
For Fedora 12 this update additionally fixes IPv6 connection issues, issues with
suspend/hibernate, and handling of system WiFi connections that use ASCII WEP
keys.

ChangeLog:

* Tue Aug 31 2010 Dan Williams  - 0.8.1-6
- core: add dispatcher events on DHCPv4 and DHCPv6 lease changes
- core: enforce access permissions when enabling/disabling WiFi and WWAN (rh 
#626337)
- core: listen for UPower suspend/resume signals
- applet: fix disabled Enable Networking and Enable Wireless menu items (rh 
#627365)
- applet: updated translations
- applet: obscure Mobile Broadband PIN in secondary unlock dialog
* Wed Aug 18 2010 Dan Williams  - 0.8.1-5
- core: fix some systemd interaction issues
* Tue Aug 17 2010 Dan Williams  - 0.8.1-4
- core: rebuild to fix polkit 0.97 build issue
- applet: updated translations

References:

  [ 1 ] Bug #626337 - non-local user can disable wifi and wwan
https://bugzilla.redhat.com/show_bug.cgi?id=626337
  [ 2 ] Bug #627365 - Enable Networking and Enable Wireless options are grayed 
out in NetworkManager Applet after update
https://bugzilla.redhat.com/show_bug.cgi?id=627365
  [ 3 ] Bug #590874 - let dhclient get a new lease on existing lease expiration 
before terminating connection
https://bugzilla.redhat.com/show_bug.cgi?id=590874
  [ 4 ] Bug #619775 - [abrt] crash in NetworkManager-gnome-1:0.8.1-1.fc13: 
nag_dialog_response_cb: Process /usr/bin/nm-applet was killed by signal 11 
(SIGSEGV)
https://bugzilla.redhat.com/show_bug.cgi?id=619775
  [ 5 ] Bug #615085 - system asking for 3g broadband pin in the clear
https://bugzilla.redhat.com/show_bug.cgi?id=615085
  [ 6 ] Bug #611831 - Allow  key in SIM PIN window of NM
https://bugzilla.redhat.com/show_bug.cgi?id=611831
  [ 7 ] Bug #557495 - [abrt] crash in eap_method_nag_user()
https://bugzilla.redhat.com/show_bug.cgi?id=557495
  [ 8 ] Bug #610891 - [abrt] crash in 
NetworkManager-gnome-1:0.8.1-0.1.git20100510.fc13: cell_editing_canceled: 
Process /usr/bin/nm-connection-editor was killed by signal 11 (SIGSEGV)
https://bugzilla.redhat.com/show_bug.cgi?id=610891
  [ 9 ] Bug #603566 - [abrt] crash in get_permissions_cb()
https://bugzilla.redhat.com/show_bug.cgi?id=603566
  [ 10 ] Bug #605338 - nm doesn't restore 127.0.0.1 entry in  /etc/hosts
https://bugzilla.redha

Fedora 13 updates-testing report

[updates]

The following builds have been pushed to Fedora 13 updates-testing

CVector-1.0.3-1.5Aug09.fc13
NetworkManager-0.8.1-6.git20100831.fc13
PackageKit-0.6.6-2.fc13
R-qtl-1.18.7-1.fc13
bdii-5.1.8-1.fc13
cherokee-1.0.8-2.fc13
cntlm-0.35.1-4.fc13
cryptopp-5.6.1-1.fc13
flies-python-client-0.0.5-1.fc13
fluidsynth-1.1.2-1.fc13
fswebcam-20100622-2.fc13
ghc-type-level-0.2.4-2.fc13
gthumb-2.11.91-1.fc13
gwibber-2.31.91-1.832bzr.fc13
jarbundler-2.1.0-5.fc13
k3b-2.0.1-1.fc13
kde-partitionmanager-1.0.3-1.fc13
libvpx-0.9.1-3.fc13
mc-4.7.3-2.fc13
mmapper-2.1.0-1.fc13
myproxy-5.2-1.fc13
mysql-connector-c++-1.1.0-0.2.bzr888.fc13
perl-Class-XSAccessor-1.07-1.fc13
perl-HTML-Parser-3.67-1.fc13
perl-Net-Telnet-Cisco-1.10-3.fc13
perl-Term-Shell-0.02-2.fc13
perl-Test-Pod-1.44-1.fc13
quagga-0.99.17-1.fc13
root-5.26.00d-2.fc13
ruby-cairo-1.8.5-1.fc13
selinux-policy-3.7.19-54.fc13
setools-3.3.7-7.fc13
system-config-lvm-1.1.15-1.fc13
wmfrog-0.2.2-1.fc13
xrootd-20100315-5.fc13

Details about builds:



 CVector-1.0.3-1.5Aug09.fc13 (FEDORA-2010-13972)
 ANSI C API for Dynamic Arrays

Update Information:

Initial release

References:

  [ 1 ] Bug #545046 - Review Request: CVector - ANSI C API for Dynamic Arrays
https://bugzilla.redhat.com/show_bug.cgi?id=545046




 NetworkManager-0.8.1-6.git20100831.fc13 (FEDORA-2010-14005)
 Network connection manager and user applications

Update Information:

This update fixes an issue with insensitive Enable Networking and Enable
Wireless checkboxes in the network applet and enforces access permissions when
choosing those options.

ChangeLog:

* Tue Aug 31 2010 Dan Williams  - 0.8.1-6
- core: add dispatcher events on DHCPv4 and DHCPv6 lease changes
- core: enforce access permissions when enabling/disabling WiFi and WWAN (rh 
#626337)
- core: listen for UPower suspend/resume signals
- applet: fix disabled Enable Networking and Enable Wireless menu items (rh 
#627365)
- applet: updated translations
- applet: obscure Mobile Broadband PIN in secondary unlock dialog
* Wed Aug 18 2010 Dan Williams  - 0.8.1-5
- core: fix some systemd interaction issues

References:

  [ 1 ] Bug #626337 - non-local user can disable wifi and wwan
https://bugzilla.redhat.com/show_bug.cgi?id=626337
  [ 2 ] Bug #627365 - Enable Networking and Enable Wireless options are grayed 
out in NetworkManager Applet after update
https://bugzilla.redhat.com/show_bug.cgi?id=627365




 PackageKit-0.6.6-2.fc13 (FEDORA-2010-13968)
 Package management service

Update Information:

 - Add a conflict with older selinux-policy to fix fresh installs

ChangeLog:

* Wed Sep  1 2010 Adel Gadllah  - 0.6.6-2
- Add a conflict with older selinux-policy to fix RH#620943

References:

  [ 1 ] Bug #620943 - Require selinux-policy to fix the update issue for new 
installs
https://bugzilla.redhat.com/show_bug.cgi?id=620943




 R-qtl-1.18.7-1.fc13 (FEDORA-2010-14013)
 Tools for analyzing QTL experiments

Update Information:

Update to latest upstream version.

ChangeLog:

* Thu Sep  2 2010 Mattias Ellert  - 1.18.7-1
- New upstream release




 bdii-5.1.8-1.fc13 (FEDORA-2010-14004)
 The Berkeley Database Information Index (BDII)

Update Information:

Update to version 5.1.8.This update fixes an uncaught exception that co

Re: FTBFS triage request

[Bruno Wolff III]

On Thu, Sep 02, 2010 at 23:42:04 +0530,
  Siddhesh Poyarekar  wrote:
> 
> Ok, but what good is a build if it has not been pushed out through
> bodhi? Couldn't we have another option, like successful builds being
> auto-pushed or something? I know that auto-pushing is probably not a
> very good idea but that's the best I can think of right now.

A new build may not be needed. The reason we worry about FTBFS is that if
we need a build (say to handle a soname bump in another package) we want
to be able to be able to do it in a timely manner. So just being able to
build is useful.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Adam Williamson]

On Thu, 2010-09-02 at 12:09 -0700, Scott Doty wrote:

> Anyway, I could say more -- but I've probably already shown how bananas 
> my ideas can be.

It's not bananas, it's just a lot of work that no-one's done yet - well,
actually, it's implemented quite well in Launchpad, but most things
don't use Launchpad. Patches are probably welcome ;) It's definitely
something I'd like to have.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #104: F14 systemd Test Day

[Fedora QA]

#104: F14 systemd Test Day
---+
  Reporter:  adamwill  |   Owner:  adamwill 
  Type:  defect|  Status:  assigned 
  Priority:  major |   Milestone:  Fedora 14
 Component:  Test Day  | Version:   
Resolution:|Keywords:   
---+
Comment (by adamwill):

 Test Day moved to Sept 7th, so it can come before Beta deadline and we can
 use the results to decide whether to go ahead with systemd for beta and
 final. Page moved to
 https://fedoraproject.org/wiki/Test_Day:2010-09-07_Systemd , schedule
 updated.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Scott Doty]

  On 09/02/2010 11:16 AM, Adam Williamson wrote:
>
> There's no guarantee the bug will get closed even if the problem is
> fixed, unless someone else has the same hardware as you and is testing.
> A fix may come down from upstream without being recognized specifically
> as a fix for this particular Fedora bug report - a lot of stuff comes
> down from upstream, and there's no guarantee the kernel team will match
> up every upstream change to Fedora bug reports without assistance from
> testers.

How difficult would it be for BZ to implement some kind of 
"federations"?  Though some projects don't use BZ for bug tracking, I'd 
hope there would be willingness on maintainers of all bug tracking 
software to agree on a protocol for updating each other.

Simply put, imagine if Alice finds a bug at company X.  She files a bug 
report on her company BZ server.

Whoever is handling in-house development sees the bug, sees that it will 
need an upstream fix, and kicks it upstream.  Alternately, she may fix 
the bug, and could kick _that_ upstream, too.

If the fix is made upstream, that info would get passed down to the 
sub-federated servers that subscribe to that component.

Finally -- and this could be postponed until "Version 2" ;) -- each 
component in each distro has it's own newsgroup in a private news 
hierarchy.  This way, if Bob User wants to track the discussion & work 
on a component, he can go read the newsgroup and see all the discussion 
going on.

That's a few rough ideas.  But it seems like a win to use known, tried, 
and true telecommunications protocols to pass discussion traffic around 
-- expecially if Bob User could use an nnrp client to participate in 
said discussion!

Anyway, I could say more -- but I've probably already shown how bananas 
my ideas can be.

Happy Thursday! :)

  -Scott

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Andre Robatino]

Kevin Fenzi  scrye.com> writes:

> > Has it been disabled recently?  
> 
> Short answer: Yes. It has. 
> 
> Longer answer: 
> 
> FESCo looked at trying to use voting data to give us an idea on 'hot'
> bugs that we might be able to send more resources to fix. Sadly, voting
> isn't at all good for this, as people have many votes (100 or 1000, I
> forget which), so it's hard to tell if an issue affects 10 people or
> 100 by that. Many people didn't see the voting interface, so they
> wouldn't have used it even if the problem was severe or affected a lot
> of people. Some people were using the voting interface, even though no
> maintainers ever noticed it (ie, thinking this could help the bug get
> solved, but it's like the maintainer and voter were in seperate worlds
> without any communication). 
> 
> So, we decided it would be less confusing to just disable it. 
> 
> We decided to look into using CC or comments to tell when a bug had a
> lot of people affected or was 'very active'. Unfortunately, this also
> is proving to be difficult to implement. See: 
> https://fedorahosted.org/fedora-engineering-services/ticket/24
> any help there would be appreciated. 

Not that it matters now, but it probably would have been better to allow just
one vote apiece, not an arbitrary number. Having said that, using CC or comments
is probably a better way since it happens automatically. CC might be more
useful, since people can inflate the comment number by posting multiple
comments, but can only CC themselves once.




-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Adam Williamson]

On Thu, 2010-09-02 at 14:56 -0400, Jan Wildeboer wrote:
> IMHO it is an unfortunate decision. But I understand the reasoning.
> 
> Take a look at how google handles this for android.
> 
> Very simple solution which would adapt to our bugzilla like this:
> 
> - once you are logged in to Bugzilla, you can "star" a bug.
> - you can star/unstar at any time
> - so you have as many votes as bugs exist, but only one single vote per bug
> - maintainers/packagers can see the total amount of votes and drill into 
> stuff like "how many stars added in the last 24 hours/week/month
> - you can graph this data and see the "hot spots" of the last day, week, 
> month etc.
> 
> I don't know how hard it is to implement it, but it is a simple, 
> straightforward solution worth thinking of.

That's just the current system except for only allowing one vote per
bug. It doesn't address the other issues, and really, isn't much more
use than just counting CCs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Jan Wildeboer]

IMHO it is an unfortunate decision. But I understand the reasoning.

Take a look at how google handles this for android.

Very simple solution which would adapt to our bugzilla like this:

- once you are logged in to Bugzilla, you can "star" a bug.
- you can star/unstar at any time
- so you have as many votes as bugs exist, but only one single vote per bug
- maintainers/packagers can see the total amount of votes and drill into 
stuff like "how many stars added in the last 24 hours/week/month
- you can graph this data and see the "hot spots" of the last day, week, 
month etc.

I don't know how hard it is to implement it, but it is a simple, 
straightforward solution worth thinking of.

Jan

- Original Message -
From: test-boun...@lists.fedoraproject.org 

To: test@lists.fedoraproject.org 
Sent: Thu Sep 02 11:27:22 2010
Subject: Re: Some or all of your votes have been removed

On Thu, 2 Sep 2010 08:16:00 -0400
Scott Robbins  wrote:

> On Thu, Sep 02, 2010 at 09:29:40AM +, "Jóhann B. Guðmundsson"
> wrote:
> >   Never seen any option for voting on bugs in bugzilla and
> > seriously doubt the use of it's existence because maintainers would
> > ignore that just as well as if you start messing around with the
> > priority levels and severity levels. ( The priority levels are for
> > them to set and use only ).
>
> >
> > But I'm not surprised that your privileges got revoked on this
> > voting system if you went trigger happy on the voting and thus
> > abused it's existence and it's purpose one can even go so far and
> > say you managed to voted your self out of it :)
>
> That's not quite the way it used to work (at least until today.)  One
> has X amount of votes, and could choose to use as many, or as few as
> one, as desired, depending upon the importance, to the individual, of
> the bug.
>
> I imagine someone decided to change the rules, and announced somewhere
> that none of us who were surprised by it look.  'Tain't the first
> time. :)

I'll repost what I posted to devel just a few ago.
Sorry for any confusion. I didn't think it would be sending emails, and
particularly with such a poor subject. ;(

> Has it been disabled recently?

Short answer: Yes. It has.

Longer answer:

FESCo looked at trying to use voting data to give us an idea on 'hot'
bugs that we might be able to send more resources to fix. Sadly, voting
isn't at all good for this, as people have many votes (100 or 1000, I
forget which), so it's hard to tell if an issue affects 10 people or
100 by that. Many people didn't see the voting interface, so they
wouldn't have used it even if the problem was severe or affected a lot
of people. Some people were using the voting interface, even though no
maintainers ever noticed it (ie, thinking this could help the bug get
solved, but it's like the maintainer and voter were in seperate worlds
without any communication).

So, we decided it would be less confusing to just disable it.

We decided to look into using CC or comments to tell when a bug had a
lot of people affected or was 'very active'. Unfortunately, this also
is proving to be difficult to implement. See:
https://fedorahosted.org/fedora-engineering-services/ticket/24
any help there would be appreciated.

kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Adam Williamson]

On Thu, 2010-09-02 at 17:09 +1000, Rodd Clarkson wrote:
> 
> 
> On Thu, Sep 2, 2010 at 4:34 PM, Matthias Runge
>  wrote:
> 
> 
> 
> Although I think, this is the wrong way, putting
> exclude=kernel-*
> in your /etc/yum.conf will exclude the kernel from updating.
> 
> Thanks Matthias,
> 
> I don't like excluding kernels either, but I don't need to be adding
> --exclude=kernel\* to each run of yum update until this is resolved,
> and since there's an open bug for this, I'll know when it's resolved
> because I'm following the bug.  At this time I can allow the new
> kernels again.

There's no guarantee the bug will get closed even if the problem is
fixed, unless someone else has the same hardware as you and is testing.
A fix may come down from upstream without being recognized specifically
as a fix for this particular Fedora bug report - a lot of stuff comes
down from upstream, and there's no guarantee the kernel team will match
up every upstream change to Fedora bug reports without assistance from
testers.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Adam Williamson]

On Thu, 2010-09-02 at 16:24 +1000, Rodd Clarkson wrote:

> Ah, and here I guess lies the problem.  The email from the fedora
> engineers (some weeks ago) quite clearly stated not to give this
> kernel karma points so that it didn't get pushed until they were sure
> it wouldn't cause issues, so I haven't been giving it negative karma
> as a result.

I missed that, but it's really not the right approach. They should
simply have turned off karma automation if they didn't want the update
to be pushed automatically. It's an option when submitting an update.
(I'm not sure if there's still a bug in Bodhi which makes critpath
updates get auto-pushed when they hit the critpath approval threshold,
but I hope not).

> I'm really not happy with this entire process.  I've also received an
> email saying that my 99 votes have been removed because someone at
> fedora decided to change the rules regarding my bug and voting and
> that my votes don't count any more.  What a way to run an election.

There is no election. Bug voting is a feature of upstream Bugzilla which
has no standing in Fedora, it's not officially recognized or monitored
or tracked in any way. It'd probably be easier all round if we turned it
off, but basically, there's no point in voting for Fedora bugs; to my
knowledge, no developers take any account of bug votes.

> Anyhow, what a waste of time all around.  I spend a couple of painful
> hours booting and rebooting my system to try and isolate this bug and
> the developers couldn't take two minutes to mention that they needed
> to post the kernel and that they would address my bug some time soon.

I understand, I'm just trying to explain the situation honestly so you
understand what's going on. I'm not saying I think it's the best
possible process, though it *is* a painful fact that we don't have
enough kernel developers to resolve all kernel issues that are noted in
Fedora.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: FTBFS triage request

[Siddhesh Poyarekar]

On Thu, Sep 02, 2010 at 10:52:48AM -0500, Bruno Wolff III wrote:
> On Thu, Sep 02, 2010 at 19:17:13 +0530,
>   Siddhesh Poyarekar  wrote:
> > 
> > I had just started working on this, but I noticed that in some cases
> > the builds were not pushed as updates. Should these be closed as
> > CURRENTRELEASE?
> 
> When I was getting more time to work on this I was doing things both ways.
> If the maintainer hadn't touched the ticket and there were successful
> builds since the initial report, then I closed the ticket since it was
> clear the package was no longer FTBFS. (Though there might still be
> issues with pushing the version that builds out.)
> 
> However if the maintainer was working with the bug, then I let things
> take their normal course. Typically that would mean being on QA with
> bodhi set to close the bug once the build made it to stable.

Ok, but what good is a build if it has not been pushed out through
bodhi? Couldn't we have another option, like successful builds being
auto-pushed or something? I know that auto-pushing is probably not a
very good idea but that's the best I can think of right now.

--
Siddhesh
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: FTBFS triage request

[Bruno Wolff III]

On Thu, Sep 02, 2010 at 19:17:13 +0530,
  Siddhesh Poyarekar  wrote:
> 
> I had just started working on this, but I noticed that in some cases
> the builds were not pushed as updates. Should these be closed as
> CURRENTRELEASE?

When I was getting more time to work on this I was doing things both ways.
If the maintainer hadn't touched the ticket and there were successful
builds since the initial report, then I closed the ticket since it was
clear the package was no longer FTBFS. (Though there might still be
issues with pushing the version that builds out.)

However if the maintainer was working with the bug, then I let things
take their normal course. Typically that would mean being on QA with
bodhi set to close the bug once the build made it to stable.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

cannot firefox in F14

[Felix Miata]

# yum install firefox
Loaded plugins: fastestmirror, langpacks, presto
Adding en_US to language list
Determining fastest mirrors
rawhide/metalink
 |  13 kB 00:00
 * rawhide: hpc.arc.georgetown.edu
 
http://hpc.arc.georgetown.edu/mirror/fedora/development/rawhide/i386/os/repodata/repomd.xml:
[Errno 14] HTTP Error 404 :
http://hpc.arc.georgetown.edu/mirror/fedora/development/rawhide/i386/os/repodata/repomd.xml

 Trying other mirror.
 rawhide
  | 4.3 kB 00:00
 rawhide/primary_db
  |  11 MB 00:12
 Setting up Install Process
 Resolving Dependencies
 --> Running transaction check
 ---> Package firefox.i686 0:3.6.4-2.fc14 set to be installed
 --> Processing Dependency: xulrunner >= 1.9.2.4-1 for package:
firefox-3.6.4-2.fc14.i686
 --> Processing Dependency: libxul.so for package: firefox-3.6.4-2.fc14.i686
 --> Processing Dependency: libxpcom.so for package: firefox-3.6.4-2.fc14.i686
 --> Running transaction check
 ---> Package xulrunner.i686 0:1.9.3.0-0.1b4.fc15 set to be installed
 --> Processing Conflict: firefox-3.6.4-2.fc14.i686 conflicts xulrunner >=
1.9.2.5
 --> Finished Dependency Resolution
 Error: firefox conflicts with xulrunner
  You could try using --skip-broken to work around the problem
   You could try running: rpm -Va --nofiles --nodigest
   [r...@kt880 ~]# rpm -e --nodeps  xulrunner
   error: package xulrunner is not installed
#

Are FF & XULR out of sync on or missing from mirrors?
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Kevin Fenzi]

On Thu, 2 Sep 2010 08:16:00 -0400
Scott Robbins  wrote:

> On Thu, Sep 02, 2010 at 09:29:40AM +, "Jóhann B. Guðmundsson"
> wrote:
> >   Never seen any option for voting on bugs in bugzilla and
> > seriously doubt the use of it's existence because maintainers would
> > ignore that just as well as if you start messing around with the
> > priority levels and severity levels. ( The priority levels are for
> > them to set and use only ).
> 
> > 
> > But I'm not surprised that your privileges got revoked on this
> > voting system if you went trigger happy on the voting and thus
> > abused it's existence and it's purpose one can even go so far and
> > say you managed to voted your self out of it :)
> 
> That's not quite the way it used to work (at least until today.)  One
> has X amount of votes, and could choose to use as many, or as few as
> one, as desired, depending upon the importance, to the individual, of
> the bug.  
> 
> I imagine someone decided to change the rules, and announced somewhere
> that none of us who were surprised by it look.  'Tain't the first
> time. :)

I'll repost what I posted to devel just a few ago. 
Sorry for any confusion. I didn't think it would be sending emails, and
particularly with such a poor subject. ;( 

> Has it been disabled recently?  

Short answer: Yes. It has. 

Longer answer: 

FESCo looked at trying to use voting data to give us an idea on 'hot'
bugs that we might be able to send more resources to fix. Sadly, voting
isn't at all good for this, as people have many votes (100 or 1000, I
forget which), so it's hard to tell if an issue affects 10 people or
100 by that. Many people didn't see the voting interface, so they
wouldn't have used it even if the problem was severe or affected a lot
of people. Some people were using the voting interface, even though no
maintainers ever noticed it (ie, thinking this could help the bug get
solved, but it's like the maintainer and voter were in seperate worlds
without any communication). 

So, we decided it would be less confusing to just disable it. 

We decided to look into using CC or comments to tell when a bug had a
lot of people affected or was 'very active'. Unfortunately, this also
is proving to be difficult to implement. See: 
https://fedorahosted.org/fedora-engineering-services/ticket/24
any help there would be appreciated. 

kevin


signature.asc
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

F-14 Branched report: 20100902 changes

[Branched Report]

Compose started at Thu Sep  2 13:15:31 UTC 2010

Broken deps for x86_64
--
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
RackTables-0.18.3-1.fc14.noarch requires /usr/local/bin/php
RackTables-0.18.3-1.fc14.noarch requires perl(File::FnMatch)
RackTables-0.18.3-1.fc14.noarch requires perl(Net::Telnet::Cisco)
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10
cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10
fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
gnome-color-manager-2.31.4-1.fc14.x86_64 requires 
libgnome-control-center.so.1()(64bit)
gnome-packagekit-2.31.4-2.fc14.x86_64 requires 
libgnome-control-center.so.1()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10
libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit)
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10
libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit)
libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.i686 requires 
libboost_filesystem-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
libopenvrml-gl-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
libpst-python-0.6.47-4.fc14.x86_64 requires 
libboost_python.so.1.41.0()(64bit)
libvirt-qpid-0.2.18-1.fc14.x86_64 requires libqmf.so.1()(64bit)
libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10
libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit)
matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit)
mine_detector-6.0-3.fc13.x86_64 requires libgnat-4.4.so()(64bit)
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
nautilus-sound-converter-1.0.5-5.fc14.x86_64 requires 
libgnome-media-profiles-3.0.so.0()(64bit)
openvrml-java-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
openvrml-java-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)
openvrml-javascript-0.18.6-1.fc14.x86_64 requires 
libboost_thread-mt.so.1.41.0()(64bit)
openvrml-javascript-0.18.6-1.fc14.x86_64 requires 
libboost_filesystem-mt.so.1.41.0()(64bit)

Re: FTBFS triage request

[Siddhesh Poyarekar]

On Thu, Sep 02, 2010 at 08:29:48AM -0500, Bruno Wolff III wrote:
> On Thu, Sep 02, 2010 at 10:04:50 +0300,
>   Alexander Kurtakov  wrote:
> > Hi testers,
> > This is stronly a developer request.
> > I'm watching the FTBFS list in bugzilla because I'm trying to fix base java 
> > FTBFS using my provenpackager status. But the list currently is more than 
> > 200 
> > bugs which makes it a bit hard to follow. And there are a number of bugs 
> > that 
> > have been fixed by other provenpackagers but they may not be aware of the 
> > FTBFS 
> > bugs.
> > So my request is:
> > Can someone triage the bugs list [1], check whether there are newer builds 
> > in 
> > koji and if there are closing the bug saying that this FTBFS is fixed 
> > because 
> > there is newer bug?
> 
> FES is also doing some work with these. And I think that Matt is going to be
> asked to run his check for these again and if that gets done will probably
> get rid of the bugs that have been fixed.

I had just started working on this, but I noticed that in some cases
the builds were not pushed as updates. Should these be closed as
CURRENTRELEASE?

--
Siddhesh
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: FTBFS triage request

[Bruno Wolff III]

On Thu, Sep 02, 2010 at 10:04:50 +0300,
  Alexander Kurtakov  wrote:
> Hi testers,
> This is stronly a developer request.
> I'm watching the FTBFS list in bugzilla because I'm trying to fix base java 
> FTBFS using my provenpackager status. But the list currently is more than 200 
> bugs which makes it a bit hard to follow. And there are a number of bugs that 
> have been fixed by other provenpackagers but they may not be aware of the 
> FTBFS 
> bugs.
> So my request is:
> Can someone triage the bugs list [1], check whether there are newer builds in 
> koji and if there are closing the bug saying that this FTBFS is fixed because 
> there is newer bug?

FES is also doing some work with these. And I think that Matt is going to be
asked to run his check for these again and if that gets done will probably
get rid of the bugs that have been fixed.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Dennis J.]

On 09/02/2010 02:39 PM, drago01 wrote:
> On Thu, Sep 2, 2010 at 2:27 PM, cornel panceac  wrote:
>>
>>
>> 2010/9/2 drago01
>>>
>>> On Thu, Sep 2, 2010 at 2:17 PM, Dennis J.  wrote:
>>>
 2. Regressions can be easier to fix because you have a "known to work"
 case
 you can use as a comparison. If bugs could be flagged as regression then
 developers you potentially look at these first right after the
 regressions
 occurred and probably identify the reason for the regression right away.
>>>
>>> It isn't that easy as you make it sound (especially for the kernel).
>>> It can up to need a git bisect but that requires being able to
>>> reproduce said bug (which might require hardware that the maintainer
>>> does not have).
>>>
>>>
>> that's one of the many reasons testers' work should not just be discarded.
>
> Where did I say that?
>
>> they have a lot of hardware and a lot of time the developers can not
>> possibly have. also they are more significant as average users since they
>> are not special persons working for special companies. i assumed here that
>> the average user is important, at least as important as a(ny) company.
>
> Well yeah if a tester actually takes the time and run a bisect and
> tells the developer "this bug is caused by commit foo" it would indeed
> be very helpful.
>
> I was just replying to the statement "it is a regression and thus
> easier to fix", which isn't that simply in real world.

Just to clarify I didn't say that a regression *is* easier to fix but that 
it *can be* easier to fix due to the fact that a regression can be flagged 
as such, be pushed to the front of the queue sooner if only for a cursory 
inspection/early triaging by the developer and potentially be resolved 
because said developer still has a recent memory of the changes made.

You'll not be able to solve the problem of dealing with regressions 
completely but you can at least try to improve the process.

Regards,
   Dennis
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[cornel panceac]

2010/9/2 drago01 

> On Thu, Sep 2, 2010 at 2:27 PM, cornel panceac  wrote:
> >>
> > that's one of the many reasons testers' work should not just be
> discarded.
>
> Where did I say that?
>
> > they have a lot of hardware and a lot of time the developers can not
> > possibly have. also they are more significant as average users since they
> > are not special persons working for special companies. i assumed here
> that
> > the average user is important, at least as important as a(ny) company.
>
> Well yeah if a tester actually takes the time and run a bisect and
> tells the developer "this bug is caused by commit foo" it would indeed
> be very helpful.
>
> I was just replying to the statement "it is a regression and thus
> easier to fix", which isn't that simply in real world.
>

it's true. and it was proved impossible to me, but i'm not a developer :)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[drago01]

On Thu, Sep 2, 2010 at 2:27 PM, cornel panceac  wrote:
>
>
> 2010/9/2 drago01 
>>
>> On Thu, Sep 2, 2010 at 2:17 PM, Dennis J.  wrote:
>>
>> > 2. Regressions can be easier to fix because you have a "known to work"
>> > case
>> > you can use as a comparison. If bugs could be flagged as regression then
>> > developers you potentially look at these first right after the
>> > regressions
>> > occurred and probably identify the reason for the regression right away.
>>
>> It isn't that easy as you make it sound (especially for the kernel).
>> It can up to need a git bisect but that requires being able to
>> reproduce said bug (which might require hardware that the maintainer
>> does not have).
>>
>>
> that's one of the many reasons testers' work should not just be discarded.

Where did I say that?

> they have a lot of hardware and a lot of time the developers can not
> possibly have. also they are more significant as average users since they
> are not special persons working for special companies. i assumed here that
> the average user is important, at least as important as a(ny) company.

Well yeah if a tester actually takes the time and run a bisect and
tells the developer "this bug is caused by commit foo" it would indeed
be very helpful.

I was just replying to the statement "it is a regression and thus
easier to fix", which isn't that simply in real world.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[cornel panceac]

2010/9/2 drago01 

> On Thu, Sep 2, 2010 at 2:17 PM, Dennis J.  wrote:
>
> > 2. Regressions can be easier to fix because you have a "known to work"
> case
> > you can use as a comparison. If bugs could be flagged as regression then
> > developers you potentially look at these first right after the
> regressions
> > occurred and probably identify the reason for the regression right away.
>
> It isn't that easy as you make it sound (especially for the kernel).
> It can up to need a git bisect but that requires being able to
> reproduce said bug (which might require hardware that the maintainer
> does not have).
>
>
> that's one of the many reasons testers' work should not just be discarded.
they have a lot of hardware and a lot of time the developers can not
possibly have. also they are more significant as average users since they
are not special persons working for special companies. i assumed here that
the average user is important, at least as important as a(ny) company.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[drago01]

On Thu, Sep 2, 2010 at 2:17 PM, Dennis J.  wrote:

> 2. Regressions can be easier to fix because you have a "known to work" case
> you can use as a comparison. If bugs could be flagged as regression then
> developers you potentially look at these first right after the regressions
> occurred and probably identify the reason for the regression right away.

It isn't that easy as you make it sound (especially for the kernel).
It can up to need a git bisect but that requires being able to
reproduce said bug (which might require hardware that the maintainer
does not have).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Dennis J.]

On 09/02/2010 12:35 PM, "Jóhann B. Guðmundsson" wrote:
> To actually see the extent and identifying problem(s) and regressions (
> you could notice reporting trends with components ) and deal with it
> accordingly we need to gather and make public bugzilla stats for
> components.
>
> Making those stats public ( pretty sure you can easily gather them in
> bugzilla ) is more a political issue then technical one.

What I would like to see is a distinction between regressions and other 
bugs. There are a least two reasons why this might be worthwhile:

1. Regressions break functionality that has been known to work previously 
and the users already rely on. If new stuff gets added and has bugs that is 
not as serious because users are not yet relying on this to work.

2. Regressions can be easier to fix because you have a "known to work" case 
you can use as a comparison. If bugs could be flagged as regression then 
developers you potentially look at these first right after the regressions 
occurred and probably identify the reason for the regression right away.

Regards,
   Dennis
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Scott Robbins]

On Thu, Sep 02, 2010 at 09:29:40AM +, "Jóhann B. Guðmundsson" wrote:
>   Never seen any option for voting on bugs in bugzilla and seriously 
> doubt the use of it's existence because maintainers would ignore that 
> just as well as if you start messing around with the priority levels and 
> severity levels. ( The priority levels are for them to set and use only ).

> 
> But I'm not surprised that your privileges got revoked on this voting 
> system if you went trigger happy on the voting and thus abused it's 
> existence and it's purpose one can even go so far and say you managed to 
> voted your self out of it :)

That's not quite the way it used to work (at least until today.)  One
has X amount of votes, and could choose to use as many, or as few as
one, as desired, depending upon the importance, to the individual, of
the bug.  

I imagine someone decided to change the rules, and announced somewhere
that none of us who were surprised by it look.  'Tain't the first time.
:)


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

rawhide report: 20100902 changes

[Rawhide Report]

Compose started at Thu Sep  2 08:15:32 UTC 2010

Broken deps for x86_64
--
PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so
PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so
PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit)
PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit)
RackTables-0.18.4-1.fc15.noarch requires perl(File::FnMatch)
RackTables-0.18.4-1.fc15.noarch requires perl(Net::Telnet::Cisco)
aldo-0.7.6-2.fc15.x86_64 requires libao.so.2()(64bit)
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
cdrdao-1.2.3-6.fc13.x86_64 requires libao.so.2()(64bit)
claws-mail-plugins-geolocation-3.7.6-5.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gtkmm-0.9.5-1.fc14.i686 requires libclutter-gtk-0.10.so.0
clutter-gtkmm-0.9.5-1.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
clutter-gtkmm-devel-0.9.5-1.fc14.i686 requires 
pkgconfig(clutter-gtk-0.10) >= 0:0.10.2
clutter-gtkmm-devel-0.9.5-1.fc14.x86_64 requires 
pkgconfig(clutter-gtk-0.10) >= 0:0.10.2
cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
eekboard-0.0.5-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit)
emerillon-0.1.2-7.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
entangle-0.1.0-7.fc14.x86_64 requires libmozjs.so()(64bit)
ethos-0.2.2-7.fc15.i686 requires libmozjs.so
ethos-0.2.2-7.fc15.x86_64 requires libmozjs.so()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libedata-book-1.2.so.2()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-1.2.so.17()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libgtkhtml-editor.so.0()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libebook-1.2.so.9()(64bit)
evolution-couchdb-0.4.92-1.fc14.x86_64 requires 
libcamel-provider-1.2.so.17()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit)
evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit)
firstaidkit-plugin-openscap-0.2.14-1.fc15.noarch requires openscap >= 
0:0.6.1-1
flac123-0.0.11-7.fc12.x86_64 requires libao.so.2()(64bit)
frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10
frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit)
gcdmaster-1.2.3-6.fc13.x86_64 requires libao.so.2()(64bit)
gcstar-1.6.1-1.fc15.noarch requires 
perl(GCPlugins::GCfilms::GCThemoviedb)
gjs-0.7.1-3.fc14.i686 requires libmozjs.so
gjs-0.7.1-3.fc14.x86_64 requires libmozjs.so()(64bit)
1:gnome-bluetooth-2.90.0-5.fc15.x86_64 requires 
libgnome-control-center.so.1()(64bit)
gnome-color-manager-2.31.4-1.fc14.x86_64 requires 
libgnome-control-center.so.1()(64bit)
1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gnome-media-2.31.5-5.fc15.x86_64 requires 
libgnome-control-center.so.1()(64bit)
gnome-packagekit-2.31.4-2.fc14.x86_64 requires 
libgnome-control-center.so.1()(64bit)
gnome-shell-2.31.5-5.fc14.x86_64 requires libmozjs.so()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
gthumb-2.11.91-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
gxine-0.5.905-3.fc13.x86_64 requires libmozjs.so()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples
kadu-0.6.5.4-4.fc15.x86_64 requires libao.so.2()(64bit)
libchamplain-gtk-0.6.1-4.fc14.i686 requires libclutter-gtk-0.10.so.0
libchamplain-gtk-0.6.1-4.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
libchamplain-gtk-devel-0.6.1-4.fc14.i686 requires 
pkgconfig(clutter-gtk-0.10)
libchamplain-gtk-devel-0.6.1-4.fc14.x86_64 requires 
pkgconfig(clutter-gtk-0.10)
libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10
libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10
libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit)
libopenvrml-0.18.6-1.fc14.i686 requires libboost_filesystem-mt.so.

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Matthew Miller]

On Thu, Sep 02, 2010 at 04:24:37PM +1000, Rodd Clarkson wrote:
> I'm really not happy with this entire process.  I've also received an email
> saying that my 99 votes have been removed because someone at fedora decided
> to change the rules regarding my bug and voting and that my votes don't
> count any more.  What a way to run an election.

It's not an election. It's a misguided bugzilla feature.

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Jóhann B. Guðmundsson]

  On 09/02/2010 09:56 AM, Dennis J. wrote:
> I think the question is how regressions are prioritized. For me the issue
> is that my Radeon card has been working perfectly on F11 but had a major
> performance regression with F12 that makes the system too slow for regular
> use. I filed a bug with lots of information and a sysprof profile that
> shows extreme differences in behavior between the F11 system and a current
> F14 build but this hasn't been dealt with since I posted that profile.
> The result is that I'm pretty much stuck on F11 for now which is
> frustrating not because I expect any particular fancy features to work but
> because I bought this card since it was so well supported and working
> nicely on F11. Also the mobile version of the same gfx-chip doesn't have
> this issue on my notebook so I have a hunch that this isn't some major
> problem but something that could potentially be solved relatively quickly.

On bug 617683 is one possible explanation on why users suffer hw 
regression with the kernel which hopefully will be discussed and dealt 
with on this years kernel summit.

"This firmware isn't *in* the upstream linux-firmware tree. The author 
of the driver in question has made his driver require a new firmware 
without putting that firmware *anywhere* sensible."

No movement on bug reports does not necessary mean that the bugs are not 
being worked on. Yes in ideal world they would comment on it being 
looked at or what not and it's frustrated that they dont comment on the 
status of the bug in question and actually close bugs when they are 
fixed ( often that's not the case and reports get cleaned up by EOL  
process instead of being closed as FIXED ) however this problem goes 
both ways with reporters not responding to et all or do not respond in 
timely manner to a NEEDINFO request from maintainer, which is real 
problem because finally when the maintainer has reach your bug on his 
priority list ( As I have mentioned before reporters and triagers 
changing priority and severity status on a bug report means nothing to a 
maintainer ) and has time to look at and fix the issue at hand 
everything grinds to a halt because the NEEDINFO has not been responded 
to so he moves on and may or may not put you at the bottom at the stacks 
of reports to deal with.

To actually see the extent and identifying problem(s) and regressions ( 
you could notice reporting trends with components ) and deal with it 
accordingly we need to gather and make public bugzilla stats for 
components.

Making those stats public ( pretty sure you can easily gather them in 
bugzilla ) is more a political issue then technical one.

For one we share bugzilla with Red Hat which I like since I'm using both 
RHEL and Fedora ( I personally would like to keep it that way ) but that 
sharing limits us a bit for doing things like we want it and then it's 
the issue with maintainers may not want to make their good or not so 
good bugzilla stats public..

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[drago01]

On Thu, Sep 2, 2010 at 8:29 AM, Rodd Clarkson  wrote:
>
>> Anyhow, what a waste of time all around.  I spend a couple of painful
>> hours booting and rebooting my system to try and isolate this bug and the
>> developers couldn't take two minutes to mention that they needed to post the
>> kernel and that they would address my bug some time soon.
>
> Anyhow, enough bitching.  It's unlikely to change anything.

To be a bit more productive than bitching ... the most obvious change
in .34 is async suspend/resume does disabling it help your case?

echo 0 > /sys/power/pm_async (as root).

Should disable it.

If that makes your laptop suspend/resume again please add this
information to the bug. (And you can disable it on your system in lets
say rc.local rather than downgrading the kernel).

If it isn't that trying to find the offending driver if any using
pm_trace would be the next step.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[cornel panceac]

2010/9/2 Dennis J. 

> On 09/02/2010 04:18 AM, Adam Williamson wrote:
> > On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote:
> >
> >>
> >> It is however, perfectly reasonable to expect that having tried a
> >> kernel at the request of a fedora developer on fedora-test-list and
> >> then having filed a bug against said kernel reporting problems, that
> >> someone might actually have a few minutes required to actually ask a
> >> few more questions and try and address the problem.
> >>
> >> Otherwise, why did they ask for feedback if it was just to be ignored?
> >
> > To be frank, they don't have time to look at everything, and suspend is
> > a bit of a way down the list. They are aware of your bug - I know
> > because one of the kernel team asked me if I was aware of any problems
> > with 2.6.34 more serious than suspend issues, so obviously they've seen
> > yours, but haven't had time to respond to it yet.
>
> I think the question is how regressions are prioritized. For me the issue
> is that my Radeon card has been working perfectly on F11 but had a major
> performance regression with F12 that makes the system too slow for regular
> use. I filed a bug with lots of information and a sysprof profile that
> shows extreme differences in behavior between the F11 system and a current
> F14 build but this hasn't been dealt with since I posted that profile.
> The result is that I'm pretty much stuck on F11 for now which is
> frustrating not because I expect any particular fancy features to work but
> because I bought this card since it was so well supported and working
> nicely on F11. Also the mobile version of the same gfx-chip doesn't have
> this issue on my notebook so I have a hunch that this isn't some major
> problem but something that could potentially be solved relatively quickly.
>
> What am I supposed to do in this situation? I guess I could spend another
> hundred bucks on a new card but then I don't know if that will loose
> support in the next Fedora release either.
> I think regressions need to be prioritized.
>
> Regards,
>Dennis
> -
>

imho , regressions should not be tolerated unless there' s a serious reason
to. too many times it happened that one thing worked now but no longer
worked in the next version, and this scenario keeps repeating. see k3b, qemu
and gthumb, for some examples. also there are outstanding bugs, linux kernel
related which are simply ignored. (like the inability to read from bios
which hard disk is first, or the recently fixed security hole.) of course
development means trying new things all the time, but why this is happening
on releases labeled as stable, is beyond my ability to understand.

-- 
Among the maxims on Lord Naoshige's wall, there was this one: "Matters of
great concern should be treated lightly." Master Ittei commented, "Matters
of small concern should be treated seriously."
(Ghost Dog : The Way of The Samurai)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Jóhann B. Guðmundsson]

  On 09/02/2010 09:43 AM, Frank Murphy wrote:
> I got one two, a 1 vote removed.
> I only ever passed  comments on bohdi?

Are we talking about of voting in bugzilla or in bodhi ( or some other 
place ).

I've never used nor ever seen any kind of option to vote in bugzilla so 
I'm a bit curious where that option is supposed to reside?

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Dennis J.]

On 09/02/2010 04:18 AM, Adam Williamson wrote:
> On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote:
>
>>
>> It is however, perfectly reasonable to expect that having tried a
>> kernel at the request of a fedora developer on fedora-test-list and
>> then having filed a bug against said kernel reporting problems, that
>> someone might actually have a few minutes required to actually ask a
>> few more questions and try and address the problem.
>>
>> Otherwise, why did they ask for feedback if it was just to be ignored?
>
> To be frank, they don't have time to look at everything, and suspend is
> a bit of a way down the list. They are aware of your bug - I know
> because one of the kernel team asked me if I was aware of any problems
> with 2.6.34 more serious than suspend issues, so obviously they've seen
> yours, but haven't had time to respond to it yet.

I think the question is how regressions are prioritized. For me the issue 
is that my Radeon card has been working perfectly on F11 but had a major 
performance regression with F12 that makes the system too slow for regular 
use. I filed a bug with lots of information and a sysprof profile that 
shows extreme differences in behavior between the F11 system and a current 
F14 build but this hasn't been dealt with since I posted that profile.
The result is that I'm pretty much stuck on F11 for now which is 
frustrating not because I expect any particular fancy features to work but 
because I bought this card since it was so well supported and working 
nicely on F11. Also the mobile version of the same gfx-chip doesn't have 
this issue on my notebook so I have a hunch that this isn't some major 
problem but something that could potentially be solved relatively quickly.

What am I supposed to do in this situation? I guess I could spend another 
hundred bucks on a new card but then I don't know if that will loose 
support in the next Fedora release either.
I think regressions need to be prioritized.

Regards,
   Dennis
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Frank Murphy]

On 02/09/10 10:29, "Jóhann B. Guðmundsson" wrote:

> But I'm not surprised that your privileges got revoked on this voting
> system if you went trigger happy on the voting and thus abused it's
> existence and it's purpose one can even go so far and say you managed to
> voted your self out of it :)
>
> JBG

I got one two, a 1 vote removed.
I only ever passed  comments on bohdi?

-- 
Regards,

Frank Murphy
UTF_8 Encoded
Friend of Fedora
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some or all of your votes have been removed

[Jóhann B. Guðmundsson]

  Never seen any option for voting on bugs in bugzilla and seriously 
doubt the use of it's existence because maintainers would ignore that 
just as well as if you start messing around with the priority levels and 
severity levels. ( The priority levels are for them to set and use only ).

But I'm not surprised that your privileges got revoked on this voting 
system if you went trigger happy on the voting and thus abused it's 
existence and it's purpose one can even go so far and say you managed to 
voted your self out of it :)

JBG
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Some or all of your votes have been removed

[Kamil Paral]

Bugzilla has disabled voting, or what is it? Anyone knows?

I no longer see any option to vote for a bug.

- Forwarded Message -
From: bugzi...@redhat.com
To: kpa...@redhat.com
Sent: Thursday, September 2, 2010 5:29:30 AM GMT +01:00 Amsterdam / Berlin / 
Bern / Rome / Stockholm / Vienna
Subject: Bug 541230 Some or all of your votes have been removed.

Some or all of your votes have been removed from bug 541230.

You had 50 votes on this bug, but 50 have been removed.

You have no more votes remaining on this bug.

Reason:
  The rules for voting on this product has changed; you had
  too many total votes, so all votes have been removed.


https://bugzilla.redhat.com/show_bug.cgi?id=541230
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Andre Robatino]

Rodd Clarkson  clarkson.id.au> writes:

> Ah, and here I guess lies the problem.  The email from the fedora engineers
(some weeks ago) quite clearly
> stated not to give this kernel karma points so that it didn't get pushed until
they were sure it wouldn't cause > issues, so I haven't been giving it negative
karma as a result.

The email probably said not to give _positive_ karma (the only kind that
triggers a push) immediately, so people with problems would have a chance to
provide negative karma first. I doubt there's ever a good reason to delay
negative karma, when it's clear that a bug exists.





-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Rodd Clarkson]

On Thu, Sep 2, 2010 at 4:34 PM, Matthias Runge wrote:

>
> Although I think, this is the wrong way, putting
> exclude=kernel-*
> in your /etc/yum.conf will exclude the kernel from updating.
>

Thanks Matthias,

I don't like excluding kernels either, but I don't need to be adding
--exclude=kernel\* to each run of yum update until this is resolved, and
since there's an open bug for this, I'll know when it's resolved because I'm
following the bug.  At this time I can allow the new kernels again.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

FTBFS triage request

[Alexander Kurtakov]

Hi testers,
This is stronly a developer request.
I'm watching the FTBFS list in bugzilla because I'm trying to fix base java 
FTBFS using my provenpackager status. But the list currently is more than 200 
bugs which makes it a bit hard to follow. And there are a number of bugs that 
have been fixed by other provenpackagers but they may not be aware of the FTBFS 
bugs.
So my request is:
Can someone triage the bugs list [1], check whether there are newer builds in 
koji and if there are closing the bug saying that this FTBFS is fixed because 
there is newer bug?

E.g. There is http://koji.fedoraproject.org/koji/buildinfo?buildID=186292 and 
there are https://bugzilla.redhat.com/show_bug.cgi?id=565168 and 
https://bugzilla.redhat.com/show_bug.cgi?id=599752. So these bugs have been 
fixed but the bugs are still open.

If someone thinks that this is not the right approach just say so.

Thanks in advance,
Alexander Kurtakon

[1] 
https://bugzilla.redhat.com/query.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&product=Fedora&query_format=advanced&short_desc=FTBFS&short_desc_type=allwordssubstr&known_name=FTBFS
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test