Matthew Garrett wrote:
> We have the authority to do that, and the decision you're referring to
> effectively *did* override the maintainer by saying that the selinux
> policy change should be reverted. If a package is generally
> well-maintained and then broken by a change introduced by another
>
On Sat, Aug 14, 2010 at 08:25:46PM -0700, Matt McCutchen wrote:
> I am aware of that. But FESCo has the authority to override the
> maintainer, and in their recent discussion of the SELinux patch, they
> decided not to move forward on the basis of the trademarks:
>
> https://meetbot.fedoraprojec
On Thu, 2010-08-12 at 23:29 -0700, Jesse Keating wrote:
> 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 onl
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
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 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 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
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
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
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 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 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
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 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
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
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
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
>
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
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
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
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
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
-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. Fe
ckage,
> and in this case they seem to be favoring sticking close to upstream as
> opposed to throwing in code willy nilly because it looks cool. Upstream
> has a code review process for a reason.
IMO, staying close to upstream is simply a means to the end of shipping
better software, and
35 matches
Mail list logo
