Orphaning packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have had no time for the past months to look after my packages so I am orphaning them. teseq, mausezahn,samefile. I have been steadily orphaning packages because of time issues. Now I do not have any packages with me. So, if this calls for my removal from the package maintainer group please do so. If I want to take up some packages later once I have more time, I can always start the process. Regards, Vivek - - - -- Everyone is entitled to my opinion. - - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8SqRkACgkQwuZtrSampF9kfgCbBYSxi4uEjPv+RBHhPa13YXbs 7/wAn1ms9fBsq5QTpzgdbqS0O/PM9m8c =Gj3Y - - -END PGP SIGNATURE- - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8SqTYACgkQwuZtrSampF+GsACfR6sjiEwMJIN7Nlo+s/xqFu06 f8MAn34Zy3cudDkM8TRPcJDix4pYkK8u =dg80 - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8SqjoACgkQwuZtrSampF/4NgCdHaPLK4XLDdu0XAICO9zwCjNM 7tIAn3PkXWEF9XQbrdBMAzzjkCfuyktB =65z3 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/14/2012 07:12 PM, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) Kevin Kofler I agree! If a package is orphaned, can't we automatically escalate ownership to the next co-maintainer (when there is one - perhaps the one with the most commits for example). If a package is being orphaned for legitimate reasons, the owner should announce the intention to their co-maintainers first and they can opt to remove their ACLs before the package is orphaned. Its hard enough getting packages reviewed as is, let alone throwing a myriad of perfectly functioning packages back on the pile. Brendan (bsjones) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On Sun, 15 Jan 2012 11:28:10 +0100, VS (Vivek) wrote: >I have had no time for the past months to look after my packages so I am > orphaning them. > > teseq, mausezahn,samefile. I've taken "samefile". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphan: avant-windows-navigator and friends
With a little sadless I has to orhan avant-windows-navigator, awn-extras-applet and libdesktop-agnostic for fedora-devel (fedora-17) The avant-windows-navigator package don't build in rawhide because of changes in latest version of vala The awn-extras-applet has lot of problems with gnome 2.x dependencies there no longer is in fedora, because of transition to gnome 3. Upstream is moving very slow, so there is not much help there. I will keep it for F16 & F15 until they are EOL. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-01-16 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-01-16 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again, now we're ramping up towards Alpha, and the four of us who are at FUDCon will be bringing back lots of exciting news and progress (laugh now!) for you all. So join us on Monday to check in on the action items from last week and get an update on the FUDCon-y goings on. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120116 The current proposed agenda is include below. If no topics beyond the standard "Previous meeting follow-up" and "AutoQA update" topics are present or proposed, the meeting will be canceled. == Proposed Agenda Topics == 1. F16 retrospective task update 2. FUDCon report / follow-up 3. AutoQA update 4. Open Discussion - -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sun, Jan 15, 2012 at 11:48:35 +0100, Brendan Jones wrote: > On 01/14/2012 07:12 PM, Kevin Kofler wrote: > I agree! If a package is orphaned, can't we automatically escalate > ownership to the next co-maintainer (when there is one - perhaps the > one with the most commits for example). > > If a package is being orphaned for legitimate reasons, the owner > should announce the intention to their co-maintainers first and they > can opt to remove their ACLs before the package is orphaned. Currently to change ownership you need to orphan the package first so that the co-maintainer can take ownership. There isn't a one step way to give away a package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sun, Jan 15, 2012 at 2:46 PM, Bruno Wolff III wrote: > On Sun, Jan 15, 2012 at 11:48:35 +0100, > Brendan Jones wrote: >> On 01/14/2012 07:12 PM, Kevin Kofler wrote: >> I agree! If a package is orphaned, can't we automatically escalate >> ownership to the next co-maintainer (when there is one - perhaps the >> one with the most commits for example). >> >> If a package is being orphaned for legitimate reasons, the owner >> should announce the intention to their co-maintainers first and they >> can opt to remove their ACLs before the package is orphaned. > > Currently to change ownership you need to orphan the package first so that > the co-maintainer can take ownership. There isn't a one step way to > give away a package. He was talking about how the process should be improved not about the current state ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
I took teseq. 15.01.2012 14:28, Vivek Shah wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have had no time for the past months to look after my packages so I am orphaning them. teseq, mausezahn,samefile. I have been steadily orphaning packages because of time issues. Now I do not have any packages with me. So, if this calls for my removal from the package maintainer group please do so. If I want to take up some packages later once I have more time, I can always start the process. Regards, Vivek - - - -- Everyone is entitled to my opinion. - - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8SqRkACgkQwuZtrSampF9kfgCbBYSxi4uEjPv+RBHhPa13YXbs 7/wAn1ms9fBsq5QTpzgdbqS0O/PM9m8c =Gj3Y - - -END PGP SIGNATURE- - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8SqTYACgkQwuZtrSampF+GsACfR6sjiEwMJIN7Nlo+s/xqFu06 f8MAn34Zy3cudDkM8TRPcJDix4pYkK8u =dg80 - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk8SqjoACgkQwuZtrSampF/4NgCdHaPLK4XLDdu0XAICO9zwCjNM 7tIAn3PkXWEF9XQbrdBMAzzjkCfuyktB =65z3 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Bill Nottingham venit, vidit, dixit 13.01.2012 17:11: > Each release, before branching, we block currently orphaned packages. > It's that time again for Fedora 17. > > New this go-round is that we are also blocking packages that have > failed to build since before Fedora 15. > > The following packages are currently orphaned, or fail to build. If > you have a need for one of these packages, please pick them up. > > Due to the orphaning of packages due to inactive maintainers, this list > is a little longer than normal. > > Orphan GREYCstoration > Orphan adaptx > Orphan ario > Orphan armadillo > Orphan asa > comaintained by: pertusus > Orphan autodafe > Orphan avalon-framework > Orphan avalon-logkit > Orphan avl > Orphan axis > Orphan bcel > Orphan bibexport > comaintained by: pertusus > Orphan bit > Orphan blackbox > Orphan blt > Orphan bmake > Orphan bsf > Orphan bsh > Orphan bwidget > Orphan byaccj > comaintained by: dbhole > Orphan camstream > Orphan castor > Orphan ccsm > Orphan compiz > Orphan compiz-bcop > Orphan compiz-fusion-extras > Orphan compiz-fusion-unsupported > Orphan compiz-manager > Orphan compizconfig-backend-gconf > Orphan compizconfig-backend-kconfig4 > Orphan compizconfig-python > Orphan concurrent > Orphan conexus > Orphan crcimg > Orphan dbus-cxx > Orphan dotconf > Orphan eazykeyboard > Orphan eclipse-setools > Orphan eclipse-slide > Orphan eclipse-systemtapgui > Orphan eg > Orphan eiciel > Orphan erlang-erlzmq2 > Orphan expatmm > Orphan fortune-firefly > Orphan freehdl > comaintained by: chitlesh > Orphan ganglia > Orphan gestikk > Orphan gget > Orphan gimpfx-foundry > Orphan gkrellm-volume > Orphan gmime22 > Orphan gnome-paint > Orphan gnubversion > Orphan gpx-viewer > Orphan higlayout > Orphan intellij-idea > Orphan intuitively > comaintained by: pertusus > Orphan invulgotracker > Orphan itaka > Orphan itcl > Orphan itk > Orphan itools > Orphan iwak > Orphan iwidgets > Orphan jakarta-commons-httpclient > Orphan jps > Orphan kcirbshooter > Orphan kurdit-unikurd-web-fonts > Orphan libcompizconfig > Orphan libgnomeprint22 > Orphan libgnomeprintui22 > Orphan libmetalink > Orphan libmodelfile > Orphan libnoise > Orphan libspe2 > Orphan libsx > comaintained by: pertusus > Orphan libxdg-basedir > Orphan libyahoo2 > comaintained by: siddhesh > Orphan lifeograph > comaintained by: sundaram > Orphan log4c > Orphan lush > Orphan maradns > Orphan mathmap > Orphan maxr > comaintained by: cassmodiah > Orphan mediawiki-rss > comaintained by: ianweller > Orphan medusa > Orphan memchan > Orphan metalink > Orphan mingw32-OpenSceneGraph > Orphan mingw32-SDL_image > Orphan mingw32-SDL_mixer > Orphan mingw32-plib > Orphan mod_perlite > Orphan monsoon > Orphan mtkbabel > Orphan mulk > Orphan mysqlreport > comaintained by: wolfy > Orphan nanoxml > Orphan netbeans > Orphan nethack-vultures > Orphan netstiff > Orphan nsca > comaintained by: xavierb > Orphan olpc-netutils > Orphan openbios > Orphan papyrus > Orphan perl-Acme-Damn > comaintained by: ppisar psabata mmaslano > Orphan perl-AppConfig-Std > comaintained by: ppisar psabata mmaslano > Orphan perl-Archive-RPM > comaintained by: ppisar psabata mmaslano > Orphan perl-Array-RefElem > comaintained by: ppisar psabata mmaslano > Orphan perl-B-Hooks-OP-Check-StashChange > comaintained by: ppisar psabata mmaslano > Orphan perl-Best > comaintained by: ppisar psabata mmaslano > Orphan perl-CPAN-Mini > comaintained by: ppisar psabata mmaslano > Orphan perl-CPANPLUS-Shell-Default-Plugins-Changes > comaintained by: ppisar psabata mmaslano > Orphan perl-CPANPLUS-Shell-Default-Plugins-Diff > comaintained by: ppisar psabata mmaslano > Orphan perl-CPANPLUS-Shell-Default-Plugins-RT > comaintained by: ppisar psabata mmaslano > Orphan perl-Cache > comaintained by: ppisar psabata mmaslano > Orphan perl-Chatbot-Eliza > comaintained by: ppisar psabata mmaslano > Orphan perl-Check-ISA > comaintained by: ppisar psabata mmaslano > Orphan perl-Class-Can > Orphan perl-Class-DBI-Plugin-DeepAbstractSearch > comaintained by: ppisar psabata mmaslano > Orphan perl-Class-Data-Accessor > comaintained by: ppisar psabata mmaslano > Orphan perl-Class-Exporter > Orphan perl-Class-Factory > comaintained by: ppisar psabata mmaslano > Orphan perl-Class-Prototyped > comaintained by: ppisar psabata mmaslano > Orphan perl-Config-IniHash > comaintained by: ppisar psabata mmaslano > Orphan perl-Context-Preserve > comaintained by: ppisar psabata mmaslano > Orphan perl-Contextual-Return > comaintained by: ppisar psabata mmaslano > Orphan perl-Convert-NLS_DATE_FORMAT > comaintained by: ppisar psabata mmaslano > Orphan perl-DBD-Mock > comaintained by: ppisar psabata mmaslano > Orphan perl-DBD-Multi > comaintained by: ppisar psabata mmaslano > Orphan perl-DBI-Dumper > comaintained by:
Plan for tomorrow's FESCo meeting
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:00UTC (1:00pm EST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = None = New business = #topic #742 F17 Feature: KDE Plasma Workspaces 4.8 - https://fedoraproject.org/wiki/Features/KDE48 .fesco 742 #topic #743 F17 Feature: OpenNebula - https://fedoraproject.org/wiki/Features/OpenNebula .fesco 743 #topic #744 F17 Feature: SSSD Auto FS Integration - https://fedoraproject.org/wiki/Features/SSSDAutoFSSupport .fesco 744 #topic #745 F17 Feature: SSSD Sudo Integration - https://fedoraproject.org/wiki/Features/SSSDSudoIntegration .fesco 745 #topic #746 F17 Feature: Sugar 0.96 - https://fedoraproject.org/wiki/Features/Sugar_0.96 .fesco 746 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
I'm just entered the world of Fedora packagers and I see a few points that can be optimized in my opinion. 1. I saw a package that need to be upgraded. I opened a bug in bugzilla, after some time whit no response from the maintainer I asked in pkgdb permissions for that package: I'm still waiting, after two weeks, that the maintainer gives me such permissions. So why I can take an orphaned package with automatic procedure and I cannot apply as co-maintainer in the same manner? 2. In review requests I see some of them are requests for existent packages that should be renamed. Why bothering reviewers (that are not so much, I think, looking at the long list of reviews pending) with this extra-work only to rename an existing package? In my opinion these two points can be modified to have less bureaucracy and to make things working a bit faster. Il 14/01/2012 13:03, Michael Schwendt ha scritto: On Sat, 14 Jan 2012 09:12:06 +0100, KK (Kevin) wrote: Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. Not if we make it a project-wide policy to upgrade whenever there isn't a strong reason not to (as I've been proposing all this time) and encourage provenpackagers (or even any packagers) to just upgrade the packages (unless the maintainer explicitly left a note in the specfile why it shouldn't be upgraded and the reason given actually makes sense), instead of discouraging it as we do now. Wow, that's a bit much for wrapping it into one sentence only! There is _a package_ with _a maintainer_. Is it an arbitrary maintainer or one assigned to the package's team of maintainers, who also handle incoming bug reports? Anyway, that maintainer has looked into performing an upgrade, but has found a reason not to upgrade and leaves a note in the specfile or a separate README in git. So far, so good. That reminds me of what I've been doing for Audacious during its troublesome v2 series. That is a basic idea, not a tested bullet-proof process, however. For example, what happens if an upgrade-mad maintainer thinks the notes in the spec file no longer apply? What happens if this is not (or cannot be) discussed for various reasons with the person that added the note? A single pet-peeve bug fixed in the latest upstream release could lead to a maintainer pushing forward an upgrade without taking care of the package normally. Conflict resolvement would be necessary. I'm not convinced that would be easy. Else there would not be regular threads-of-doom on the mailing-lists either. The system would lead quickly to some people accusing others of abusing their package write-access. What happens if there is no note and someone does an upgrade, which turns out to be broken in several ways? Who decides whether to downgrade (Epoch-fun!) or whether to try to fix the problems? And if the problems affect external packages and require porting to a new API (or require heavier development even), are there volunteer maintainers to do that for packages that are not being assigned to? Why is it so difficult to say "I'm interested in many more packages, I want to contribute to those packages, and I do that either upstream or only in the Fedora packages, and in order to do so, I request pkgdb access to the packages in Fedora properly"? Then you could find out whether team-work is possible with the existing maintainers. Why must it be the opposite? Arbitrary access to packages, possibly sporadic or random upgrades (as time permits), with no one taking care of the packages normally. With that, the policy would be: You think the software is old? You upgrade it. Problem solved. =:-o That's all? Software is old, replace it? You must be kidding. Especially Fedora's users expect the distribution makers to offer the full show: Everything from choosing a working combination/collection of software to testing/QA, integration-work, and maintaining all this during the life-time of the distribution. If software is new but broken, users turn that against you. Even if this is Fedora and not RHEL. real PITA to resurrect them. (If I want to pick up a package I missed in one of the previous "retiring" announcements, I have to get it through all the review process again just as if it had never been in Fedora!) This is almost ridiculous. The reason you've missed it could very well be that the package doesn't interest you at all and that you've not had a look at it (or its http://bugz.fedoraproject.org/NAME page) before. You haven't taken care of it in the package collection either. And if you've discovered the software just recently, would you be its only user in Fedora? Nobody else? Perhaps just a few users who run with a personal repo or a 3rd party repo on the web? Impressive. And finally, I'm almost certain FESCo could be approached with a proposal to have provenpackagers not require a re-review of previously retired packages. The reason they have been retired is
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sun, 15 Jan 2012 20:37:16 +0100, MV (Mattia) wrote: > I'm just entered the world of Fedora packagers and I see a few points > that can be optimized in my opinion. > > 1. I saw a package that need to be upgraded. I opened a bug in bugzilla, > after some time whit no response from the maintainer I asked in pkgdb > permissions for that package: I'm still waiting, after two weeks, that > the maintainer gives me such permissions. That package is "skychart" according to the bugzilla searching I've done. The bugzilla ticket ( http://bugzilla.redhat.com/769454 ) raises a couple of questions. It could be that the assignee is confused so far (and the ticket has been opened on Dec 20th, btw). You wrote: | I'm not a packager, but I would like to became a co-maintainer. This could be confusing enough for the assignee to wait with approving your commit access request in pkgdb. Have you talked to him privately before, also about your pkgdb requests? Sometimes, pkgdb mails get filtered into special folders by users. An upgrade request in bugzilla with an immediate request to become a co-maintainer could be understood as some form of assault. I mean, not only would you (and the current co-maintainer) need to agree on the packaging anyway, you would also need to agree on how to team up in general (e.g. with regard to monitoring upstream commits and evaluating a new release). You've not commented on any changes in the new release. | I need a review of this package and a sponsorship, if possible. This is another confusing point. At least, I don't understand it yet either. The "skychart" packager cannot sponsor you if he's not a sponsor. He could apply forwarded spec changes, however. Submitting them as a unified diff (against current git, for example) could save some time. On the other hand, pkgdb lists two packages for your account, ... but as I said, this is confusing. > So why I can take an orphaned > package with automatic procedure and I cannot apply as co-maintainer in > the same manner? An orphaned package would be unmaintained, that is "first come first served" for whoever is fastest to take it again. For packages with existing maintainers, you are supposed to talk to them about becoming a co-maintainer. Sometimes it just needs a private mail (and for others, IRC is even faster) to point them at pkgdb requests. > 2. In review requests I see some of them are requests for existent > packages that should be renamed. Why bothering reviewers (that are not > so much, I think, looking at the long list of reviews pending) with this > extra-work only to rename an existing package? Well, this is some form of unneeded bureaucracy. The http://fedoraproject.org/wiki/Package_Renaming_Process page is brief. It mentions "proper Obsoletes and Provides", however, which might be a primary reason for expecting packagers to follow this process. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to send a package update
Hello, About three years ago, I created two very simple packages: mk-files and bmake. I followed the instructions at that time to get them into the distribution, and the packages were accepted. For a variety of reasons, I had not been paying attention to those packages since then, but other developers have taken care of mk-files alone. Now, I'm interested in working on some new packages. However, in an attempt to "refresh" my knowledge of the packaging procedures and tools, I thought that updating bmake to the latest version would be a simple exercise. In fact, downloading the .spec file, updating it to the new version and building it through Koji has been relatively straightforward. Unfortunately, I'm lost now. I have been digging through the wiki for hours, reading many of the documents... and pretty much everything focuses on how to create a new package, not how to update an existing one. For example: I cannot figure out how I am supposed to submit my changes to the spec file for approval (which I assume has to be done due to my lack of experience). Also, I cannot tell if three years ago I gained some privileges that I have now lost due to the conversion of the packages repository from cvs to git. For example, a "fedpkg clone" without the -a option fails due to a permission denied (reason: publickey), although I have made sure that my SSH key is up-to-date in the accounts system. Could anyone provide some pointers please? Thank you! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sat, 14 Jan 2012 18:28:15 +0100 Kevin Kofler wrote: > Michael Schwendt wrote: > > However, with the current features of pkgdb, each member of such a > > group would need to "subscribe to" the package in pkgdb. Not just > > for "commit" access, but also for someone to monitor bugzilla and > > the package-owner mail alias, which is convenient for team-work, > > too. > > That's exactly why we need proper support for group ownership in > pkgdb. In particular, a new developer joining a SIG should > AUTOMATICALLY get write access to all the packages (co)maintained by > that SIG. How does one determine what SIGS exist? How does one determine who is a member of a SIG? How does one determine what packages a SIG controls? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sun, 15 Jan 2012 18:39:48 +0100 Michael J Gruber wrote: ...snip... (Please trim you emails...) > Took bibexport. > > mathmap seems to be dead upstream as a Gimp plugin, unfortunately. > (It's supposed to be turned into a web service...) > > While it's a pitty to see it go away, pampering the "final" version in > Fedora appears to be futile. > > And yes, I feel quite uneasy about this mass removal, too. I mean, it > affects even packages with comaintainers when the owner disappeared > for whatever reasons. In this case the co-maintainers should have been seeing bounce emails for any commit against the package from the missing maintainer. They also should see that it's orphaned in the above list and should consider one of them taking over ownership. > Unless I'm using a package already, I'd have to check what it does, > what state it is in etc. before taking ownership - but it's gone by > that time already, requiring much more "paperwork" to take over. well, we still have a good deal of time before any of the packages on this list are retired. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sun, 15 Jan 2012 20:37:16 +0100 Mattia Verga wrote: > I'm just entered the world of Fedora packagers and I see a few points > that can be optimized in my opinion. Welcome by the way. ;) > 1. I saw a package that need to be upgraded. I opened a bug in > bugzilla, after some time whit no response from the maintainer I > asked in pkgdb permissions for that package: I'm still waiting, after > two weeks, that the maintainer gives me such permissions. So why I > can take an orphaned package with automatic procedure and I cannot > apply as co-maintainer in the same manner? We talked about, but never finished implementing a timeout on acl requests. The way this would work is that maintainer would have some time.. 3 weeks or something to reject a acl request. If they did not do so, pkgdb would automatically approve it at the end of the time. This would help in cases where the maintainer is overloaded or not paying attention. > 2. In review requests I see some of them are requests for existent > packages that should be renamed. Why bothering reviewers (that are > not so much, I think, looking at the long list of reviews pending) > with this extra-work only to rename an existing package? It's very easy to mess up however, so we determined that a review was needed. Many times people don't do the obsoletes and provides correctly for the old name. > In my opinion these two points can be modified to have less > bureaucracy and to make things working a bit faster. Thanks for the ideas! kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
On 01/16/2012 03:20 AM, Kevin Fenzi wrote: On Sat, 14 Jan 2012 18:28:15 +0100 Kevin Kofler wrote: Michael Schwendt wrote: However, with the current features of pkgdb, each member of such a group would need to "subscribe to" the package in pkgdb. Not just for "commit" access, but also for someone to monitor bugzilla and the package-owner mail alias, which is convenient for team-work, too. That's exactly why we need proper support for group ownership in pkgdb. In particular, a new developer joining a SIG should AUTOMATICALLY get write access to all the packages (co)maintained by that SIG. Exactly. How does one determine what SIGS exist? How does one determine who is a member of a SIG? How does one determine what packages a SIG controls? All these are the known deficiencies/missing features of Fedora's infrastructure (esp. the packagedb) - there simply is no concept of "group ownership". Likely, the simpliest apprach to implement "group ownership" would be handle this similar to "provenpackager", but with "limited/restricted privileges". Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to send a package update
Julio Merino wrote: > Also, I cannot tell if three years ago I gained some privileges that I > have now lost due to the conversion of the packages repository from cvs > to git. For example, a "fedpkg clone" without the -a option fails due > to a permission denied (reason: publickey), although I have made sure > that my SSH key is up-to-date in the accounts system. > > Could anyone provide some pointers please? http://fedoraproject.org/wiki/Package_update_HOWTO the permission denied thing may be due to: "Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30" http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to send a package update
On Sun, Jan 15, 2012 at 20:08:20 -0500, Julio Merino wrote: > > Also, I cannot tell if three years ago I gained some privileges that > I have now lost due to the conversion of the packages repository > from cvs to git. For example, a "fedpkg clone" without the -a > option fails due to a permission denied (reason: publickey), > although I have made sure that my SSH key is up-to-date in the > accounts system. > > Could anyone provide some pointers please? If you didn't change your FAS credentials and your ssh key your packager status may have been removed. bmake is now orphaned and mk-files is owned by someone else. Without knowing your FAS account it's hard to check if you are still a packager. There is another client side cert beside your ssh key that also expires. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
