devel April 2010

devel@lists.fedoraproject.org

238 participants
262 discussions

Re: Upstream bugs vs. Fedora bugs: KDE people do it wrong
by Oliver Falk 31 Mar '10

31 Mar '10

I had similar issues already and I totally agree with Christoph! The maintainer should not redirect the bugreporter to the upstream bugreporting plattform. I already have plenty of accounts on upstream bugzillas because of exactly this... -of Christoph Wickert <christoph.wickert(a)googlemail.com> schrieb: >I am irritated by the way the KDE SIG and the KDE bugzappers handle >bugs. For most bugs that are reported they demand the reporter to file >an upstream bug report at bugs.kde.org and set the bug to NEEDINFO. If >the reporter doesn't respond, the bug is closed NOTABUG or WONTFIX. But >if the bug has been reported upstream, the Fedora bug gets closed >UPSTREAM. Ether way, the bug gets closed, no matter if it was actually >fixed or not. > >IMHO filing bugs upstream is a maintainers duty. We are doing the same >in Xfce or I do the same with all my packages. The only exception I make >are feature requests, because I cannot support a request that I don't >understand or that I am not convinced of. The use of a feature should be >discussed upstream with the developers because they are in no way >specific to the distribution, but bugs that affect Fedora need to be >tracked in Fedora. > >The wiki says: >> Deal with reported bugs in a timely manner >> * [...] >> * If there are bugs which you aren't capable of fixing yourself >> because they deal with intricacies of the source code which >> you don't fully understand, then you still need to address >> these bugs. It can be helpful to work with the upstream >> maintainer of the code, obtain help from more code-oriented >> people on fedora-devel, or check other distributions for >> patches. Always be sure to post to the bug report what you >> have done so that the reporter knows what it happening and >> what to expect. It is recommended that non-coder packagers >> should find co-maintainers who are familiar with the >> programming language used by their package(s), and can help >> with such bugs as a kind of 'second line support'. > >https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_wit… > >The Fedora KDE maintainers and bugzappers already have a KDE bugzilla >account, while most of our users don't. Thus it is easier for them to >file the bug than it is for the user. The maintainer has to act as a >proxy between the reporter and the developer. > >By closing down the bugs, our bugzilla is effectively rendered useless >because there is no way of searching for bugs that affect our KDE >packages. Bugzilla is for tracking bugs, not for blindly closing bug >reports no matter if they are fixed or not! > >I'd like the KDE SIG and their bugzappers to reconsider their policy: > 1. Forward bugs to the upstream developers > 2. Leave bugs open until they are fixed upstream and in Fedora > >Regards, >Christoph > >-- >devel mailing list >devel(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel

20 73

[Test-Announce] F-13-Beta Go/No-Go Meeting @ 2010-04-01 00:00 UTC (2010-03-31 @ 8pm EDT)
by James Laska 31 Mar '10

31 Mar '10

# F-13-Beta Go/No-Go meeting # Date: 2010-04-01 # Time: 00:00 UTC (20:00 EDT, 17:00 PDT) # Location: #fedora-meeting on irc.freenode.net Before each public release Development, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the: Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. Release Criteria are set for each public release and are found at https://fedoraproject.org/wiki/Fedora_Release_Criteria For more details about this important meeting see https://fedoraproject.org/wiki/Engineering_Readiness_Meetings To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto Thanks, James _______________________________________________ test-announce mailing list test-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel April 2010