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
>
On Friday, August 13, 2010 03:26:11 am Chris Adams wrote:
> Once upon a time, Kevin Kofler 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
contributors.
> All you
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
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 f
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 D
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)
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 co-maintain them too. I wil
Hello!
2010/8/13 Garrett Holmstrom :
> 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?
Next thing in my
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
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)
PragmARC-20060427-6.fc1
Once upon a time, Kevin Kofler 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 packages, and that even FESCo
On 08/13/2010 05:31 AM, Christof Damian wrote:
> On Fri, Aug 13, 2010 at 10:50, Pavel Alexeev (aka Pahan-Hubbitus)
> 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-Str
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). Le
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
> 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 /usr/bin/implantis
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
https://admin.fedorapro
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 immediatel
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 (*)
336a4d
commit 336a4d1100c77696fa220d41afa0dcd20aa1562a
Merge: 397641f a3151e5 8e300b5
Author: Iain Arnell
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 mailing list
perl-de..
commit 14cc28929cb82630a44329bb857b9a6328e566fe
Author: Iain Arnell
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 insertions(+), 8 deleti
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 (*)
336a4d
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 auto
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 pseu
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 pseu
> 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
http://www.fedoraproject.org/wiki/Extra
On Thu, Aug 12, 2010 at 9:34 PM, Nicolas Mailhot
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 over
>> and done wi
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
devel@lists.fedor
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.
--
Fedor
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 po
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
https://admin.fedoraproject.org/mailman/listinfo/deve
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 de
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. Eit
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
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,
b
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
https://admin.fed
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
>
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
https://admin.fe
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 ve
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)
LuxRender-0
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
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 i
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 t
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
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 outsi
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
im
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.
> >
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, y
Once upon a time, Kevin Kofler 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
problem now). If you are
Once upon a time, Kevin Kofler 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.
Again, proof
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 comp
Rahul Sundaram wrote:
> I expect more fine tuning will be needed for these changes but thanks for
> all your work on this.
No thanks from me. By implementing FESCo's diktats defying common sense, you
broken updates for everyone.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproj
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
Once upon a time, Kevin Kofler 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 over all packages in
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 perf
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 bugs in bugzilla or should they rather put patch
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
> could help as Kevin proposed?
Yeah, the SIGs
On Fri, Aug 13, 2010 at 04:51:40PM +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
>
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 some
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 SIG
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 ker
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 wor
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 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 (technical, cosmeti
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
http://people.redhat.com/agospoda/pi
On Fri, Aug 13, 2010 at 16:54:22 +0200,
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
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
> > time/e
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
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 w
On Thu, Aug 12, 2010 at 22:22:18 -0700,
Jesse Keating 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 ask developers
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 c
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 imag
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 wo
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 "someti
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 lik
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" wrote:
>On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote:
>> Al Dunsmuir wrote:
>> > You are assuming that it is
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
devel@lists.f
On Fri, Aug 13, 2010 at 09:49:42 -0600,
"Nathanael D. Noblet" 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 working bits
> t
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 u
On Fri, 13 Aug 2010, Bruno Wolff III wrote:
> On Fri, Aug 13, 2010 at 09:49:42 -0600,
> "Nathanael D. Noblet" 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
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
On Fri, Aug 13, 2010 at 06:20:29PM +0200, Kevin Kofler 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 maintainers (and you
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
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-testin
On Fri, Aug 13, 2010 at 10:04:22 -0500,
Michael Cronenworth 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 sign
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
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 KDE-re
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
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.
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.
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 cha
On Fri, Aug 13, 2010 at 18:20:29 +0200,
Kevin Kofler 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 maintainers (and you, ap
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 u
1 - 100 of 179 matches
Mail list logo
