Re: concept of package ownership
On Thu, 2010-07-01 at 23:28 -0500, Adam Miller wrote: I don't think it really matters what we call it, I just think that package maintainers are starting to get a sense of entitlement and I feel that's counter productive to the open environment we're used to and are trying to help continue to grow. Absolutely. I've often commented on this problem -- we really don't want package maintainers to throw their toys out of the pram when someone touches their package; this is a collaborative effort. In the old days of RHL and beehive, I think we had it about right... with the obvious exception that it was Red Hat only, but the attitude to packaging was right, IMHO. There _was_ someone who knew most about a package and was expected to deal with it most of the time, but it was also perfectly reasonable for other people to work on the packages too. Fedora seems to have regressed a lot in that respect, although it did improve after we started approving ProvenPackagers. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Thu, 2010-07-01 at 21:09 +0200, Chitlesh GOORAH wrote: I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. Petr Pisar seems to mess with my packages. It's simply disgusting !! You haven't provided enough information. What's _wrong_ with helping out by packaging the latest version (I assume that's what he did?) Did he do it only for rawhide, or also with updates for F-13 etc.? Was there a good reason to upgrade? Are there open bugs which are fixed by the old version? Was there a good reason _not_ to upgrade? I see no fundamental reason why a Fedora packager shouldn't update a Fedora package; without any further information my first inclination is to think that you're being far too precious. -- dwmw2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Net-CIDR-Lite-0.21.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Net-CIDR-Lite: 12280b3754886b876918f03f53aee4f5 Net-CIDR-Lite-0.21.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.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Net-CIDR-Lite/EL-6 .cvsignore, 1.3, 1.4 perl-Net-CIDR-Lite.spec, 1.9, 1.10 sources, 1.3, 1.4
Author: pghmcfc
Update of /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv31350
Modified Files:
.cvsignore perl-Net-CIDR-Lite.spec sources
Log Message:
* Fri Jun 2 2010 Paul Howarth p...@city-fan.org - 0.21-1
- Update to 0.21
- Fix spanner clean() docs (CPAN RT#14535)
- Undef dereference with empty object (CPAN RT#25898)
- Add short_list_range() method (CPAN RT#30777)
- clean() or list() before add() causes error (CPAN RT#48308)
- spanner add() did not accept non-object (CPAN RT#50042)
- :: not accepted as valid IPv6 address (CPAN RT#52571)
- Don't create license files
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 21 Mar 2006 22:12:44 - 1.3
+++ .cvsignore 2 Jul 2010 06:39:49 - 1.4
@@ -1 +1 @@
-Net-CIDR-Lite-0.20.tar.gz
+Net-CIDR-Lite-0.21.tar.gz
Index: perl-Net-CIDR-Lite.spec
===
RCS file: /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6/perl-Net-CIDR-Lite.spec,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- perl-Net-CIDR-Lite.spec 26 Jul 2009 13:38:44 - 1.9
+++ perl-Net-CIDR-Lite.spec 2 Jul 2010 06:39:49 - 1.10
@@ -1,6 +1,6 @@
Name: perl-Net-CIDR-Lite
-Version:0.20
-Release:6%{?dist}
+Version:0.21
+Release:1%{?dist}
Summary:Net::CIDR::Lite Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -35,9 +35,6 @@ find $RPM_BUILD_ROOT -depth -type d -exe
%{_fixperms} $RPM_BUILD_ROOT/*
-perldoc -t perlgpl COPYING
-perldoc -t perlartistic Artistic
-
%check
make test
@@ -46,19 +43,20 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
-%doc Changes README COPYING Artistic
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes README
+%{perl_vendorlib}/Net/
+%{_mandir}/man3/Net::CIDR::Lite.3pm*
%changelog
-* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.20-6
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
-
-* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.20-5
-- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-
-* Thu Mar 06 2008 Tom spot Callaway tcall...@redhat.com - 0.20-4
-Rebuild for new perl
+* Fri Jun 2 2010 Paul Howarth p...@city-fan.org - 0.21-1
+- Update to 0.21
+ - Fix spanner clean() docs (CPAN RT#14535)
+ - Undef dereference with empty object (CPAN RT#25898)
+ - Add short_list_range() method (CPAN RT#30777)
+ - clean() or list() before add() causes error (CPAN RT#48308)
+ - spanner add() did not accept non-object (CPAN RT#50042)
+ - :: not accepted as valid IPv6 address (CPAN RT#52571)
+- Don't create license files
* Wed Apr 18 2007 Steven Pritchard st...@kspei.com 0.20-3
- Use fixperms macro instead of our own chmod incantation.
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Net-CIDR-Lite/EL-6/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 21 Mar 2006 22:12:45 - 1.3
+++ sources 2 Jul 2010 06:39:49 - 1.4
@@ -1 +1 @@
-54998db6b297ffc8a20adb91ea744200 Net-CIDR-Lite-0.20.tar.gz
+12280b3754886b876918f03f53aee4f5 Net-CIDR-Lite-0.21.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.fedoraproject.org/mailman/listinfo/perl-devel
Re: Evolution update in F13
On Fri, Jul 02, 2010 at 03:46:29AM +0200, Kevin Kofler wrote: Kevin Fenzi wrote: It's only in updates-testing yet. Now this is complete nonsense. The update is required to fix broken dependencies so it should go to stable IMMEDIATELY. people make mistakes. it happens, no big deal. pushing it to testing helps to ensure the fix won't be another screwup but really fixes the issue. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
2010/7/1, Chitlesh GOORAH chitlesh.goo...@gmail.com: Hello there, I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. Petr Pisar seems to mess with my packages. It's simply disgusting !! Chitlesh ! It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. imho that you have to ask him now why he did this is an unbounded cheek. he has to ask or informyou BEFORE he twiddled with your package. This is a minimum of respect he should give to you as maintainer of this package! -- Josephine Fine Tannhäuser -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The one exception being Mozilla. There is nothing Red Hat specific about it. imho that you have to ask him now why he did this is an unbounded cheek. he has to ask or informyou BEFORE he twiddled with your package. This is a minimum of respect he should give to you as maintainer of this package! Respect is mutual. IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide and if there are mistakes in the process which will happen from time to time, deal with it politely offlist. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 09:37 AM, Rahul Sundaram wrote: On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. I am not sure what I should think of this from a general perspective. Fact is, except of committing a couple of beginner mistakes, at least Petr Pisar so far has been doing an excellent job. Respect is mutual. Yes. Please understand that Fedora is a community project. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
2010/7/2 Chitlesh GOORAH chitlesh.goo...@gmail.com: Hello there, I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. It looks like Petr Pisar just fixed some FTBTS bugs in rawhide after mass-rebuiding of all perl-related packages. If he done anything wrong to violate fedora packaging guideline, you can point them out, otherwise I don't think it's a serious problem for fixing FTBTS bugs before notifying particular maintainers. See https://fedoraproject.org/wiki/Features/perl5.12 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 01:23 PM, Ralf Corsepius wrote: The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. I am not aware of the specifics here. Fedora's sponsorship model allows any sponsor to approve a new person to become a package maintainer . If there is a process violation, file it with FESCo but as the ongoing other thread related to this topic, less rigid idea of ownership is the right mind set. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to lure me to updates-testing
On 2010/07/01 10:46 AM, Adam Williamson wrote: On Wed, 2010-06-30 at 16:44 -0500, Michael Cronenworth wrote: Nathanael Noblet wrote: I presume a fedora account with certs are required for this? Yes, but for your karma to have any merit, you need a Fedora account. Non-Fedora account karma does not count. I agree a GUI would be nice for all of this, and I would be willing to create one, but time has been an issue lately. If we're in pony mode, sure, this is a pony I would also like to see. :) Although I think perhaps it would be best to integrate the functions into PackageKit (perhaps as an optional extension package) than to write an entirely new tool. FWIW I wanted to mention that I think this is an excellent idea. I read FedoraForum often (as does Adam) and it's not uncommon to see rant threads posted by users who need to vent because not only are they frustrated that software XYZ isn't working properly, but the path to resolving the problem is unclear. These users have valuable feedback but don't know how to tell it to the packagers developers, or perhaps don't realize that they can at all... From what I can tell, this situation is what seems to be causing a great deal of frustration to many users. Getting users involved in the QA process by giving them the tools they need to provide feedback in an easy, simple manner will benefit users and developers. I understand that we're still at the planning stage, but I would be happy to write some documentation on the forum and post it as a sticky once the tools are user-ready. Stewart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 10:05 AM, Rahul Sundaram wrote: On 07/02/2010 01:23 PM, Ralf Corsepius wrote: The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. I am not aware of the specifics here. I am mostly familiar with it. Fedora's sponsorship model allows any sponsor to approve a new person to become a package maintainer . If there is a process violation, There was: These people are apparent new-comers and have been granted access to several 100s (in the order of 1000) packages. file it with FESCo but as the ongoing other thread related to this topic, less rigid idea of ownership is the right mind set. The problem is not ownership the problem is qualification and double standards. That said, I can't avoid having to agree to Josephine. The Petr's hardly would have been granted this amount of CVS access if they had not been @RH. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Chitlesh GOORAH wrote, at 07/02/2010 04:09 AM +9:00: Hello there, I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. Petr Pisar seems to mess with my packages. It's simply disgusting !! Chitlesh ! Apart from politeness, I want to clarify what actually occurred here: Perhaps Chitlesh complained about this change: http://lists.fedoraproject.org/pipermail/scm-commits/2010-May/433306.html http://cvs.fedoraproject.org/viewvc/rpms/perl-SystemPerl/devel/?pathrev=perl-SystemPerl-1_334-1_fc14 However, looking carefully: --- Author: mmaslano Update of /cvs/pkgs/rpms/perl-SystemPerl/devel In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv26946 Modified Files: .cvsignore perl-SystemPerl.spec sources Log Message: * Thu May 13 2010 Petr Pisar ppisar at redhat.com - 1.334-1 - Version bump - Disable parallel make (https://rt.cpan.org/Public/Bug/Display.html?id=57469) --- So the actually committer is not ppisar but mmaslano. Actually as far as I checked the pkgdb / FAS, ppisar does not have any acls for perl-SystemPerl. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 11:35 AM, Mamoru Tasaka wrote: Chitlesh GOORAH wrote, at 07/02/2010 04:09 AM +9:00: Hello there, I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. Petr Pisar seems to mess with my packages. It's simply disgusting !! Chitlesh ! Apart from politeness, I want to clarify what actually occurred here: Perhaps Chitlesh complained about this change: http://lists.fedoraproject.org/pipermail/scm-commits/2010-May/433306.html http://cvs.fedoraproject.org/viewvc/rpms/perl-SystemPerl/devel/?pathrev=perl-SystemPerl-1_334-1_fc14 Lets see if I got this right: 2009-09-15 chitlesh updates to 1.331, build fails 2009-12-07 kasal does mass perl 5.10.1 rebuild, build fails 2010-05-12 mmaslano does mass perl 5.10.2 rebuild, build fails 2010-05-14 mmaslano checks in ppisar's change which fixes the build 2010-07-01 chitlesh sends this mail So, the build was broken for 8 months, then mmaslano (a provenpackager) checked in a fix. After another 7 weeks, Chitlesh finally notices someone has fixed the package and says its disgusting. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Kalev Lember wrote, at 07/02/2010 05:51 PM +9:00: On 07/02/2010 11:35 AM, Mamoru Tasaka wrote: Chitlesh GOORAH wrote, at 07/02/2010 04:09 AM +9:00: Hello there, I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. Petr Pisar seems to mess with my packages. It's simply disgusting !! Chitlesh ! Apart from politeness, I want to clarify what actually occurred here: Perhaps Chitlesh complained about this change: http://lists.fedoraproject.org/pipermail/scm-commits/2010-May/433306.html http://cvs.fedoraproject.org/viewvc/rpms/perl-SystemPerl/devel/?pathrev=perl-SystemPerl-1_334-1_fc14 Lets see if I got this right: 2009-09-15 chitlesh updates to 1.331, build fails 2009-12-07 kasal does mass perl 5.10.1 rebuild, build fails 2010-05-12 mmaslano does mass perl 5.10.2 rebuild, build fails 2010-05-14 mmaslano checks in ppisar's change which fixes the build 2010-07-01 chitlesh sends this mail It seems so. http://koji.fedoraproject.org/koji/packageinfo?packageID=8618 So, the build was broken for 8 months, then mmaslano (a provenpackager) checked in a fix. After another 7 weeks, Chitlesh finally notices someone has fixed the package and says its disgusting. Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 01:56 PM, Ralf Corsepius wrote: That said, I can't avoid having to agree to Josephine. The Petr's hardly would have been granted this amount of CVS access if they had not been @RH. It seems Chitlesh was wrong and the person doing the commit was different. You seem to be complaining about a different issue altogether. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Dne 2.7.2010 09:37, Rahul Sundaram napsal(a): On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The one exception being Mozilla. There is nothing Red Hat specific about it. a) even more strongly, being a Red Hat employee doesn't give you anything ... you have to go through the Fedora provenpackager process b) if you don't like provenpackagers to mess with your packages, go and make a switch in pkgdb. Matěj -- We can tell our level of faith in what God wants to do for us by our level of enthusiasm for what we want God to do for other. -- Dave Schmelzer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Matěj Cepl wrote: b) if you don't like provenpackagers to mess with your packages, go and make a switch in pkgdb. http://fedoraproject.org/wiki/Provenpackager_policy To exclude a package from provenpackagers access, you have to open a ticket at FESCo issue tracker and explain why provenpackagers should not have access to it. FESCo will discuss and vote on one of its weekly meetings about your request. ProvenPackagers are there precisely to do what it looks like happened with : http://koji.fedoraproject.org/koji/packageinfo?packageID=8618 Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! Btw, there is: https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages and if there are mistakes in the process which will happen from time to time, deal with it politely offlist. Agreed. And the initial message that started this thread is lacking details. Still it's reason to be concerned. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
Dne 2.7.2010 06:28, Adam Miller napsal(a): I don't think it really matters what we call it, I just think that package maintainers are starting to get a sense of entitlement and I feel that's counter productive to the open environment we're used to and are trying to help continue to grow. I don't think it is that much matter of words, but matter of culture. Wandering provenpackagers (although they were not called that then) were the most striking difference for me when I came from the Debian world, where the possesion of the package is much stronger concept. Probably with increasing number of Ubuntu converts coming to Fedora world, we need to stress this more? Matěj -- Q: Is vi an easy editor to learn, is it intuitive? A: Yes, some of us think so. But most people think that we are crazy. -- vi FAQ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
David Woodhouse píše v Pá 02. 07. 2010 v 07:08 +0100: On Thu, 2010-07-01 at 21:09 +0200, Chitlesh GOORAH wrote: I would appreciate if someone else who is NEITHER a co-maintainer NOR FESCo member don't version bump my packages, without notifying me. Petr Pisar seems to mess with my packages. It's simply disgusting !! You haven't provided enough information. What's _wrong_ with helping out by packaging the latest version (I assume that's what he did?) Did he do it only for rawhide, or also with updates for F-13 etc.? Was there a good reason to upgrade? Are there open bugs which are fixed by the old version? Was there a good reason _not_ to upgrade? I see no fundamental reason why a Fedora packager shouldn't update a Fedora package; without any further information my first inclination is to think that you're being far too precious. (Completely abstracting from the specifics of this package, about which I don't know anything.) Fedora expects a package maintainer to be the main go to person, to handle bug reports, update the package for RPM changes, compiler changes, packaging standards and so forth - even if all the maintainer really cares about is that the package works in their particular environment with their particular Fedora version. Many package maintainers don't get anything in return except for the minimal reward of being known as the maintainer of the package. Because the maintainer will be expected to deal with the resulting bug reports, it seems quite reasonable to me that the maintainer should at least be consulted about non-trivial changes to the package. Also, changing a package contrary to the wishes of primary maintainer removes their authority and discretion over the tasks they are expected to do, which is understood to decrease intrinsic motivation. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 02 Jul 2010 10:33:52 +0100, Mark wrote: ProvenPackagers are there precisely to do what it looks like happened with : http://koji.fedoraproject.org/koji/packageinfo?packageID=8618 Wait a minute, it's not that easy. Provenpackagers are not supposed to jump in every N months, apply a fix, but leave a package unmaintained for the rest of the time. Such a package should become an orphan and be assigned to a new maintainer. What's currently referred to as package owner(s) is the primary maintainer(s) who ought to keep the packages and builds in a good state and who also ought to take care of bugzilla tickets. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 02 Jul 2010 11:40:11 +0200, Matěj wrote: Dne 2.7.2010 11:34, Michael Schwendt napsal(a): Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! The primary package maintainer (see the other thread about owning a package) who has a package 8 months in FTBFS doesn't have much rights in my thinking. The provenpackager, who has had 8 month to notice such a problem, has had 8 months to start the non-responsive maintainer procedure. What will happen the next time the package is affected by a bad problem? Does the same provenpackager now keep an eye on the package and will be available to fix it much sooner? Or will it takes 8 months again, because that is possible in the Fedora package collection? Matěj /thread Feel free to consider it closed and don't reply anymore. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Excerpts from Michael Schwendt's message of Fri Jul 02 11:34:38 +0200 2010: On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! Btw, there is: https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages There was email sent out to perl mailing list about this AFAIK. And NOT one person sent an email to complain (I believe there was a few day window between mail sent to perl mailing list and mass change of packagers) -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 11:40:11AM +0200, Matěj Cepl wrote: Dne 2.7.2010 11:34, Michael Schwendt napsal(a): Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! The primary package maintainer (see the other thread about owning a package) who has a package 8 months in FTBFS doesn't have much rights in my thinking. I think that this is very wrong. I don't know the specifics of this package either, but I remember that for one of my packages, I had to hold of correcting a FTBS because it meant upgrading, and I coudn't do that because of some incompatibilities. Bottom line is -- unless it changed -- in the spirit of provenpackager policies for non urgent things like FTBS, provenpackagers should do as little as possible, contact packagers before doing anything, do change in cvs but let time for the packager to build or revert. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Michael Schwendt wrote: On Fri, 02 Jul 2010 10:33:52 +0100, Mark wrote: ProvenPackagers are there precisely to do what it looks like happened with : http://koji.fedoraproject.org/koji/packageinfo?packageID=8618 Wait a minute, it's not that easy. Provenpackagers are not supposed to jump in every N months, apply a fix, but leave a package unmaintained for the rest of the time. Such a package should become an orphan and be assigned to a new maintainer. Yes, but they are supposed to fix significant issue like Perl packages which FTBFS after a PERL version update if the maintainer doesn't. Or long standing bugs with NO comments from the developers. Should they also then kick off the orphaning process would be a question for FESCo Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
Patrice Dumas wrote: I think that this is very wrong. I don't know the specifics of this package either, but I remember that for one of my packages, I had to hold of correcting a FTBS because it meant upgrading, and I coudn't do that because of some incompatibilities. So at least comment on the Bugzilla ticket, at which point the PP would know what was going on and leave well alone. Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of wxGTK without the internal crash handler in Rawhide
Kevin Kofler píše v Pá 02. 07. 2010 v 04:06 +0200: Dan Horák wrote: I will rebuild wxGTK without the internal crash handler for the the devel/F14 branch so we can use ABRT to report crashes from wxGTK-based apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and this change affects all applications linked with wxGTK, because one symbol is removed from the base library. I will take care of rebuilding the packages in the next days, but the package owners should still check what is their implementation of the wxApp::OnFatalExpection() virtual method doing, because it will not be called anymore. Usually it is used to display the wxGTK-based crash report. Please let me know if you want to rebuild the package yourself or if you have some questions. Do you really think this is a good idea? IMHO crash reports should go upstream, so using upstream's crash handler is a much better idea. ABRT spams our downstream Bugzilla with crash reports which really should go upstream instead. It's also technically nicer for the crash handler to be in the app, since it prevents having to dump core and then having an external process inspect the core dump. But the default crash handler only creates a text file with a rather useless stack trace and the file is stored on the local computer. So in fact the crash is lost for everybody but the concrete user who usually can do nothing with it. If someone from the application maintainers will come with an argument against, we can discuss a better solution. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 582163] Review Request: perl-Test-Smoke - Perl core test smoke suite
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=582163 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: who is Petr Pisar from redhat ?
I get the feeling that no one on this thread has looked into https://fedorahosted.org/fesco/ticket/403 So this has already been handled by FESCo, mistakes have been made and most likely will be avoided in the future. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 02 Jul 2010 11:42:10 +0100, Mark wrote: ProvenPackagers are there precisely to do what it looks like happened with : http://koji.fedoraproject.org/koji/packageinfo?packageID=8618 Wait a minute, it's not that easy. Provenpackagers are not supposed to jump in every N months, apply a fix, but leave a package unmaintained for the rest of the time. Such a package should become an orphan and be assigned to a new maintainer. Yes, but they are supposed to fix significant issue like Perl packages which FTBFS after a PERL version update They _may_ fix those packages (it's described in the Wiki *when* a fix may be considered important), but what kind of fix they apply may be subject to prior discussion. Some types of packages may be trivial to fix with/without a version upgrade. For other packages a version upgrade could result in further significant issues. Something a dedicated maintainer would need to take care of and not just an arbitrary provenpackager, who happens to notice issues after N weeks/months. if the maintainer doesn't. The important thing to find out would be why the maintainer doesn't fix issues, which are considered significant. Or long standing bugs with NO comments from the developers. Which *could* imply that the package is unmaintained. Not always, because tickets could be useless, but somebody to look into it would be good. Currently, at dist end-of-life, valid bug reports are killed by scripts without anyone fixing the bugs. Should they also then kick off the orphaning process would be a question for FESCo It depends and is beyond the scope of this thread (because of a poorly chosen Subject line). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of wxGTK without the internal crash handler in Rawhide
On Fri, Jul 2, 2010 at 12:58 PM, Dan Horák d...@danny.cz wrote: Kevin Kofler píše v Pá 02. 07. 2010 v 04:06 +0200: Dan Horák wrote: I will rebuild wxGTK without the internal crash handler for the the devel/F14 branch so we can use ABRT to report crashes from wxGTK-based apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and this change affects all applications linked with wxGTK, because one symbol is removed from the base library. I will take care of rebuilding the packages in the next days, but the package owners should still check what is their implementation of the wxApp::OnFatalExpection() virtual method doing, because it will not be called anymore. Usually it is used to display the wxGTK-based crash report. Please let me know if you want to rebuild the package yourself or if you have some questions. Do you really think this is a good idea? IMHO crash reports should go upstream, so using upstream's crash handler is a much better idea. ABRT spams our downstream Bugzilla with crash reports which really should go upstream instead. It's also technically nicer for the crash handler to be in the app, since it prevents having to dump core and then having an external process inspect the core dump. But the default crash handler only creates a text file with a rather useless stack trace and the file is stored on the local computer. This question might not be very popular, but do you really think that a, in your eyes useless stack trace (upstream obviously want that) is any better than a useless ABRT backtrace? The not popular part comes in as the ABRT backtrace is useless as almost nobody of the packagers/maintainers are able to read it (me included) and upstream doesn't care about it. All that happens is that our BZ gets spammed with it. Yes, i'm a bit frustrated about this traces :-) I really really would love to see at least one ABRT developer giving a class (we have #fedora-classroom for that) how to read and understand ABRT backtraces. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, Jul 01, 2010 at 03:13:55PM -0700, Jesse Keating wrote: On 7/1/10 2:55 PM, Till Maas wrote: But I guess somehow it boils down to the majority wants that other people to work for them, which might even be true. But in a FOSS community I doubt it is very healthy to follow this too much. I bet if we stopped making package reviews mandatory, none would get done. This follows the same. This is an interesting comparison, because there are still not enough reviewers even though it is mandatory. Also everyone directly benefits from the reviews, because there are clear statements what is checked and there are more often issues to be fixed in reviews, than there are updates that are bad. And in addition people who care already extra review packages and catch issues that were not found in the official review or check packages after guidelines changed, like there are checks for the static libs guidelines. So there is non mandatory action to fix brokenness and I am very sure that there would be more if more packages were when reviews were not mandatory, as long as the Guidelines make sense and help the packages to interact. There are even people catching mistakes in commits currently, which is also completely non mandatory. Regards Till pgpAZ0M5G2HyR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 2010-07-02 at 11:34 +0200, Michael Schwendt wrote: On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! I think you are spot-on with this comment. There probably wouldn't be such a discussion if the (proven)packager simply stated his intentions to the package maintainer. Léon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 2010-07-02 at 13:55 +0200, Léon Keijser wrote: On Fri, 2010-07-02 at 11:34 +0200, Michael Schwendt wrote: On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! I think you are spot-on with this comment. There probably wouldn't be such a discussion if the (proven)packager simply stated his intentions to the package maintainer. That doesn't really scale, on a single package basis yeah maybe, if I have to bump 10 or 15 packages after a mass rebuild it get ugly quick. You get mails from CVS, its all in version control, if you disagree with what they did, back it out, state in the spec what they did wrong. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 12:03:34PM +0200, Michael Schwendt wrote: On Fri, 02 Jul 2010 11:40:11 +0200, Matěj wrote: Dne 2.7.2010 11:34, Michael Schwendt napsal(a): Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! The primary package maintainer (see the other thread about owning a package) who has a package 8 months in FTBFS doesn't have much rights in my thinking. The provenpackager, who has had 8 month to notice such a problem, has had 8 months to start the non-responsive maintainer procedure. What will happen the next time the package is affected by a bad problem? Does the same provenpackager now keep an eye on the package and will be available to fix it much sooner? Or will it takes 8 months again, because that is possible in the Fedora package collection? Afaik there is no good procedure available for these kind of issues. The worst case is that the package is not fixed, the best case is that there is one dedicated maintainer that starts to care about the package and the described actions are in-between. But it seems not to worry anyone enough to do something about it, e.g. like implementing a package monkey group that maintains together a lot of packages none of the members would like to maintain alone without all the bureaucracy of acking changes to the package by the bad-responsive package maintainer or a package watch list might be another idea to watch these kind of packages. Regards Till pgpJvaUR1J8hT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide 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 possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-DBI-Dumper
perl-DBI-Dumper has broken dependencies in the rawhide tree: On x86_64: perl-DBI-Dumper-2.01-8.fc12.x86_64 requires perl(:MODULE_COMPAT_5.10.0) On i386: perl-DBI-Dumper-2.01-8.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 01:55:21PM +0200, Léon Keijser wrote: I think you are spot-on with this comment. There probably wouldn't be such a discussion if the (proven)packager simply stated his intentions to the package maintainer. Just to step into this for a moment, but this wouldn't work (in this case) since it took the package maintainer nearly 2 months to realize that his package had been updated by the provenpackager. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpt26nUcGYA2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
2010-07-02 03:18 keltezéssel, Kevin Kofler írta: Dave Airlie wrote: So I've noticed maintainers of packages in Fedora seem to have a concept of ownership, and I'm wondering if we could remove that word from usage about maintainership. +1 IMHO any sponsored packager should be free to do changes which benefit the Fedora Project to any package, no matter who officially maintains the package. And such changes include things like upgrading the package to the current upstream release in Rawhide, especially when that release is needed for other packages. Even a provenpackager can't always make such changes without getting yelled at. I think we need to get rid of the concept of ownership entirely, that'd also make orphaned or de-facto orphaned packages less of a problem. You see a problem, you fix it. Who cares whether the package has an active maintainer or not? +1 I'd like to get syslog-ng updated to the latest version in Rawhide (I work part time for the upstream developer and I'm also an occasional Fedora user). I contacted the package owner, no response. Created a bugreport to get it updated ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ), and also provided an updated package, which compiles and works fine on Fedora 12, 13 and Rawhide. After waiting for weeks, I started a maintainer time out. It was closed within an hour. I got some comments on bugzilla, but nothing happened ever since. The updated package was never downloaded from my website. What can I do in this situation? Obviously I'm not a proven packager to update the package myself, as I'm not a Fedora developer. I worked a lot to update and test the package, but still I'm stuck. And as you can see, the maintainer timeout procedure does not help either... Bye, CzP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
@fedoraproject.org email alias
I have just joined as a member and co-maintainer of the Fedora Design Suite. Apparently, as a member of the Fedora community I am entitled to the email alias foxmulder...@fedoraproject.org. Whereas foxmulder881 is my username. Now I can't for the life of me get the email alias to work correctly and every time I send an email to that address as a test, it bounces. What's going on or what am I doing wrong? Regards -- Chris Jones Photographic Imaging Professional and Graphic Designer ABN: 98 317 740 240 Photo Resolutions - Photo Printing, Editing and Restorations Web: http://photoresolutions.freehostia.com Email: chrisjo...@comcen.com.au or ubuntu...@comcen.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100702 changes
Compose started at Fri Jul 2 08:15:29 UTC 2010 Broken deps for i386 -- BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl FlightGear-2.0.0-2.fc14.i686 requires libosgText.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgSim.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgUtil.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgFX.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgGA.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgParticle.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosg.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgDB.so.55 FlightGear-2.0.0-2.fc14.i686 requires libosgViewer.so.55 SimGear-2.0.0-1.fc14.i686 requires libosg.so.55 SimGear-2.0.0-1.fc14.i686 requires libosgDB.so.55 SimGear-2.0.0-1.fc14.i686 requires libosgParticle.so.55 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12 eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle-optional = 0:4.1 eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle = 0:4.1 esperanza-0.4.0-6.fc13.i686 requires libxmmsclient.so.5 esperanza-0.4.0-6.fc13.i686 requires libxmmsclient++.so.3 gnome-phone-manager-0.65-6.fc14.i686 requires libgnome-bluetooth.so.7 1:gnumeric-plugins-extras-1.10.0-1.fc14.i686 requires perl(:MODULE_COMPAT_5.10.1) 1:imlib-devel-1.9.15-14.fc14.i686 requires libjpeg-devel(x86-32) libpeas-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0 libpeas-devel-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0 maven2-plugin-checkstyle-2.0.8-3.fc12.noarch requires checkstyle-optional = 0:4.1 merkaartor-0.16.1-1.fc13.i686 requires libexiv2.so.6 mrpt-apps-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-apps-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-apps-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-apps-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-apps-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-base-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-base-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-base-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-base-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-base-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-gui-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-gui-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-gui-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-gui-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-gui-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-hmtslam-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-hwdrivers-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-maps-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-maps-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-maps-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-maps-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-maps-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-obs-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-obs-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-obs-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-obs-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-obs-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-opengl-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-opengl-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-opengl-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-opengl-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-opengl-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libml.so.2.0 mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libcxcore.so.2.0 mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libhighgui.so.2.0 mrpt-reactivenav-0.9.0-0.3.fc14.i686 requires libcvaux.so.2.0 mrpt-slam-0.9.0-0.3.fc14.i686 requires libcv.so.2.0 mrpt-slam-0.9.0-0.3.fc14.i686 requires libml.so.2.0
Re: who is Petr Pisar from redhat ?
On 07/02/2010 01:55 PM, Léon Keijser wrote: On Fri, 2010-07-02 at 11:34 +0200, Michael Schwendt wrote: On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! I think you are spot-on with this comment. There probably wouldn't be such a discussion if the (proven)packager simply stated his intentions to the package maintainer. Léon I wrote to perl-sig that we are working on perl5.12 update, which means rebuild of all packages. Also I sent list of failed packages. Some of them were fixed by maintainers, some of them were fixed by me or other people from perl-sig. I suppose every perl maintainer read perl-sig mailing list or see changelog, which explained the change. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On Fri, Jul 2, 2010 at 2:23 PM, Peter Czanik pcza...@fang.fa.gau.hu wrote: 2010-07-02 03:18 keltezéssel, Kevin Kofler írta: Dave Airlie wrote: So I've noticed maintainers of packages in Fedora seem to have a concept of ownership, and I'm wondering if we could remove that word from usage about maintainership. +1 IMHO any sponsored packager should be free to do changes which benefit the Fedora Project to any package, no matter who officially maintains the package. And such changes include things like upgrading the package to the current upstream release in Rawhide, especially when that release is needed for other packages. Even a provenpackager can't always make such changes without getting yelled at. I think we need to get rid of the concept of ownership entirely, that'd also make orphaned or de-facto orphaned packages less of a problem. You see a problem, you fix it. Who cares whether the package has an active maintainer or not? Well, who's the one in charge for bugreports within that system? Everyone? Nobody? I see a lot of who cares and frustration coming up with that everyone builds what he think he have to build system. +1 I'd like to get syslog-ng updated to the latest version in Rawhide (I work part time for the upstream developer and I'm also an occasional Fedora user). I contacted the package owner, no response. Created a bugreport to get it updated ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ), and also provided an updated package, which compiles and works fine on Fedora 12, 13 and Rawhide. After waiting for weeks, I started a maintainer time out. It was closed within an hour. I got some comments on bugzilla, but nothing happened ever since. The updated package was never downloaded from my website. What can I do in this situation? Obviously I'm not a proven packager to update the package myself, as I'm not a Fedora developer. I worked a lot to update and test the package, but still I'm stuck. And as you can see, the maintainer timeout procedure does not help either... You have to accept the maintainers decision to not update it yet? What do you think will happen if everyone builds the wishes he has and breaks a lot of stuff with it? Anarchy? We have processes for that in Fedora: https://fedoraproject.org/wiki/MikeKnox/AWOL_Maintainers I'm really trying very hard to see it positive. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 01:58 PM, Dave Airlie wrote: On Fri, 2010-07-02 at 13:55 +0200, Léon Keijser wrote: On Fri, 2010-07-02 at 11:34 +0200, Michael Schwendt wrote: On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! I think you are spot-on with this comment. There probably wouldn't be such a discussion if the (proven)packager simply stated his intentions to the package maintainer. That doesn't really scale, on a single package basis yeah maybe, Exactly. The perl-5.12.x rebuild involved ca. 1500 packages ;) You get mails from CVS, its all in version control, if you disagree with what they did, back it out, state in the spec what they did wrong. Exactly. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 02 Jul 2010 21:58:10 +1000, Dave wrote: On Fri, 2010-07-02 at 13:55 +0200, Léon Keijser wrote: On Fri, 2010-07-02 at 11:34 +0200, Michael Schwendt wrote: On Fri, 02 Jul 2010 13:07:45 +0530, Rahul wrote: IMO, there is absolutely nothing wrong with anyone with commit access updating packages in Rawhide Of course there is. There ought to be prior communication about such plans to upgrade a package. The primary package maintainer may have good reasons for not upgrading the package. Just ask! I think you are spot-on with this comment. There probably wouldn't be such a discussion if the (proven)packager simply stated his intentions to the package maintainer. That doesn't really scale, on a single package basis yeah maybe, if I have to bump 10 or 15 packages after a mass rebuild it get ugly quick. Could be that devel list is doomed. Normal mass-rebuilds most of the time are not a problem at all. If, however, with bump 10 or 15 packages you include a version-upgrade of 10 or 15 packages, then we're not talking about the same thing. You get mails from CVS, its all in version control, if you disagree with what they did, back it out, state in the spec what they did wrong. Would only work if nothing got built already. Else an Epoch bump would be needed for version upgrades the maintainer doesn't agree with. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 01:33:05PM +0200, Till Maas wrote: I do not want to be asked for trivial changes to my packages that fix bugs I neglected or rebuild it because of an update of a dependency. I am happy for every work I do not have to do and sending extra mails for such changes reduces the offload significantly, e.g. bumping the SPEC and starting a rebuild takes about the same time to read and write a mail. bumping and doing a rebuild may be always considered harmless. But anything else is not. It could fall in the provenpackager policy, in case provenpackagers should follow it. Otherwise there is no policy and packagers should ok changes to their packages. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On Fri, Jul 02, 2010 at 02:23:43PM +0200, Peter Czanik wrote: 2010-07-02 03:18 keltezéssel, Kevin Kofler írta: I think we need to get rid of the concept of ownership entirely, that'd also make orphaned or de-facto orphaned packages less of a problem. You see a problem, you fix it. Who cares whether the package has an active maintainer or not? That's very much against the fedora policies. I'd like to get syslog-ng updated to the latest version in Rawhide (I work part time for the upstream developer and I'm also an occasional Fedora user). I contacted the package owner, no response. Created a bugreport to get it updated ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ), and also provided an updated package, which compiles and works fine on Fedora 12, 13 and Rawhide. After waiting for weeks, I started a maintainer time out. It was closed within an hour. Indeed. Maintainer time out are for completly missing maintainers, not to force them to apply a change. Obviously I'm not a proven packager to update the package myself, as I'm not a Fedora developer. Even if you were a provenpackager you would be forbidden from doing that. Provenpackagers right to modify other people packages are far from being that large. Have a look at the relevant policy if you want more information. I worked a lot to update and test the package, but still I'm stuck. And as you can see, the maintainer timeout procedure does not help either... And the provenpackager policy wouldn't help either. In the past we proposed a policy for that kind of issues with Rahul, but it was never approved (nor really considered). http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance The only thing that can be done, right now for such issues is the traditional escalation procedure. I don't know if it is documented anywhere, but it is along * make yourself clear in a bugreport (which is already done) * explain the issue on the devel list (guess you already did that) * escalate to FESCo -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rebuild of wxGTK without the internal crash handler in Rawhide
Thomas Janssen píše v Pá 02. 07. 2010 v 13:21 +0200: On Fri, Jul 2, 2010 at 12:58 PM, Dan Horák d...@danny.cz wrote: Kevin Kofler píše v Pá 02. 07. 2010 v 04:06 +0200: Dan Horák wrote: I will rebuild wxGTK without the internal crash handler for the the devel/F14 branch so we can use ABRT to report crashes from wxGTK-based apps. This will mean a rebuild of wxGTK with --disable-catch_segvs and this change affects all applications linked with wxGTK, because one symbol is removed from the base library. I will take care of rebuilding the packages in the next days, but the package owners should still check what is their implementation of the wxApp::OnFatalExpection() virtual method doing, because it will not be called anymore. Usually it is used to display the wxGTK-based crash report. Please let me know if you want to rebuild the package yourself or if you have some questions. Do you really think this is a good idea? IMHO crash reports should go upstream, so using upstream's crash handler is a much better idea. ABRT spams our downstream Bugzilla with crash reports which really should go upstream instead. It's also technically nicer for the crash handler to be in the app, since it prevents having to dump core and then having an external process inspect the core dump. But the default crash handler only creates a text file with a rather useless stack trace and the file is stored on the local computer. This question might not be very popular, but do you really think that a, in your eyes useless stack trace (upstream obviously want that) is what upstream? wxGTK upstream (who adds the default handler) is generally not interested in crashed application. And the application should build its own handler only if the symbol wxUSE_ON_FATAL_EXCEPTION is defined by the wxGTK library as it's an optional functionality. any better than a useless ABRT backtrace? The not popular part comes in as the ABRT backtrace is useless as almost nobody of the packagers/maintainers are able to read it (me included) and upstream doesn't care about it. All that happens is that our BZ gets spammed with it. Yes, i'm a bit frustrated about this traces :-) I really really would love to see at least one ABRT developer giving a class (we have #fedora-classroom for that) how to read and understand ABRT backtraces. The backtraces ABRT generates are not specific to ABRT, they are normal backtraces from gdb, so anyone with enough gdb and debugging knowledge could do it. ABRT ensures that the backtrace is generated with debug information installed meaning it will contain more useful information. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
2010/7/2 Patrice Dumas pertu...@free.fr: On Fri, Jul 02, 2010 at 02:23:43PM +0200, Peter Czanik wrote: 2010-07-02 03:18 keltezéssel, Kevin Kofler írta: I think we need to get rid of the concept of ownership entirely, that'd also make orphaned or de-facto orphaned packages less of a problem. You see a problem, you fix it. Who cares whether the package has an active maintainer or not? That's very much against the fedora policies. I'd like to get syslog-ng updated to the latest version in Rawhide (I work part time for the upstream developer and I'm also an occasional Fedora user). I contacted the package owner, no response. Created a bugreport to get it updated ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ), and also provided an updated package, which compiles and works fine on Fedora 12, 13 and Rawhide. After waiting for weeks, I started a maintainer time out. It was closed within an hour. Indeed. Maintainer time out are for completly missing maintainers, not to force them to apply a change. Obviously I'm not a proven packager to update the package myself, as I'm not a Fedora developer. Even if you were a provenpackager you would be forbidden from doing that. Provenpackagers right to modify other people packages are far from being that large. Have a look at the relevant policy if you want more information. I worked a lot to update and test the package, but still I'm stuck. And as you can see, the maintainer timeout procedure does not help either... And the provenpackager policy wouldn't help either. In the past we proposed a policy for that kind of issues with Rahul, but it was never approved (nor really considered). http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance The only thing that can be done, right now for such issues is the traditional escalation procedure. I don't know if it is documented anywhere, but it is along * make yourself clear in a bugreport (which is already done) * explain the issue on the devel list (guess you already did that) * escalate to FESCo -- I think escalating to FESCo is only suitable for changes which are controversial between different people, we should have another policy to treat those non-responsive issues, maintainers should respond on bugzilla report in time. Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On 07/02/2010 06:46 PM, Patrice Dumas wrote: In the past we proposed a policy for that kind of issues with Rahul, but it was never approved (nor really considered). http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance I had forgotten about this but since becoming provenpackager I have helped out in simple rebuilds or even version bumps on occasions and have gotten positive feedback. The written policy is rather rigid but people tend to be more flexible about others helping out in effect. We should generally assume goodwill and not try to mandate common sense via minute policies. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
Hello, 2010-07-02 14:48 keltezéssel, Thomas Janssen írta: +1 I'd like to get syslog-ng updated to the latest version in Rawhide (I work part time for the upstream developer and I'm also an occasional Fedora user). I contacted the package owner, no response. Created a bugreport to get it updated ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ), and also provided an updated package, which compiles and works fine on Fedora 12, 13 and Rawhide. After waiting for weeks, I started a maintainer time out. It was closed within an hour. I got some comments on bugzilla, but nothing happened ever since. The updated package was never downloaded from my website. What can I do in this situation? Obviously I'm not a proven packager to update the package myself, as I'm not a Fedora developer. I worked a lot to update and test the package, but still I'm stuck. And as you can see, the maintainer timeout procedure does not help either... You have to accept the maintainers decision to not update it yet? What do you think will happen if everyone builds the wishes he has and breaks a lot of stuff with it? Anarchy? We have processes for that in Fedora: https://fedoraproject.org/wiki/MikeKnox/AWOL_Maintainers Well, syslog-ng is a leaf package. AFAIK, there are no others depending on it, so it can't really break a lot of stuff. Also, I tested the package heavily, not just updated, and no problems came up during testing. Version 2.X of syslog-ng, which is currently included in Fedora, is now obsolate. The current release is 3.1.1, this is the version I prepared for Fedora. And it is not just a random wish: I did the update for openSUSE and FreeBSD, where they are accepted already and in use. Gentoo, Arch, Mandriva, Debian, Ubuntu, NetBSD, Solaris, etc. all did the switch at least in their devel versions for the above reasons. Only Fedora is missing from the list... Bye, CzP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On Fri, Jul 02, 2010 at 09:36:34PM +0800, Chen Lei wrote: I think escalating to FESCo is only suitable for changes which are controversial between different people, we should have another policy to treat those non-responsive issues, maintainers should respond on bugzilla report in time. I agree with you, and that's why I proposed a policy with Rahul. This may certainly be enhanced. If I recall well this was rejected. http://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance I am no more involved in Fedora (except for unfrequent whining on the devel list) so I won't be able to follow on this issue, but I still agree that it is a problematic issue. Until such a policy is available, however, ther is no other possibility than escalation to FESCo. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On Fri, Jul 02, 2010 at 07:15:54PM +0530, Rahul Sundaram wrote: I had forgotten about this but since becoming provenpackager I have helped out in simple rebuilds or even version bumps on occasions and have gotten positive feedback. You mean that you didn't only send a patch but you did commit version bumps without prior communication with the maintainer or with a maintainer not responding to your offer to do a version bump? The written policy is rather rigid but people tend to be more flexible about others helping out in effect. We should generally assume goodwill and not try to mandate common sense via minute policies. I am not that positive. Maybe the fedora project changed since these days, but there were quite a bit of cases where bugs with fixes were not considered for a long time. -- Pat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On 07/02/2010 07:27 PM, Patrice Dumas wrote: On Fri, Jul 02, 2010 at 07:15:54PM +0530, Rahul Sundaram wrote: I had forgotten about this but since becoming provenpackager I have helped out in simple rebuilds or even version bumps on occasions and have gotten positive feedback. You mean that you didn't only send a patch but you did commit version bumps without prior communication with the maintainer or with a maintainer not responding to your offer to do a version bump? I offered to do versions bumps and uniformly got a positive response. In some cases, I filed a patch in bugzilla. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On 07/02/2010 07:37 PM, Patrice Dumas wrote: Ok, this policy was for the other case, a case when the maintainer does not respond. I am not saying that it happens a lot, but it happened in the past, and the syslog-ng case exposed in the thread is another recent case. Maybe a policy is not needed and a case by case handling by escalation to FESCo is enough, though. In my days as a Fedora contributor, however, this issue was annoying enough that I proposed the policy, maybe things have changed now. A global view of package versions in rawhide vs the latest upstream similar to http://wiki.debian.org/DEHS would be useful to know how we stand. Rakesh Pandit was looking into this earlier. Not sure of the status on that now. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning perl-TermReadKey
Hi, I have orphaned perl-TermReadKey, for Fedora 11-devel, EPEL 4,5. Anyone interested, please take it. Stepan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Subscribing to package updates in bodhi?
Hi all, I have a pretty simple question: Is there a way to subscribe to certain packages in bodhi so that I get a notification via mail whenever updates are queued for it or pushes happen? That would be pretty useful for monitoring changes of dependencies, so I have enough time to make sure my package works with the newer version like it should. Does such a feature exist? If not, what would be the best way to accomplish something like that (I mean, except of asking the maintainer to send me a mail everytime he plans to update)? Thanks for answers in advance, Julian signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
webkitgtk abi bump
Just a headsup: I've just built webkitgtk-1.3.2 in rawhide, which changes library sonames, so things depending on it will have to be rebuilt. repoquery says that the following packages might be affected: anjuta awn-extras-applets cairo-dock-plug-ins-webkit claws-mail-plugins-fancy devhelp empathy epiphany evolution-rss gimp-help-browser gimp-help-browser gmpc gnucash kazehakase-webkit lekhonee-gnome libproxy-webkit liferea midori pino pywebkitgtk pywebkitgtk seed shotwell surf uzbl-core webkitgtk webkitgtk-devel yelp yelp-libs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subscribing to package updates in bodhi?
On Fri, 2010-07-02 at 16:33 +0200, Julian Aloofi wrote: Hi all, I have a pretty simple question: Is there a way to subscribe to certain packages in bodhi so that I get a notification via mail whenever updates are queued for it or pushes happen? That would be pretty useful for monitoring changes of dependencies, so I have enough time to make sure my package works with the newer version like it should. Does such a feature exist? If not, what would be the best way to accomplish something like that (I mean, except of asking the maintainer to send me a mail everytime he plans to update)? Thanks for answers in advance, Julian I don't know about bodhi but in koji you can subscribe for notifications depending on packages/tags. It might even make more sense if you want to test your packages with new versions. - Andreas -- BRef Andreas Bierfert, M.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierf...@lowlatency.de| http://lowlatency.de | signed/encrypted phone: +49 6897 1721738 | cell: +49 170 9665206| mail preferred signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: webkitgtk abi bump
On Fri, Jul 2, 2010 at 8:06 PM, Matthias Clasen mcla...@redhat.com wrote: Just a headsup: I've just built webkitgtk-1.3.2 in rawhide, which changes library sonames, so things depending on it will have to be rebuilt. lekhonee-gnome rebuild done. Kushal -- http://fedoraproject.org http://kushaldas.in -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On Thu, Jul 01, 2010 at 11:28:09PM -0500, Adam Miller wrote: I don't think it really matters what we call it, I just think that package maintainers are starting to get a sense of entitlement and I feel that's counter productive to the open environment we're used to and are trying to help continue to grow. The package owner gets emails about cvs commits, so they are always aware of what's going on and can review the changes to packages they maintain. In the event of a discrepancy then the person receiving the email obviously has an email account and can easily email the person who made the edit in order to extend a friendly inquiry as to the change. It doesn't need to be any more complicated than that. I for one welcome co-maintainers because I'm a big fan of collaboration and a sense of community, and if I can't trust my fellow community member and contributor to help in the maintenance of packages that I just so happen to have a bit flipped for in the pkgdb, then I'm in the wrong place. Good points all, Adam. My personal experience with a couple of my packages, where for example Matthias Clasen found and stomped a bug, or Jesse Keating took care of a rebuild when I wasn't around[1], gave me confidence that fellow contributors have my back, as opposed to sneaking around behind it. I prefer to presume goodwill. At worst I've caused them to grumble for taking up my slack -- in which case they know where to find my inbox to complain. :-) * * * [1] These happened both when I was a volunteer, and when I was a Red Hat employee, FWIW. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: webkitgtk abi bump
On Fri, 2010-07-02 at 10:36 -0400, Matthias Clasen wrote: Just a headsup: I've just built webkitgtk-1.3.2 in rawhide, which changes library sonames, so things depending on it will have to be rebuilt. claws-mail-plugins rebuild done - Andreas -- BRef Andreas Bierfert, M.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierf...@lowlatency.de| http://lowlatency.de | signed/encrypted phone: +49 6897 1721738 | cell: +49 170 9665206| mail preferred signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 09:53:00AM +0200, Ralf Corsepius wrote: On 07/02/2010 09:37 AM, Rahul Sundaram wrote: On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. Ralf, you need to stop repeating this particular line when I have repeatedly told you that working for Red Hat is not the rationale. The rationale is that a Fedora packager made a request that the packages which the perl-sig was on allow two other packagers to commit to them. Under the mistaken impression that there was a perl-sig that could decide that sort of issue, I had the ticket CC'd to the perl-sig's mailing list for objections. The ticket received one okay and zero don't do it's so after a week I went ahead and made the change. If the person being added had been you in the request, I would have done so as well. Now that I know that there really isn't an actual perl-sig that is capable of yaying or naying this sort of change I wouldn't do it again. Since the last FESCo meeting we also have criteria for judging who needs to approve a mass acl change that's quite simple: Owners and approveacls holders do this. If the owner/approveacl holder does not (through lack of response, largeness of the update, etc) then the decision to authorize goes to FESCo. -Toshio pgpik8AGRMron.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 2 July 2010 17:00, Toshio Kuratomi a.bad...@gmail.com wrote: They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. Ralf, you need to stop repeating this particular line when I have repeatedly told you that working for Red Hat is not the rationale. I had to apply and justify the reasons why I wanted to be a provenpackager. I work at Red Hat on lots of upstream GNOME packages, and felt I went through exactly the same process and was judged in the same way as a non-Red Hat person. I really don't think there is any kind on conspiracy doing on, honestly. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 11:26:32AM +0200, Matěj Cepl wrote: Dne 2.7.2010 09:37, Rahul Sundaram napsal(a): On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The one exception being Mozilla. There is nothing Red Hat specific about it. a) even more strongly, being a Red Hat employee doesn't give you anything ... you have to go through the Fedora provenpackager process One thing that being a RH employee does give you is access to people who are willing to sponsor you into the packager group more quickly than has traditionally been the case in Fedora. However, that's changing as *Fedora* has tried to move to a model of sponsorship into the packager group that is quicker. My clarification doesn't impact provenpackager at all. b) if you don't like provenpackagers to mess with your packages, go and make a switch in pkgdb. Actually, when FESCo was deciding whether to open all packages to provenpackager, they also decided to disable the ability to change whether provenpackager could be turned on and off. I believe the idea was that provenpackager should have access to almost everything. The firefox and thunderbird packages (because of trademark) were the one exception. Membership in provenpackager is the means for deciding whether someone is responsible enough to wield that power. -Toshio pgp9zcb0WIqua.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subscribing to package updates in bodhi?
Am Freitag, den 02.07.2010, 17:02 +0200 schrieb Andreas Bierfert: On Fri, 2010-07-02 at 16:33 +0200, Julian Aloofi wrote: Hi all, I have a pretty simple question: Is there a way to subscribe to certain packages in bodhi so that I get a notification via mail whenever updates are queued for it or pushes happen? That would be pretty useful for monitoring changes of dependencies, so I have enough time to make sure my package works with the newer version like it should. Does such a feature exist? If not, what would be the best way to accomplish something like that (I mean, except of asking the maintainer to send me a mail everytime he plans to update)? Thanks for answers in advance, Julian I don't know about bodhi but in koji you can subscribe for notifications depending on packages/tags. It might even make more sense if you want to test your packages with new versions. - Andreas That's what I've been looking for, thanks! :) Regards, Julian signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 06:00 PM, Toshio Kuratomi wrote: On Fri, Jul 02, 2010 at 09:53:00AM +0200, Ralf Corsepius wrote: On 07/02/2010 09:37 AM, Rahul Sundaram wrote: On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. Ralf, you need to stop repeating this particular line when I have repeatedly told you that working for Red Hat is not the rationale. Toshio, I am tired of you (==Toshio) not wanting recognize what you (== RH) are did: Granting widest privileges to people who, never, repeat never would have been granted these privileges if they were not @RH. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 06:07 PM, Richard Hughes wrote: On 2 July 2010 17:00, Toshio Kuratomia.bad...@gmail.com wrote: They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. Ralf, you need to stop repeating this particular line when I have repeatedly told you that working for Red Hat is not the rationale. I had to apply and justify the reasons why I wanted to be a provenpackager. I know you did, but the Petr's did not. Their presumable supervisor @RH (Marcella) rushed them through the process and they had been granted access to several 100 package. I really don't think there is any kind on conspiracy doing on, honestly. I am not talking about conspiracy, I am talking about double standards. What would do if John Doe would apply for proven packager and write access to 1500 packages? Seriously, you'd likely tell him he's nuts. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
measuring success [was Re: Bodhi 0.7.5 release]
On Thu, 2010-07-01 at 06:33 +0200, Kevin Kofler wrote: Fedora Legacy has shown how well this works… not! I completely agree with Ralf Corsepius and Tom Lane on this subject: this policy is very unhelpful, and applying it to security updates is just totally insane. We're going to see machines compromised because critical fixes are getting delayed by brainless technobureaucracy. Let's put aside the needless, inflammatory rhetoric for just a brief moment, and actually try to think about ways to solve problems, shall we? The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies, or updates that cause serious regressions requiring manual intervention / emergency update replacements. That sort of thing. But your assertion seems to be something like: This is obviously going to fail horribly and therefore any testing is a waste of time. Various reasons for this have been bandied about - there isn't enough manpower and it's going to slow down updates and make people vulnerable for longer are the most prominent ones, as I see it. Now. For each of these reasons - pro and con - there should be some things we can actually measure. Turnaround time on security updates, for instance. Given measurements of some agreed-upon metrics over time, we can actually quantify whether or not this policy is a failure, rather than just SHOUTING and WAVING OUR ARMS and PREDICTING DOOM and QUOTING WAYNE'S WORLD at one another. Therefore: I propose that we choose a few metrics (turnaround time on security updates, average number of live updates with broken dependencies per day, etc.). Then we begin measuring them (and, if possible, collect historical, pre-critpath data to compare that to). I'm willing to bet that these metrics have improved since we started the critpath policies before F13 release, and will continue to improve over the course of F13's lifecycle and the F14 development cycle. In fact, Kevin, given a set of metrics we're both happy with, I'd be willing to stake my subscription to this list on it - for, say, 3 months. Are you willing to do the same? -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On 07/02/2010 06:20 PM, Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies, or updates that cause serious regressions requiring manual intervention / emergency update replacements. That sort of thing. Should be done scripted as part of the package push process. No need for karmas, no need for provenpackager Doesn't Michael Schwendt have a script for this? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution update in F13
On 07/02/2010 12:09 AM, Kevin Fenzi wrote: It's in stable now. The time in testing allowed us to fix and add several more packages to it and confirm that it did indeed fix things. Maybe it's still being propagated, but when I did update --skip-broken followed by yum update, right now (Fri Jul 2, 0400 GMT) I get Loaded plugins: auto-update-debuginfo, refresh-packagekit Found 87 installed debuginfo package(s) Enabling rpmfusion-free-debuginfo: RPM Fusion for Fedora 13 - Free - Debug Enabling fedora-debuginfo: Fedora 13 - i386 - Debug Enabling updates-debuginfo: Fedora 13 - i386 - Updates - Debug Enabling rpmfusion-free-updates-debuginfo: RPM Fusion for Fedora 13 - Free - Updates Debug Setting up Update Process Resolving Dependencies -- Running transaction check --- Package ekiga.i686 0:3.2.7-3.fc13 set to be updated --- Package empathy.i686 0:2.30.2-3.fc13 set to be updated --- Package evolution.i686 0:2.30.2-1.fc13 set to be updated -- Processing Dependency: libedataserver-1.2.so.11 for package: almanah-0.7.2-1.fc13.i686 --- Package evolution-data-server.i686 0:2.30.2-2.fc13 set to be updated --- Package evolution-data-server-devel.i686 0:2.30.2-2.fc13 set to be updated --- Package evolution-help.noarch 0:2.30.2-1.fc13 set to be updated --- Package evolution-perl.i686 0:2.30.2-1.fc13 set to be updated --- Package giggle.i686 0:0.5-2.fc13 set to be updated --- Package gnome-panel.i686 0:2.30.0-3.fc13 set to be updated --- Package gnome-panel-devel.i686 0:2.30.0-3.fc13 set to be updated --- Package gnome-panel-libs.i686 0:2.30.0-3.fc13 set to be updated --- Package libpurple.i686 0:2.7.1-3.fc13 set to be updated --- Package nautilus-sendto.i686 0:2.28.4-3.fc13 set to be updated --- Package pidgin.i686 0:2.7.1-3.fc13 set to be updated --- Package pidgin-evolution.i686 0:2.7.1-3.fc13 set to be updated -- Finished Dependency Resolution Error: Package: almanah-0.7.2-1.fc13.i686 (@anaconda-InstallationRepo-201005130056.i386) Requires: libedataserver-1.2.so.11 Removing: evolution-data-server-2.30.1-2.fc13.i686 (@anaconda-InstallationRepo-201005130056.i386) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, Jul 02, 2010 at 06:15:44PM +0200, Ralf Corsepius wrote: On 07/02/2010 06:00 PM, Toshio Kuratomi wrote: On Fri, Jul 02, 2010 at 09:53:00AM +0200, Ralf Corsepius wrote: The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. Ralf, you need to stop repeating this particular line when I have repeatedly told you that working for Red Hat is not the rationale. Toshio, I am tired of you (==Toshio) not wanting recognize what you (== RH) are did: Granting widest privileges to people who, never, repeat never would have been granted these privileges if they were not @RH. Hah! What I do is worse. I'm willing to grant them privileges without requiring that they have any standing in the community or backing from a Red Hat manager. All it takes with me is the word of a measley package owner and a week without complaints on a mailing list! -Toshio pgpydEsYkUQ9j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/10 9:18 AM, Ralf Corsepius wrote: I had to apply and justify the reasons why I wanted to be a provenpackager. I know you did, but the Petr's did not. Their presumable supervisor @RH (Marcella) rushed them through the process and they had been granted access to several 100 package. The Petrs were not applying for provenpackager. They had what was assumed to be a sig's blessing to be granted write access to a set of packages. Not the entire world. We at that point had no policy that would stop this, regardless of who requested and who was the people being added. Being @RH had absolutely no play in this. I really don't think there is any kind on conspiracy doing on, honestly. I am not talking about conspiracy, I am talking about double standards. What would do if John Doe would apply for proven packager and write access to 1500 packages? Seriously, you'd likely tell him he's nuts. Bad analogy. There was no provenpackager access granted. Toshio didn't blindly accept the request, he called out to what he thought was the correct governing body over those packages and did not receive any negative feedback, after a week. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwuFzkACgkQ4v2HLvE71NV9twCgxmDU7xDtsjDfUxCWuvPJ51Rd q3UAnjPrmeyTbHpNxxP51u6bbUAyzT7U =edXM -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution update in F13
On Fri, 02 Jul 2010 12:41:18 -0400, Przemek wrote: On 07/02/2010 12:09 AM, Kevin Fenzi wrote: It's in stable now. The time in testing allowed us to fix and add several more packages to it and confirm that it did indeed fix things. Maybe it's still being propagated, but when I did update --skip-broken followed by yum update, right now (Fri Jul 2, 0400 GMT) I get http://lists.fedoraproject.org/pipermail/test/2010-July/091839.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On Fri, 2 Jul 2010, Ralf Corsepius wrote: On 07/02/2010 06:00 PM, Toshio Kuratomi wrote: On Fri, Jul 02, 2010 at 09:53:00AM +0200, Ralf Corsepius wrote: On 07/02/2010 09:37 AM, Rahul Sundaram wrote: On 07/02/2010 12:57 PM, Josephine Tannhäuser wrote: It's seems to me that you have to be an employee of red hat to get the privilegue to deal arbitrarily with all packages. Incorrect. Anyone in the provenpackagers group has access to almost all packages. The Petr's are apparent newbies/newcomers. They were granted access to all perl-packages, because they are @RH. Probably because it is their paid job to work on these packages. Ralf, you need to stop repeating this particular line when I have repeatedly told you that working for Red Hat is not the rationale. Toshio, I am tired of you (==Toshio) not wanting recognize what you (== RH) are did: Granting widest privileges to people who, never, repeat never would have been granted these privileges if they were not @RH. In infrastructure when people have mass requests to put in we try to complete them if they seem reasonable and if they come from people who have the authority to grant it. He did the work because he was asked to, as would I have. The infrastructure team is a service oriented team. It wasn't Toshio's job to decide who had access to what and AFAIK, he didn't make those decisions he just did the work. You're shooting the messenger not that you care. -Mike-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution update in F13
On 07/02/2010 12:47 PM, Michael Schwendt wrote:
On Fri, 02 Jul 2010 12:41:18 -0400, Przemek wrote:
On 07/02/2010 12:09 AM, Kevin Fenzi wrote:
It's in stable now. The time in testing allowed us to fix and add
several more packages to it and confirm that it did indeed fix things.
Maybe it's still being propagated, but when I did update --skip-broken
followed by yum update, right now (Fri Jul 2, 0400 GMT) I get
http://lists.fedoraproject.org/pipermail/test/2010-July/091839.html
Oh, I get it --- almanah requires old libedataserver which prevents
evolution and all the other packages from updating.
I did rpm -e almanah; yum update and it worked; is there another way?
I suppose it would have to leave both versions of
/usr/lib/libedataserver-1.2.so.{11,13}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-PatchReader (Fedora EPEL, 5) updated by tibbs
tibbs added a Fedora EPEL 5 branch for perl-PatchReader Package perl-PatchReader in Fedora EPEL 5 is now owned by pfrields tibbs approved watchbugzilla on perl-PatchReader (Fedora EPEL 5) for perl-sig tibbs approved watchcommits on perl-PatchReader (Fedora EPEL 5) for perl-sig tibbs approved commit on perl-PatchReader (Fedora EPEL 5) for perl-sig tibbs approved build on perl-PatchReader (Fedora EPEL 5) for perl-sig tibbs approved approveacls on perl-PatchReader (Fedora EPEL 5) for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-PatchReader -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-PatchReader (Fedora EPEL, 6) updated by tibbs
tibbs added a Fedora EPEL 6 branch for perl-PatchReader Package perl-PatchReader in Fedora EPEL 6 is now owned by pfrields tibbs approved watchbugzilla on perl-PatchReader (Fedora EPEL 6) for perl-sig tibbs approved watchcommits on perl-PatchReader (Fedora EPEL 6) for perl-sig tibbs approved commit on perl-PatchReader (Fedora EPEL 6) for perl-sig tibbs approved build on perl-PatchReader (Fedora EPEL 6) for perl-sig tibbs approved approveacls on perl-PatchReader (Fedora EPEL 6) for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-PatchReader -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Subscribing to package updates in bodhi?
On Fri, Jul 2, 2010 at 4:33 PM, Julian Aloofi julian.fedorali...@googlemail.com wrote: Hi all, I have a pretty simple question: Is there a way to subscribe to certain packages in bodhi so that I get a notification via mail whenever updates are queued for it or pushes happen? That would be pretty useful for monitoring changes of dependencies, so I have enough time to make sure my package works with the newer version like it should. Does such a feature exist? If not, what would be the best way to accomplish something like that (I mean, except of asking the maintainer to send me a mail everytime he plans to update)? Watchcommit in pkgdb. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success
On Fri, Jul 02, 2010 at 12:20:21PM -0400, Will Woods wrote: Therefore: I propose that we choose a few metrics (turnaround time on security updates, average number of live updates with broken dependencies per day, etc.). Then we begin measuring them (and, if possible, collect historical, pre-critpath data to compare that to). I'm willing to bet that these metrics have improved since we started the critpath policies before F13 release, and will continue to improve over the course of F13's lifecycle and the F14 development cycle. I am interested in these metrics, too. Afaik it will be the first time in the update testing discussion that there will be metrics that can be used to evaluate it. But imho the turnaround time is not only interesting for security updates, but for all updates that fix bugs, so probably most non-newpackage updates. Btw. on a related issue:How do provenpackagers properly test for broken deps manually? The case where two updates in updates-testing are required to update one of them seems to me hard to ensure manually. But when only one of both updates is pushed to stable, there will be a broken dependency. I know that the fix is to bundle the builds of both updates into one, but how is this tested? Regards Till pgpvMFOwX1aJA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subscribing to package updates in bodhi?
On Fri, Jul 02, 2010 at 04:33:20PM +0200, Julian Aloofi wrote: Hi all, I have a pretty simple question: Is there a way to subscribe to certain packages in bodhi so that I get a notification via mail whenever updates are queued for it or pushes happen? That would be pretty useful for monitoring changes of dependencies, so I have enough time to make sure my package works with the newer version like it should. Does such a feature exist? If not, what would be the best way to accomplish something like that (I mean, except of asking the maintainer to send me a mail everytime he plans to update)? I requested this feature: https://fedorahosted.org/bodhi/ticket/427 RFE: RSS feeds against ... everything (well, package + release anyway) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote: For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. I am just wondering, is this some intermediate step until the Package update acceptance criteria[0] are implemented? Because these criteria only say that updates require positive Bodhi karma from a defined group of testers, so there is no need for the +1 from another authenticated user. Also they are about the important packages, which is a subset of critical path. And the policy says that it is not yet live. Regards Till [0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria pgpKwhwwnCu8m.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/10 11:27 AM, Till Maas wrote: On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote: For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. I am just wondering, is this some intermediate step until the Package update acceptance criteria[0] are implemented? Because these criteria only say that updates require positive Bodhi karma from a defined group of testers, so there is no need for the +1 from another authenticated user. Also they are about the important packages, which is a subset of critical path. And the policy says that it is not yet live. Regards Till [0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria I believe it's a continuation of the criteria we used for F13 branched, which came from the No Frozen Rawhide proposals. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwuM+EACgkQ4v2HLvE71NVp/ACeJhYvjxvhmhglJR1O+4V+xVO+ 4hgAoI3YXJyFlkPv5j3rP4qBlAy159Y7 =wimC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Fri, 02 Jul 2010 20:27:27 +0200 Till Maas opensou...@till.name wrote: On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote: For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. I am just wondering, is this some intermediate step until the Package update acceptance criteria[0] are implemented? Because these criteria only say that updates require positive Bodhi karma from a defined group of testers, so there is no need for the +1 from another authenticated user. I have clarified this. This is using the same critical path setup that branched releases use, which is: +1 from a proventester, and +1 from any logged in user. Also they are about the important packages, which is a subset of critical path. Superset. :) In any case, the items mentioned there should be implemented. Bodhi calls them all 'critical path' so perhaps we should change to do that there too. And the policy says that it is not yet live. I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. https://fedoraproject.org/wiki/Package_update_acceptance_criteria kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVS admin requests
On Thu, 1 Jul 2010 13:32:20 -0600, Kevin wrote: The page Package Change Requests for existing packages is unclear: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure#Package_Change_Requests_for_existing_packages Please expand on what explanatory text you want in addition to the Package Change Request template. If there is a branch request, e.g. for a released dist version, is it necessary to transcribe the filled out template into a full sentence? Well, I'm not sure how to rephrase that... Basically we want to know if there are any non standard conditions to look at, ie: - You are not the owner and want to maintain in epel. Did you contact the fedora owner and wait and/or hear back that they didn't want to maintain it? How would I know that this would be relevant? And why is it relevant? Can the Fedora package owner block another packager's request to become the maintainer in EPEL? I don't think so. - Is the package a dead package you are bringing back? etc. You don't need to add additional text for normal vanilla regular requests. Now that you've given two examples, can't you simply sum up the special situations in which you demand additional details? How many are there? - resurrecting an orphan or retired package - bringing a package to EPEL - ... - (?) transferring ownership You know your requirements, so tell people what input you need. It just saves cvsadmins the time to ask you what you want. What is the template for then? It specifies exactly what a person wants. If you are interested in some background (a full story of what had happened prior to somebody filling out the template), you could enumerate the special cirumstances when you need those extra details. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CVS admin requests
On Fri, 2 Jul 2010 21:50:08 +0200 Michael Schwendt mschwe...@gmail.com wrote: ...snip... - You are not the owner and want to maintain in epel. Did you contact the fedora owner and wait and/or hear back that they didn't want to maintain it? How would I know that this would be relevant? And why is it relevant? Can the Fedora package owner block another packager's request to become the maintainer in EPEL? I don't think so. No. There is a process however: - Check to see if fedora packager is on the I don't do EPEL list If they are, great, request. - If they are not on that list, file a bug and ask if they wish to maintain in EPEL. If they say no in the bug, great, request. - If they don't answer in a week, great request. Sometimes however we get requests that request the branch, are filed on something different where the fedora maintainer is not cc'ed and they don't want to wait a week anyhow. - Is the package a dead package you are bringing back? etc. You don't need to add additional text for normal vanilla regular requests. Now that you've given two examples, can't you simply sum up the special situations in which you demand additional details? How many are there? I don't know. When have you been asked for additional details? - resurrecting an orphan or retired package - bringing a package to EPEL - ... - (?) transferring ownership You know your requirements, so tell people what input you need. Sure, How about we strike that part entirely, and if there is some question, cvsadmin's can just ask in the bug. It just saves cvsadmins the time to ask you what you want. What is the template for then? It specifies exactly what a person wants. If you are interested in some background (a full story of what had happened prior to somebody filling out the template), you could enumerate the special cirumstances when you need those extra details. Because sometimes we don't know if we can act on the template right then. Another example: New package review cvs request, but the submitter says someone else entirely should be the owner of the new package. Should we ask them if the person has said thats ok? If they added a note saying I've asked bob to be the owner, as he works on this upstream, he's ok with this. It would save us the round trip to ask that. Anyhow, I guess I would say we should just strike that and cvsadmins can ask if there are questions. I just don't want people to get mad at a delay when we do so. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote: On Fri, 02 Jul 2010 20:27:27 +0200 Till Maas opensou...@till.name wrote: Also they are about the important packages, which is a subset of critical path. Superset. :) In any case, the items mentioned there should be implemented. Bodhi calls them all 'critical path' so perhaps we should change to do that there too. Yes, superset. If the important packages and critical path packages are the same and handled the same in any way, then the term import packages should imho vanish and never be used again. The inflation of different terms for the same thing is imho a major problem in the Fedora docs in general. :-( And the policy says that it is not yet live. I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. I tried to make it more consistent. Regards Till pgpDRqXHYAy2N.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning a few packages
Hi all, since I'll be entering college soon, I'm revisiting my workload (I'll continue to work on Sugar and Etherpad). I'm using neither of the following applications (nodm was originally intended to be used for sugar-related work) and since both avogadro and nodm have a few open bugs which I've been failing to keep up with, I'm orphaning these. * avogadro * blazeblogger * nodm Feel free to take them. Thanks, --Sebastian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subscribing to package updates in bodhi?
Am Freitag, den 02.07.2010, 19:31 +0200 schrieb Thomas Janssen: On Fri, Jul 2, 2010 at 4:33 PM, Julian Aloofi julian.fedorali...@googlemail.com wrote: Hi all, I have a pretty simple question: Is there a way to subscribe to certain packages in bodhi so that I get a notification via mail whenever updates are queued for it or pushes happen? That would be pretty useful for monitoring changes of dependencies, so I have enough time to make sure my package works with the newer version like it should. Does such a feature exist? If not, what would be the best way to accomplish something like that (I mean, except of asking the maintainer to send me a mail everytime he plans to update)? Watchcommit in pkgdb. -- LG Thomas Dubium sapientiae initium Ah, that sounds useful as well, I settled with the koji solution though. Thanks for the answer! :) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @fedoraproject.org email alias
On Fri, Jul 2, 2010 at 11:28 PM, Nicu Buculei nicu_fed...@nicubunu.rowrote: I just added him to the Design Team group so his alias should start working. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ Thanks. Yes it is now working correctly. Regards -- Chris Jones Photographic Imaging Professional and Graphic Designer ABN: 98 317 740 240 Photo Resolutions - Photo Printing, Editing and Restorations Web: http://photoresolutions.freehostia.com Email: chrisjo...@comcen.com.au or ubuntu...@comcen.com.au Fedora Design Suite Developer and Co-Maintainer foxmulder...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies The right way to prevent that is to get AutoQA completed, which will, if it works as intended, automatically detect and throw out updates with broken dependencies without needlessly delaying all those updates which don't have broken dependencies. Once AutoQA is completed, the testing process will do NOTHING whatsoever to prevent broken dependencies because they wouldn't make it through AutoQA anyway. or updates that cause serious regressions requiring manual intervention / emergency update replacements. No amount of testing is going to catch all such cases, and when it does happen, the testing requirements actually HINDER a quick fix, increasing the window of exposure to the bug and therefore making it affect many more users and for longer time. In fact, Kevin, given a set of metrics we're both happy with, I'd be willing to stake my subscription to this list on it - for, say, 3 months. Are you willing to do the same? No. Metrics just encourage working to the metric to game the system, and any improvement you measure from the new process might just be due to chance or to factors we aren't considering at all. Plus, do we even have the historical data to compare with, given that everything older than F12 is deleted from Bodhi? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
Kevin Fenzi wrote: On Fri, 02 Jul 2010 00:44:29 -0400 Tom Lane t...@redhat.com wrote: I think it's counterproductive to downgrade that responsibility, or even worse pretend that it doesn't matter --- and Kevin's lead statement in this thread is damn close to pretending that. Sorry Kevin, we are not interchangeable parts. Which Kevin? I never intended to say any such thing... :) I did, so I guess he's talking about me. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
Ralf Corsepius wrote: We need groups, with grouped privileges/acls etc. It's essentially what e.g. the perl-sig originally was meant to be. Yes, group ACLs are definitely needed, but in addition to that technical feature, we also need to make sure that the SIG actually gets commit access to ALL packages related to the SIG. ALL perl-* packages should be committable to by the Perl SIG. That's what a SIG is for. And it'd have prevented this whole why were X and Y added as maintainers to my perl-* packages fiasco, it would just have been the SIG's decision to add the people to the SIG and this should automatically give commit access to all perl-* packages. Similarly, all packages using Qt should be committable to by the KDE SIG etc. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
Thomas Janssen wrote: You have to accept the maintainers decision to not update it yet? What do you think will happen if everyone builds the wishes he has and breaks a lot of stuff with it? Anarchy? We have processes for that in Fedora: https://fedoraproject.org/wiki/MikeKnox/AWOL_Maintainers It is part of the Fedora Objectives: https://fedoraproject.org/wiki/Objectives to be on the leading edge of free and open source technology. Given that, it is completely unacceptable to not upgrade software to the current release in Rawhide (within a reasonable timeframe, of course we're all not available 24/7) unless there's a really good reason to (in which case that reason ought to be given in the bug report asking for the upgrade!), especially when upstream is asking for their software to be upgraded. So the maintainer's decision (assuming there even WAS a decision rather than just lack of time or worse) goes against Fedora's Objectives and so it's not OK to say that it should just get accepted. We should really be more aggressive about allowing to upgrade other people's packages in Rawhide if the maintainers don't do it within a reasonable timeframe and don't document any good reason not to do the upgrade. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
David Woodhouse wrote: In the old days of RHL and beehive, I think we had it about right... with the obvious exception that it was Red Hat only, but the attitude to packaging was right, IMHO. There _was_ someone who knew most about a package and was expected to deal with it most of the time, but it was also perfectly reasonable for other people to work on the packages too. Fedora seems to have regressed a lot in that respect, although it did improve after we started approving ProvenPackagers. But the official provenpackager policy is way too restrictive on allowed changes, so I'm often left wondering Will I get away with doing that change?, and several times, I have to err on the side of caution, wasting both my and the maintainer's time by filing bugs etc. when I could just fix the issue. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success
On 07/02/2010 08:12 PM, Till Maas wrote: Btw. on a related issue:How do provenpackagers properly test for broken deps manually? Like ordinary packagers should do ;) The only difference between provenpackagers and ordinary packagers is them having write access to packages they do not own. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package ownership
On 07/03/2010 03:49 AM, Kevin Kofler wrote: David Woodhouse wrote: In the old days of RHL and beehive, I think we had it about right... with the obvious exception that it was Red Hat only, but the attitude to packaging was right, IMHO. There _was_ someone who knew most about a package and was expected to deal with it most of the time, but it was also perfectly reasonable for other people to work on the packages too. Fedora seems to have regressed a lot in that respect, although it did improve after we started approving ProvenPackagers. But the official provenpackager policy is way too restrictive on allowed changes, so I'm often left wondering Will I get away with doing that change? Yep. On such occasions, I usually resort to being ultra conservative, i.e. to only apply changes when I am sure about them. and several times, I have to err on the side of caution, wasting both my and the maintainer's time by filing bugs etc. when I could just fix the issue. So do I. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who is Petr Pisar from redhat ?
On 07/02/2010 06:43 PM, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/10 9:18 AM, Ralf Corsepius wrote: I had to apply and justify the reasons why I wanted to be a provenpackager. I know you did, but the Petr's did not. Their presumable supervisor @RH (Marcella) rushed them through the process and they had been granted access to several 100 package. The Petrs were not applying for provenpackager. True. They actually wanted perl-sig access, which current is technically impossible, because the Fedora's packager infrastructure doesn't support groups. Instead they had applied for full access to all perl-related packages and had been granted it. Being @RH had absolutely no play in this. As I already said, my view differs. I really don't think there is any kind on conspiracy doing on, honestly. I am not talking about conspiracy, I am talking about double standards. What would do if John Doe would apply for proven packager and write access to 1500 packages? Seriously, you'd likely tell him he's nuts. Bad analogy. Correct, I was incorrect in using the provenpackager, here. Scratch it, the rest of the anology still applies. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
