Hi,
On Fri, Aug 13, 2010 at 4:17 PM, Christoph Wickert
wrote:
> What are they doing and how is ck-launch-session different from
> ck-xinit-session?
The differences are extremely minor. The latter was written first to
fill a specific need for fedora and was stuffed in the xorg-x11-xinit
package,
On Fri, 2010-08-13 at 18:49 -0700, Ryan Rix wrote:
> On Fri 13 August 2010 18:44:37 Adam Williamson wrote:
> > Perhaps the problem isn't the projects,
> > after all?
>
> The KDE Firefox integration patches were written by openSuSE developers, not
> Kev.
Kevin's the one complaining about how hard
On Fri, Aug 13, 2010 at 08:24:07PM -0400, David Malcolm wrote:
> On Fri, 2010-08-13 at 19:38 -0400, Toshio Kuratomi wrote:
> > On Fri, Aug 13, 2010 at 02:20:51PM -0400, David Malcolm wrote:
> > > Possible ways forward:
> > > (a) don't fix this; treat enabling the warning in the "Doctor, it
> > >
On Fri, 2010-08-13 at 18:16 +0200, Kevin Kofler wrote:
> 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
On Fri 13 August 2010 18:44:37 Adam Williamson wrote:
> Perhaps the problem isn't the projects,
> after all?
The KDE Firefox integration patches were written by openSuSE developers, not
Kev.
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/
On Fri, 2010-08-13 at 10:52 -0500, Chris Adams wrote:
> 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
On Fri 13 August 2010 11:36:09 Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
> > If we really are the only ones true to Fedora's original principles
>
> As I recall, "upstream, upstream, upstream" was one of those principles
> that you are demanding others now break.
And the same pol
On Fri, Aug 13, 2010 at 4:24 PM, David Malcolm wrote:
> Sorry about this.
You don't know how sorry! You've made it onto my Christmas Card list.
Which means I send you a live puppy in the mail COD overnight delivery
for Christmas day to your place of work. Now you have a choice. You
can either b
On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote:
> 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
> > p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 11:15 PM, Michael Cronenworth wrote:
> By network install, I meant using a local intranet-based HTTP or FTP
> server to install from.
Ok fair enough, I misunderstood what you meant. My apologies.
Regards
- --
http://home.comcen.com
On Fri, 2010-08-13 at 13:44 -0800, Jeff Spaleta wrote:
> On Fri, Aug 13, 2010 at 10:20 AM, David Malcolm wrote:
> > Personally, I'm leaning towards option (a) above (the "don't override
> > warnings" option): closing the various as WONTFIX, and adding a section
> > to the release notes, whilst wor
On Fri, 2010-08-13 at 19:38 -0400, Toshio Kuratomi wrote:
> On Fri, Aug 13, 2010 at 02:20:51PM -0400, David Malcolm wrote:
> > (Sorry about the length of this email)
> >
> > Python 2.7 deprecated the PyCObject API in favor of a new "capsule" API.
> > http://docs.python.org/dev/whatsnew/2.7.html#
On Thu, 2010-08-12 at 16:11 -0600, Linuxguy123 wrote:
> On the data side, it would be very interesting to go back to each one of
> those slips and identify the component(s) that caused the slip and then
> question the individuals behind them to find out what happened. Then
> take that information
On Fri, Aug 13, 2010 at 02:20:51PM -0400, David Malcolm wrote:
> (Sorry about the length of this email)
>
> Python 2.7 deprecated the PyCObject API in favor of a new "capsule" API.
> http://docs.python.org/dev/whatsnew/2.7.html#capsules
>
> The deprecations are set to "ignore" by default, so in
Hello folks,
On Fri, Aug 13, 2010 at 09:48:56AM -0500, 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!
>
> http://fedoraproject.org/wiki/Fedora_Engineering_Services:Join
>
> -Mike
I'm a newcomer
On 08/13/2010 10:16 AM, Till Maas wrote:
> 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
On Fri, 2010-08-13 at 16:12 -0600, Kevin Fenzi wrote:
> On Fri, 13 Aug 2010 23:17:39 +0200
> Sven Lankes wrote:
>
> > On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
> >
> > > I wonder why I get the impression that the only ones who strongly
> > > oppose this change are you folks
On Fri, 13 Aug 2010 23:17:39 +0200
Sven Lankes wrote:
> On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
>
> > I wonder why I get the impression that the only ones who strongly
> > oppose this change are you folks from KDE SIG... Are you doing
> > things differently from anyone el
On Fri, 13 Aug 2010 15:39:59 -0400
Toshio Kuratomi wrote:
> I'm negative towards this change and not part of the KDE SIG but don't
> really like to clutter up the mailing lists with a bunch of negative
> energy. And I don't like the way it makes me feel about Fedora to
> continually try to get a
On Fri, Aug 13, 2010 at 10:20 AM, David Malcolm wrote:
> Personally, I'm leaning towards option (a) above (the "don't override
> warnings" option): closing the various as WONTFIX, and adding a section
> to the release notes, whilst working towards fixing this in Fedora 15.
> Affected applications
On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly
> oppose this change are you folks from KDE SIG... Are you doing things
> differently from anyone else in fedora - the rest of us are either
> more or less neutral or
W dniu 13.08.2010 01:12, Orcan Ogetbil pisze:
> 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 have been
>> in testing for N days (fedora: N=7, epel: N=14), and will
>>
https://bugzilla.redhat.com/show_bug.cgi?id=610281
https://bugzilla.redhat.com/attachment.cgi?id=438753&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=438753&action=edit
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-dev
And not "surprise" in the good sense, I'm afraid.
A few minutes ago, I ran:
shutdown -h 06:00 Emergency building power maintenance
Of course, I expected the system to alert users of the impending shutdown,
forbid new logins as the shutdown approaches, and then, at the selected
time, halt the s
Hello all,
currently I'm looking for a review for two of my packages:
lockfile-progs: https://bugzilla.redhat.com/show_bug.cgi?id=601115
is a dependency of
logcheck: https://bugzilla.redhat.com/show_bug.cgi?id=589867
liblockfile (needed for lockfile-progs) is included in rawhide and in
updates-t
Hi there,
is there any documentation on ConsoleKit available? ATM the package only
includes a README which refers to
http://www.freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html
which is mainly an API documentation. What I need is a user
documentation about the binaries installed by ConsoleK
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote:
> Martin Sourada wrote:
> > I wonder why I get the impression that the only ones who strongly oppose
> > this change are you folks from KDE SIG... Are you doing things
> > differently from anyone else in fedora - the rest of us are either more
On Tue, Aug 10, 2010 at 09:07:21AM -0600, Stephen John Smoogen wrote:
> On Sun, Aug 8, 2010 at 14:04, Matt McCutchen wrote:
> > On Thu, 2010-08-05 at 22:23 +0200, Till Maas wrote:
> >> Yes ssh is secure if used properly. To get the proper known_hosts entry,
> >> one has to download https://admin.f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/13/2010 03:41 PM, João Neto wrote:
> Hello All,
>
> In the /etc/bash_complete.d/ have some aucomplete bash plugins - like
> yum, subversion and GIT. But this not work?
>
> Put $ yum (PRESS TAB) do not autocomplete.
>
> $ yum list (PRESS TAB) d
Hello All,
In the /etc/bash_complete.d/ have some aucomplete bash plugins - like yum,
subversion and GIT. But this not work?
Put $ yum (PRESS TAB) do not autocomplete.
$ yum list (PRESS TAB) do not autocomplete
Some problems or i need to enable something on my system?
--
Atenciosamente,
Joã
On Fri, 2010-08-13 at 20:17 +0200, Kevin Kofler wrote:
> Martin Sourada wrote:
> > I wonder why I get the impression that the only ones who strongly oppose
> > this change are you folks from KDE SIG... Are you doing things
> > differently from anyone else in fedora - the rest of us are either more
On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
> On Fri, 2010-08-13 at 17:17 +0200, Jaroslav Reznik wrote:
> > 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
> > >
On Fri, Aug 13, 2010 at 08:20:04PM +0200, Kevin Kofler wrote:
> Chris Adams wrote:
> > What if it isn't a bug, but just different behavior?
>
> Do you really think it's acceptable for a library to terminate the whole
> application when an error happens??? There's a reason rpmlint complains
> lou
Bug or not, changing the behavior of a library is not something to be done
without coordination and consideration and cooperation. Our releases are not
rawhide, stuff can't be rammed in whenever upstream bumps a number.
We are off on a tangent here, the point is that our releases have differen
Jesse Keating wrote:
> Doing so would have changed behavior and broken software that relied upon
> that behavior. Sounds like a great way to run the distro
Software relying on an error in a library to terminate the whole
application, as opposed to raising an interceptable exception? Is there
One more success.
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon 2100
With AMD 64 X2 CPU
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 08/13/2010 12:20 PM, Nicolas Mailhot wrote:
>
> Le Ven 13 août 2010 16:01, Nathanael D. Noblet a écrit :
>
>> There was however a kernel issue from dmesg, should this be filed?
>>
>> ===
>> [ INFO: suspicious rcu_dereference_check() usage. ]
>> ---
Once upon a time, Kevin Kofler said:
> If we really are the only ones true to Fedora's original principles
As I recall, "upstream, upstream, upstream" was one of those principles
that you are demanding others now break.
--
Chris Adams
Systems and Network Administrator - HiWAAY Internet Service
Till Maas wrote:
> The same people that provided the -1 karma can provide a +1 karma. And
> you only need have of these people to change their karma vote to get
> back to zero karma. This should also not be a major problem, unless
> there are people providing unjustified -1 karma to cause problems.
Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly oppose
> this change are you folks from KDE SIG... Are you doing things
> differently from anyone else in fedora - the rest of us are either more
> or less neutral or positive towards this new change?
Oh, and
Chris Adams wrote:
> What if it isn't a bug, but just different behavior?
Do you really think it's acceptable for a library to terminate the whole
application when an error happens??? There's a reason rpmlint complains
loudly about "shared-library-calls-exit".
Kevin Kofler
--
devel ma
On 08/13/2010 01:23 PM, Jesse Keating wrote:
> Doing so would have changed behavior and broken software that relied upon
> that behavior. Sounds like a great way to run the distro
>
With that attitude, how would we ever change gcc versions in a stable
release? ;)
-J
> "Kevin Kofler"
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote:
> Martin Sourada wrote:
> > I wonder why I get the impression that the only ones who strongly oppose
> > this change are you folks from KDE SIG... Are you doing things
> > differently from anyone else in fedora - the rest of us are either more
Doing so would have changed behavior and broken software that relied upon that
behavior. Sounds like a great way to run the distro
"Kevin Kofler" wrote:
>seth vidal wrote:
>> and that's what the testing helped with. The bug was noticed. It was
>> patched upstream to accomodate the versions
(Sorry about the length of this email)
Python 2.7 deprecated the PyCObject API in favor of a new "capsule" API.
http://docs.python.org/dev/whatsnew/2.7.html#capsules
The deprecations are set to "ignore" by default, so in theory the API
still works: every time an extension uses the API, a deprec
Le Ven 13 août 2010 16:01, Nathanael D. Noblet a écrit :
> There was however a kernel issue from dmesg, should this be filed?
>
> ===
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---
> kerne
seth vidal wrote:
> and that's what the testing helped with. The bug was noticed. It was
> patched upstream to accomodate the versions of sqlite that act
> differently and we moved along.
>
> So, in fact, testing worked exactly as we wanted it to.
But if SQLite had consistently been tracking upst
On 08/13/2010 01:10 PM, Kevin Kofler wrote:
> Al Dunsmuir wrote:
>> The FireFox maintainer might well be viewed as best qualified to
>> determine which (if any) distribution-specific patches they want to
>> support over the life of the package. If you say no, then put that
>> maintai
Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly oppose
> this change are you folks from KDE SIG... Are you doing things
> differently from anyone else in fedora - the rest of us are either more
> or less neutral or positive towards this new change?
If we r
Le Ven 13 août 2010 19:24, Jon Ciesla a écrit :
> The person may point to their SIGs enhanced guidelines, but unless they
> get FPC to add them to the general guidelines, then they're optional.
Which is a lot of work, and not something everyone will apply even after FPC
blessing, but it's the on
Al Dunsmuir wrote:
> The FireFox maintainer might well be viewed as best qualified to
> determine which (if any) distribution-specific patches they want to
> support over the life of the package. If you say no, then put that
> maintainer in a "FireFox SIG" and repeat the question.
1.
On 08/13/2010 12:58 PM, Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> The current approach of trying to force maintainers to accept patches
>> simply does not work.
> The only reason it doesn't work is that our organizational structure is not
> built to make this work.
>
> Kevin Kofler
Once upon a time, Kevin Kofler said:
> Rahul Sundaram wrote:
> > The current approach of trying to force maintainers to accept patches
> > simply does not work.
>
> The only reason it doesn't work is that our organizational structure is not
> built to make this work.
But why should it be made t
Rahul Sundaram wrote:
> The current approach of trying to force maintainers to accept patches
> simply does not work.
The only reason it doesn't work is that our organizational structure is not
built to make this work.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
ht
On Fri, 2010-08-13 at 12:43 -0500, Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
> > I tried many things, even running for FESCo and getting voted in. As you
> > can
> > see, it didn't achieve anything either.
>
> Is it impossible for you to accept the fact that not everybody agrees
Once upon a time, Kevin Kofler said:
> The people who voted them in were a small minority
As were the people that voted you in. Does that invalidate your FESCo
standing as well?
> I tried many things, even running for FESCo and getting voted in. As you can
> see, it didn't achieve anything eit
Once upon a time, Kevin Kofler said:
> Jesse Keating wrote:
> > 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
>
> Right. If F12 has a buggy SQLite, then that SQLite should
Once upon a time, Kevin Kofler said:
> 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.
That's y
On Fri, Aug 13, 2010 at 19:07:57 +0200,
Kevin Kofler wrote:
> Bruno Wolff III wrote:
> > Most features are fairly independent and don't cause problems when they
> > run late or have problems, outside of that feature. Some are somewhat
> > disruptive and can make it hard to test other things whil
On Friday, August 13, 2010, 1:26:34 PM, Jon wrote:
> Hey, no fair stating the same point as I did, at the same time, but
> better, and without ranting. That's cheating!
> :)
> -J
Sorry... Must be feeling mellow - it's Friday afternoon, and I'm
taking next week off.
I'll make sure I flick
On Fri, 2010-08-13 at 13:30 -0400, Al Dunsmuir wrote:
> On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote:
> > Jesse Keating wrote:
> >> 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
On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote:
> Jesse Keating wrote:
>> 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
> Right. If F12 has a buggy SQLite, then that SQLi
seth vidal wrote:
> On f12, however, the version of sqlite that f12 had handles an error
> condition differently than on f13 and f14. It meant that instead of
> raise an exception and letting us move along that it raised an exception
> and then exited.
Jesse already anticipated my reply there. :-)
On Fri, Aug 13, 2010 at 05:54:30PM +0200, Kevin Kofler wrote:
> 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 t
On 08/13/2010 12:23 PM, Al Dunsmuir wrote:
> On Friday, August 13, 2010, 1:05:16 PM, Kevin wrote:
>> Jon Ciesla wrote:
>>> My understanding of the SIG concept was that they were groups of people
>>> who were self-organizing around a particular theme to further that theme
>>> in Fedora, i.e. Games
Bruno Wolff III wrote:
> Most features are fairly independent and don't cause problems when they
> run late or have problems, outside of that feature. Some are somewhat
> disruptive and can make it hard to test other things while they are having
> their kinks worked out or just waiting for rebuilds
On 08/13/2010 12:05 PM, Kevin Kofler wrote:
> Jon Ciesla wrote:
>> My understanding of the SIG concept was that they were groups of people
>> who were self-organizing around a particular theme to further that theme
>> in Fedora, i.e. Games, Live Upgrade, KDE, etc.
> Right, but that makes them nat
On Friday, August 13, 2010, 1:05:16 PM, Kevin wrote:
> Jon Ciesla wrote:
>> My understanding of the SIG concept was that they were groups of people
>> who were self-organizing around a particular theme to further that theme
>> in Fedora, i.e. Games, Live Upgrade, KDE, etc.
> Right, but that makes
On Fri, 2010-08-13 at 17:17 +0200, Jaroslav Reznik wrote:
> 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 somet
Jesse Keating wrote:
> 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
Right. If F12 has a buggy SQLite, then that SQLite should be fixed!
Kevin Kofler
--
devel mailing
Jon Ciesla wrote:
> My understanding of the SIG concept was that they were groups of people
> who were self-organizing around a particular theme to further that theme
> in Fedora, i.e. Games, Live Upgrade, KDE, etc.
Right, but that makes them naturally the best bodies to make decisions
related to
On 08/13/2010 10:33 PM, Kevin Kofler wrote:
>
> Uh, AFAIK Jaroslav Řezník has talked to both the OO.o and the Firefox
> maintainers about KDE integration (there are maintainers or comaintainers of
> both in the same RH office), in both cases with little success so far. In
> OO.o's case, some or
Dave Jones wrote:
> 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
Luke Macken wrote:
> The only case for update starvation that I can think of is if you keep
> adding/removing builds from an update before it reaches a week in
> testing or the karma thresholds.
For any large update group, that's just always going to happen. There's
always another important fix y
Rahul Sundaram wrote:
> You are calling a lot of things including the kernel and Firefox KDE
> related even though KDE Spin does not even include Firefox by default.
> In other words, you want a organization policy that lets you dictate to
> other maintainers what patches they should merge even if
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
>
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 intentio
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
>>
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 i
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
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 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 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 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.
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
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
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
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 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
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 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
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, 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
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, 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
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
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 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
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
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
1 - 100 of 179 matches
Mail list logo
