From time to time, I see trivial patches posted in bugzilla which end
up sitting there because the maintainer is too busy / gets bombarded
with tons of bugzilla mails and misses that particular one / whatever
reason. As a packager, sometimes it seems very hard to get such trivial
patches applied. What you can do is
- You can keep pinging bugzilla
- You can apply for commit rights, which might be excessive for just
this one patch, and still requires the maintainer to answer.
- You can start the non-responsive maintainer procedure, even if you
know perfectly well that the maintainer is still active. Or you might
suspect that the maintainer is inactive, but you'd rather not have to
wait for an entire month, because this one bug is blocking your work.
- You can start asking on irc for a proven packager to jump in and hope
a proven packager is online and has time at that moment.
- You can post on -devel, though again, unless someone has time right
now it gets forgotten an people move on.
- Repeat the above n times until someone shouts at you and flags your
email as spam :)
So wondering, if there is a way we can improve the situation. One idea
which comes to mind would be something like "trivial patch policy"
- after i.e. one week of inactivity one can flag such a bug as a trivial
bug. You can only do so if you are a packager and post a patch (which
also updates the SPEC, so just a matter of apply patch, fedpkg commit &
- for anything else than packaging issues, the patch may only be a well
justified upstream commit backport
- a proven packagers gets notified about the issue, validates the patch
and if ok fires the update. The entire thing might work similar to how a
New Package / Package Change request works, by posting something like
this to the bug:
Trivial Patch Request
From my experience such situations do not occur too frequently, but
when they happen, they can be hard to deal with.
My name is David Nichols, and I'm the author of the Qore programming language.
I've recently made a package submission request to Fedora for Qore, which is under review here: https://bugzilla.redhat.com/show_bug.cgi?id=1111691
I've been running fedora (and before that redhat) for many years, and use fedora and redhat extensively at home and at work.
I've been packaging qore with RPM for many years, but now I'm getting into Fedora-specific packaging, and have found that my RPM skills were out of date and, even though I've been providing 3rd-party RPMs for Fedora for many years, I have found through the review process that I had a lot to learn.
Fortunately there is a lot of documentation, and also I've gotten a lot of constructive advise in the qore review.
My goal is to become the maintainer of Qore for Fedora, and since I'm responsible for upstream development as well, I can make sure that the Fedora packages remain high-quality.
I hope everyone who has read this far has a great day :)
= Proposed System Wide Change: Replace Yum With DNF =
Note: This is Fedora 22 proposal!
Change owner(s): Aleš Kozumplík <kozumplik(a)gmail.com>
Make DNF/Yum4 the new default packaging tool in F22.
== Detailed Description ==
DNF was forked from Yum in January 2012 and available for experimenting in
Fedora since release 18 . The project is now fully capable of replacing Yum
in new Fedora installations. We want DNF to become the new default packaging
tool in Fedora 22. This entails:
* letting system administrators (including users who routinely manage their
packages using the legacy Yum) perform all common packaging operations using
DNF, with no or minimal and documented  change to the command syntax, apart
from replacing the command name. (done)
* providing implementation of Anaconda backend so system can be bootstrapped
completely without using legacy Yum. (done)
* providing alternative to all Yum plugins from yum-utils (ongoing)
* providing alternative to all release engineering tools (repoquery, bodhi
etc.) from yum-utils (ongoing)
* being ready/having the capacity to help out users with migration of their
custom legacy plugins and extensions to DNF. The solid API documentation 
we provide is of great advantage here. (ongoing)
In practice, the change implies:
* Anaconda installs the system using the DNF backend (with no special
* package 'dnf' is installed by default (referenced by the base comps groups)
* package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum
and provides its own <code>/usr/bin/yum</code>, a short script that redirects
to <code>/usr/bin/dnf</code> with an appropriate warning message that DNF is
the preferred package manager now. Notice that upgrading F21 to F22 will not
cause the compat package to be installed so will not disturb any upgrading
== Scope ==
This change will be completely transparent for users that use only the
graphical package management tools. For anybody using the command line
directly there will be some differences, but all the important operations are
available with DNF, using the same CLI syntax.
* Proposal owners: The majority of tasks on this change are completed. Some
plugins and API calls still need to be added. The Anaconda payload
implementation needs more testing, Fedora Test Day for this is pending.
* Other developers: We provide the paylaod implementation for Anaconda
developers. Developers of other extensions and developers of plugins that are
not part of yum-utils will have to update their code.
* Release engineering: Release engineering tools that are internal to the
releng teams and not part of yum-utils will need modifications to migrate to
the DNF API.
* Policies and guidelines: None at the moment.
devel-announce mailing list
I'm a mule developer and fedora user. Recently, I noticed that the version
of mule packaged with fedora is not only very behind the current upstream
version but it is also orphaned. I'd like to take over maintaining the
packaging of mule on fedora if there are no objections.
After going through the thread, a revelation, a deep understanding
occured. There is always a confusion regarding Linux, why does it not
get popular even when being the best (Am Beston;) OS in the whole
Universe. <OMG>, it was not renamed even once since the nineties even
when the hole f^%(*g thing was qoverhowled a million times. <OMG>
The hole f^%(*g thing things should be renamed:
Cat has changed its codebase by around 87.73% since it was last
christened cat & does not justifies anymore to be called cat. Some
These are just some samples, Feel free to append your own. The whole OS
along with all its binaries, packages etc need a naming over hole.
Thank you very much for your precious time.
Mucchaas Gracias, Great Going down the drain. Splosh.....
# Fedora Quality Assurance Meeting
# Date: 2014-06-30
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location:
#fedora-meeting on irc.freenode.net
This is a reminder of the upcoming QA meeting. Please reply to this
mail with any suggestions for additions to the agenda.
The current proposed agenda is included below. If no topics beyond the
standard "Previous meeting follow-up" and "Open Discussion" topics are
present or proposed, the meeting will be cancelled.
== Proposed Agenda Topics ==
1. Fedora 21 Status Updates
A. Blocker Status - Count and Any especially worrysome ones?
B. roshi and/or pschindl report on Test Days - See Action Item
from 2014-06-09 meeting notes
C. Rawhide Testing Status
2. Taskotron Discussion
A. Status Report
B. bodhi2 integration discussion?
3. Alpha Release Related Items ??
4. Open Floor
Anyone with additional agenda items please respond to the mailing list
this weekend. If you hit send after 0400 Monday they probably won't
make the meeting and you'll have to raise them during Open Floor.
test-announce mailing list