Re: Fedora clean up process seems to be seriously broken...
Can I be added to the list of maintainers that need help very badly from the beginning? I maintain a number of packages that are very low in the Java stack and would force the whole Java stack to be removed if they are removed but noone wants to maintain them. That's how I gained them! If such a policy is adopted it would be very bad decision if there isn't a mechanism prior to that for maintainers to list packages that they maintain to keep the distro integrity but don't care about them personally. I bet that there would be a very big list of maintainers that would list a number of there packages in this list. To give a better estimate - I'm owner of 69 packages(139 comaintainer) of these I would like to maintain only 11 (eclipse*) packages but the rest is crucial to something. The problem should be obvious now - I would like to list this 58 packages as something I need help with. And to explain things better - yes I do fix bugs when they arrive in this packages- but just a real bugs (broken functionality, crashers, etc.) and let aside bugs asking for new version update, new functionality, pony:) until I need them. It's volunteer based effort and NOONE has the right to put more burden on packagers or you will lose them. And everyone stop telling the story about disappointed bug reporters, why noone is saying about disappointed maintainers? My experience is quite the opposite at least 7 out of 10 bug reports are from people that don't want to help. I'm speaking for bug reports that stay needing info from reporters for weeks and months before I close them as INSUFFICIENT_DATA. If a decision to orphan packages is made a similar decision should be made to ban bugzilla accounts that don't respond to information requests from maintainers. If a packager is losing time for reporters if he doesn't respond, there are for sure reporters that lose time of the packagers. In my case they lose me so much time that I would have probably fixed some of the bugs that I haven't responded to!!! Does the previous paragraph sounds right? HELL NO!! There should be an effort to make more people help as much as they can (even if it's one day per year), not an effort to put more burden on people that are already doing work. Pissed by the constant efforts to draw maintainers as lazy and non-responsive, Alexander Kurtakov - Original Message - From: Kevin Fenzi ke...@scrye.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 12:36:39 AM Subject: Re: Fedora clean up process seems to be seriously broken... On Mon, 21 Nov 2011 14:03:43 -0800 Jesse Keating jkeat...@j2solutions.net wrote: This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I don't think anybody disagrees (well maybe KKoffler) that unmaintained software should be discovered and ejected from the distro, the entirety of the problem lies how to discover (as well as side issues about what to do about maintainers that are active for one package, but completely ignore 3 others, etc…) So if you are serious about wanting this fixed, draft a proposal, figure out who's going to do the coding work, and bring it to FESCo. To quote Ajax: +! I think the current policy is not very ideal either, but haven't had time/energy to work out a new one. ;) My last thought was to come up with a automated/script way to gather info from: bugzilla, pkgdb, koji, git, mailing lists, etc and output a list of 'likely inactive people'. Then, have a group of humans look at the list, and try and contact/ping people. With no reply after a timeperiod, orphan their packages. Note that we need to balance here cases like: * maintainer is very active, just ignoring $leafpackage right now. * maintainer is on vacation/sick/etc * maintainer needs help, we should try and help them out. * maintainer doesn't use our bugzilla as their primary bug zone. * maintainer maintains a software that has a vast number of bugs and they can't deal with them all. * maintainer is working on higher priority bug, so ignoring feature requests/etc. Anyhow, I for one would welcome written up, concrete proposals here. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File XML-DifferenceMarkup-1.04.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-XML-DifferenceMarkup: d753b39fec3c8da3917c35c40d101fef XML-DifferenceMarkup-1.04.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
[perl-XML-DifferenceMarkup] Import
commit 4c02cd7b6579f6519b70046a899cc672b47be04f
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 22 09:53:34 2011 +0100
Import
.gitignore |1 +
perl-XML-DifferenceMarkup.spec | 53
sources|1 +
3 files changed, 55 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..432cee3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/XML-DifferenceMarkup-1.04.tar.gz
diff --git a/perl-XML-DifferenceMarkup.spec b/perl-XML-DifferenceMarkup.spec
new file mode 100644
index 000..81c8d27
--- /dev/null
+++ b/perl-XML-DifferenceMarkup.spec
@@ -0,0 +1,53 @@
+Name: perl-XML-DifferenceMarkup
+Version:1.04
+Release:1%{?dist}
+Summary:XML diff and merge
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/XML-DifferenceMarkup/
+Source0:
http://www.cpan.org/authors/id/V/VB/VBAR/XML-DifferenceMarkup-%{version}.tar.gz
+BuildRequires: diffmark-devel
+BuildRequires: libxml2-devel
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(XML::LibXML) = 1.70
+BuildRequires: perl(XSLoader)
+# Tests only:
+BuildRequires: perl(Test)
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(XML::LibXML) = 1.70
+
+%{?perl_default_filter}
+
+%description
+This module implements an XML diff producing XML output. Both input and
+output are DOM documents, as implemented by XML::LibXML.
+
+%prep
+%setup -q -n XML-DifferenceMarkup-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/XML*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Nov 18 2011 Petr Pisar ppi...@redhat.com 1.04-1
+- Specfile autogenerated by cpanspec 1.78.
+- Remove BuildRoot and defattr from spec code
diff --git a/sources b/sources
index e69de29..139e2eb 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+d753b39fec3c8da3917c35c40d101fef XML-DifferenceMarkup-1.04.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: Fedora clean up process seems to be seriously broken...
On Tue, 22 Nov 2011 00:09:36 +0100, RH (Reindl) wrote: Am 21.11.2011 23:50, schrieb Michael Schwendt: On Mon, 21 Nov 2011 22:58:50 +0100, RH (Reindl) wrote: +1 nothing is more frustrating for users as ignored bugreports reintroduced from release to relase while th eonly response is from bugzapper about EOL of the release Well, that's not the same problem as this thread is about. There a very active packagers (and developers who also do packaging tasks) who don't respond to [all] tickets due to various reasons. Some of the reasons are valid. Become a package maintainer yourself, Harald, before you judge about them all. i do not judge! in my opinion there is no reason to not respond respond can be negative with a short why well, this would be much more helpful as bugzapper-mails That's even another topic. ;) Those automated bugzapper mails come *much* too late. They are a poor attempt at cleaning up old cruft in bugzilla. They don't handle the case of bug reporters refreshing tickets again and again in response to the automated NEEDINFO query *without* any human being ever deciding to spend time on the ticket. However, for _some_ components of the distribution, if you want human beings to handle the incoming bugzilla traffic, these would need to be real bugzilla monkeys. Some components receive hundreds (if not thousands) tickets per dist lifetime. In Fedora bugzilla. In addition to the upstream bug tracker. it is a hughe difference if you give no feedback to anyone who took the time to make a bugreport or ignore it Given the amount of bz traffic for some pkgs, it isn't easy to even try to respond to them all. Especially if the devs are active in the upstream ticket system, too. There is also no guarantee that the bug reporter will be helpful beyond the initial report. Some reporters simply don't respond anymore either. As I say it, ABRT can be both a blessing and a curse. ABRT makes it much easier for arbitrary users to dump something into bugzilla, under the assumption that the submitted backtrace is enough, even if the problem is not reproducible. if the respponse is sorry no time yet is would be much morehelpful than no response at all *That* should be an automated response. Including the request to consider filing a bug upstream. An opt-in service for packagers to enable it for their packages. All not trivial, however, as _somebody_ will need to decide whether a bug is specific to Fedora or whether it's a general bug in the source code. At first you may be satisfied by a sorry no time yet response, but for how long? Eventually you would demand a fix to be delivered, or another response, or some kind of promise to spend time on the issue. we all know that nothing will be perfect now or in future but give users the feeling that they are not ignored is a high value Are they? Not in general. We need to find out the _where_ and _why_. It's not unusual for your own issues to become your pet peeves. Instead of waiting for others to work on fixes, try to find an area where to contribute. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, 22 Nov 2011 00:00:33 +0100, MT (Miloslav) wrote: Nothing is in place to detect inactive maintainers automatically. We don't really need absolute automation - if a package is not actively maintained but nobody notices, does it really matter?[1] Yes. Users notice, but they report their findings in bugzilla only to learn months later that nobody seems to listen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 11/22/2011 04:51 AM, Jóhann B. Guðmundsson wrote: On 11/21/2011 10:50 PM, Michael Schwendt wrote: I understand this thread as a comment on improving the detection of inactive maintainers and unmaintained packages. It is indeed intended as such. I would recommend you stop this thread at this point and write up a concrete proposal and submit it to FESCo and/or help with scripts that automate the detection of potentially unmaintained packages. I would also recommend that you become a package maintainer so that you are aware of the other side and understand the problem areas better. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
Excerpts from Jóhann B. Guðmundsson's message of Tue Nov 22 00:28:32 +0100 2011: On 11/21/2011 11:21 PM, Jóhann B. Guðmundsson wrote: On 11/21/2011 10:50 PM, Michael Schwendt wrote: I understand this thread as a comment on improving the detection of inactive maintainers and unmaintained packages. It is indeed intended as such. BTW does anyone have any insight on how other distributions are solving this Debian/Suse/Gentoo/Arch etc. since we are all faced with this problem and surely some distribution might have solved this problem already. Well Gentoo has a different approach to ownership and all that. And from that also a different approach to slacking/activity. Basic thing considered is commits/month[1]. If that seems low over prolonger period of time other sources of contribution for given developer are being searched for. Usually his/hers team leads are being asked if he/she does some thing out of our cvs tree. It can be answering questions on forum or other activities. We don't really have different levels of developers (think maintainer vs. qa vs. provenpackager etc). All in all this is semi-automated process. Tools gather data, produce statistics and few people look at them and from time to time try to ping people. Though the whole approach is mostly: If you can help at least a bit, don't leave. Plus there is the whole devaway[2] system so people can be inactive for prolonged periods of time and other devs know what to do (oh, you say you are away on long vacation until end of December and others are welcome to fix bugs in your packages. Cool). I am sure something similar could be done in Fedora. If the packager hasn't made any commit in any of his packages in past 2 releases + some other conditions maybe, it's likely he has no idea about current guidelines, processes, has never used fedpkg etc. [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/cvs-log-all-2011-10.txt [2] http://dev.gentoo.org/devaway/ -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 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: Libs with applications
On Sun, Nov 20, 2011 at 02:33:34PM -0500, Steve Grubb wrote: # ldd /usr/bin/msntest | wc -l 20 # ldd /usr/lib64/libmsn.so.0.3.0 | wc -l 9 Please, be careful. ldd(1) prints recursively all dependencies. $ ldd /usr/bin/msntest | wc -l 20 $ readelf -a /usr/bin/msntest | grep NEEDED | wc -l 8 It means that the /usr/bin/msntest depends on 8 libraries only. I didn't test all of them, but the extra dependencies are unneeded. Yes, typical problem is (usually) completely broken .pc (pkg-config) file. My experience is that developers don't have a clue about 'Requires.private' pkg-config field and they add all libraries to 'Requires' or 'Libs', so then binaries are linked with many unnecessary libraries (possible workaround is --as-needed ld(1) option). man pkg-config: In the situation where each .pc file corresponds to a library, Requires.private shall be used exclusively to specify the dependencies between the libraries. $ pkg-config --libs gtk+-3.0 -pthread -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpng12 -lm -lcairo-gobject -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 ... I don't believe that gtk ABI contains symbols from all this libraries :-) Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request update of shared-mime-info
On Mon, 2011-11-21 at 14:36 -0500, Jon Masters wrote: Folks, Can someone please push the update that I made (with permission) to shared-mime-info? I'm getting jcm does not have commit access when I try to make the F16 update. This fix is required to actually be able to play many MP3 files (including all purchased from Amazon.com) on F16. No, it's needed _only_ to play Amazon.com purchased files. Even if it's possible to create a broken file, I hardly think that trying to artificially raise the severity of the problem is useful. Tested Koji builds: F16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530557 F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3530543 Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Snap! A system snapshotter for Fedora/Ubuntu/Windows/and more
Hey all, I'm looking for help testing a project I've been working on over the last few months. Snap [1] is a cross-platform system snapshot and restoration utility which uses the underlying package management system to take snapshots of packages installed as well as files modified outside of the package management system. Only files modified post-installation and new-files (eg those not tracked by the package system) are backed up so that snapshots are lightweight and are able to be migrated across hosts. Currently supported are RPM based distros (Fedora, RHEL, CentOS ./CentOS.html), Deb based distros (Debian, Ubutunu), and Windows Also supported are service snapshots. For example postgres and mysql db's will be backed up, as are Apache and IIS websites using the native tooling. All of this is built ontop of a very modular / plugable system which allows developers to extend Snap to take and restore snapshots of any custom target. My intention of this project was to make cross-virtualization-hypervisor and cross-cloud-provider [2] snapshots a cinch, but it can also be used for general system backup and recovery. I've tried to harden it up as much as I could up to this point, writing an extensive test suite, and conducting full integration testing on various platforms but am looking for more widespread testing, especially in alternative environments. Also I would like to start forming a community around this project, to write backends to support snapshots on a variety of platforms and of a variety of services. The project is as open source as it gets, written in Python and licensed under the GPLv3. I've submitted Snap to Fedora [3] and Debian / Ubuntu [4], any package reviews would be more than appreciated. Thanks for reading so far! -Mo Morsi [1] https://github.com/movitto/snap [2] http://mo.morsi.org/blog/node/347 [3] https://bugzilla.redhat.com/show_bug.cgi?id=755890 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649585 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 755903] New: Use of uninitialized value in string eq at .. FormFu/Constraint.pm line 107
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Use of uninitialized value in string eq at .. FormFu/Constraint.pm line 107 https://bugzilla.redhat.com/show_bug.cgi?id=755903 Summary: Use of uninitialized value in string eq at .. FormFu/Constraint.pm line 107 Product: Fedora Version: 16 Platform: All OS/Version: Linux Status: NEW Severity: unspecified Priority: unspecified Component: perl-HTML-FormFu AssignedTo: iarn...@gmail.com ReportedBy: dgp...@corefiling.co.uk QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Created attachment 534999 -- https://bugzilla.redhat.com/attachment.cgi?id=534999 Make the noise stop in FormFu::Constraint Description of problem: Use of uninitialized value in string eq at /usr/share/perl5/vendor_perl/HTML/FormFu/Constraint.pm line 107. Version-Release number of selected component (if applicable): 0.09003-2.fc16 How reproducible: Certain input data causes the warning to be generated Steps to Reproduce: 1. 2. 3. Actual results: Use of uninitialized value in string eq at /usr/share/perl5/vendor_perl/HTML/FormFu/Constraint.pm line 107. printed to terminal Expected results: Glorious silence Additional info: Scalar::Util's reftype can return undef. There is no sanity check before using in a string eq, hence terminal spam. -- 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: Fedora clean up process seems to be seriously broken...
On 11/22/2011 08:51 AM, Aleksandar Kurtakov wrote: Can I be added to the list of maintainers that need help very badly from the beginning? If such an list existed I dont see why that should be a problem. I maintain a number of packages that are very low in the Java stack and would force the whole Java stack to be removed if they are removed but noone wants to maintain them. That's how I gained them! If such a policy is adopted it would be very bad decision if there isn't a mechanism prior to that for maintainers to list packages that they maintain to keep the distro integrity but don't care about them personally. I bet that there would be a very big list of maintainers that would list a number of there packages in this list. Not sure what you mean about distro integrity since arguably shipping few but well maintained components is better then shipping many poorly maintained or not maintained at all. But basically you winded up being stuck with them since you wanted to ship component A but to do so you required B), C) and D) but nobody is/wants maintain B),C) and D). Nothing can actually be done here since that's the price one has to pay wanting to ship component A). To give a better estimate - I'm owner of 69 packages(139 comaintainer) of these I would like to maintain only 11 (eclipse*) packages but the rest is crucial to something. The problem should be obvious now - I would like to list this 58 packages as something I need help with. And to explain things better - yes I do fix bugs when they arrive in this packages- but just a real bugs (broken functionality, crashers, etc.) and let aside bugs asking for new version update, new functionality, pony:) until I need them. It's volunteer based effort and NOONE has the right to put more burden on packagers or you will lose them. Nobody is putting burden on anyone other then the maintainers themselves. Either they do it directly to themselves ( by maintaining more things they can handle which eventually may lead to burnout ) or it's being done by other sloppy/non responsive/absent maintainers indirectly through the component they are supposed to maintain ( which they aren't doing which results in other maintainers have to do all the leg work themselves encase their components depends on the one that he maintains ) or through various policy's/processes we in place trying to deal with those. Which is what I would say is just another symptom of the underlying problem that needs to be dealt with as in active maintainers themselves are paying hefty price for those inactive once. Through bureaucracy and what you are experiencing above amongst other things. And everyone stop telling the story about disappointed bug reporters, why noone is saying about disappointed maintainers? My experience is quite the opposite at least 7 out of 10 bug reports are from people that don't want to help. I'm speaking for bug reports that stay needing info from reporters for weeks and months before I close them as INSUFFICIENT_DATA. If a decision to orphan packages is made a similar decision should be made to ban bugzilla accounts that don't respond to information requests from maintainers. If a packager is losing time for reporters if he doesn't respond, there are for sure reporters that lose time of the packagers. In my case they lose me so much time that I would have probably fixed some of the bugs that I haven't responded to!!! Does the previous paragraph sounds right? HELL NO!! There should be an effort to make more people help as much as they can (even if it's one day per year), not an effort to put more burden on people that are already doing work. We actually have process in place to deal with that name Triagers however a while back I and James I believe and perhaps few others in QA went ahead with How_To_componentDebug pages to try to deal with that problem in an attempt to educate and have proper documentation for reporters and Triager to follow. Aiming for a workflow like this... Report comes in ( preferably containing proper information to begin with ) -- Gets triaged ( if == insufficent data point reporter to how to debug page for a given component and wait until he provides proper data ) -- Flag Triaged and hand it to maintainer for further processing. At that time we had what roughly 6000 - 7000 components in the distribution and I quickly realize that we could not write all those how to debug pages without maintainers participation in the process ( which went lala depending on who you were dealing with ) at least we needed to prevent further components being introduced into the distribution without having that information available so we eventually gradually would manage to work on those 6000 - 7000 components and slowly bringing that number down. ( We even had played with the idea if we could integrate this to Bugzilla somehow as on components page would be a link
[Bug 755906] New: perl-Archive-Tar-1.82 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Archive-Tar-1.82 is available https://bugzilla.redhat.com/show_bug.cgi?id=755906 Summary: perl-Archive-Tar-1.82 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Archive-Tar AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.82 Current version in Fedora Rawhide: 1.80 URL: http://search.cpan.org/dist/Archive-Tar/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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
[Bug 755907] New: perl-Net-HTTP-6.02 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Net-HTTP-6.02 is available https://bugzilla.redhat.com/show_bug.cgi?id=755907 Summary: perl-Net-HTTP-6.02 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Net-HTTP AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 6.02 Current version in Fedora Rawhide: 6.01 URL: http://search.cpan.org/dist/Net-HTTP/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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: Packaging Yorick
Excerpts from Jonathan Underwood's message of Mon Nov 21 22:43:48 +0100 2011: Hi, I have just started looking at packaging Yorick[1][2], an interpreted programming language for scientific simulations. It seems that this is BSD licensed and so would be suitable for packaging in Fedora. However, by default and design it has a really horrible filesystem layout[3], with files under the following directory: relocate/ files required for building compiled packages, and: bin/ binary executables lib/ binary libraries for compiled packages include/ header files for compiled package APIs i0/ interpreted code required for yorick to start i/ optional interpreted code libraries i-start/ interpreted code that autoloads at startup g/ graphics style files, palettes, and templates doc/ documentation files According to the docs[3], it's possible to move the whole relocate directory elsewhere (eg. to be under /usr), but not to move directories underneath the main directory. This of course violates our packaging guidelines in many ways. Before I look into what's required to patch this beast to meet the packaging guidelines, I wonder if anyone else has tried packaging it, and/or wants to help? One approach you can use is symlinking. It's what tomcat package uses. It too has a specific directory structure, but we put things in right places and then symlink them back into one directory. If those dirs don't change too much it should be possible to maintain it. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 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: Fedora clean up process seems to be seriously broken...
On 11/22/2011 09:40 AM, Rahul Sundaram wrote: On 11/22/2011 04:51 AM, Jóhann B. Guðmundsson wrote: On 11/21/2011 10:50 PM, Michael Schwendt wrote: I understand this thread as a comment on improving the detection of inactive maintainers and unmaintained packages. It is indeed intended as such. I would recommend you stop this thread at this point and write up a concrete proposal and submit it to FESCo and/or help with scripts that automate the detection of potentially unmaintained packages. I would also recommend that you become a package maintainer so that you are aware of the other side and understand the problem areas better. First of all why do I need to come up with a concrete proposal to FESCO why dont they come up with something to try to improve the distribution. Does that governing body only exist to say yay or nay to others proposals? Secondly the only reason I don't maintain packages within the distribution is because I'm fully aware that I dont have time in doing so. So instead of me working under the illusion that I can resulting in me half ass maintaining stuff at best I rather choose not, to cause I know for a fact that nobody gains anything from it infact I would just be signing up to become the part of the problem not the solution if I did. And I'm already fully aware of the other side given that I receive every bug filed at systemd and I also can tell you that of each of ca 8 of 10 bugs filed there the reporter should be filing against relevant component containing their unit files as opposed to systemd itself. ( Apparently if anything fails at bootup it's systemd's fault ) I am giving what I can when I can, to contribute the distribution and my actions there speak well enough for themselves and will continue to do so. My first and foremost priority is to get the migration process over with. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 755907] perl-Net-HTTP-6.02 is available
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=755907 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=750793 -- 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
[Bug 755906] perl-Archive-Tar-1.82 is available
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=755906 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- 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
[perl-Net-HTTP] 6.02 bump
commit a75812327163a91391cdec4d9fe55297155fbb6c
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 22 13:00:23 2011 +0100
6.02 bump
.gitignore |1 +
perl-Net-HTTP.spec |8 ++--
sources|2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 78ccad7..fcb7382 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Net-HTTP-6.00.tar.gz
/Net-HTTP-6.01.tar.gz
+/Net-HTTP-6.02.tar.gz
diff --git a/perl-Net-HTTP.spec b/perl-Net-HTTP.spec
index c91f896..d3ae70a 100644
--- a/perl-Net-HTTP.spec
+++ b/perl-Net-HTTP.spec
@@ -1,6 +1,6 @@
Name: perl-Net-HTTP
-Version:6.01
-Release:2%{?dist}
+Version:6.02
+Release:1%{?dist}
Summary:Low-level HTTP connection (client)
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,6 +55,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Nov 22 2011 Petr Pisar ppi...@redhat.com - 6.02-1
+- 6.02 bump
+- Fixes HTTPS time-out in LWP::UserAgent/IO::Socket::SSL (bug #750793)
+
* Tue Jul 19 2011 Petr Sabata con...@redhat.com - 6.01-2
- Perl mass rebuild
diff --git a/sources b/sources
index d082010..616f556 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d7ae2675fca351147adcd26f840b6993 Net-HTTP-6.01.tar.gz
+b0fa0a246872ff8da48c65da6f5281fc Net-HTTP-6.02.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: Fedora clean up process seems to be seriously broken...
Comments inline. - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 1:36:53 PM Subject: Re: Fedora clean up process seems to be seriously broken... On 11/22/2011 08:51 AM, Aleksandar Kurtakov wrote: Can I be added to the list of maintainers that need help very badly from the beginning? If such an list existed I dont see why that should be a problem. I maintain a number of packages that are very low in the Java stack and would force the whole Java stack to be removed if they are removed but noone wants to maintain them. That's how I gained them! If such a policy is adopted it would be very bad decision if there isn't a mechanism prior to that for maintainers to list packages that they maintain to keep the distro integrity but don't care about them personally. I bet that there would be a very big list of maintainers that would list a number of there packages in this list. Not sure what you mean about distro integrity since arguably shipping few but well maintained components is better then shipping many poorly maintained or not maintained at all. But basically you winded up being stuck with them since you wanted to ship component A but to do so you required B), C) and D) but nobody is/wants maintain B),C) and D). Nothing can actually be done here since that's the price one has to pay wanting to ship component A). To give a better estimate - I'm owner of 69 packages(139 comaintainer) of these I would like to maintain only 11 (eclipse*) packages but the rest is crucial to something. The problem should be obvious now - I would like to list this 58 packages as something I need help with. And to explain things better - yes I do fix bugs when they arrive in this packages- but just a real bugs (broken functionality, crashers, etc.) and let aside bugs asking for new version update, new functionality, pony:) until I need them. It's volunteer based effort and NOONE has the right to put more burden on packagers or you will lose them. Nobody is putting burden on anyone other then the maintainers themselves. Either they do it directly to themselves ( by maintaining more things they can handle which eventually may lead to burnout ) or it's being done by other sloppy/non responsive/absent maintainers indirectly through the component they are supposed to maintain ( which they aren't doing which results in other maintainers have to do all the leg work themselves encase their components depends on the one that he maintains ) or through various policy's/processes we in place trying to deal with those. Which is what I would say is just another symptom of the underlying problem that needs to be dealt with as in active maintainers themselves are paying hefty price for those inactive once. Through bureaucracy and what you are experiencing above amongst other things. We seem to disagree here. I value every maintainer even one that steps in once in a year. And yes I value him more than someone that would open 10 bugreports without instructions how to reproduce. So someone inactive for you seems to be active for me, right? And everyone stop telling the story about disappointed bug reporters, why noone is saying about disappointed maintainers? My experience is quite the opposite at least 7 out of 10 bug reports are from people that don't want to help. I'm speaking for bug reports that stay needing info from reporters for weeks and months before I close them as INSUFFICIENT_DATA. If a decision to orphan packages is made a similar decision should be made to ban bugzilla accounts that don't respond to information requests from maintainers. If a packager is losing time for reporters if he doesn't respond, there are for sure reporters that lose time of the packagers. In my case they lose me so much time that I would have probably fixed some of the bugs that I haven't responded to!!! Does the previous paragraph sounds right? HELL NO!! There should be an effort to make more people help as much as they can (even if it's one day per year), not an effort to put more burden on people that are already doing work. We actually have process in place to deal with that name Triagers however a while back I and James I believe and perhaps few others in QA went ahead with How_To_componentDebug pages to try to deal with that problem in an attempt to educate and have proper documentation for reporters and Triager to follow. Aiming for a workflow like this... Report comes in ( preferably containing proper information to begin with ) -- Gets triaged ( if == insufficent data point reporter to how to debug page for a given component and wait until he provides proper data ) -- Flag Triaged and hand it to maintainer for further processing. At that time we had what roughly 6000 - 7000 components in the
Re: Fedora clean up process seems to be seriously broken...
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 12:57:24 PM Subject: Re: Fedora clean up process seems to be seriously broken... On 11/22/2011 09:40 AM, Rahul Sundaram wrote: On 11/22/2011 04:51 AM, Jóhann B. Guðmundsson wrote: On 11/21/2011 10:50 PM, Michael Schwendt wrote: I understand this thread as a comment on improving the detection of inactive maintainers and unmaintained packages. It is indeed intended as such. I would recommend you stop this thread at this point and write up a concrete proposal and submit it to FESCo and/or help with scripts that automate the detection of potentially unmaintained packages. I would also recommend that you become a package maintainer so that you are aware of the other side and understand the problem areas better. First of all why do I need to come up with a concrete proposal to FESCO why dont they come up with something to try to improve the distribution. You don't improve distribution, when you start bullying contributors. Bunch of people were already annoyed with your proposal. Does that governing body only exist to say yay or nay to others proposals? Imho FESCo should mainly decide about technical difficulties. All of us already have our own projects, so why should I care about this one? Anyone on list can get your idea and work on heuristics if (s)he believes it helps and than propose some actions. Secondly the only reason I don't maintain packages within the distribution is because I'm fully aware that I dont have time in doing so. So instead of me working under the illusion that I can resulting in me half ass maintaining stuff at best I rather choose not, to cause I know for a fact that nobody gains anything from it infact I would just be signing up to become the part of the problem not the solution if I did. And I'm already fully aware of the other side given that I receive every bug filed at systemd and I also can tell you that of each of ca 8 of 10 bugs filed there the reporter should be filing against relevant component containing their unit files as opposed to systemd itself. ( Apparently if anything fails at bootup it's systemd's fault ) I am giving what I can when I can, to contribute the distribution and my actions there speak well enough for themselves and will continue to do so. My first and foremost priority is to get the migration process over with. JBG Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 11/22/2011 10:18 AM, Stanislav Ochotnicky wrote: Excerpts from Jóhann B. Guðmundsson's message of Tue Nov 22 00:28:32 +0100 2011: On 11/21/2011 11:21 PM, Jóhann B. Guðmundsson wrote: On 11/21/2011 10:50 PM, Michael Schwendt wrote: I understand this thread as a comment on improving the detection of inactive maintainers and unmaintained packages. It is indeed intended as such. BTW does anyone have any insight on how other distributions are solving this Debian/Suse/Gentoo/Arch etc. since we are all faced with this problem and surely some distribution might have solved this problem already. Well Gentoo has a different approach to ownership and all that. And from that also a different approach to slacking/activity. Basic thing considered is commits/month[1]. If that seems low over prolonger period of time other sources of contribution for given developer are being searched for. Usually his/hers team leads are being asked if he/she does some thing out of our cvs tree. It can be answering questions on forum or other activities. We don't really have different levels of developers (think maintainer vs. qa vs. provenpackager etc). Hum I think the only way to achieve something like this for maintainership we need to drop the ownership module so either nobody owns a package/component in the project or relevant SIG owns the package. All in all this is semi-automated process. Tools gather data, produce statistics and few people look at them and from time to time try to ping people. Though the whole approach is mostly: If you can help at least a bit, don't leave. Plus there is the whole devaway[2] system so people can be inactive for prolonged periods of time and other devs know what to do (oh, you say you are away on long vacation until end of December and others are welcome to fix bugs in your packages. Cool). I am sure something similar could be done in Fedora. If the packager hasn't made any commit in any of his packages in past 2 releases + some other conditions maybe, it's likely he has no idea about current guidelines, processes, has never used fedpkg etc. If I can recall correctly I think fesco had someone working on something to gather activity stats ( wiki/bugzilla ) dont know if that ever got finished nor can I recall if the results from that tool if it came to existence were made public anyway if that tool exist the result from it should be made public from my pov. In general gather statistic is an area all groups/communities within the project needs improvements in atleast I know for a fact that we have had the tendency in the past within the QA group to implement some idea without at the same time be measuring what the outcome of the idea is hence we have not been able to measure if things are improving or actually getting worse. Afaik I dont think we can even give measurements on our own sub community's health as simple as are we gaining members more than we are loosing them and I suspect that we are not alone in that regard. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 755903] Use of uninitialized value in string eq at .. FormFu/Constraint.pm line 107
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=755903 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED External Bug ID||CPAN 72611 --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-11-22 07:36:40 EST --- I've reported the problem upstream with a slightly modified patch. -- 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: Fedora clean up process seems to be seriously broken...
On 11/22/2011 12:37 PM, Marcela Maslanova wrote: You don't improve distribution, when you start bullying contributors. Bunch of people were already annoyed with your proposal. Please provide explanation further how I was bullying contributors. Thanks JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 1:57:24 PM Subject: Re: Fedora clean up process seems to be seriously broken... On 11/22/2011 09:40 AM, Rahul Sundaram wrote: On 11/22/2011 04:51 AM, Jóhann B. Guðmundsson wrote: On 11/21/2011 10:50 PM, Michael Schwendt wrote: I understand this thread as a comment on improving the detection of inactive maintainers and unmaintained packages. It is indeed intended as such. I would recommend you stop this thread at this point and write up a concrete proposal and submit it to FESCo and/or help with scripts that automate the detection of potentially unmaintained packages. I would also recommend that you become a package maintainer so that you are aware of the other side and understand the problem areas better. First of all why do I need to come up with a concrete proposal to FESCO why dont they come up with something to try to improve the distribution. Because FESCO is an engineering committee and in engineering things usually can be measured. What we speak about is a social problem for me. Aka noone is obligated to do anything. Does that governing body only exist to say yay or nay to others proposals? Yes, because everywhere in FOSS one must be ready to work on what he wants. Secondly the only reason I don't maintain packages within the distribution is because I'm fully aware that I dont have time in doing so. But you think that if I don't have time to work on someone's bugreport I should be banned?? That's what I call a friendly atmosphere. So instead of me working under the illusion that I can resulting in me half ass maintaining stuff at best I rather choose not, to cause I know for a fact that nobody gains anything from it infact I would just be signing up to become the part of the problem not the solution if I did. And I'm already fully aware of the other side given that I receive every bug filed at systemd and I also can tell you that of each of ca 8 of 10 bugs filed there the reporter should be filing against relevant component containing their unit files as opposed to systemd itself. ( Apparently if anything fails at bootup it's systemd's fault ) I am giving what I can when I can, to contribute the distribution and my actions there speak well enough for themselves and will continue to do so. So do all of us!!! Hence why I'm so angry at ideas for putting more requirements on packagers. My first and foremost priority is to get the migration process over with. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 2:42:37 PM Subject: Re: Fedora clean up process seems to be seriously broken... On 11/22/2011 12:37 PM, Marcela Maslanova wrote: You don't improve distribution, when you start bullying contributors. Bunch of people were already annoyed with your proposal. Please provide explanation further how I was bullying contributors. Hmm, haven't this started with if you're not ready to reply to every bugreport we will ban you because we don't want your contribution? Thanks JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 755907] perl-Net-HTTP-6.02 is available
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=755907 --- Comment #1 from Fedora Update System upda...@fedoraproject.org 2011-11-22 07:45:30 EST --- perl-Net-HTTP-6.02-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Net-HTTP-6.02-1.fc16 -- 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
File Archive-Tar-1.82.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Archive-Tar: 60493433f434811b2e610ab754529388 Archive-Tar-1.82.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
[perl-Archive-Tar] 1.82 bump
commit a59f4d2efd0972bd798f0cca753e90451f04fd7a
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 22 13:47:54 2011 +0100
1.82 bump
.gitignore|1 +
perl-Archive-Tar.spec | 29 ++---
sources |2 +-
3 files changed, 20 insertions(+), 12 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 45a1777..f493ea3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Archive-Tar-1.64.tar.gz
/Archive-Tar-1.76.tar.gz
/Archive-Tar-1.78.tar.gz
/Archive-Tar-1.80.tar.gz
+/Archive-Tar-1.82.tar.gz
diff --git a/perl-Archive-Tar.spec b/perl-Archive-Tar.spec
index f912c1a..d50cdd4 100644
--- a/perl-Archive-Tar.spec
+++ b/perl-Archive-Tar.spec
@@ -1,19 +1,24 @@
Name: perl-Archive-Tar
-Version:1.80
+Version:1.82
Release:1%{?dist}
Summary:A module for Perl manipulation of .tar files
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Archive-Tar/
Source0:
http://www.cpan.org/authors/id/B/BI/BINGOS/Archive-Tar-%{version}.tar.gz
-
BuildArch: noarch
# Most of the BRS are needed only for tests, compression support at run-time
# is optional soft dependency.
+BuildRequires: perl(Carp)
BuildRequires: perl(Compress::Zlib) = 2.015
+BuildRequires: perl(constant)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
-# Required only by Makefile.PL, ask upstream to remove it
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Spec::Unix)
+BuildRequires: perl(File::Path)
BuildRequires: perl(IO::Compress::Base) = 2.015
BuildRequires: perl(IO::Compress::Bzip2) = 2.015
BuildRequires: perl(IO::Compress::Gzip) = 2.015
@@ -24,7 +29,8 @@ BuildRequires: perl(Test::Harness) = 2.26
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(Compress::Zlib) = 2.015, perl(IO::Zlib) = 1.01
+Requires: perl(Compress::Zlib) = 2.015
+Requires: perl(IO::Zlib) = 1.01
%description
Archive::Tar provides an object oriented mechanism for handling tar
@@ -33,7 +39,6 @@ while also allowing for the creation of tar file objects for
custom
manipulation. If you have the IO::Zlib module installed, Archive::Tar
will also support compressed or gzipped tar files.
-
%prep
%setup -q -n Archive-Tar-%{version}
@@ -42,15 +47,14 @@ will also support compressed or gzipped tar files.
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
+chmod -R u+w %{buildroot}/*
%check
make test
-
%files
%doc CHANGES README
%{_bindir}/*
@@ -60,6 +64,9 @@ make test
%changelog
+* Tue Nov 22 2011 Petr Šabata con...@redhat.com - 1.82-1
+- 1.82 bump
+
* Fri Oct 14 2011 Petr Sabata con...@redhat.com - 1.80-1
- 1.80 bump
diff --git a/sources b/sources
index 6edbcbc..7c30f25 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b834ba3045db8ddc35fc29b0a6d2bd1e Archive-Tar-1.80.tar.gz
+60493433f434811b2e610ab754529388 Archive-Tar-1.82.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: Rethinking proventester and critpath
On Mon, 2011-11-21 at 10:32 -0800, Adam Williamson wrote: red_alert (sandro mathys): critpath packages should have detailed test plans Hm. The list of (implicitly labeled) critpath packages seems to have proliferated recently: a few days ago I submitted an update for sane-backends and then found out that it's on critpath, probably by way of critical-path-gnome - control-center - colord - sane-backends-libs. On the one hand it would probably be a good idea to notify maintainers of such packages being implicitly pulled in (in this case when BR: colord-devel was added to control-center). On the other hand, sane-backends is a particularly nasty case and a detailed test plan would probably start with this: 0. Have a lot of scanners handy, or at least models affected by the changes. Not even I get past that point in most cases: I have one USB scanner in the office, and two rather ancient SCSI models at home. The only thing I can meaningfully test is these models/their drivers and the HW-independent parts of the package, and I don't expect more from the testers. With the package being critpath now, I fear that updates for sane-backends might never see the light of day, depending on the HW affected, unless Bruno's proposal (two weeks of wait for critpath without needed and no negative karma) or enough (proven)testers are content with only cursory testing :-/. Don't get me wrong: I'd really like sane-backends to get as much testing as possible before turning updates loose on the unsuspecting public. I just don't see how it can be done right at the moment. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 11/22/2011 12:35 PM, Aleksandar Kurtakov wrote: Comments inline. - Original Message - snip We seem to disagree here. I value every maintainer even one that steps in once in a year. And yes I value him more than someone that would open 10 bugreports without instructions how to reproduce. So someone inactive for you seems to be active for me, right? Certainly I value the person more that bothered to use the component and go through all the necessary step to report the bug he came across against that component than an indvidual that drop in to say hey after a year. The overall quality of the bug report and how to improve along with lowering reporters expectations is something we need to deal with and solve @QA And everyone stop telling the story about disappointed bug reporters, why noone is saying about disappointed maintainers? My experience is quite the opposite at least 7 out of 10 bug reports are from people that don't want to help. I'm speaking for bug reports that stay needing info from reporters for weeks and months before I close them as INSUFFICIENT_DATA. If a decision to orphan packages is made a similar decision should be made to ban bugzilla accounts that don't respond to information requests from maintainers. If a packager is losing time for reporters if he doesn't respond, there are for sure reporters that lose time of the packagers. In my case they lose me so much time that I would have probably fixed some of the bugs that I haven't responded to!!! Does the previous paragraph sounds right? HELL NO!! There should be an effort to make more people help as much as they can (even if it's one day per year), not an effort to put more burden on people that are already doing work. We actually have process in place to deal with that name Triagers however a while back I and James I believe and perhaps few others in QA went ahead with How_To_componentDebug pages to try to deal with that problem in an attempt to educate and have proper documentation for reporters and Triager to follow. Aiming for a workflow like this... Report comes in ( preferably containing proper information to begin with ) -- Gets triaged ( if == insufficent data point reporter to how to debug page for a given component and wait until he provides proper data ) -- Flag Triaged and hand it to maintainer for further processing. At that time we had what roughly 6000 - 7000 components in the distribution and I quickly realize that we could not write all those how to debug pages without maintainers participation in the process ( which went lala depending on who you were dealing with ) at least we needed to prevent further components being introduced into the distribution without having that information available so we eventually gradually would manage to work on those 6000 - 7000 components and slowly bringing that number down. ( We even had played with the idea if we could integrate this to Bugzilla somehow as on components page would be a link to the how to debug page ) But no the proposal made to FESCO/FPC winded up in *Recommendation* instead *Requirement* which automatically made that process and effort to be in vain since I knew that maintainers would not provide that information if they did not have to and guess what I turned out to be right. Hmm, this sound like a sloppy excuse to me. It's well known that first thing requested is how to reproduce. Do you have an idea how many of the bug reports have this information? My experience is less than 10%. If someone wants to help maintainers he can do that but just closing the bugs that don't have clean howto reproduce procedure written. You may consider this an sloppy I however do not as I see it the how to debug page for your component is necessary since without having spoon feeding information on how to do that the reporter will never be able to provide you with the information you want. We simply can not improve reporting in general without having the necessary documentation on how to obtain that information and what minimal information the maintainer wants ( the how to debug pages ). snip Do you really think that one can write a simple howto test page? Huge numbers of bugs are results of interpackage dependencies and every next day we try different approach in testing because we have new knowledge about some change somewhere. The how to test is was aimed an more general QA activity ( building test cases either for reporters to use or automation ) Would you agree to tighten the requirement for reporters too? If you can't do a debug build and provide me the output you're not qualified to report an issue. It sounds stupid I agree but you see the point now. Again to the point with the purpose of the how to debug pages =) Before filing a report -- follow how to debug page for the given component Requirements to join should loosen in order for Fedora to gain a
Re: Fedora clean up process seems to be seriously broken...
On 11/22/2011 12:49 PM, Aleksandar Kurtakov wrote: Hmm, haven't this started with if you're not ready to reply to every bugreport we will ban you because we don't want your contribution? If you are referring to Well if people want more controversial proposal of sign of live that's relatively easier to accomplish. Revoke that maintainers package privileges for $next-release if he does not respond to bug reports in timely manner in GA releases and orphan his package. Arguable a bit drasting but at the same time far more effective clean up process. It says in timely manner... As I have said before the problem here is not active contributors but the inactive/non responsive ones so the cleanup process needs to identify and handle those and what's the best way to do that. But somehow the thread winded up in the never ending debate of reporter vs maintainer which in the end both parties need work on improving and both parts are valuable contributors to the project. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Libs with applications
On Tue, 2011-11-22 at 11:46 +0100, Karel Zak wrote: Yes, typical problem is (usually) completely broken .pc (pkg-config) file. My experience is that developers don't have a clue about 'Requires.private' pkg-config field and they add all libraries to 'Requires' or 'Libs', so then binaries are linked with many unnecessary libraries (possible workaround is --as-needed ld(1) option). man pkg-config: In the situation where each .pc file corresponds to a library, Requires.private shall be used exclusively to specify the dependencies between the libraries. You have to be careful when you read documentation as well. That 'shall' sentence is a bit of a propaganda piece. In reality, things are not as black-and-white. $ pkg-config --libs gtk+-3.0 -pthread -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpng12 -lm -lcairo-gobject -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 ... I don't believe that gtk ABI contains symbols from all this libraries :-) Well, the pkg-config output effectively states that they are. And changing it now will cause breakage. We already experienced that when I removed the -lpng12 and -lm from the gdk-pixbuf pc file. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 3:34:50 PM Subject: Re: Fedora clean up process seems to be seriously broken... On 11/22/2011 12:49 PM, Aleksandar Kurtakov wrote: Hmm, haven't this started with if you're not ready to reply to every bugreport we will ban you because we don't want your contribution? If you are referring to Well if people want more controversial proposal of sign of live that's relatively easier to accomplish. Revoke that maintainers package privileges for $next-release if he does not respond to bug reports in timely manner in GA releases and orphan his package. Arguable a bit drasting but at the same time far more effective clean up process. It says in timely manner... As I have said before the problem here is not active contributors but the inactive/non responsive ones so the cleanup process needs to identify and handle those and what's the best way to do that. The problem here is that in my eyes there are no inactive contributors and there shouldn't be anything preventing people from contributing (even if it's one update per year). While I agree that projects that FTBFS, can't be installed and etc. should be purged every release, everything else should be out of question because the fact that someone considers something legacy doesn't mean that it's not usable for others. And to make it clear handling bugs is not a measure at all about activity. So if you come with a technical list of things that make sure that a package is unusable for 100%(e.g. can't be installed because of missing dependency) of the users it's not a question that it should be removed, but if there is someone that signed as a maintainer and there is even a slight possibility that someone can use nothing more can be required from the maintainer. Note the usage of required, all kind of suggestions can be made and people can do additional work but everyone should do as much as he can/want/have fun to do. Alex But somehow the thread winded up in the never ending debate of reporter vs maintainer which in the end both parties need work on improving and both parts are valuable contributors to the project. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost soname bump
Bruno Wolff III br...@wolff.to writes: It looks like there was a soname bump in boost yesterday. Boost affects enough stuff, that there really should have been a heads up message posted to the devel list about this. Yes, Denis Arnaud has kindly prepared a new release, but forgot to give a yell. That said, it's been a ritual for about past three years that with every Fedora there comes a point in time when boost breaks all its clients. That much should be hardly surprising. To address a point raised in another mail: this version is here to stay, unless something goes awry. We will of course fix bugs as they turn up, but neither further rebasing, nor withdrawing this version is in plan as of now. Note that boost::filesystem v2 has been scheduled for removal in 1.48, but this doesn't seem to have happened yet, the code is still there. If there are problems with compiling against the new boost, or you want to address some point of packaging, feel free to contact me. I'm _petr on #fedora-devel. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 755906] perl-Archive-Tar-1.82 is available
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=755906 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Archive-Tar-1.82-1.fc1 ||7 Resolution||RAWHIDE Last Closed||2011-11-22 08:53:43 -- 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: Fedora clean up process seems to be seriously broken...
On 11/22/2011 01:48 PM, Aleksandar Kurtakov wrote: - Original Message - The problem here is that in my eyes there are no inactive contributors and there shouldn't be anything preventing people from contributing (even if it's one update per year). While I agree that projects that FTBFS, can't be installed and etc. should be purged every release, everything else should be out of question because the fact that someone considers something legacy doesn't mean that it's not usable for others. And to make it clear handling bugs is not a measure at all about activity. So if you come with a technical list of things that make sure that a package is unusable for 100%(e.g. can't be installed because of missing dependency) of the users it's not a question that it should be removed, but if there is someone that signed as a maintainer and there is even a slight possibility that someone can use nothing more can be required from the maintainer. Note the usage of required, all kind of suggestions can be made and people can do additional work but everyone should do as much as he can/want/have fun to do. If more than you and Kevin Kofler are working under this assumption than the whole scenario begs the question why we even bother with QA and Security et all... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Mon, 2011-11-21 at 21:46 +0100, Reindl Harald wrote: Am 21.11.2011 21:32, schrieb Till Maas: Hi, a recent kernel update[0] broke Fedora's ability to be a VirtualBox host, because asm/amd_iommu.h was removed. The removal of the file was noticed during testing, but it seems nobody noticed that this affects VirtualBox. Is this kind of change sanctioned by the current update criteria? virtualbox is not part of fedora and vmware is running great after some changes of version.checks but vmware is also not part of fedora better breaking some non-distribution-stuff than as happened with F14 that current intel machiens with sandy-bridge was not supportted and forced eople with new hardware way too early to F15/systemd This is a non-argument: kernels 2.6.40.x/3.x broke dual head/xrandr[1] and WLAN[1] for me (on Intel hardware, FWIW). Nils [1]: https://bugzilla.redhat.com/show_bug.cgi?id=731296 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=732592 -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On 11/21/2011 09:32 PM, Till Maas wrote: a recent kernel update[0] broke Fedora's ability to be a VirtualBox host, because asm/amd_iommu.h was removed. This is a part of the in-kernel API, not the kernel-userspace interface. The internal API can change at any time. External kernel modules can break whenever the kernel is updated for the smallest bugfix. http://lxr.linux.no/#linux+v3.1.2/Documentation/stable_api_nonsense.txt Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
- Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 3:57:03 PM Subject: Re: Fedora clean up process seems to be seriously broken... On 11/22/2011 01:48 PM, Aleksandar Kurtakov wrote: - Original Message - The problem here is that in my eyes there are no inactive contributors and there shouldn't be anything preventing people from contributing (even if it's one update per year). While I agree that projects that FTBFS, can't be installed and etc. should be purged every release, everything else should be out of question because the fact that someone considers something legacy doesn't mean that it's not usable for others. And to make it clear handling bugs is not a measure at all about activity. So if you come with a technical list of things that make sure that a package is unusable for 100%(e.g. can't be installed because of missing dependency) of the users it's not a question that it should be removed, but if there is someone that signed as a maintainer and there is even a slight possibility that someone can use nothing more can be required from the maintainer. Note the usage of required, all kind of suggestions can be made and people can do additional work but everyone should do as much as he can/want/have fun to do. If more than you and Kevin Kofler are working under this assumption than the whole scenario begs the question why we even bother with QA and Security et all... Sorry but I don't see the relation. Everything is based on volunteers. The fact that I package something doesn't mean that QAs are required to test it. Certain people do it and I'm really thankful to them. But I'm not going and saying QAs should test everyone of my packages for every Fedora release. To generalize - the fact that I decided to spend my time working on something should not require someone else to do work he doesn't want to do or doesn't consider important. It should be the same from the other POV - the fact that someone else decided to spend his time on something should not put any requirement on me unless I consider it important and want to do it. Alex JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rethinking proventester and critpath
On Tue, Nov 22, 2011 at 6:06 AM, Nils Philippsen n...@redhat.com wrote: Hm. The list of (implicitly labeled) critpath packages seems to have proliferated recently Why not impose a self-restriction on the number of critpath packages? Make a rule like The ratio of proventesters to critpath packages must be x or higher. When the critpath numbers start creeping up, drop a few other packages from critpath. This will help focus testing efforts, and allow it to expand along with the growth of the community. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Mon, Nov 21, 2011 at 04:59:54PM -0800, Toshio Kuratomi wrote: The updates policy is meant to protect users of Fedora within reason. Compiling, writing, and using third party software on Fedora is a valid use of Fedora whether or not that software exists within Fedora. This update may be acceptable because the bugs fixed were deemed more worthwhile than the changes that were introduced but that decision should not hinge upon the availability of affected software within Fedora but upon the popularity of such software among users of Fedora, the ease with which that software can be made to work with Fedora once the change goes in, and how those questions weigh against the issues that are resolved by the new version. We don't support out of tree kernel modules at all, so they're not considered when making the determination about whether an update is appropriate for a stable update. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from yesterday's FESCo meeting (2011-11-21 at 18UTC)
=== #fedora-meeting: FESCO (2011-11-21) === Meeting started by mjg59 at 18:00:31 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-11-21/fesco.2011-11-21-18.00.log.html . Meeting summary --- * init process (mjg59, 18:00:41) * #667 Request to fix CRITPATH update process (mjg59, 18:01:55) * LINK: https://fedorahosted.org/bodhi/ticket/642 (nirik, 18:08:07) * ACTION: mmaslano to follow up with proventesters to find out what they think about the proposal (mjg59, 18:16:50) * #692 Adjust FESCo election policy (mjg59, 18:17:09) * AGREED: No change for now (mjg59, 18:28:33) * #699 Proposal to remove the package tzdata from Critical Path (mjg59, 18:28:37) * ACTION: notting to find out how feasible this change is (mjg59, 18:39:05) * #703 Boost 1.48 Uplift http://fedoraproject.org/wiki/Features/F17Boost148 (mjg59, 18:42:09) * #704 BTRFS default file system https://fedoraproject.org/wiki/Features/F17BtrfsDefaultFs (mjg59, 18:43:46) * AGREED: btrfs approved conditional on working fsck and no relevant feature regressions. Will revisit before feature freeze to make sure. (mjg59, 18:55:36) * Next week's chair (mjg59, 18:55:53) * AGREED: t8m to chair next week (mjg59, 19:01:16) * Open Floor (mjg59, 19:01:23) * LINK: http://meetbot.fedoraproject.org/teams/fesco/fesco.2011-08-22-16.59.log.html#l-92 (gholms, 19:01:34) Meeting ended at 19:09:13 UTC. Action Items * mmaslano to follow up with proventesters to find out what they think about the proposal * notting to find out how feasible this change is Action Items, by person --- * mmaslano * mmaslano to follow up with proventesters to find out what they think about the proposal * notting * notting to find out how feasible this change is * **UNASSIGNED** * (none) People Present (lines said) --- * mjg59 (79) * nirik (31) * t8m (29) * cwickert (28) * sgallagh (21) * notting (20) * mmaslano (19) * ajax (11) * zodbot (9) * gholms (4) * lmacken (3) * nb (2) * abadger1999 (1) * pjones (0) -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why has fedpkg suddenly grown a dependency on MySQL-python?
Toshio Kuratomi a.bad...@gmail.com writes: On Tue, Nov 22, 2011 at 01:16:01AM -0500, Tom Lane wrote: I was rather surprised to find a routine yum update on my F14 system suddenly wanting to pull in a lot of mysql stuff that I'd not had installed at the moment. Are you able to upgrade to a later Fedora? I think you're seeing this bug: https://bugzilla.redhat.com/show_bug.cgi?id=754538 Yes, that's the same issue, thanks for the reference. Obviously, I won't be using F14 for very much longer. What I was mainly worried about was the possibility that this growth in deps was a reflection of a new fedpkg version, so that I could expect to have to contend with the issue even in F15 and beyond. If the dependencies have been cleaned up in more recent branches then my concern is minimal. I do agree with the complainers in the BZ that this was something inappropriate to do in F14, but what's done is done. Even if you undid it, anyone who's done yum update recently on an F14 box will have all those unnecessary deps installed. Personally, I always do a fresh install not an upgrade when going to a new Fedora, so the extra deps won't be permanent baggage for me, but they will be for other people. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why has fedpkg suddenly grown a dependency on MySQL-python?
On 11/22/2011 09:02 PM, Tom Lane wrote: I do agree with the complainers in the BZ that this was something inappropriate to do in F14, but what's done is done. Even if you undid it, anyone who's done yum update recently on an F14 box will have all those unnecessary deps installed. Not necessarily. man yum.conf and read up on clean_requirements_on_remove Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
Am 22.11.2011 01:59, schrieb Toshio Kuratomi: The updates policy is meant to protect users of Fedora within reason. Compiling, writing, and using third party software on Fedora is a valid use of Fedora whether or not that software exists within Fedora. This update may be acceptable because the bugs fixed were deemed more worthwhile than the changes that were introduced but that decision should not hinge upon the availability of affected software within Fedora but upon the popularity of such software among users of Fedora, the ease with which that software can be made to work with Fedora once the change goes in, and how those questions weigh against the issues that are resolved by the new version. If those aren't the criteria that we want to use then the updats policy (and possibly the updates vision) should be amended. please complain on the rpmfusion list why th e hell they are not maintain their packages as they stopped support open-vm-tools for F15 and do not blame fedora that it will not happen again like with F14 that a brand new operating system does not support current hardware and yes a 6 month old release is brand new signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rethinking proventester and critpath
Ken Dreyer (ktdre...@ktdreyer.com) said: On Tue, Nov 22, 2011 at 6:06 AM, Nils Philippsen n...@redhat.com wrote: Hm. The list of (implicitly labeled) critpath packages seems to have proliferated recently Why not impose a self-restriction on the number of critpath packages? Make a rule like The ratio of proventesters to critpath packages must be x or higher. When the critpath numbers start creeping up, drop a few other packages from critpath. This will help focus testing efforts, and allow it to expand along with the growth of the community. This then implies creation of a process that involves continual review of the critpath package list, where it was designed to be able to be simply computed without a lot of manual work. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rethinking proventester and critpath
On Tue, 2011-11-22 at 07:42 -0700, Ken Dreyer wrote: On Tue, Nov 22, 2011 at 6:06 AM, Nils Philippsen n...@redhat.com wrote: Hm. The list of (implicitly labeled) critpath packages seems to have proliferated recently Why not impose a self-restriction on the number of critpath packages? Make a rule like The ratio of proventesters to critpath packages must be x or higher. When the critpath numbers start creeping up, drop a few other packages from critpath. This will help focus testing efforts, and allow it to expand along with the growth of the community. But that wouldn't really help, would it? I assume packages are explicitly labeled critpath for a reason: if they break, the system might not boot up, or users might not be able to log in (or several other reasons). I think the current system is a bit too simplistic when it comes to the packages upon which critpath components depend, however. For instance (picking this example because it affects me), I don't think that logging in should fail because of problems the scanner library may have. Or because (drawing examples from a hat) the desktop background can't be set, or there's an issue with the camera in your laptop. Yet, by way of simply following package dependencies, we do as if that were the case. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote: On Mon, Nov 21, 2011 at 04:59:54PM -0800, Toshio Kuratomi wrote: The updates policy is meant to protect users of Fedora within reason. Compiling, writing, and using third party software on Fedora is a valid use of Fedora whether or not that software exists within Fedora. This update may be acceptable because the bugs fixed were deemed more worthwhile than the changes that were introduced but that decision should not hinge upon the availability of affected software within Fedora but upon the popularity of such software among users of Fedora, the ease with which that software can be made to work with Fedora once the change goes in, and how those questions weigh against the issues that are resolved by the new version. We don't support out of tree kernel modules at all, so they're not considered when making the determination about whether an update is appropriate for a stable update. Nonsense. We don't support them but the updates policy as written covers them. I quoted the places in the policy in my other mail. If you don't like what the updates policy says then change the updates policy to remove, amend, or clarify those sections. However, I also said that the updates policy leaves the decision as a weighted judgement on the maintainer's behalf; the maintainer is free to consider that the bugfixes that the update brings in are more important than the not-in-Fedora-packages that could be broken. I think that is sufficient to cover this case. -Toshio pgpIYwvzTKcfe.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 08:12:42AM -0800, Toshio Kuratomi wrote: On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote: We don't support out of tree kernel modules at all, so they're not considered when making the determination about whether an update is appropriate for a stable update. Nonsense. We don't support them but the updates policy as written covers them. I quoted the places in the policy in my other mail. If you don't like what the updates policy says then change the updates policy to remove, amend, or clarify those sections. The kernel ABI is the syscall interface, /sys and /proc. There is no stable module ABI between kernels - even with a small security update, the symbol versioning may change in such a way that the module ABI will change. Given that any interpretation of the stable update policy that prevented us from ever providing kernel security updates would be absurd, that's clearly not the correct interpretation. And if the module ABI isn't supported, nor is the API. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 752698] The icon is packaged, but it doesn't show on Gnome 3.2.
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=752698 Karel Klíč kk...@redhat.com changed: What|Removed |Added CC||mephi...@fastmail.net --- Comment #3 from Karel Klíč kk...@redhat.com 2011-11-22 11:31:35 EST --- *** Bug 746449 has been marked as a duplicate of this bug. *** -- 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: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 05:32:56PM +0100, Vít Ondruch wrote: It would be reasonable, on the beginning of each development cycle, to publish a list of packages which were not touched by it maintainer in previous release. For all these packages, new co-maintainer could stepped up and they would be granted the co-maintainers privileges automatically. There are several packages I am the main maintainer of, but do not need any work from my side during a new release. Iirc at least for one package the co-maintainer usually updates it. So what is broken here? Imho the focus should be on untouched important bugs. If they pile up, then the maintainer needs help. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
Dne 22.11.2011 17:44, Chris Adams napsal(a): Once upon a time, Vít Ondruchvondr...@redhat.com said: It would be reasonable, on the beginning of each development cycle, to publish a list of packages which were not touched by it maintainer in previous release. For all these packages, new co-maintainer could stepped up and they would be granted the co-maintainers privileges automatically. How is not touched automatically a problem that needs new maintainers? Not every package has rapid development that necessarily needs a package update within a 6 month period. I am not saying it is automatically problem, but it might be. Its obvious that package, which is in latest version, probably doesn't need update. However that is not easy to track, as long as the upstream release monitoring is not mandatory. I am not proposing change of owner or anything like this. I am speaking about new co-maintainer. There is nothing wrong about it I believe. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 04:23:28PM +, Matthew Garrett wrote: On Tue, Nov 22, 2011 at 08:12:42AM -0800, Toshio Kuratomi wrote: On Tue, Nov 22, 2011 at 03:08:07PM +, Matthew Garrett wrote: We don't support out of tree kernel modules at all, so they're not considered when making the determination about whether an update is appropriate for a stable update. Nonsense. We don't support them but the updates policy as written covers them. I quoted the places in the policy in my other mail. If you don't like what the updates policy says then change the updates policy to remove, amend, or clarify those sections. The kernel ABI is the syscall interface, /sys and /proc. There is no stable module ABI between kernels - even with a small security update, the symbol versioning may change in such a way that the module ABI will change. Given that any interpretation of the stable update policy that prevented us from ever providing kernel security updates would be absurd, that's clearly not the correct interpretation. And if the module ABI isn't supported, nor is the API. That's not a logical conclusion. As I said in both my previous emails, the updates policy allows the maintainer to decide that the benefits of a new version outwiegh the problems. According to the updates policy the maintainer needs to consider that their change will cause problems for third party kernel module packagers and end users that are compiling their own kernel modules. The policy does not require that the kernel maintainers weigh this more heavily than the need to provide security updates (or new hardware or major bugfixes). If you're steamed up that the policy requires maintainers to consider their impact on end users at all, the onus is on you to make a change to the policy. As long as the policy gives the maintainer the ability to explain how the pros and cons of updates stack up in their view, however, it doesn't seem nearly as bad as you make it out to be. -Toshio pgp9reAft7PbD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 12:38:23 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: I think the only way to achieve something like this for maintainership we need to drop the ownership module so either nobody owns a package/component in the project or relevant SIG owns the package. We can already do this. People that want to help co-maintain other packages can ask as long as they are a packager. For packages I am the designated owner, I am happy to accept help. One area where we could probably do more advertising for is getting new packagers via the co-maintainer route. I think most of the new packagers still come in by packaging a new package. I think we really want most of the new packagers coming in as co-maintainers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
2011/11/22 Matthew Garrett mj...@srcf.ucam.org: The kernel ABI is the syscall interface, /sys and /proc. There is no stable module ABI between kernels - even with a small security update, the symbol versioning may change in such a way that the module ABI will change. Given that any interpretation of the stable update policy that prevented us from ever providing kernel security updates would be absurd, that's clearly not the correct interpretation. And if the module ABI isn't supported, nor is the API. -- Matthew Garrett | mj...@srcf.ucam.org -- The failure is due to Fedora *non-upstream* versionning scheme, VirtualBox has *already* fixes the API/ABI issue upstream relying on the kernel version (since 3.2 RC). It has nothing to do with the kernel non-stable ABI policy (which is notorious). The least we can do is helping third-party packagers to fix this issue, not slamming the door on their face. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
2011/11/22 Bruno Wolff III br...@wolff.to: One area where we could probably do more advertising for is getting new packagers via the co-maintainer route. I think most of the new packagers still come in by packaging a new package. I think we really want most of the new packagers coming in as co-maintainers. Yes, this seems to be an chicken-or-the-egg issue. There seems to be permanent resource shortages with package maintenance which means we need more contributors, and then at the same time there are hundreds of package reviews languishing, many of which need sponsors. I don't want to get too far off topic but being short handed is directly related... Does the sponsor processes need to be more formalized? Currently you must be nominated (either by someone or yourself) but there's no concrete requirements on a knowledge or skill level required to be a sponsor. To bring it to a more personal level, I have no idea if I've done or proven myself enough to become a sponsor or not. If I am deficient in an area, there's currently no formal feedback mechanism for me to know in what areas I need to improve. I can't be the only person stuck in this nebulous position... Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote: According to the updates policy the maintainer needs to consider that their change will cause problems for third party kernel module packagers and end users that are compiling their own kernel modules. We *know* we're going to break out of tree modules. It's entirely expected. There's nothing to consider here at all. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 06:00:43PM +0100, 80 wrote: The failure is due to Fedora *non-upstream* versionning scheme, VirtualBox has *already* fixes the API/ABI issue upstream relying on the kernel version (since 3.2 RC). It has nothing to do with the kernel non-stable ABI policy (which is notorious). The least we can do is helping third-party packagers to fix this issue, not slamming the door on their face. The supported way to provide a module for Fedora is to have it in the upstream kernel source. Anything else is explicitly not supported. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 752698] The icon is packaged, but it doesn't show on Gnome 3.2.
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=752698 Emmanuel Seyman emmanuel.sey...@club-internet.fr changed: What|Removed |Added CC||emmanuel.seyman@club-intern ||et.fr --- Comment #4 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2011-11-22 12:11:26 EST --- FWIW, if I take the file /usr/share/applications/fedora-padre.desktop and replace : Icon=padre with Icon=/usr/share/icons/hicolor/64x64/apps/padre.png the icon shows up in gnome-shell. -- 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: Changing kernel API / Breaking VirtualBox - update criteria violation?
On 11/22/2011 12:13 PM, Matthew Garrett wrote: On Tue, Nov 22, 2011 at 06:00:43PM +0100, 80 wrote: The failure is due to Fedora *non-upstream* versionning scheme, VirtualBox has *already* fixes the API/ABI issue upstream relying on the kernel version (since 3.2 RC). It has nothing to do with the kernel non-stable ABI policy (which is notorious). The least we can do is helping third-party packagers to fix this issue, not slamming the door on their face. The supported way to provide a module for Fedora is to have it in the upstream kernel source. Anything else is explicitly not supported. For those having trouble - one pragmatic way is just to download the f16 3.1.x source rpm and rebuild it on F15 - VB will now work fine. Of course - caution drove the renaming of this kernel to 2.6.41 so it could break ... that said it does work fine for me ... gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 756108] New: Use of uninitialized value $root in exists at .../Role/NestedHashUtils.pm line 121.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Use of uninitialized value $root in exists at .../Role/NestedHashUtils.pm line 121. https://bugzilla.redhat.com/show_bug.cgi?id=756108 Summary: Use of uninitialized value $root in exists at .../Role/NestedHashUtils.pm line 121. Product: Fedora Version: 16 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-HTML-FormFu AssignedTo: iarn...@gmail.com ReportedBy: dgp...@corefiling.co.uk QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Created attachment 535130 -- https://bugzilla.redhat.com/attachment.cgi?id=535130 Stop warning in HTML::FormFu::Role::NestedHashUtils Description of problem: Submitting a form containing a Label element generates the follow warning: Use of uninitialized value $root in exists at /usr/share/perl5/vendor_perl/HTML/FormFu/Role/NestedHashUtils.pm line 121. Version-Release number of selected component (if applicable): 0.09003 How reproducible: Always Steps to Reproduce: 1. Create a form containing a Label and Submit elements Sample YAML: elements: - type: Label label: foo - type: Submit name: submit 2. Hit Submit Actual results: Use of uninitialized value $root in exists at /usr/share/perl5/vendor_perl/HTML/FormFu/Role/NestedHashUtils.pm line 121. printed to console Expected results: No warnings to the console Additional info: Developing with Catalyst. Attaching a simple patch to stop the noise. -- 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: Fedora clean up process seems to be seriously broken...
On Tue, 22 Nov 2011 17:32:56 +0100, VO (Vít) wrote: I remember at leas one example from history when I was not able to reach the maintainer and at the end he was quite angry that I was so daring to call him unresponsive, even though I wanted just to help him. Also, there are other packages I asked for ACL's but never get them confirmed. Just for completeness, do you refer to completing the http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers procedure with an unsatisfactory result at its end? If so, can you link to example tickets in bugzilla? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 11:05:37AM -0600, Richard Shaw wrote: 2011/11/22 Bruno Wolff III br...@wolff.to: One area where we could probably do more advertising for is getting new packagers via the co-maintainer route. I think most of the new packagers still come in by packaging a new package. I think we really want most of the new packagers coming in as co-maintainers. Yes, this seems to be an chicken-or-the-egg issue. There seems to be permanent resource shortages with package maintenance which means we need more contributors, and then at the same time there are hundreds of package reviews languishing, many of which need sponsors. I don't want to get too far off topic but being short handed is directly related... Does the sponsor processes need to be more formalized? Currently you must be nominated (either by someone or yourself) but there's no concrete requirements on a knowledge or skill level required to be a sponsor. To bring it to a more personal level, I have no idea if I've done or proven myself enough to become a sponsor or not. If I am deficient in an area, there's currently no formal feedback mechanism for me to know in what areas I need to improve. What helped me was first to find someone I wanted to sponsor. I would like to sponsor someone else, but looking through the review tickets I hardly find any potential new contributor that performed informal reviews as stated in the wiki. Or at least there was not trace of the informal reviews in the review ticket. Back to the question: I guess the main skill needed is to be able to monitor the sponsoree's activities and to identify bad behaviour. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
Genes MailLists wrote: For those having trouble - one pragmatic way is just to download the f16 3.1.x source rpm and rebuild it on F15 - VB will now work fine. You don't need to do that. Just use my attached patch. (Only use the patch on F15 systems with F15 kernels.) --- /usr/share/virtualbox/src/vboxhost/vboxpci/linux/VBoxPci-linux.c.orig 2011-08-09 01:30:24.0 -0500 +++ /usr/share/virtualbox/src/vboxhost/vboxpci/linux/VBoxPci-linux.c 2011-11-22 11:46:55.231412945 -0600 @@ -35,11 +35,7 @@ #ifdef VBOX_WITH_IOMMU #include linux/dmar.h #include linux/intel-iommu.h -#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0) # include asm/amd_iommu.h -#else -# include linux/amd-iommu.h -#endif #endif -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
Michael Cronenworth wrote: Just use my attached patch. It helps if I attach the correct patch. --- /usr/share/virtualbox/src/vboxhost/vboxpci/linux/VBoxPci-linux.c.orig 2011-08-09 01:30:24.0 -0500 +++ /usr/share/virtualbox/src/vboxhost/vboxpci/linux/VBoxPci-linux.c 2011-11-22 11:50:24.657346362 -0600 @@ -35,12 +35,8 @@ #ifdef VBOX_WITH_IOMMU #include linux/dmar.h #include linux/intel-iommu.h -#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0) -# include asm/amd_iommu.h -#else # include linux/amd-iommu.h #endif -#endif /*** -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Dropping the ownership model
What do people see as pros and cons continuing to use the current package ownership model? Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? Would it be viable to move to something like language SIG based ownership of packages? As in lower the barrier of entry of contributor without the need and or introduction of an package or any sponsorship and have them assigned to relevant SIG based on language they either know or want to learn. ( not necessarly having to tie packaging with code contribution ). The governing body of the SIG would in essence be the once that would be responsible for the components. So as an example a indvidual skilled in Java who would want to join the project would automatically be assigned to the java SIG which in turn would be assigned and managing all Java related components then the Java SIG based on what ever process/workflow they have decided would assign to that individual what ever task is needed at current times prioritized by the knowledge and resource they posses. So basically the barrier of entry is no higher than what the individual wants to learn or knows already as in.. Do you know or want to learn python. Join the python SIG etc... Do you want to learn distribution packaging join the Packaging SIG Or the individual would learn how to package components relevant to the SIG he just joined Thoughts? Far off and totally crazy, you are mad! What meds are you on can I have some? The SIG approach is something that actually might work... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, 22 Nov 2011 11:05:37 -0600, RS (Richard) wrote: 2011/11/22 Bruno Wolff III: One area where we could probably do more advertising for is getting new packagers via the co-maintainer route. I think most of the new packagers still come in by packaging a new package. I think we really want most of the new packagers coming in as co-maintainers. Yes, this seems to be an chicken-or-the-egg issue. There seems to be permanent resource shortages with package maintenance which means we need more contributors, and then at the same time there are hundreds of package reviews languishing, many of which need sponsors. Uh, come on, ... package submitters waiting on the NEEDSPONSOR list could _really_ work a little bit more actively on persuading potential sponsors of their packaging skills. Instead, some wait silently for months without doing any package review themselves. In other cases, reviewers post reviews, but it takes many weeks or months for the package submitter to respond. What does that tell potential sponsors about the submitter's motivation to become a package maintainer? Btw, it has happened before that people have been sponsored without doing a couple of package reviews. Sometimes as a result of them actively seeking for a sponsor. That may be easier than waiting for magic to happen. We still don't have enough package reviewers. I don't want to get too far off topic but being short handed is directly related... Does the sponsor processes need to be more formalized? Currently you must be nominated (either by someone or yourself) but there's no concrete requirements on a knowledge or skill level required to be a sponsor. To bring it to a more personal level, I have no idea if I've done or proven myself enough to become a sponsor or not. If I am deficient in an area, there's currently no formal feedback mechanism for me to know in what areas I need to improve. I can't be the only person stuck in this nebulous position... And still there have been self-nominations before. You could look up FESCo tickets of past nominations. Are you an active reviewer? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
VO == Vít Ondruch vondr...@redhat.com writes: VO It would be reasonable, on the beginning of each development cycle, VO to publish a list of packages which were not touched by it VO maintainer in previous release. I certainly hope you realize that there are very many packages in the distribution that simply do not need to be touched by the maintainer all that often. Many packages will have seen no upstream changes at all for quite some time and unless we do a mass rebuild or make changes to the packaging guidelines which require updates, there is simply no need to pointlessly waste time messing with packages just to avoid appearing on some potentially horrible maintainers list. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 12:08:14PM -0500, Dave Jones wrote: On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote: According to the updates policy the maintainer needs to consider that their change will cause problems for third party kernel module packagers and end users that are compiling their own kernel modules. We *know* we're going to break out of tree modules. It's entirely expected. There's nothing to consider here at all. I don't disagree with your first two sentences. In fact I'd go further -- It's not only expected, it's also accepted by you. The third sentence is the only thing that I think needs to be looked at in terms of the Update Policy. The updates policy and the updates vision on which it is based strive to make maintainers realize that pushing updates has both positive and negative effects on end users. Some of those effects are also expected and accepted. For instance, the updates vision says Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks. Simply issuing an update is in and of itself one negative in the updates vision. So, yes, it may be fully expected that issuing an update will break out of tree modules but that doesn't stop it from being one factor to *consider*. Just remember that I am *not* arguing that just because you should be considering it you have to decide that it's more important than you already do. You think of it as a cost of doing business just like the cost to the user of dealing with a large number of updates at all. This is a cost that you have implicitly weighed against the benefits of being able to bring new kernels to the end user that fix real bugs, support new hardware, and are otherwise beneficial. I have no problem with you deciding that the benefit amply justifies the cost. -Toshio pgptp5M7FAcDX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
2011/11/22 Jóhann B. Guðmundsson johan...@gmail.com: What do people see as pros and cons continuing to use the current package ownership model? Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? Allowing any packager to commit to most packages is something that we could try. There is a risk of people making undesirable changes, but we won't know until we try. Also, the definition of undesirable often depends on some project-specific knowledge that is not documented anywhere, and having the access more open would be an incentive to get this documented. I wouldn't want to get rid of the ownership model altogether, I think there should be a specific person responsible for handling bug reports/RFEs. When a group is responsible to handle something not really pleasant to do, often no single member of that group feels personally responsible. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 22/11/11 17:53, Michael Schwendt wrote: Uh, come on, ... package submitters waiting on the NEEDSPONSOR list could _really_ work a little bit more actively on persuading potential sponsors of their packaging skills. Instead, some wait silently for months without doing any package review themselves. As somebody who is in exactly that situation all I can say is that if doing informal reviews is an essential prerequisite to getting sponsored then the wiki could be a lot clearer. Currently it reads more like it's just one thing that may help. Tom (who is off to look for something to review) -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
On 11/22/2011 05:59 PM, Miloslav Trmač wrote: 2011/11/22 Jóhann B. Guðmundssonjohan...@gmail.com: What do people see as pros and cons continuing to use the current package ownership model? Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? Allowing any packager to commit to most packages is something that we could try. There is a risk of people making undesirable changes, but we won't know until we try. Also, the definition of undesirable often depends on some project-specific knowledge that is not documented anywhere, and having the access more open would be an incentive to get this documented. I wouldn't want to get rid of the ownership model altogether, I think there should be a specific person responsible for handling bug reports/RFEs. When a group is responsible to handle something not really pleasant to do, often no single member of that group feels personally responsible. With that move as in either to SIG or Group model I would think they would have to have set of representitives as in head's of the group/SIG which would be set of individual responsible for overseeing the group activity and at the same time be responsible for all the packages that group/SIG maintains. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote: So, yes, it may be fully expected that issuing an update will break out of tree modules but that doesn't stop it from being one factor to *consider*. Consideration implies that the following thought process will occur This update will break out of tree modules, perhaps we shouldn't push it. That isn't going to happen. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
As much as we have disagreed on the previous topic we might have similar thoughts here :). - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 7:51:31 PM Subject: Dropping the ownership model What do people see as pros and cons continuing to use the current package ownership model? Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? Well, everyone becoming a proven packager is going too far from the beginning. Though I have to say that this approach worked quite good in Mandriva in the past. I still remember misc telling me please don't break too much . For the few years I maintained packages there I haven't seen a single case of someone abusing his powers. Would it be viable to move to something like language SIG based ownership of packages? SIGs are quite good idea and making more use of them can help providing more structure when in need of getting help. As in lower the barrier of entry of contributor without the need and or introduction of an package or any sponsorship and have them assigned to relevant SIG based on language they either know or want to learn. ( not necessarly having to tie packaging with code contribution ). The governing body of the SIG would in essence be the once that would be responsible for the components. Well SIGs don't really have governing bodies and it is always good to have a concrete name when you look for contacts for some package. Probably packages can be assigned to person and SIG and they are open for everyone from the SIG but still having a concrete name you can talk to. Essentially the SIG will be the owner of the package and a person(s) will be listed as something like primary contact(s). So as an example a indvidual skilled in Java who would want to join the project would automatically be assigned to the java SIG which in turn would be assigned and managing all Java related components then the Java SIG based on what ever process/workflow they have decided would assign to that individual what ever task is needed at current times prioritized by the knowledge and resource they posses. As we(Java SIG) have quite similar approach aka someone from the SIG is taking a task he wants to work on and do it no matter who is the maintainer/co-maintainers the current situation is a bit annoying because people have to collect way too many permissions in pkgdb and this is either slowing down the process or depending on some provenpackager to push the work. Such a SIG approach to packaging will definetely make it easier and as long as the packager has access only to the SIG's packages this should not scare other SIGs because new packager in certain SIG wouldn't be able to touch other SIGs packages. Alexander Kurtakov So basically the barrier of entry is no higher than what the individual wants to learn or knows already as in.. Do you know or want to learn python. Join the python SIG etc... Do you want to learn distribution packaging join the Packaging SIG Or the individual would learn how to package components relevant to the SIG he just joined Thoughts? Far off and totally crazy, you are mad! What meds are you on can I have some? The SIG approach is something that actually might work... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 12:55 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Tue, Nov 22, 2011 at 12:08:14PM -0500, Dave Jones wrote: On Tue, Nov 22, 2011 at 08:53:13AM -0800, Toshio Kuratomi wrote: According to the updates policy the maintainer needs to consider that their change will cause problems for third party kernel module packagers and end users that are compiling their own kernel modules. We *know* we're going to break out of tree modules. It's entirely expected. There's nothing to consider here at all. I don't disagree with your first two sentences. In fact I'd go further -- It's not only expected, it's also accepted by you. The third sentence is the only thing that I think needs to be looked at in terms of the Update Policy. The updates policy and the updates vision on which it is based strive to make maintainers realize that pushing updates has both positive and negative effects on end users. Some of those effects are also expected and accepted. For instance, the updates vision says Similarly, dealing with a large number of updates on a regular basis is distracting from the user's desired productivity tasks. Simply issuing an update is in and of itself one negative in the updates vision. So, yes, it may be fully expected that issuing an update will break out of tree modules but that doesn't stop it from being one factor to *consider*. We have considered it. A really long time ago. At that time, it was decided that we consider out-of-tree modules to be something we don't support, don't care about, and won't hold up updates for because of the aforementioned heavier considerations of fixing bugs. So, with that phrasing in mind, everything is compliant with what you're saying about the updates policy. Maybe now this thread can end, because it's really not accomplishing anything at all. If we wanted to sit around and practice wordsmithing, there are much better places and topics to do it with. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
TH == Tom Hughes t...@compton.nu writes: TH As somebody who is in exactly that situation all I can say is that TH if doing informal reviews is an essential prerequisite to getting TH sponsored then the wiki could be a lot clearer. Currently it reads TH more like it's just one thing that may help. It is just one thing that may help. Since we give sponsors significant choice in who they will or will not sponsor, different sponsors may choose to look at different things. Most of them will want to see something that illustrates packaging experience, though. Doing informal reviews is a good way to do that. Which is pretty much what the wiki says, isn't it? - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
Miloslav Trmač wrote: I wouldn't want to get rid of the ownership model altogether, I think there should be a specific person responsible for handling bug reports/RFEs. When a group is responsible to handle something not really pleasant to do, often no single member of that group feels personally responsible. All the core KDE packages are de facto SIG-maintained; no matter who the official primary maintainer of the particular package is, we all feel equally responsible for them. This works very well. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
2011/11/22 Dave Jones da...@redhat.com: On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote: Consideration implies that the following thought process will occur This update will break out of tree modules, perhaps we shouldn't push it. That isn't going to happen. To me, this sounds like knowingly violating the Updates Policy, which states: Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 11:53 AM, Michael Schwendt mschwe...@gmail.com wrote: On Tue, 22 Nov 2011 11:05:37 -0600, RS (Richard) wrote: 2011/11/22 Bruno Wolff III: One area where we could probably do more advertising for is getting new packagers via the co-maintainer route. I think most of the new packagers still come in by packaging a new package. I think we really want most of the new packagers coming in as co-maintainers. Yes, this seems to be an chicken-or-the-egg issue. There seems to be permanent resource shortages with package maintenance which means we need more contributors, and then at the same time there are hundreds of package reviews languishing, many of which need sponsors. Uh, come on, ... package submitters waiting on the NEEDSPONSOR list could _really_ work a little bit more actively on persuading potential sponsors of their packaging skills. Instead, some wait silently for months without doing any package review themselves. That may be true, but from my own experience, it could also because they're intimidated by the whole process. Submitting my first package I certainly felt intimidated by the process. I was lucky I had good sponsors to walk me through the process but I'm not sure that everyone is. In other cases, reviewers post reviews, but it takes many weeks or months for the package submitter to respond. What does that tell potential sponsors about the submitter's motivation to become a package maintainer? I won't argue that that doesn't happen because it does Btw, it has happened before that people have been sponsored without doing a couple of package reviews. Sometimes as a result of them actively seeking for a sponsor. That may be easier than waiting for magic to happen. We still don't have enough package reviewers. I don't want to get too far off topic but being short handed is directly related... Does the sponsor processes need to be more formalized? Currently you must be nominated (either by someone or yourself) but there's no concrete requirements on a knowledge or skill level required to be a sponsor. To bring it to a more personal level, I have no idea if I've done or proven myself enough to become a sponsor or not. If I am deficient in an area, there's currently no formal feedback mechanism for me to know in what areas I need to improve. I can't be the only person stuck in this nebulous position... And still there have been self-nominations before. You could look up FESCo tickets of past nominations. I never thought about that, perhaps it should be added to the contributor wiki? Are you an active reviewer? It comes in spurts when I have time, but yes. That also begs the question: How does a sponsor find future sponsors? Just because I complete an informal or formal review doesn't mean that a sponsor sees it, unless there's some system that provides visibility that I'm unaware of. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote: On Tue, Nov 22, 2011 at 05:12:12PM +, Matthew Garrett wrote: I don't know how much clearer I can make this. The update policy applies to the supported ABI of the package. For instance, if I have an application that depends on byte 0x9e0 of /bin/ls being 0xdf and an update breaks that, that's not a relevant consideration for the update policy. The kernel module interface is not a supported ABI in Fedora. It's simply not a relevant consideration for the update policy. I don't know how much clearer I can make this -- The updates policy applies to more than the supported ABI of a package. For instance, if you have an application that dependds on /bin/ls printing ? when it encounters a filename with a byte that cannot be decoded in the current locale and it starts printing \001 instead, that is a relevant consideration according to the updates policy. Consuming the output of ls is a supported way to use ls. Building third party modules is not a supported way to use the kernel. The policy is fine as is. The problem is your overreaching definition of ABI. We could make it explicit that the module interface isn't an exported ABI by modifying the loader so that third-party modules simply can't be loaded at all and then this clearly wouldn't be an issue, but I don't think anyone benefits from us doing that. The definition of ABI is not at issue. The reach of the updates policy itself is. If I'm understanding you correctly you think the updates policy applies to a much more limited scope of changes than I do. I would suggest that that is an indication that the updates policy needs to be reworded in at least certain places so as to more clearly illustrate whether it has a broad scope (in which things like ABI are examples of criteria for deciding not to issue an update) or limited scope (in which ABI is one of the specific criteria for decding to withhold an update.) It's clear that if we disabled the ability to build third party modules at all that the ability to use third party modules would be entirely irrelevant and clearly not a consideration. So just pretend that we've done that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 11/22/2011 05:27 PM, Jóhann B. Guðmundsson wrote: First of all why do I need to come up with a concrete proposal to FESCO why dont they come up with something to try to improve the distribution. Does that governing body only exist to say yay or nay to others proposals? FESCo exists mostly to approve, yes. If you want them to do something, write up a proposal or atleast start a discussion with the goal of eventually writing one. Otherwise, you are just wasting time. Secondly the only reason I don't maintain packages within the distribution is because I'm fully aware that I dont have time in doing so. Then recognize that other people have limited time and your tone doesn't seem to ack that at all. This is the reason you are perceived to be demanding and bullying people. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
On 11/22/2011 06:51 PM, Jóhann B. Guðmundsson wrote: What do people see as pros and cons continuing to use the current package ownership model? ownership = responsibility Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? No. a) This would allow any arbitrary clueless newbie to hack around in stuff he fails to understand he is not qualified to do. b) This would encourage an attitude of lazyness (Others will do) Would it be viable to move to something like language SIG based ownership of packages? Yes, except that this kind of model would require an amount of bureacratic overhead Fedora is not able to supply. Thoughts? Far off and totally crazy, you are mad! No you are naive ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 11/22/2011 11:55 PM, Richard Shaw wrote: On Tue, Nov 22, 2011 at 11:53 AM, Michael Schwendt mschwe...@gmail.com wrote: And still there have been self-nominations before. You could look up FESCo tickets of past nominations. I never thought about that, perhaps it should be added to the contributor wiki? Sure. Feel free to do so and also file a ticket with FESCo to nominate yourself as a sponsor along with it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
Am 22.11.2011 18:00, schrieb 80: The failure is due to Fedora *non-upstream* versionning scheme, VirtualBox has *already* fixes the API/ABI issue upstream relying on the kernel version (since 3.2 RC). It has nothing to do with the kernel non-stable ABI policy (which is notorious). The least we can do is helping third-party packagers to fix this issue, not slamming the door on their face. well and why is RPMFUSION not updateing their packages as they did also with open-vm-tools and in the case of open-vm-tools they decided to drop the whole package as example for vmware: VMware-Workstation 8 requires ONE single line changed and the modules get compiled with 2.6.41 so complain rpmfusion why they are ALWAYS behind the fedora-kernel-packages and all their kmod and so on are making troubles days and weeks before they are push at fedora-stable repo, so the rpmfusion-maintainers should consider to use UPDATES-TESTING to see minor issues before the endusers signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 11:57:24AM +, Jóhann B. Guðmundsson wrote: First of all why do I need to come up with a concrete proposal to FESCO why dont they come up with something to try to improve the distribution. Because demanding that other people do work generally doesn't result in the desired outcome. I'm not paid to work on Fedora. Time I spend on fesco is time I volunteer because I genuinely want to help Fedora improve. I think it's great that this is an issue you're concerned about, but if you want to turn your concern into something useful then you either need to convince other people to care as much as you or you need to come up with a proposal yourself. Does that governing body only exist to say yay or nay to others proposals? As a body, yes. As individuals, no. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
On Tue, 22 Nov 2011 17:51:31 + Jóhann B. Guðmundsson johan...@gmail.com wrote: What do people see as pros and cons continuing to use the current package ownership model? Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? I'm not sure it would be. Would it be viable to move to something like language SIG based ownership of packages? Well, if we did that we would need to revamp SIGs I suppose. We would need to make sure that there was some kind of SIG that covered all packages so people would know who to talk with. Also, currently some SIGs are very active and some really aren't at all. Also, a number of SIGs overlap. As in lower the barrier of entry of contributor without the need and or introduction of an package or any sponsorship and have them assigned to relevant SIG based on language they either know or want to learn. ( not necessarly having to tie packaging with code contribution ). One thing thats worth noting here is: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer As another avenue to becoming a packager. The governing body of the SIG would in essence be the once that would be responsible for the components. So as an example a indvidual skilled in Java who would want to join the project would automatically be assigned to the java SIG which in turn would be assigned and managing all Java related components then the Java SIG based on what ever process/workflow they have decided would assign to that individual what ever task is needed at current times prioritized by the knowledge and resource they posses. So basically the barrier of entry is no higher than what the individual wants to learn or knows already as in.. Do you know or want to learn python. Join the python SIG etc... Do you want to learn distribution packaging join the Packaging SIG Good example. How do we handle overlaps here? Someone wishes to help with general packaging things, so they need to update the java package guidelines and fix those packages. Do they join the Packaging SIG? Java sig? both? Or the individual would learn how to package components relevant to the SIG he just joined Thoughts? Far off and totally crazy, you are mad! What meds are you on can I have some? The SIG approach is something that actually might work... I'm not convinced it would, without changing how our sigs are setup. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 07:24:20PM +0100, Thomas Moschny wrote: 2011/11/22 Dave Jones da...@redhat.com: On Tue, Nov 22, 2011 at 09:55:59AM -0800, Toshio Kuratomi wrote: Consideration implies that the following thought process will occur This update will break out of tree modules, perhaps we shouldn't push it. That isn't going to happen. To me, this sounds like knowingly violating the Updates Policy, which states: Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. (Ignoring the fact that changing a documented unstable API isn't anything to do with a developer experience) The kernel gets more bugs filed against it than any other component in the distro. Obviously this needs to be dealt with somehow. Asides from rebasing, we have two alternatives. 1. We backport just the fixes from upstream. Not feasible with the limited manpower we have. (See F14 for a great example of this failing) 2. We close every bug with -NEXTRELEASE If someone wants to do the relevant beurocracy to document this in the policies, go wild, but the kernel has always been this way since Fedora's inception. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 06:28:06PM +, Matthew Garrett wrote: On Tue, Nov 22, 2011 at 10:08:18AM -0800, Toshio Kuratomi wrote: On Tue, Nov 22, 2011 at 05:12:12PM +, Matthew Garrett wrote: I don't know how much clearer I can make this. The update policy applies to the supported ABI of the package. For instance, if I have an application that depends on byte 0x9e0 of /bin/ls being 0xdf and an update breaks that, that's not a relevant consideration for the update policy. The kernel module interface is not a supported ABI in Fedora. It's simply not a relevant consideration for the update policy. I don't know how much clearer I can make this -- The updates policy applies to more than the supported ABI of a package. For instance, if you have an application that dependds on /bin/ls printing ? when it encounters a filename with a byte that cannot be decoded in the current locale and it starts printing \001 instead, that is a relevant consideration according to the updates policy. Consuming the output of ls is a supported way to use ls. Building third party modules is not a supported way to use the kernel. That's not the criteria I see when reading the updates vision and updates policy. I don't see supported there; I see whether we're breaking things the way end users are using them. The policy is fine as is. The problem is your overreaching definition of ABI. We could make it explicit that the module interface isn't an exported ABI by modifying the loader so that third-party modules simply can't be loaded at all and then this clearly wouldn't be an issue, but I don't think anyone benefits from us doing that. The definition of ABI is not at issue. The reach of the updates policy itself is. If I'm understanding you correctly you think the updates policy applies to a much more limited scope of changes than I do. I would suggest that that is an indication that the updates policy needs to be reworded in at least certain places so as to more clearly illustrate whether it has a broad scope (in which things like ABI are examples of criteria for deciding not to issue an update) or limited scope (in which ABI is one of the specific criteria for decding to withhold an update.) It's clear that if we disabled the ability to build third party modules at all that the ability to use third party modules would be entirely irrelevant and clearly not a consideration. So just pretend that we've done that. So that we can have this discussion again when a different package also breaks end user expectations without breaking ABI? If we want to avoid long discussions that in the end boil down to different interpretations of the policies we need to take care to make our policies clearly reflect the meaning we intend. Clarifying wording may not be as fun as coding but it is necessary if we want to stop discussing the same points over and over with slightly different cases each time. -Toshio pgp6jellzJwIG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
As much as we have disagreed on the previous topic we might have similar thoughts here :). - Original Message - From: Jóhann B. Guðmundsson johan...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, November 22, 2011 7:51:31 PM Subject: Dropping the ownership model What do people see as pros and cons continuing to use the current package ownership model? Would it be practical to dropping it altogether which in essence would make every contributor an proven packager? Well, everyone becoming a proven packager is going too far from the beginning. Though I have to say that this approach worked quite good in Mandriva in the past. I still remember misc telling me please don't break too much . For the few years I maintained packages there I haven't seen a single case of someone abusing his powers. Would it be viable to move to something like language SIG based ownership of packages? SIGs are quite good idea and making more use of them can help providing more structure when in need of getting help. As in lower the barrier of entry of contributor without the need and or introduction of an package or any sponsorship and have them assigned to relevant SIG based on language they either know or want to learn. ( not necessarly having to tie packaging with code contribution ). The governing body of the SIG would in essence be the once that would be responsible for the components. Well SIGs don't really have governing bodies and it is always good to have a concrete name when you look for contacts for some package. Probably packages can be assigned to person and SIG and they are open for everyone from the SIG but still having a concrete name you can talk to. Essentially the SIG will be the owner of the package and a person(s) will be listed as something like primary contact(s). So as an example a indvidual skilled in Java who would want to join the project would automatically be assigned to the java SIG which in turn would be assigned and managing all Java related components then the Java SIG based on what ever process/workflow they have decided would assign to that individual what ever task is needed at current times prioritized by the knowledge and resource they posses. As we(Java SIG) have quite similar approach aka someone from the SIG is taking a task he wants to work on and do it no matter who is the maintainer/co-maintainers the current situation is a bit annoying because people have to collect way too many permissions in pkgdb and this is either slowing down the process or depending on some provenpackager to push the work. Such a SIG approach to packaging will definetely make it easier and as long as the packager has access only to the SIG's packages this should not scare other SIGs because new packager in certain SIG wouldn't be able to touch other SIGs packages. This might better reflect reality anyway. There are packages I own where someone else has done most of the heavy lifting for awhile, and others that other people own where I'm doing the heavy lifting. It takes a village, etc, etc. -J Alexander Kurtakov So basically the barrier of entry is no higher than what the individual wants to learn or knows already as in.. Do you know or want to learn python. Join the python SIG etc... Do you want to learn distribution packaging join the Packaging SIG Or the individual would learn how to package components relevant to the SIG he just joined Thoughts? Far off and totally crazy, you are mad! What meds are you on can I have some? The SIG approach is something that actually might work... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Mon, 21 Nov 2011 23:16:30 + Jóhann B. Guðmundsson johan...@gmail.com wrote: Hum not so sure that will effectively work at least the cleanup process needs have take place before we start the next development cycle atleast no later then GA so basically the performance review of the maintainer would have taken place in F15 for F17 and would take place in F16 for F18 etc... I didn't mean to suggest I was doing a performance review. I was just saying we could gather more data and see how widespread things are and how we could improve them. Note that we need to balance here cases like: * maintainer is very active, just ignoring $leafpackage right now. Indicator that the maintainer needs comaintainers Sure. We don't have this data currently anywhere central we can act on. * maintainer is on vacation/sick/etc Indicator that the maintainer needs comaintainers Sure. We don't have this data currently anywhere central we can act on. * maintainer needs help, we should try and help them out. Indicator that the maintainer needs comaintainers if not that, workload could be spread out to other community groups ( provenpackager/QA etc ) Sure. We don't have this data currently anywhere central we can act on. * maintainer doesn't use our bugzilla as their primary bug zone. That problem can be solved technically as in be made transparent to reports and maintainers ( reporters using our bugzilla but maintainers using their relevant upstream one ) Not sure how off hand. ;( * maintainer maintains a software that has a vast number of bugs and they can't deal with them all. True but you would actually see that on the activity on the bug report Yes, you would see it on the collection of data report I suggest above as well. * maintainer is working on higher priority bug, so ignoring feature requests/etc. Again that would be seen on the activity on the bug report Encase we are short on maintainers one way to increase that pool would be to drop the ownership model essentially making everybody provenpackager and allow everbody to play in everybody's pool... I don't think thats completely a good idea. You would get lots of people not feeling responsible for anything in particular. You would get people changing things when they didn't have good communication with upstream or a good idea for bugreports, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Mon, 21 Nov 2011 23:40:52 +0100 Till Maas opensou...@till.name wrote: On Mon, Nov 21, 2011 at 02:03:43PM -0800, Jesse Keating wrote: This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I remember that there has been a script that checked the health status of packages in Fedora by examining when the last build happened and maybe other facts. What happened to it? I came up with the idea, but have had no time to implement it. Folks who wish to actually commit to time to work on this, please let me know and I would be happy to help out as my time permits. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
TH == Tom Hughes t...@compton.nu writes: TH As somebody who is in exactly that situation all I can say is that TH if doing informal reviews is an essential prerequisite to getting TH sponsored then the wiki could be a lot clearer. Currently it reads TH more like it's just one thing that may help. It is just one thing that may help. Since we give sponsors significant choice in who they will or will not sponsor, different sponsors may choose to look at different things. Most of them will want to see something that illustrates packaging experience, though. Doing informal reviews is a good way to do that. Which is pretty much what the wiki says, isn't it? And this is how it's worked. For some of my sponsorees I've gone through several rounds of review bugs, others have been more streamlined. It's not about a number, it's about demonstrating that the prospective packager either knows what they're doing or can be taught. If they demonstrate that they won't need a lot of hand-holding, so much the better. ;) -J - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dropping the ownership model
2011/11/22 Jóhann B. Guðmundsson johan...@gmail.com: What do people see as pros and cons continuing to use the current package ownership model? I can't speak for anyone else. But for me I'm more than willing to see other contributors work with me to fix things in packages that I own. I'll even take the heat for a couple of good faith mistakes if they commit something that ends up needing to be reworked. People just have to walk up and talk to me about it and submit a patch. Every time I get a patch that is sane I ask if they want to be a co-owner. In fact I've already transferred ownership a couple of times because my co-owner is more engaged than I am in that packages health. The only thing stopping a other people from working with me on keeping my niche packages is interested manpower. requiring a SIG approach isn't going to magically make more people interested in keeping the packages I prioritize cobwebless. You are free to organize a SIG that does this sort of work and I will happily throw my packages under the bus and give your SIG some measure of accountability to keep them maintained without having to lose ownership myself. If you want a SIG approach to be the cultural norm... then prove to the contributorbase that it works well and start with a subset of packages that your SIG shepards in a communal approach and expand that approach. Don't mandate it. Don't lobby for it. DO IT and provide metrics which show the approach is more sustainable and deals with high volume bug traffic better. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 10:49:28AM -0800, Toshio Kuratomi wrote: On Tue, Nov 22, 2011 at 06:28:06PM +, Matthew Garrett wrote: Consuming the output of ls is a supported way to use ls. Building third party modules is not a supported way to use the kernel. That's not the criteria I see when reading the updates vision and updates policy. I don't see supported there; I see whether we're breaking things the way end users are using them. So just to be clear on this, you believe that if a user is relying on byte 0x9e0 of /bin/ls to be 0xdf on x86_64, then that is something that would have to be considered under the update policy? It's clear that if we disabled the ability to build third party modules at all that the ability to use third party modules would be entirely irrelevant and clearly not a consideration. So just pretend that we've done that. So that we can have this discussion again when a different package also breaks end user expectations without breaking ABI? If we want to avoid long discussions that in the end boil down to different interpretations of the policies we need to take care to make our policies clearly reflect the meaning we intend. If the relevant metric is end user expectations, why didn't you just say that in the beginning? We should be clearer that any expectation that third-party modules will be usable over the course of a stable release is wrong. I've no problem with that. It's still not an issue with the updates policy. Clarifying wording may not be as fun as coding but it is necessary if we want to stop discussing the same points over and over with slightly different cases each time. This case requires no clarification. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Getting Sponsored (was Re: Fedora clean up process seems to be seriously broken...)
I'd like to add/note: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer is another way to become a packager. Simply work on/with an existing maintainer on their package (submit bug reports, help test, submit patches, etc) and then ask them if they would like a co-maintainer (or indeed I think many maintainers will ask you first). kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 12:39 PM, Rahul Sundaram methe...@gmail.com wrote: On 11/22/2011 11:55 PM, Richard Shaw wrote: On Tue, Nov 22, 2011 at 11:53 AM, Michael Schwendt mschwe...@gmail.com wrote: And still there have been self-nominations before. You could look up FESCo tickets of past nominations. I never thought about that, perhaps it should be added to the contributor wiki? Sure. Feel free to do so and also file a ticket with FESCo to nominate yourself as a sponsor along with it. I've added some verbage to that effect as well as providing a direct link to the sponsorship tickets (sorted in descending order by ticket # so the most recent would be on top). Although the threshold for being a sponsor is fuzzy, I was able to review enough tickets to be pretty sure I do not meet the requirements at this time. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Tue, Nov 22, 2011 at 01:21:40PM -0500, Josh Boyer wrote: We have considered it. A really long time ago. At that time, it was decided that we consider out-of-tree modules to be something we don't support, don't care about, and won't hold up updates for because of the aforementioned heavier considerations of fixing bugs. So, with that phrasing in mind, everything is compliant with what you're saying about the updates policy. Nevertheless it would have been nice to mention that the kernel update will actually break the VirtualBox kernel module in it's update notes as it seems to me that a lot of people knew it and even the problematic change was mentioned in the update's feedback. Maybe now this thread can end, because it's really not accomplishing anything at all. If we wanted to sit around and practice wordsmithing, there are much better places and topics to do it with. What about this suggestion by Josh Stone? This seems to be a good result from the discussion: http://lists.fedoraproject.org/pipermail/devel/2011-November/159818.html | On 11/22/2011 09:51 AM, Michael Cronenworth wrote: | -#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0) | | It may have be helpful for the faked 2.6.4x kernels to still present a | 3ish LINUX_VERSION_CODE. AFAIK, faking the number is for the benefit of | userspace, not any kernel module. Perhaps it's not too late? Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On Tue, Nov 22, 2011 at 11:51:52AM -0700, Kevin Fenzi wrote: On Mon, 21 Nov 2011 23:40:52 +0100 Till Maas opensou...@till.name wrote: On Mon, Nov 21, 2011 at 02:03:43PM -0800, Jesse Keating wrote: This has come up nearly every release cycle. Problem is that nobody can seem to agree on what an appropriate sign of life would be, no has made a serious FESCo proposal for a contrived sign of life. I remember that there has been a script that checked the health status of packages in Fedora by examining when the last build happened and maybe other facts. What happened to it? I came up with the idea, but have had no time to implement it. Folks who wish to actually commit to time to work on this, please let me know and I would be happy to help out as my time permits. But I remember reports that contained similar information. Therefore some kind of script must have existed. Maybe it was related to some FTBFS reports where someone else reported that his script would have reported certain packages to be unmaintained as well. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting Sponsored (was Re: Fedora clean up process seems to be seriously broken...)
Also along these lines... Perhaps this has been discussed before I'm not aware of it but do we really need to hold up a package because the submitter needs a sponsor? What I mean by that is, if I'm not misunderstanding the process, that a person who submits their first package must be sponsored before that package can be accepted into Fedora. So basically we're holding up a package that may be very desirable to others until the packager has proven themselves. Does this make sense? If the package has made it to an acceptable state, should it not be accepted regardless of the packagers sponsor status? That way they could go ahead and get experience with the whole process, with just one package to start with, because believe me, the first package I imported into Fedora was an anxiety ridden experience with a high learning curve. Not everyone already understands fedpkg and git :) The net effect would be that new packagers would get to experience the process from start to finish with one package first. If/When they submit a second package, they would set the needsponsor flag again so only sponsors would review their packages, and so forth until such time that a sponsor believed it was time to take the training wheels off. Of course, I wouldn't want to discourage doing informal reviews of other packages. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
