On 11/03/2010 10:15 AM, Greg Freemyer wrote:
On Tue, Nov 2, 2010 at 4:17 PM, Robert Schweikert
wrote: Hi,
<snip>
Based on a mail on the packaging list I guess what I need to do to get things into the distribution is to have another sr for the packages to the openSUSE:Factory project. But, that I cannot do as I am not a maintainer of devel:languages:perl. Now, I'd have to get added as a maintainer in that project and then do an sr for perl-critic and dependencies. Then rinse and repeat for any packages I might submit to other top level projects.
Was the devel maintainer issue ever addressed in this thread?
Is it real or a red-herring?
Well, I have mixed results on that, first a failed attempt: -> osc sr devel:languages:python python-boto openSUSE:Factory Warning: failed to fetch meta data for 'openSUSE:Factory' package 'python-boto' (new package?) Server returned an error: HTTP Error 403: Forbidden No permission to create request for package 'python-boto' in project 'devel:languages:python', only maintainers can create requests. And then a successful attempt: -> osc sr devel:languages:perl perl-B-Keywords openSUSE:Factory Warning: failed to fetch meta data for 'openSUSE:Factory' package 'perl-B-Keywords' (new package?) created request id 52081 Note that I am not on the maintainers list for devel:languages:python or devel:languages:perl. However, I am on the maintainers list for the perl-B-Keywords package as I originally created this package and submitted it to devel:languages:perl. Thus, apparently we already do keep track of the "original" package creator somewhere, and I have the permission to request the package to be included in Factory. Thus, for a package I originally created it does appear to just break down to having two SRs. Still don't like it, but this cuts out all the stuff in the middle I am most concerned about. However, for packages one is not the original creator, but that are needed for dependency reasons there is a lot of work and poking around to be done. I have to look at the list of maintainers for the given project, then pick one lucky winner to deal with my issue and "beg" for the package to be SRed to Factory. Maybe this is where we need some automation? osc package-needed SOURCE_PROJECT PKG_NAME TARGET_PROJECT This command then finds one of the SOURCE_PROJECT maintainers, or a "I can fiddle with all the bits super user", or the original packager and provides information to that user from the requester on why the package is desired/needed in the TARGET_PROJECT. Thus in my example it would be: osc package-needed devel:languages:python python-boto openSUSE:Factory The requester would provide "justification" why he/she wants the package in the TARGET_PROJECT. If the original packager (or the randomly selected project maintainer) is not willing to maintain this package in the TARGET_PROJECT (raised as a concern in other e-mails about the automatic mechanism) the requester must have some means to take over the maintainer-ship of said package and thus get the package into the TARGET_PROJECT. While this still does not fall onto the extremely simple scale, such a command would make it much easier when compared to the current effort required. It is important after all that as a packager I respect other packagers desire not to have their packages in :Factory or :Contrib. However, if I am willing to take over the work of maintaining the packages, then the other packager needs to be willing to have the package pushed into :Factory or :Contrib. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert@novell.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org