Re: Self Introduction : Marianne Lombard
Heya ! Welcome here and I'm glad that you finally jumped onboard :) Feel free to ping me if you're looking for a sponsor. best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
2014-04-22 16:10 GMT+02:00 Máirín Duffy du...@fedoraproject.org: To be honest, I'm fairly uncomfortable discussing this without Fedora Legal weighing in. I don't see any problem with re-visiting the decisions made along this path, but I also am pretty confident the folks who decided things had to be this way are really smart and had good reasons. ~m Well, we may end up lawyered by Legal, but I think it's good we try to realign ourselves and clear up few misunderstandings. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging of libdb-6+
Since AGPL is fedora-compliant license, there's no blocker to get libdb6 into packages collection. Besides, libdb5 is still critical for many packages (like RM), until we get rid of it, I can only agree with your proposal. Maybe, it's still time to rename the current libdb = libdb5 and get newer releases named libdb starting F21 best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Apache Mesos
+1 Mesos is definitively an asset for the Fedora Cloud Product and would fit in some of our use cases. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yet another bug caused by SELinux
2014-03-20 12:22 GMT+01:00 Kevin Kofler kevin.kof...@chello.at: Hi, GHC (Haskell) was broken for (at least) over a year because of a bug in the workaround for stupid SELinux restrictions: https://ghc.haskell.org/trac/ghc/ticket/7629 https://bugzilla.redhat.com/show_bug.cgi?id=907515 How much breakage will we have to suffer until people finally realize that SELinux is a horribly flawed idea? Kevin Kofler PS: Et ceterum censeo SELinux esse delendum. Hi, according to the RHBZ ticket, there was a fix but it was not timely applied to the package. Rather than SELinux, I'd say that the fault lies with the crazy updates policy that plague us. regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)
Hi, I don't think that worrying about perpetuating offensive stereotypes is specifc to the US, we have similar controversies in Europe: http://en.wikipedia.org/wiki/Banania#Controversy http://en.wikipedia.org/wiki/Zwarte_Piet#Controversies Anyway, the line between what is acceptable and unacceptable in Fedora should be that no one should be offended by something that directly refers to him or his origins in a negative or hurtful way. I have no opinion about the Cherokee logo, as an European citizen, it looks to me very innocent (a little child playing) but if it offends native americans, it should be fixed anyway. my 2 cts, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: AFK notice
Hi, I'm back. 2014-02-22 11:19 GMT+01:00 Matthias Runge mru...@matthias-runge.de: Does that also mean, you're changing jobs? You mentioned something like you're at least interested in a jobs at Red Hat in the cloud area? Sadly enough, I haven't changed jobs, yet. I can't dwell upon this topic on a public list (some fellow fedoristas know my situation), but I'm in deep shit. I'm still looking for either a developer or technical evangelist position preferably in the cloud area, but due to personal circumstances, I have one major constraint: being home-based (travelling is not an issue). Well, I'm also a FOSS Fedora BAKA (idiot, passionate, whatever) which also doesn't help at all. @everyone: if by knowing that, you may be interested in considering me for a position, feel free to contact me: linkedin: http://linkedin.com/in/hguemar Best wishes, I hope everything will work out well for you, Matthias -- Matthias Runge mru...@matthias-runge.de Thanks, I appreciate your kindness. The same goes for all my Fedora Friends who are helping me to go through these tough days :) best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Creating local repo
Use createrepo, its man page should be more than enough. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: State of Python 3 as default in Fedora
About boto: Mitch Garnaat (upstream maintainer) is focusing on botocore and awscli, botocore is a rethinking of boto low-level plumbing which is python3 compatible. In the long run, boto3 will be based upon botocore and support python3. I have packages of botocore and awscli, i still have to finish packaging properly a few dependencies. regards, H. 2014-02-12 13:52 GMT+01:00 Miro Hrončok mhron...@redhat.com: Hi, I've just published a blogpost that summarizes what's going on with Python 3 as default in Fedora. You can find it here: http://eng.hroncok.cz/2014/02/12/python3-fedora-default/ Feel free to post any comments on my blog or here on the mailing list(s). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: advertisement in packaged software (e.g. Firefox)
My *personal* opinion is that we should disable this kind of feature by default. Actually, unless it tracks users, i don't think that our guidelines forbids it, though it may influence our choice for the packages set installed by default. Has anyone tried to contact Mozilla Corporation about it so we may discuss this based on facts ? H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: State of Python 3 as default in Fedora
About boto: Mitch Garnaat (upstream maintainer) is focusing on botocore and awscli, botocore is a rethinking of boto low-level plumbing which is python3 compatible. In the long run, boto3 will be based upon botocore and support python3. I have packages of botocore and awscli, i still have to finish packaging properly a few dependencies. regards, H. 2014-02-12 13:52 GMT+01:00 Miro Hrončok mhron...@redhat.com: Hi, I've just published a blogpost that summarizes what's going on with Python 3 as default in Fedora. You can find it here: http://eng.hroncok.cz/2014/02/12/python3-fedora-default/ Feel free to post any comments on my blog or here on the mailing list(s). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Fedora.NEXT Products and the fate of Spins
I'm not fond of keeping spins around when we're focusing on products. That gives the message that they are second-class citizens in Fedora. I'd rather define a process that allows current spins to become either sub-products or full-featured products when they meet a set of requirements (that is to be defined yet). In a contributor-driven community, it shouldn't be a problem to accept new products if it is backed appropriately. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
It's also a negative message to the 1.4 k active contributors in fedora. Or do you assume that most of them are paid by RH which is unlikely. Don't forget that fp.o has been founded with two stakeholders: RH and the community H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
I disagree about keeping spins around in the long term. Current spins: * hinders our communication (each spin is supposed to get proper coverage from marketing, ambassadors etc.), some users think that actually installing KDE requires reinstalling from the spin ! * prevents spins with a striving community [1] to get proper love from the project. One of the main point of the product is to get *more* QA, *more* polish, *more* communication than our current offering. If a SIG is able to sustain a long-term effort in that direction, they deserve to be a product ! About the desktop spins, i think they should be considered as sub-products as it will requires some coordination between all the desktop folks for some features. * demoting spins to remixes won't prevent them to ship installable images, to get support from other SIG (ie: design) but they won't get coverage from marketing and ambassadors. We can't afford having products, spins and remixes, that's just a waste of efforts and we're lacking in manpower already. Sustainable spins should become (sub-)products, the others remixes. Until we can sort out the process for the maintained spins to become (sub-)products, we should keep them for convenience but no longer. One more thing, commitment is the only metric we should consider for promoting a (sub-)product, i don't give a shit about having people paid to work on that (no offense meant here). No matter who our employers are, it should *NEVER* matter in Fedora, we're all contributors. PERIOD H. [1] I think KDE SIG, I'm no user of the K Desktop but kudos guys for making Fedora a choice distro for KDE users. You did great ! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. btw, it wouldn't be wise to define that process while we're still in Fedora.Next early stages, it'll just had more entropy. First we should work to release our sample products, then use that experience to define the process to bring a new product. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Hi, I agree that we can't support more than a limited number of products. The point is to make a validation process sufficiently strict so we can guarantee that the would-be product would be sustainable. After all, if there are people willing to maintain it on the long term *and* our infrastructure can handle it (rel-eng, QA, etc.), why should we prevent them ? H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: self introduction - hoping to be a packager
Hi, thank you for taking the time to join us. If you want to speed things up, I'd suggest that you start doing informal reviews of other pending reviews and when you're done, link them to your review. Many sponsors will ask you that to assess your packaging knowledge anyway, just do it and do it consciously. Think of it as the fast lane to find a sponsor. best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Environment and Stacks PRD
Ruby collections ? Did you mean SCL ? At the moment, the cloud WG hadn't discuss any other options. We're not the only stakeholders on that matters, these are topics requiring collaboration with other WG. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
/me wants the ability to push force on *private* branches 2014/1/15 Dridi Boukelmoune dridi.boukelmo...@gmail.com On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch vondr...@redhat.com wrote: Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a): I have some trivial cleanups I want to make to a package a maintain. These cleanups are trivial enough that I don't think they're worth a new build. Should I commit them to the master branch? If so, I can imagine a couple of issues: - A provenpackager could kick off a rebuild for whatever reason (e.g. dependency soname bump). That will (I think) inadvertently include my changes. - I need to think about whether to add a changelog entry or not. If not, those changes might be included silently. If yes, then I need to think about what to do about the revision number. The normal GIT approach would be to develop on another branch and to merge when I want to build a new revision (the Fedora equivalent of tagging a new release). Should Fedora provide branches like master-devel, f20-devel, etc that store pending changes? Am I missing something really obvious here? --Andy Actually I'd really love to see some possibility for private branches. Now, it is possible to push whatever branch (take it literally) you have in your local git repo into dist-git, but there is no way how to delete it by myself. For example, I am using branches to keep my .spec file aligned with upstream development and I'd like to share it with other maintainers. But this .spec file should never build in Rawhide unless it is approved by FESCo. Could you please add support for private branches? I.e. the branch which starts by private- prefix could be pushed and deleted as well, non ff commit should be allowed. Actually, better would be if only master, fxx and elx are protected and others are unrestricted, but I am probably asking too much. For private branches I'd rather see something along fas/branch. With the '/' separator you can glob refspecs, and using your fas as a prefix could enable automatic acls with less pain on the infrastructure side (eg. allow anyone to manage and own private branches at will). Dridi Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Inter-WG coordination: Stable application runtimes
only over my dead body i would start wrap more and more layers on top of already virtualized infrastructures Containers have little to almost no overhead, they bring more isolation (and i can't wait docker/selinux integration for more security), the FS layered approach allows to save spaces. Yeah, leveraging containers is a waste of time ... I agree with Nicolas, containers are still immature at the moment, but that's part of our mission as fedoraproject.org to make such technologies mature and bring them to rock-solid. best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Inter-WG coordination: Stable application runtimes
My apologies if you felt i misquoted you, i didn't intend that. I do plenty of SaaS deployments at $DAYJOB, and i can easily pack hundreds to thousands // running containers on a single machine. Remember that Fedora is on the innovative side of the distro spectrum, yes vhost is the present, but containers is the *future*. Even the enterprise distro are betting their chips on containers (SLES and Ubuntu have LXC commercial support, RHEL/Docker partnership, etc.) As part of the Cloud WG, it's something we definitively want to support and are looking on how we could leverage it (both this and Software Collections) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox Gtk3 test package
What's the point ? There's absolutely no benefit in keeping Gtk+2 longer. Gtk+ 2.24.0 has been released 3 years ago (january, 2011) and is only receiving bugfix due to existing apps who didn't move to Gtk+3. By migrating more apps, we can drop Gtk+ 2.24 (at least from images), firefox is one of the major application that prevents us to do so. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox Gtk3 test package
2014/1/14 Daniel P. Berrange berra...@redhat.com In fact Fedora still ships GTK *1*. If we can't even get rid of GTK1, then talk of killing GTK2 seems wildly over optimistic. Regards, Daniel I'll quote myself again: at least from base images , not removing it from repositories. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
Hi, there's a draft, i suggest that you start checking it. http://fedoraproject.org/wiki/PackagingDrafts/Go Taking a peek at Debian and OpenSuSE Go guidelines might be worthy: http://pkg-go.alioth.debian.org/packaging.html http://en.opensuse.org/openSUSE:Packaging_Go Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Go packaging guidelines?
My apologies for linking opensuse guidelines, i missed that point in your mail. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
This discussion has now reached the phoronix point http://www.phoronix.com/scan.php?page=news_itempx=MTU2MTE Has anyone filed any tickets so we could move forward or will we continue wasting time here ? Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Congratulations for lowering the level of this discussion even lower than it already was ! H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction
Welcome in Fedora :) Out of curiosity, are you only packaging it or also developing it ? Anyway, it will be a useful library (no trolling about the rdrand instruction ;)) Best regards, H. Le 5 janv. 2014 21:14, Jan Tulak jtu...@redhat.com a écrit : Hi all I'm an IT university student. With Fedora I have a total experience about half a year, my primary distribution is Archlinux (about four or five years experience). Currently, I'm preparing a Fedora package as part of my bachelor thesis: A library for RdRand (the instruction used in Ivy Bridge and newer Intel CPUs for generating random numbers). Regards Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ambassadors places in new Working Groups
2013/10/28 Jóhann B. Guðmundsson johan...@gmail.com On 10/27/2013 11:34 AM, Nobrakal wrote: 2013/10/27, Frank Murphyfrankl...@gmail.com: On Sun, 27 Oct 2013 19:05:37 +0800 Christopher Mengcicku...@gmail.com wrote: It seems that most of members from the new formed groups are working for Red Hat. Well it's helpful to strengthen our technical base but are there any plots for other people? Well, if I believe this ticket [1]: Each working group should be comprised of no more than half (rounded up) of Red Hat employees. This is to avoid the misconception that Red Hat is dictating the planning here. That a good rule. That rule did not get approved by fesco quite the opposite + FESCO members they themselves where supposed to be the ones that selected initial members for the WG but they did not do so for all groups as in the Workstation WG initial selection was conducted by Josh Boyer ( former FESCO member,board kernel and what not everybody should know him ) as well as the Base WG was selected by Phil Knirsch, which is entirely unassociated with fesco afaik but is (co)-maintaining bunch of obsoleted stuff there in the base/core OS. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-**of-conducthttp://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ambassadors places in new Working Groups
Hi, Fesco is entitled to delegate their authority to anyone they see fit to do so. For instance, FPC members are designated by Fesco and rule packaging guidelines. Besides, the final decision was taken by Fesco. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Ambassadors places in new Working Groups
Hi, Thanks for your concern on that topic, off course, fedora.next would be an half-assed initiative if we forget communication and community mgmt. And i'm pretty sure that everyone here agrees with you on that point. As for myself, I also intend to represent users inside the Cloud WG, so i'll be glad to serve as a liaison officer with both Ambassadors and Marketing groups. I can't speak on the behalf of cwickert, but as one of the most supportive member of the Ambassadors group, I'm confident that he'll do an outstanding job -as usual- on that matter best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Ambassadors] Ambassadors places in new Working Groups
Hi, I think that coordinators and Fesco tried to integrate as much as possible community members. But truth is that most people who self-nominated were RH employees, so i'd rather say that RH employees even had an handicap. As for the Cloud WG -i can't speak for other WG-, we wish that non-voting members are integrated as much as possible in defining the future of Fedora in the clouds. We can't do everything and we don't intend to close the door to anyone. Remember that we're just kickstarting a major overhaul on how we think and build Fedora, these WG are only there to lead the definition of our products in the open and keep the process focused. Either i would have been appointed into the Cloud WG or not, i would have participated anyway in that effort. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: python-urlgrabber, yum: blatant disregard for packaging guidelines and common sense
Hi, Thank you for sharing that sad issue :( i wish that we could review regularly all packages but that's obviously not feasible. What is doable: * automated review of packages: git hooks ? regular mass fedora-review checks ? triggering a mail to a list ? our scm watchdogs do a great job at spotting some mistakes at specs might be worthy to try. * randomly choosing a number of packages every release and make them reviewed by volunteer packagers ? When common core/products plan will be active, we could focus on a smaller set of packages to improve packaging consistency (that's one of the benefits of reducing our scope) H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EOL] Retiring Gazpacho from F20+
Hi, since Gazpacho hasn't been maintained fro years and it requires an older version of python-kiwi than currently packaged in F20, i'm retiring. It has been superseeded by Glade 3 and no other packages should require it. Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 14 branching and dist-git roll out
git branch -a will show you all branches (remote included) Until fedpkg is updated, to track any remote branch other than master (ie: F-13): git checkout -b f13 remotes/origin/F-13 Then, you juste have to do for switching: git checkout my_branch Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unsafe Django version being pushed to stable
Just one thing, the title is misleading since Django 1.2.x is not an unsafe version. So what's the plan ? The update was also pushed in previous release like F12. Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Take over package I approved
I agree with Kevin on this one. Since Josef Radinger (fas: Cheese) is already a sponsored maintainer and the package legibly and properly accepted into packages collection, it should fall under the non responsive maintainer policy. We're already short on reviewers not to waste time over petty issues. https://admin.fedoraproject.org/pkgdb/users/packages/cheese H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request: Magit 0.8 packaging
magit is already packaged as emacs-magit https://admin.fedoraproject.org/pkgdb/acls/name/emacs-magit Check this with the maintainer, if you're interested by maintaining it, ask co-maintainership. best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
And so what ? In OpenArena's case, last stable releases were: * 0.8.5: 02/23/2010 * 0.8.1: 10/31/2008 You can't blame OpenArena's maintainer for that, do you ? The same goes for Wesnoth, 1.8.1 maintenance release was issued 2 May so less than two weeks ago (1.8 was released 1st april !) Best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 continuing the tradition of being an update monster
It is not part of a default package set. Even if it were, blocking bugfixes in order to reduce updates size is nothing but stupid. We have presto/deltarpm for that (since these packages mostly contain unchanged binary data like images, it should work pretty well). What's the point in having new updates policies, if we replace the previous updates craze by a more vicious stable updates frenzy ? H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: use MALLOC_PERTURB_ ... or lose
This is useful enough that it is worth considering for inclusion in /etc/profile. during development cycle: +1 for stable/production release: not so much (users would hate us for that) regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages, retiring from Fedora packaging
@Dennis: i appreciated your work on the Gtkmm stack. took : gtksourceviewmm;, libnotifymm, gstreamermm, libxml++, libgda, bakery, glom btw, libgnomedb is dead package as it's abandonned by upstream and most of it will be integrated in libgda-ui 4.2 Co-maintainers are welcome H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java Bindings for libnotify
frysk is long dead (and who was using it anyway ?), frysk developers are working on gdb/Archer now. http://sources.redhat.com/frysk/ I suggest that both frysk and old gnome java wrappers to be dropped from packages collection. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
Sounds pretty sensible. We should also keep in mind that one size does not fit all. While core and widely used packages should have a more conservative update path, some packages could benefit from faster release. karma mechanism + feedback integration in PK looks like a total win for the latter. Promoting the use of fedora-easy-karma among contributors (kudos to Till Maas !) would be more effective than a half baked proposition (hasty decisions are often bad ones). 2010/3/9 Rahul Sundaram methe...@gmail.com: I don't see how we expect that for all packages to get enough karma and while some of them can get feedback within the current infrastructure and considering the wide variety of packages (niche libraries for example) it is naive to believe that we are going to accomplish and hence my counter points are: * We need improvements in our infrastructure (easy karma is one avenue but Pacagekit integration and other ways to get users to provide input needs to be in place first) * We need to consider what we need as exceptions to this rule or more sensibly enforce this rule only in crit path packages initially * If a time limit is considered as a alternative we need to document ways to escalate and file a exception if necessary and again I would recommend only consider enforcing it for crit packages first As it current stands I am against this proposal Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scythia-0.9.3-5.fc14
2010/2/25 Kevin Kofler kevin.kof...@chello.at: Well, if you had talked to us about it, we could have bundled the rebuild together with the big update, like we did for a couple other apps which needed rebuilds for some reason. But it doesn't matter now, I see your updates are queued for stable now, so it's going to be fixed in the next push. i'll take note of it. :) (FWIW, this is clearly a Qt bug, it's not supposed to be necessary to rebuild anything. Sadly, binary compatibility has been lackluster in recent times. :-( ) +1, i've had few issues migrating applications to Qt 4.6 but still a great release. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: I'm leaving packaging on Fedora]
I'll take me-tv, co-maintainers are welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: I'm leaving packaging on Fedora]
looks like packages are not orphaned yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
