On Fri, 2010-08-13 at 07:56 +0200, Ralf Corsepius wrote:
On 08/13/2010 07:11 AM, Matt McCutchen wrote:
Let's try that again. Fedora has no obligation to you; nothing entitles
you (or anyone for that matter) to push updates or even to post to this
list.
... and people are free to have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 10:59 PM, Matt McCutchen wrote:
That's why I'm so frustrated that Fedora seems to be committed
to keeping the Mozilla trademarks, which moot any discussion of whether
to deviate for those packages. But this is only my opinion.
I took csstidy.
04.08.2010 20:32, Bill Nottingham wrote:
Each release, we undergo the effort to track down owners for orphaned
packages in the release, and block those orphaned packages where
necessary. It's that time again for Fedora 14.
The following packages are currently orphaned and
On Friday, August 13, 2010 03:10:46 am Kevin Kofler wrote:
I wrote:
But FWIW, when it comes to KDE in particular, the whole thing is moot or
soon to be moot anyway because parts of KDE are now being redefined as
critical path, resulting in even more annoying update policies, even
though
On Friday, August 13, 2010 03:26:11 am Chris Adams wrote:
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
IMHO, FESCo should be abolished, Fedora needs to be ruled by the SIGs!
Why are you here?
To work? Not to play politics games? Kevin is really one of the top Fedora
On Friday, August 13, 2010 01:27:18 am Kevin Kofler wrote:
Luke Macken wrote:
Fixed in
https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f
8e495f36
That fix is really unhelpful and makes it a PITA to edit updates! In the
past, KDE SIG has often edited in some
On Thursday, August 12, 2010 09:33:17 pm Lennart Poettering wrote:
On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not yell, lets not flame war, lets not
point
Hi,
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
If not, is it possible to perform this media check immediately after
having burned the
I add himself as co-maintainer of php-pecl-xdebug.
And If you want, can help with some more packages. Please say, if you want.
Primarily it may be: php-pear-Structures-DataGrid*.
11.08.2010 21:19, Remi Collet wrote:
Le 11/08/2010 18:32, Christopher Stone a écrit :
Im no longer maintaining
On Fri, Aug 13, 2010 at 10:50, Pavel Alexeev (aka Pahan-Hubbitus)
fo...@hubbitus.com.ru wrote:
I add himself as co-maintainer of php-pecl-xdebug.
And If you want, can help with some more packages. Please say, if you want.
Primarily it may be: php-pear-Structures-DataGrid*.
Yes, I can
Hello!
2010/8/13 Garrett Holmstrom gho...@fedoraproject.org:
On 8/12/2010 9:16, Peter Lemenkov wrote:
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh.
Do you have some way of automatically adding new packages as they are
added to Fedora in the future?
On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote:
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
- Minimum time-in-testing requirements
- Every day bodhi will look for
Compose started at Fri Aug 13 08:15:16 UTC 2010
Broken deps for x86_64
--
Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6
Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
To me, this includes shipping a great new
technology such as LZMA SquashFS, without waiting for the upstream kernel.
You've insisted over and over (and over) again that the KDE SIG should
have absolute authority over the KDE
On Fri, 13 Aug 2010, Jaroslav Reznik wrote:
On Thursday, August 12, 2010 09:33:17 pm Lennart Poettering wrote:
On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
Since 2006 I counted 18 slips (I think one or two of those may just be a
single slip listed twice). Lets not
On 08/12/2010 11:59 AM, Adam Williamson wrote:
Hi, everyone. So, we have one bug remaining for Fedora 14 whose blocker
status is unclear:
https://bugzilla.redhat.com/show_bug.cgi?id=596985
Two reporters in the bug - John Reiser and Mike Chambers - and one
reporter from the list - Rui He,
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
There are embedded MD5 checksums, sometimes 20 of them per .iso.
See
A file has been added to the lookaside cache for perl-Log-Dispatchouli:
060547d9ad3ee0838151968bec5352b6 Log-Dispatchouli-1.102220.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
Joachim Backes wrote:
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
If not, is it possible to perform this media check immediately
Summary of changes:
fae5a3f... Initialize branch F-13 for perl-Log-Dispatchouli (*)
0859425... Initialize branch F-12 for perl-Log-Dispatchouli (*)
94ebe00... initial import (*)
4746c68... initial import (*)
8e300b5... dist-git conversion (*)
a3151e5... dist-git conversion (*)
commit 336a4d1100c77696fa220d41afa0dcd20aa1562a
Merge: 397641f a3151e5 8e300b5
Author: Iain Arnell iarn...@gmail.com
Date: Fri Aug 13 15:59:55 2010 +0200
Initial pseudo merge for dist-git setup
---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
commit 14cc28929cb82630a44329bb857b9a6328e566fe
Author: Iain Arnell iarn...@gmail.com
Date: Fri Aug 13 16:14:44 2010 +0200
update to 1.102220
.gitignore |1 +
perl-Log-Dispatchouli.spec | 12 +---
sources|2 +-
3 files changed, 7
Summary of changes:
fae5a3f... Initialize branch F-13 for perl-Log-Dispatchouli (*)
0859425... Initialize branch F-12 for perl-Log-Dispatchouli (*)
94ebe00... initial import (*)
4746c68... initial import (*)
8e300b5... dist-git conversion (*)
a3151e5... dist-git conversion (*)
On Thu, Aug 12, 2010 at 05:57:28PM -0400, Luke Macken wrote:
- Show 7 days worth of entries in our RSS feeds, as opposed to 20
entries (https://fedorahosted.org/bodhi/ticket/339)
This is nice, I forgot to add myself to the CC list, so I did not notice
this before.
- Only verify the
Summary of changes:
0859425... Initialize branch F-12 for perl-Log-Dispatchouli (*)
a987996... initial import (*)
4746c68... initial import (*)
0ca7427... - Mass rebuild with perl-5.12.0 (*)
a3151e5... dist-git conversion (*)
397641f... dist-git conversion (*)
336a4d1... Initial
Summary of changes:
fae5a3f... Initialize branch F-13 for perl-Log-Dispatchouli (*)
a987996... initial import (*)
94ebe00... initial import (*)
0ca7427... - Mass rebuild with perl-5.12.0 (*)
8e300b5... dist-git conversion (*)
397641f... dist-git conversion (*)
336a4d1... Initial
Joachim Backes wrote:
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
If not, is it possible to perform this media check
FYI I've added (hopefully) on correct place the draft of changed
packaging guidelines:
https://fedoraproject.org/wiki/Packaging/GuidelinesTodo#Things_to_be_considered_for_Packaging_Guidelines
--
Marcela Mašláňová
BaseOS team Brno
--
Fedora Extras Perl SIG
On Thu, Aug 12, 2010 at 9:34 PM, Nicolas Mailhot
nicolas.mail...@laposte.net wrote:
Le jeudi 12 août 2010 à 13:51 -0500, Jason L Tibbitts III a écrit :
I guess I'm just saying that, if we had the developer time to do it, it
would be super nice if we could get the pre-F15 rawhide is useless bit
Jesse Keating wrote:
Do you have any sort of proof that it's a political reason? It would
seem to me that our kernel maintainers do not wish to include code that
hasn't been blessed by Linus in our packages.
That's political.
Kevin Kofler
--
devel mailing list
perl-Config-Model has broken dependencies in the F-14 tree:
On x86_64:
perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) =
0:0.303
On i386:
perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) =
0:0.303
Please resolve this as soon as possible.
--
Fedora
perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires
perl(:MODULE_COMPAT_5.10.1)
On i386:
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires
perl(:MODULE_COMPAT_5.10.1)
Please resolve this as soon as
Do you like fixing things but don't care what?
Are you a jack of all trades sort of person?
We need your help!
http://fedoraproject.org/wiki/Fedora_Engineering_Services:Join
-Mike
--
devel mailing list
devel@lists.fedoraproject.org
Jesse Keating wrote:
You're making an assumption here that it's the trademarks that prevent
any deviation from upstream, when in fact the maintainer has stated many
times that regardless of trademarks, he would not deviate from upstream
given the sensitivity of a software suite that has to
Chris Adams wrote:
Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the SIGs controlling the live
images should be the ones making the decision. This means the 4
On Fri, Aug 13, 2010 at 8:21 PM, Kevin Kofler wrote:
. Their position is not consistent: if we ask for non-
upstream changes, they say the trademarks forbid them so they can't do
anything, if we ask for getting the trademarks removed, they say that it
wouldn't change anything anyway.
On Fri, Aug 13, 2010 at 3:27 AM, Luke Macken wrote:
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
https://admin.fedoraproject.org/updates
I expect more fine tuning will be needed
Mike McGrath wrote:
Do you like fixing things but don't care what?
Are you a jack of all trades sort of person?
We need your help!
Hey Mike,
I know you're a cool guy and would be interested in signing up. However,
what kind of work would this entail? I see 4 hours per week listed,
but
Rahul Sundaram wrote:
I expect more fine tuning will be needed for these changes but thanks
for all your work on this.
Indeed! Thanks Luke. Bodhi became much more useful with this update even
if there are a few nay-sayers.
--
devel mailing list
devel@lists.fedoraproject.org
Mike McGrath wrote:
I'll admit, this is a convenient view to have. The problem is we're not
in high school anymore. We're professionals. We're expected to set and
keep schedules because people besides ourselves rely on those schedules.
There are other distros that set and keep schedules
On Fri, Aug 13, 2010 at 8:24 PM, Kevin Kofler wrote:
Chris Adams wrote:
Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and
almost
exclusively the live images, and as such the SIGs controlling the live
images
Jaroslav Reznik wrote:
Then we have to push broken updates, policy says so and it's ok, so let's
do it
:(
A policy requiring us to push something broken is broken. I'm not going to
push broken shit.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
Joachim Backes wrote:
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
You can already do this in K3b, there's a box you can check to
Compose started at Fri Aug 13 13:15:29 UTC 2010
Broken deps for x86_64
--
CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0
CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit)
On Friday, August 13, 2010 05:09:17 pm Kevin Kofler wrote:
Jaroslav Reznik wrote:
Then we have to push broken updates, policy says so and it's ok, so let's
do it
:(
A policy requiring us to push something broken is broken. I'm not going to
push broken shit.
Just irony but it feels
On Fri, 2010-08-13 at 16:51 +0200, Kevin Kofler wrote:
* This policy of sticking religiously to upstream means we are not shipping
KDE integration for Firefox, despite patches from openSUSE existing. This
makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything
about it.
Rahul Sundaram wrote:
You seem to refuse to accept that Firefox maintainers in Fedora don't want
the KDE patches without it getting upstream. Firefox is one of the
frequently updated software and non-upstream patches create a burden. Why
aren't the patches upstream? You are fighting in the
Hello Kevin,
On Thursday, August 12, 2010, 8:04:12 PM, Kevin Kofler wrote:
Orcan Ogetbil wrote:
The F-(x) package will have higher EVR than the F-(x+1) one. This
will break the upgrade path. Is there any measures to prevent this?
No. In fact FESCo specifically refused to consider this as an
On 08/13/2010 08:49 PM, Kevin Kofler wrote:
But applying KDE integration patches should be a KDE SIG matter, the
individual package maintainers should have to comply with KDE SIG decisions
on the matter.
No. No SIG's have any authority whatsoever over individual package
maintainers outside
On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote:
fix breaks that. Plus, edits can also be only to the description or bug
references, Bodhi doesn't allow me to edit those without editing the whole
update.
Bodhi also allows you to edit the stable karma value and unless it is
On Fri, 13 Aug 2010, Kevin Kofler wrote:
Mike McGrath wrote:
I'll admit, this is a convenient view to have. The problem is we're not
in high school anymore. We're professionals. We're expected to set and
keep schedules because people besides ourselves rely on those schedules.
There
Ralf Corsepius wrote:
I think, for packages that are modified during the testing period,
this N should be calculated from the day the last push was made to
testing.
This would very unhelpful.
Yes, this was my initial intention. However, looking at the code a bit
closer, your scenario
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
You can also run sha256sum /dev/cdrom and compare the result with the
published checksums.
IIRC, you can in some cases get the wrong value with that due to padding
(but it has been a while since I tried that, so that may not be a
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Jesse Keating wrote:
Do you have any sort of proof that it's a political reason? It would
seem to me that our kernel maintainers do not wish to include code that
hasn't been blessed by Linus in our packages.
That's political.
So with RC4. I have one success and one failure.
Works: 01:00.0 VGA compatible controller: ATI Technologies Inc RV730
PRO [Radeon HD 4650]
Fails: 01:00.0 VGA compatible controller: ATI Technologies Inc RV730XT
[Radeon HD 4670]
I've also got one more to test against later today
01:05.0 VGA
On 08/13/10 10:32, Joachim Backes wrote:
Hi,
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
If not, is it possible to perform this
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the SIGs controlling the live
images should be the ones making the decision.
SIGs don't exist to exercise control
On 08/13/2010 04:32 AM, Joachim Backes wrote:
Hi,
having the following question: What does the DVD/CD media check exactly
if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
check, because it could be done after having burned the DVD?
If not, is it possible to perform
Rahul Sundaram wrote:
Sorry but no. There is only one kernel for the entire distribution and I
rather rely on kernel maintainers expertise on their packages rather than
SIG's trying to dictate what patches the kernel should carry. The SIG
participants are not kernel developers.
But
On 08/13/2010 09:08 AM, Kevin Kofler wrote:
Jaroslav Reznik wrote:
It would hurt all sides - it would hurt Fedora, the new distribution, our
work in Red Hat, users and so on. And I don't understand why we can't work
under one roof - to make Fedora the best OS. Maybe more autonomy for SIGs
On Fri, Aug 13, 2010 at 07:16:36AM +0200, Kevin Kofler wrote:
Basically, we're missing out on an important new feature and shipping less
featureful live images than we could for purely political reasons. :-(
The reasons are purely practical. If upstream development is targeting
upstream
Just an idea, without _fully_ understanding the infrastructure, man
power etc ramifications.
Since the move to git, would it not be easier to allow features to
branch rawhide, get their individual bits together (syncing with 'trunk'
periodically)... Then like the kernel does, merge back the
Chris Tyler wrote:
If you (or whoever is interested) can't get those patches through the
upstream review process for technical reasons, then perhaps they're ugly
patches. If you can't get them through because of lack of
time/energy/motivation, then the future maintenance of those patches is
Once upon a time, Kevin Kofler kevin.kof...@chello.at said:
but it's far from easy for somebody who's
not already an experienced upstream kernel developer to manage that, LKML is
a tough place: there's politics making it hard for new contributors to get
their stuff in, there are many rules
Mike McGrath wrote:
:( I'm saddened you think so little of us Kevin. I'd have thought we
could do both.
And you think Santa Claus exists, too? ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Aug 13, 2010 at 05:49:31PM +0200, Kevin Kofler wrote:
You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla
is one of those), you can only get your poorly-written code merged if you
know the right
people. :-(
FTFY
On Fri, Aug 13, 2010 at 16:54:22 +0200,
Kevin Kofler kevin.kof...@chello.at wrote:
Chris Adams wrote:
Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the
On 08/13/2010 08:58 PM, Kevin Kofler wrote:
But sometimes the maintainers of individual package maintainers have to cave
in to allow for a coordinated distribution experience. That's why we are a
distribution and not a bunch of packages thrown together.
Coordinated distribution experience
On Fri, 2010-08-13 at 17:49 +0200, Kevin Kofler wrote:
Chris Tyler wrote:
If you (or whoever is interested) can't get those patches through the
upstream review process for technical reasons, then perhaps they're ugly
patches. If you can't get them through because of lack of
Till Maas wrote:
Bodhi also allows you to edit the stable karma value and unless it is
implemented differently (or has changed again), you can just use a
stable karma value of 1 and ask someone except the update submitter to
provide the +1 karma and the update can be pushed to stable. This is
On 08/13/2010 09:22 PM, Kevin Kofler wrote:
Mike McGrath wrote:
:( I'm saddened you think so little of us Kevin. I'd have thought we
could do both.
And you think Santa Claus exists, too? ;-)
No, his goal is certainly achievable and worth trying. The frequent
slips are a problem and we
On Thu, Aug 12, 2010 at 22:22:18 -0700,
Jesse Keating jkeat...@redhat.com wrote:
How do you suggest we be more conservative? If you expect the
developers to do this on their own, good luck. If you want there to be
some sort of enforcement I welcome suggestions.
My suggestion would be to
On Fri, 13 Aug 2010, Adam Tkac wrote:
On Fri, Aug 13, 2010 at 09:48:56AM -0500, Mike McGrath wrote:
Do you like fixing things but don't care what?
Hello,
may I ask you about FES workflow? Should FES members (with
provenpackager perms, for example) push fixes directly to git
and close
Chris Adams wrote:
Again, proof? They have enough patches to sort through every release as
it is, and they don't want to add more.
This doesn't strike me as a strong enough TECHNICAL reason to reject a
feature which would make all our live images better. Both the GNOME and the
KDE live image
On Friday, August 13, 2010, 11:52:33 AM, Kevin wrote:
Mike McGrath wrote:
:( I'm saddened you think so little of us Kevin. I'd have thought we
could do both.
And you think Santa Claus exists, too? ;-)
Kevin Kofler
http://www.snopes.com/holidays/christmas/photos/badsanta.asp
--
On Fri, Aug 13, 2010 at 05:51:57PM +0200, Kevin Kofler wrote:
Chris Adams wrote:
Again, proof? They have enough patches to sort through every release as
it is, and they don't want to add more.
This doesn't strike me as a strong enough TECHNICAL reason to reject a
feature which would
Al Dunsmuir wrote:
You are assuming that it is somehow a good idea to push release Fn, in
spite of no (or negative) testing.
Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
why testing on ANY F* isn't sufficient. Please don't bring the same old
argument that
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote:
Al Dunsmuir wrote:
You are assuming that it is somehow a good idea to push release Fn, in
spite of no (or negative) testing.
Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
why testing on ANY F* isn't
Chris Tyler wrote:
Thanks for reinforcing my point -- you have to work with the community.
Yes, you'll make some relationships along the way.
Except it works the other way round: you only have a chance to get into the
community (well, SOME upstream communities; thankfully, they're not all like
This is where Kevin blames the scenario on not having the same sqlite on all of
the Fedora releases, which is another evil plot hatched by the devils of
FESCo
seth vidal skvi...@fedoraproject.org wrote:
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote:
Al Dunsmuir wrote:
You are
Chris Adams wrote:
SIGs don't exist to exercise control over all packages in the
distribution (or all packages that tangentially affect them).
As I said elsewhere on this list, that's exactly where our organizational
structure fails.
Kevin Kofler
--
devel mailing list
On Fri, Aug 13, 2010 at 09:49:42 -0600,
Nathanael D. Noblet nathan...@gnat.ca wrote:
Since the move to git, would it not be easier to allow features to
branch rawhide, get their individual bits together (syncing with 'trunk'
periodically)... Then like the kernel does, merge back the
On 08/13/2010 09:44 PM, Kevin Kofler wrote:
Chris Tyler wrote:
Thanks for reinforcing my point -- you have to work with the community.
Yes, you'll make some relationships along the way.
Except it works the other way round: you only have a chance to get into the
community (well, SOME
On Fri, 13 Aug 2010, Bruno Wolff III wrote:
On Fri, Aug 13, 2010 at 09:49:42 -0600,
Nathanael D. Noblet nathan...@gnat.ca wrote:
Since the move to git, would it not be easier to allow features to
branch rawhide, get their individual bits together (syncing with 'trunk'
periodically)...
Bruno Wolff III wrote:
I really think the benefits and costs need to be looked at on a case by
case basis and the package maintainers should be the ones making the call.
The problem is, the kernel maintainers (and you, apparently) don't seem to
realize what big difference a 10% improvement in
Nathanael D. Noblet wrote:
Just an idea, without _fully_ understanding the infrastructure, man
power etc ramifications.
Since the move to git, would it not be easier to allow features to
branch rawhide, get their individual bits together (syncing with 'trunk'
periodically)... Then like the
On 08/13/2010 07:20 AM, Michael Schwendt wrote:
On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote:
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
- Minimum time-in-testing
On Fri, Aug 13, 2010 at 10:04:22 -0500,
Michael Cronenworth m...@cchtml.com wrote:
Mike McGrath wrote:
Do you like fixing things but don't care what?
Are you a jack of all trades sort of person?
We need your help!
Hey Mike,
I know you're a cool guy and would be interested in
On 08/13/2010 11:29 AM, Till Maas wrote:
On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote:
fix breaks that. Plus, edits can also be only to the description or bug
references, Bodhi doesn't allow me to edit those without editing the whole
update.
Bodhi also allows you to edit the
Rahul Sundaram wrote:
No. No SIG's have any authority whatsoever over individual package
maintainers outside the packages the team maintains. No one needs to
comply with your requirements.
That's exactly Fedora's organizational problem.
KDE SIG should have authority over anything
Kevin Kofler wrote:
* This policy of sticking religiously to upstream means we are not shipping
KDE integration for Firefox, despite patches from openSUSE existing. This
makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything
about it.
What reason does upstream give for
On 08/13/2010 10:47 AM, Kevin Kofler wrote:
Rahul Sundaram wrote:
No. No SIG's have any authority whatsoever over individual package
maintainers outside the packages the team maintains. No one needs to
comply with your requirements.
That's exactly Fedora's organizational problem.
KDE
On 08/13/2010 09:17 PM, Kevin Kofler wrote:
Rahul Sundaram wrote:
No. No SIG's have any authority whatsoever over individual package
maintainers outside the packages the team maintains. No one needs to
comply with your requirements.
That's exactly Fedora's organizational problem.
KDE SIG
On Fri, Aug 13, 2010 at 05:47:37PM +0200, Kevin Kofler wrote:
Good luck getting Mozilla to accept anything. Just like the kernel, they're
a very hard to work with upstream. If you don't know the right people, your
stuff just doesn't get in. :-(
Which is odd, because the number of
On Fri, Aug 13, 2010 at 18:20:29 +0200,
Kevin Kofler kevin.kof...@chello.at wrote:
Bruno Wolff III wrote:
I really think the benefits and costs need to be looked at on a case by
case basis and the package maintainers should be the ones making the call.
The problem is, the kernel
On 08/13/2010 01:57 AM, Ralf Corsepius wrote:
On 08/13/2010 01:23 AM, Luke Macken wrote:
On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that
Nathanael D. Noblet wrote:
However you don't want to let other people decide anything. You want
patches FF and kernel in so you get to do it, you want to push updates
without any testing required so you get to. To hell with whatever anyone
else wants, and when there is an organization put in
On 08/12/2010 07:47 PM, Orcan Ogetbil wrote:
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
- Minimum time-in-testing requirements
- When someone tries to push an update to stable, bodhi will
look to see if it has the appropriate karma, or if it has
On 08/13/2010 05:10 PM, Kevin Kofler wrote:
Ralf Corsepius wrote:
I think, for packages that are modified during the testing period,
this N should be calculated from the day the last push was made to
testing.
This would very unhelpful.
Yes, this was my initial intention. However, looking
On 08/13/2010 06:45 PM, Luke Macken wrote:
On 08/13/2010 01:57 AM, Ralf Corsepius wrote:
On 08/13/2010 01:23 AM, Luke Macken wrote:
On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
- Minimum time-in-testing requirements
1 - 100 of 175 matches
Mail list logo
