Re: Staying close to upstream
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.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08-03-19.30.log.html#l-66 Maybe the maintenance burden alone would also be enough to block further consideration of the patch, but there is no way to tell that from their discussion. 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 maintainer, there has to be a very strong argument to do anything other than revert the change that broke things in the first place. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 maintainer, there has to be a very strong argument to do anything other than revert the change that broke things in the first place. But the end effect is, we're allowing a web browser to disable memory protection, exposing all users to a severe security risk from merely browsing web sites. IMHO, the performance improvements in JavaScript aren't worth that risk. JavaScript JITs should be banned. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 only my opinion. Fedora is welcome to set its own course, and I am welcome to fork (in theory at least). 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 connect to the wild wild web. The maintenance burden of upstream deviation is greater than the maintainer would like to undertake, as is the risk of security issues and stability. 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.fedoraproject.org/fedora-meeting/2010-08-03/fesco.2010-08-03-19.30.log.html#l-66 Maybe the maintenance burden alone would also be enough to block further consideration of the patch, but there is no way to tell that from their discussion. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
-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. Fedora is welcome to set its own course, and I am welcome to fork (in theory at least). 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 connect to the wild wild web. The maintenance burden of upstream deviation is greater than the maintainer would like to undertake, as is the risk of security issues and stability. The kernel folks are likely walking the same path. For core components such as the kernel and our web browser, this does not seem like a bad thing at all. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxk5lkACgkQ4v2HLvE71NXpVQCfe9w1hgVQgGbN+fQ9hBUoWHSP KyAAn2rd71W8ZsCPIMdDPnUsNB2rr5wL =WEOp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 connect to the wild wild web. The maintenance burden of upstream deviation is greater than the maintainer would like to undertake, as is the risk of security issues and stability. But the end effect is: * Firefox, Thunderbird and xulrunner are the ONLY packages in the whole Fedora which are NOT open to provenpackager! (The reason given: trademarks.) IMHO this shows that the exception process which allows closing packages to provenpackager is useless and needs to be abolished, the problem is with those particular packages. * 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. In addition, trademarks are often given as one of the reasons they stick so closely to upstream when we complain about that, by the very same maintainers who then claim it's not about trademarks when we want to get the trademarks removed. 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. Either they're just using the trademarks as an excuse for their laziness, or the trademarks are the problem and need to be removed, it's one or the other. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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. Either they're just using the trademarks as an excuse for their laziness, or the trademarks are the problem and need to be removed, it's one or the other. -- 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 wrong place. The maintainers decision in this matter is final. Please accept the difference of opinion and move on. Repeating your opinions over and over again changes nothing. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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. Kevin, it seems to me that open source is about working in community, and you want to short-circuit that again. You could work in community by: - respecting our Firefox maintainers' policies, and - respecting upstream by shepherding these patches through their review process 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 in question. Either way, it strengthens our Firefox maintainers' position that those patches shouldn't be accepted. It's easy to complain that people aren't bending the rules to your liking, and harder to actually work with them and get things done in a quality, sustainable way. -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 wrong place. The maintainers decision in this matter is final. Please accept the difference of opinion and move on. Repeating your opinions over and over again changes nothing. 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. How can we offer an integrated desktop experience when individual maintainers refuse to work with us, and FESCo only makes our work harder with useless bureaucratic policies instead of helping us achieve our goals in a way coordinated throughout the distribution? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 the packages the team maintains. No one needs to comply with your requirements. How can we offer an integrated desktop experience when individual maintainers refuse to work with us, and FESCo only makes our work harder with useless bureaucratic policies instead of helping us achieve our goals in a way coordinated throughout the distribution? If you want a integrated experience, don't work around upstream. Push your patches and get it merged there. Do not try to arm twist Firefox maintainers to merge patches they do not want to maintain circumventing upstream. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 in question. Either way, it strengthens our Firefox maintainers' position that those patches shouldn't be accepted. You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla is one of those), you can only get your stuff merged if you know the right people. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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/pics/hackbar.jpg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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/energy/motivation, then the future maintenance of those patches is in question. Either way, it strengthens our Firefox maintainers' position that those patches shouldn't be accepted. You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla is one of those), you can only get your stuff merged if you know the right people. :-( Thanks for reinforcing my point -- you have to work with the community. Yes, you'll make some relationships along the way. -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 that!) if you already have the right relationships. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 upstream communities; thankfully, they're not all like that!) if you already have the right relationships. New people come into Mozilla and get their patches merged all the time. It certainly does not hurt to know people and talk to them in a cooperative way in any community. Your approach has much less chance of succeeding in either case. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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-related. Likewise, the Perl SIG should have authority over anything Perl-related: if the Perl SIG decides that a new Perl developer @ RH should have commit access to all perl-* packages, it should be their decision to do so, it was really counterproductive of FESCo to interfere with that! If you want a integrated experience, don't work around upstream. Push your patches and get it merged there. 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. :-( Providing system integration is exactly what a distribution is for. You will never achieve an integrated experience by just throwing together disparate upstream tarballs. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 not accepting said patches? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 SIG should have authority over anything KDE-related. Likewise, the Perl SIG should have authority over anything Perl-related: if the Perl SIG decides that a new Perl developer @ RH should have commit access to all perl-* packages, it should be their decision to do so, it was really counterproductive of FESCo to interfere with that! So if someone writes a KDE plugin for Application XYZ, it becomes a KDE package? What? 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. I never got the impression that they were little fiefdoms with absolute power. This is shades of the Federal-power vs. State's Rights debate in the U.S. And for similar reasons, it seems. -J If you want a integrated experience, don't work around upstream. Push your patches and get it merged there. 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. :-( Providing system integration is exactly what a distribution is for. You will never achieve an integrated experience by just throwing together disparate upstream tarballs. Kevin Kofler -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 should have authority over anything KDE-related. 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 the packages are only tangentially related such as Firefox. This is ultimately a power grab and not healthy and will never be acceptable. Besides, you repeatedly refer to the KDE SIG but KDE SIG has made no formal request to the Firefox maintainers.I can't accept that you represent all of KDE SIG's viewpoint in this matter. This appears just your person view points. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 changesets per release seems to be increasing. As does the number of new committers. It's almost like you're talking complete rubbish. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 the packages are only tangentially related such as Firefox. This is ultimately a power grab and not healthy and will never be acceptable. Besides, you repeatedly refer to the KDE SIG but KDE SIG has made no formal request to the Firefox maintainers.I can't accept that you represent all of KDE SIG's viewpoint in this matter. This appears just your person view points. 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 all of the KDE stuff actually went upstream (I'm not sure if it's finally all upstreamed or if there are still patches from go-oo needed; I'll also note that we're the only major distro not to use go-oo), the maintainers said they'd look into enabling it, nothing happened. In Firefox's case, the answer was just trademarks and so we never bothered making a formal request because we know it wouldn't get anywhere. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 odd, because the number of changesets per release seems to be increasing. As does the number of new committers. It's almost like you're talking complete rubbish. Or maybe the situation is slowly improving… :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 all of the KDE stuff actually went upstream (I'm not sure if it's finally all upstreamed or if there are still patches from go-oo needed; I'll also note that we're the only major distro not to use go-oo), the maintainers said they'd look into enabling it, nothing happened. In Firefox's case, the answer was just trademarks and so we never bothered making a formal request because we know it wouldn't get anywhere. My point remains. You cannot claim to represent all of KDE SIG's viewpoints on this matter unless you can point to such a request. Red Hat employees talking to each other in their offices cannot change this. I can't rely on water cooler discussions. It should be public for the sake of transparency in this matter. I recommend KDE SIG push for KDE integration patches upstream. The current approach of trying to force maintainers to accept patches simply does not work. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 those respective themes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 them naturally the best bodies to make decisions related to those respective themes. Kevin Kofler It seems to me that best depends on the point of view of the person in question, and the outcome of a given decision. 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. FESCo might well be viewed as best to deal with policies related to updates across _all_ Fedora SIGs and releases, since that one of the tasks they were _ELECTED_ to perform. Seems you think best is one way in one case, and the other way in the other case. It is this inconsistency that folks are trying to bring to your attention. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 naturally the best bodies to make decisions related to those respective themes. Kevin Kofler For most things, probably, but they're still subject to the packaging guidelines, review guidelines, and FESCO and FAB. In some cases, SIGs have extra guidelines on top of the general guidelines, but they don't exempt themselves from the general guidelines. If someone from a SIG of which I am not a member modifies my package in a way contrary to my wishes, am I supposed to just say Oh, gosh, well, I mean, the SIG is the law, so I have to suck it up.? No. I engage the person in question, and in the event of an unresolvable dispute, I go to FESCO. 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. My point in this example is not to imply that the various guidelines are the law, but to show that unless I missed a rather major announcement, FESCO has authority superior to that of any SIG. Nor is the point of my example to denigrate the expertise gathered in many SIGs. I get that, there are tons. But a group of expert lawyers sitting around the pub are not the same as, say, the Supreme Court, however expert they may be. /rant -J -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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, Live Upgrade, KDE, etc. Right, but that makes them naturally the best bodies to make decisions related to those respective themes. Kevin Kofler It seems to me that best depends on the point of view of the person in question, and the outcome of a given decision. 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. FESCo might well be viewed as best to deal with policies related to updates across _all_ Fedora SIGs and releases, since that one of the tasks they were _ELECTED_ to perform. Seems you think best is one way in one case, and the other way in the other case. It is this inconsistency that folks are trying to bring to your attention. Al Hey, no fair stating the same point as I did, at the same time, but better, and without ranting. That's cheating! :) -J -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 open the napalm dispenser next time. 8^) Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
Once upon a time, Kevin Kofler kevin.kof...@chello.at 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 to work? Why should the KDE SIG be able to force the kernel maintainers to take a patch? What if that patch conflicts with one another SIG wants - who wins (if you can call it winning)? SIGs should stick to their area of expertise. The KDE SIG should work on KDE packages and not assume they know what's best for the rest of the distribution. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 I've yet to see a convincing argument that it should be so. If a patch has technical merit and for some reason is suitable and beneficial for Fedora and not upstream, it should be reasonably easy to convince the maintainer of this. If not, then FESCO. But these are rare cases. Maintaining forks of a slew of packages is not why we're here, for the security and sustainability arguments already ably made. -J -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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. It doesn't make sense to have a SIG for a single package, a SIG needs to be for a set of packages. For example, the Perl SIG is not for just the perl package, but for most perl-* (and IMHO should be responsible for ALL perl-* packages). 2. Even packages primarily maintained by one SIG can be subject to decisions by other SIGs. E.g. I fully accept that the Games SIG should have its say over kdegames as long as they don't step into KDE territory (e.g. requiring us to change the BR kdelibs4-devel to a BR kdelibs-devel = 6:4.0 would be unacceptable), that the SIGs for interpreted languages should have some control over their respective subpackages of kdebindings (and in fact we already try hard to follow their language-specific packaging guidelines there; if we don't, it's a bug) etc. My position is not the KDE SIG should rule everything, it's SIGs must be given authority over their subject matter, even if it means overruling individual maintainers or even, in the worst case, other SIGs, in order to allow for a consistent experience across the distribution. FESCo might well be viewed as best to deal with policies related to updates across _all_ Fedora SIGs and releases, since that one of the tasks they were _ELECTED_ to perform. FESCo is a too central body and the election process is broken in many ways (very low turnaround, too few and not sufficiently diverse candidates etc.). Seems you think best is one way in one case, and the other way in the other case. It is this inconsistency that folks are trying to bring to your attention. This perceived inconsistency just comes out of misunderstandings. There is a middle ground between an authoritarian central authority and anarchic I refuse to apply the patches you need because of XYZ attitudes. SIGs are the right granularity for management. Usually, and by default, the maintainer should be trusted. Where integration across packages is relevant (and that's exactly the case for those KDE _integration_ patches!), that's a matter for the SIGs (who should be allowed to overrule individual maintainers). Our central governing bodies are just bureaucratic overhead. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 only way to go forward. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
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 maintainer in a FireFox SIG and repeat the question. 1. It doesn't make sense to have a SIG for a single package, a SIG needs to be for a set of packages. For example, the Perl SIG is not for just the perl package, but for most perl-* (and IMHO should be responsible for ALL perl-* packages). 2. Even packages primarily maintained by one SIG can be subject to decisions by other SIGs. E.g. I fully accept that the Games SIG should have its say over kdegames as long as they don't step into KDE territory (e.g. requiring us to change the BR kdelibs4-devel to a BR kdelibs-devel= 6:4.0 would be unacceptable), that the SIGs for interpreted languages should have some control over their respective subpackages of kdebindings (and in fact we already try hard to follow their language-specific packaging guidelines there; if we don't, it's a bug) etc. My position is not the KDE SIG should rule everything, it's SIGs must be given authority over their subject matter, even if it means overruling individual maintainers or even, in the worst case, other SIGs, in order to allow for a consistent experience across the distribution. FESCo might well be viewed as best to deal with policies related to updates across _all_ Fedora SIGs and releases, since that one of the tasks they were _ELECTED_ to perform. FESCo is a too central body and the election process is broken in many ways (very low turnaround, too few and not sufficiently diverse candidates etc.). So if I say, Great, if that's what you want to do, run for FESCO, I know what your answer is. :) Seems you think best is one way in one case, and the other way in the other case. It is this inconsistency that folks are trying to bring to your attention. This perceived inconsistency just comes out of misunderstandings. There is a middle ground between an authoritarian central authority and anarchic I refuse to apply the patches you need because of XYZ attitudes. SIGs are the right granularity for management. Ok, but it would seem that the community (as expressed via FESCO) would disagree. If you can campaign and get enough people who agree elected, then there you go. I'm not saying FESCO or it's election processes are infallible, but if you want the system changed to fit what you think it should be, then why can't the system be changed to what *I* think it should be? Usually, and by default, the maintainer should be trusted. Where integration across packages is relevant (and that's exactly the case for those KDE _integration_ patches!), that's a matter for the SIGs (who should be allowed to overrule individual maintainers). Our central governing bodies are just bureaucratic overhead. Well, shoot, so is the police force and the court system, but you still have to abide by the speed limit until you can get your representatives to change it, either by petitioning them or by becoming them. You either work within the system (in Fedora and in Democracy, via elections) or you replace the system (fork the distro, or start a revolution). In replacing the system, however, it's good to have numerical superiority. Democracies circumvent revolution by having elections and so whenever you have a large enough group to violently overthrow the government, they start winning elections and become the government. -J Kevin Kofler -- - in your fear, speak only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
