I'll take me-tv, co-maintainers are welcome.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
looks like packages are not orphaned yet.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2010/2/25 Kevin Kofler :
>
> 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
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.
> I think Fedora's balance has moved a bit to far in the fast-moving, frontier
> direction
This could be fixed by better feedbacks (statistics, autoQA, more
testers, integration of bodhi in package managers, etc ...), so
maintainers can adapt their update policy.
Another idea would be defining pa
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.
@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
> 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/list
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 reg
> 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
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.or
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 issu
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
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
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
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
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
Hi,
I'm back.
2014-02-22 11:19 GMT+01:00 Matthias Runge :
> 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
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 unaccepta
2014-03-20 12:22 GMT+01:00 Kevin Kofler :
> 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 wil
+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
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
2014-04-22 16:10 GMT+02:00 Máirín Duffy :
>
> 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 ar
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/c
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
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
spotti
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
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
2013/10/28 "Jóhann B. Guðmundsson"
>
> On 10/27/2013 11:34 AM, Nobrakal wrote:
>
>> 2013/10/27, Frank Murphy:
>>
>>> >On Sun, 27 Oct 2013 19:05:37 +0800
>>> >Christopher Meng wrote:
>>> >
>>>
>>It seems that most of members from the new formed groups are
>>working for Red Hat. Well it'
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
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" a écrit :
> Hi all
>
> I'm an IT university student. With Fedora I have
This discussion has now reached the "phoronix" point
http://www.phoronix.com/scan.php?page=news_item&px=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.fedora
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
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 m
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
As far as i'm concerned, the draft is good enough to be submitted to the
FPC.
Still, i'm not confident enough in my go skills to suggest it :)
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject
> 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.
Yea
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 co
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
2014/1/14 Daniel P. Berrange
>
> 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
/me wants the ability to push force on *private* branches
2014/1/15 Dridi Boukelmoune
> On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch 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 tr
"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/ma
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 c
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 remi
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 infrastructur
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 c
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
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.fe
48 matches
Mail list logo
