On 11/02/2010 04:24 PM, Marcus Rueckert wrote:

hi,

simple answer: you need to define a maintenance policy for contrib.

the current policy is the same as the distro. that means no version updates just backports after contrib got frozen for a distro release.

if you leave it open for version update you have no real stable base for people to work with.

I did not mean to imply that the policy for contrib should change. It should be a stable/frozen repo as it is today. For example, a developer at company X that writes perl code for their application shouldn't have to add devel:languages:perl to get perl-critic as the developer now uses a moving repo and one zypper up could potentially cause major issues. (Just to stick to the example that I already used).

if you keep the current policy many people wouldnt have the resources or time to maintain all the packages with that policy. thats why many people dont want their packages in the distro or contrib. (me included)

I am trying to find a way to make it easier for people to get their packages into the "stable/frozen" world. I think this will encourage contributions. Maybe we need another per package flag, "OK_FOR_CONTRIB" lets the packager indicate this package can be auto collected. Robert

you also needs a team for QA/maintenance for that project.

that said ... as nice as it sounds on paper, it is a lot of work.

darix

-- 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

On Nov 02, 10 16:46:30 -0400, Greg Freemyer wrote:

I agree, for a lot of leaf packages there does not seem to be a reason to not do a single SR that hits a devel repo and the main repo.

If I could tell my submit-request, that I want the package go back where it originally came from, I'd most of the time do so. Currently, when I branch from Factory, I usually get rerouted to a devel-project. So the submit (being perceived as the end of my transaction) ends up at the devel project, not at Factory, where the package originally was taken from. Flagging a submitrequest as 'please forward to Factory' could tell the project maintainers, what the actual roundtrip should be.

But, from what I can tell, contrib is already an artifact from days gone by!

It falls to disuse, doesn't it? Too many levels of manual indirection... Maybe an automatic forward to contrib helps, to test how the package would behave in a Factory context without actually breaking Factory?

So the flag should be "OK_FOR_FACTORY".

Yeay, many possibilities :-) cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 11/02/2010 07:44 PM, Stephan Kleine wrote:

On Tuesday November 2 2010 21:37:56 Robert Schweikert wrote:

...

On 11/02/2010 04:24 PM, Marcus Rueckert wrote:

...

hi,

simple answer: you need to define a maintenance policy for contrib.

the current policy is the same as the distro. that means no version updates just backports after contrib got frozen for a distro release.

if you leave it open for version update you have no real stable base for people to work with.

I did not mean to imply that the policy for contrib should change. It should be a stable/frozen repo as it is today.

For example, a developer at company X that writes perl code for their application shouldn't have to add devel:languages:perl to get perl-critic as the developer now uses a moving repo and one zypper up could potentially cause major issues. (Just to stick to the example that I already used).

...

if you keep the current policy many people wouldnt have the resources or time to maintain all the packages with that policy. thats why many people dont want their packages in the distro or contrib. (me included)

I am trying to find a way to make it easier for people to get their packages into the "stable/frozen" world. I think this will encourage contributions. Maybe we need another per package flag, "OK_FOR_CONTRIB" lets the packager indicate this package can be auto collected.

That leaves out the main issue. The stuff in Contrib is version frozen and therefore any security fixes need to be backported and the packages in there need to be maintained.

Agreed.

Who will do that? If the original submitter is willing to do that he prolly will already submit it to Contrib

This is where I disagree. I am saying that the process of getting a package into Contrib or Factory is not as straight forward as it should be. There are too many steps. To get something into contrib or factory one has to - create the package(s) in home: - submit to a devel project - get added to the list of maintainers for the devel project - submit the package(s) again to factory or contrib Submitting the same stuff multiple times is not intuitive. I would guess most people will stop after the first submit step even if they are willing to do the maintenance work. This just means that the package never sees "the light of day", meaning the package is not available to users that do not add devel repos to their system. When I contribute a patch to a project I only submit the patch once, if I only care that it gets into the development tree which eventually gets released. All I have to do is the development work, create the patch, and submit it to a mailing list, attach to bug report, or send it to someone with commit access. One patch one commit, simple. This is the way it should be with packages. If I create a package and am willing to maintain it I should be able to get the package into :Factory or :Contrib without having to do multiple submit requests for the same package (plus get added to some "magic" list of users of a given devel project)

so I don't see how that will change besides collecting more unmaintained packages in Contrib which isn't really what we should want.

I am not advocating to have more packages for the sake of having more packages. Packages in :Factory and :Contrib should be of high quality and be maintained. No question about it. 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

On 11/02/2010 10:09 PM, Stephan Kleine wrote:

On Wednesday November 3 2010 01:17:58 Robert Schweikert wrote:

...

On 11/02/2010 07:44 PM, Stephan Kleine wrote:

...

On Tuesday November 2 2010 21:37:56 Robert Schweikert wrote:

...

On 11/02/2010 04:24 PM, Marcus Rueckert wrote:

...

hi,

simple answer: you need to define a maintenance policy for contrib.

the current policy is the same as the distro. that means no version updates just backports after contrib got frozen for a distro release.

if you leave it open for version update you have no real stable base for people to work with.

I did not mean to imply that the policy for contrib should change. It should be a stable/frozen repo as it is today.

For example, a developer at company X that writes perl code for their application shouldn't have to add devel:languages:perl to get perl-critic as the developer now uses a moving repo and one zypper up could potentially cause major issues. (Just to stick to the example that I already used).

...

if you keep the current policy many people wouldnt have the resources or time to maintain all the packages with that policy. thats why many people dont want their packages in the distro or contrib. (me included)

I am trying to find a way to make it easier for people to get their packages into the "stable/frozen" world. I think this will encourage contributions. Maybe we need another per package flag, "OK_FOR_CONTRIB" lets the packager indicate this package can be auto collected.

That leaves out the main issue. The stuff in Contrib is version frozen and therefore any security fixes need to be backported and the packages in there need to be maintained.

Agreed.

...

Who will do that? If the original submitter is willing to do that he prolly will already submit it to Contrib

This is where I disagree. I am saying that the process of getting a package into Contrib or Factory is not as straight forward as it should be. There are too many steps. To get something into contrib or factory one has to

- create the package(s) in home: - submit to a devel project - get added to the list of maintainers for the devel project - submit the package(s) again to factory or contrib

Submitting the same stuff multiple times is not intuitive. I would guess most people will stop after the first submit step even if they are willing to do the maintenance work. This just means that the package never sees "the light of day", meaning the package is not available to users that do not add devel repos to their system.

Well, IMHO, the default assumption that the one who submits something to some devel project also wants to comply with the version restrictions in Contrib or Factory is wrong. E.g. I have several packages I needs as deps which I update when I see it fit and file SRs against their devel projects but I absolutely do not want to maintain them in any way as in being responsible for them in some way while having to do more than upstream does (e.g. backporting security fixes).

Well, then maybe the policy needs to be looked at, as Lars pointed out. Following a "simple maintenance model" of bumping the version to get upstream bug fixes would be a lot less work and might be a sufficient relaxation to get more people to contribute packages.

...

When I contribute a patch to a project I only submit the patch once, if I only care that it gets into the development tree which eventually gets released. All I have to do is the development work, create the patch, and submit it to a mailing list, attach to bug report, or send it to someone with commit access. One patch one commit, simple. This is the way it should be with packages. If I create a package and am willing to maintain it I should be able to get the package into :Factory or

:Contrib without having to do multiple submit requests for the same

package (plus get added to some "magic" list of users of a given devel project)

...

so I don't see how that will change besides collecting more unmaintained packages in Contrib which isn't really what we should want.

I am not advocating to have more packages for the sake of having more packages. Packages in :Factory and :Contrib should be of high quality and be maintained. No question about it.

I'm not sure if I am getting you right, do you mean

1. Make it a default for all?

Not necessarily, but a flag (OK_FOR_FACTORY as suggested in another e-mail) might be sufficient to indicate that a packager who is submitting a package to a devel project would like to see the package pushed into factory. The flag could be interpreted such that these packages get automatically collected and pushed to :Factory, or that a maintainer of the given devel project is on the hook to do this manually.

Then the above holds. My main point simply is that anyone who is comfortable to comply with the policy for Contrib or Factory will also have no problem filling one more SR to get his stuff in there.

It is more than just a second SR. One also has to be a maintainer of the given devel project from which the package is supposed to be pushed into :Factory. Thus, this implies that the original packager now either needs to become a maintainer of the given devel project (meaning one has to figure that out) or pick a maintainer of the devel project and ask the maintainer to submit an SR. There are just too many touchpoints.

2. Just make it easier to import packages for people who certainly will comply with the policy? E.g. you are paid by Novell to maintain package X so you are just interested in porting package X from some internal packages to the public OBS? Then just add some option to "osc sr".

I guess my point simply is that I'm strongly against anything that makes it "easier"

Well, in that case we really have no business in looking over the fence with envy and say, look distro X has a ton more packages and a lot more contributors. And then ask, how do we get there. We do not get there by making things difficult, that much I know.

("easier" ~ filing _2_ SRs)

There is more involved than just filing 2 SRs ;)

to get stuff into Contrib or Factory since it would just lead to loads of "dead" / unmaintained packages (which lowers the promised quality) drop & forget style.

Not necessarily. We could track the origination of packages, i.e. who first created the package and then poke those people automatically to update the package once a release cycle. devel project maintainers continue to be the gate keepers and do reviews of spec files etc. when a new package gets submitted to the devel project. But the original packager (unless the package is handed to someone else) continues to bear the responsibility of keeping the package up to date. The "forget" part is solved by automatic e-mail messages. If the maintainer commits a new version the e-mails stop until the next release cycle of oS begins and a packager can stop the notification e-mail by submitting a web form or via osc command that a given package has no new version available for the given oS release. I think we have plenty of opportunity here to avoid the "drop and forget" style of contribution. 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

* Robert Schweikert [Nov 03. 2010 01:18]:

This is where I disagree. I am saying that the process of getting a package into Contrib or Factory is not as straight forward as it should be. There are too many steps.

Fully agreed. There are actually two issues here to be solved 1. Giving users knowledge about and access to packages. This one got lots of attention during the openSUSE conference and a solution is currently being discussed on opensuse-softwaremgmt@opensuse.org The current proposal revolves around 'karma/trust' to find good packages and good maintainers. Let the community vote about the quality of packages, the ability of the maintainer to fix bugs, ease of installation, completeness of the documentation, you name it. 2. Making a package belong to the 'choosen ones' This is indeed tightly coupled to point 1 above because good karma is essential here. However, I wonder if the current model of 'pushing to Factory' can be extended. One extension could be voting (i.e. "Hey Coolo, Robert has this cool package in his home project, add it to Factory !"). Another would be adding 'pull requests' to the workflow. Instead of the package maintainer, the 'distribution maintainer' should choose which packages (resp. projects) he wants to have in his distribution. The package maintainer gets notified of pull requests and, if he accepts, all changes to his package get pulled into the distribution. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wednesday 03 November 2010 09:28:25 Stephan Kulow wrote:

Am Mittwoch 03 November 2010 schrieb Stephan Kleine:

...

That leaves out the main issue. The stuff in Contrib is version frozen and therefore any security fixes need to be backported and the packages in there need to be maintained.

While this is surely desireable, I don't think it should block anything that is highly security irrlevant from going straight into factory.

Sure, I don't want a 4th unmaintained SMTP daemon in the distribution, but keeping perl packages out of factory for that reason is stupid.

wow, does that mean that some packages from devel:languages:ruby:ext or devel:languages:python may have a chance too? -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com

On 11/03/2010 04:28 AM, Stephan Kulow wrote:

Am Mittwoch 03 November 2010 schrieb Stephan Kleine:

...

That leaves out the main issue. The stuff in Contrib is version frozen and therefore any security fixes need to be backported and the packages in there need to be maintained. While this is surely desireable, I don't think it should block anything that is highly security irrlevant from going straight into factory.

Sure, I don't want a 4th unmaintained SMTP daemon in the distribution, but keeping perl packages out of factory for that reason is stupid.

Thus, maybe for certain devel projects such a Perl, Python, Ruby, etc. and automatic inclusion in :Factory of everything the successfully builds at branch time maybe an option? Then at least for these types of projects we would invite the "more casual packager" and we would drastically lower the barrier to entry. 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

On 11/03/2010 08:01 AM, Lars Müller wrote:

On Wed, Nov 03, 2010 at 12:44:04AM +0100, Stephan Kleine wrote: [ 8< ]

...

That leaves out the main issue. The stuff in Contrib is version frozen and therefore any security fixes need to be backported and the packages in there need to be maintained.

I believe - and with Samba we've proofen - this "version frozen" policy as inadequate.

All depends from the dependencies. For example a kernel and glibc version change more likely will break working setups.

While a version upgrade to Samba worked well for several openSUSE and SUSE Linux Enterprise products. As an official update and not only as we offer packages from the network:samba:STABLE and TESTING repositories of the openSUSE Build Service.

For some components of the system we need something like rolling updates. Or is any of you still happily and satisfied using the initial Firefox as offered for SUSE Linux Enterprise 10 or openSUSE 11.2?

Rolling updates for certain parts of the distribution are probably the best approach to the "stuck with very old version" problems. This would also make the "simple maintenance model" you outline below more feasible. However, this does not address the issue of how to get a package into the distro in the first place.

There is nothing like one simple policy. Reality is sucking complex. ;)

...

Who will do that? If the original submitter is willing to do that he prolly will already submit it to Contrib so I don't see how that will change besides collecting more unmaintained packages in Contrib which isn't really what we should want.

Take the exim example. As I'm using it I'm quite happy to help and complained as soon as it should get dropped.

I'm never going to work on a security update for exim. All I'm willing to do is to keep the exim package in openSUSE on a current level. If there is a security issue I would address it with the new version.

I think there are a lot more potential contributors in this boat. These contributors would be willing to keep one or more packages up to date, but when it comes to fixing code or back-porting then things probably become iffy. Thus having a more lenient policy w.r.t. version changes via updates would probably open the door for more contributors. As simply the maintenance load is reduced by not having to back-port anything and being able to address bugs with a version bump from upstream. Still we need to look at the initial hurdle of the double submit, and being a "blessed" maintainer of a devel project to get stuff into :Factory or :Contrib. Yes, trust and quality of work do come into play. However, there are loads of package opportunities (Perl, Python, Ruby....Applications and modules) where the upstream code has some kind of testing and what is really needed is a person willing to push the version for every oS release and in between if needed due to some kind of bug. I claim, and maybe I am wrong, that the current policies and procedures keep these types of packagers away and subsequently packages out of the distribution. 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

On Thu, Nov 04, 2010 at 10:49:40AM +0100, Ludwig Nussel wrote:

Lars Müller wrote:

...

I'm never going to work on a security update for exim. All I'm willing to do is to keep the exim package in openSUSE on a current level. If there is a security issue I would address it with the new version.

Which is perfectly ok for a package where upstream already is careful to not break stuff. That doesn't work in general though.

Yes, that is exactly what I tried to express with my mail. Being more verbose my statement sounds like: It depends on the upstream project, the package complexity, how the software is used in SUSE (less or more prominent), is it part of the default install, where in the dependeny chain is it located (at ground like glibc/ bash or up at the attic like Samba). These are all factors we have to keep in mind. And that's something primarily the particular project maintainers have to decide on. Who secondarily? Those in charge of the maintenance process. This requires communication and explanations. Some of us are part of the openSUSE project since a year. Others are using it since 15 years. I'm stressing this to illustrate the different point of views or motivations.

...

With exim this is possible. It's not the default MTA of SUSE and therefore the risk to break 80% of installed and working systems is much lower.

The question is whether users of exim are aware that they rely on a "second-tier" package. OTOH there is no guarantee that packages that are in the default install are treated with more care either.

We might need an additional attribute on package level our users might rely on and libzypp (zypper + YaST) is able to handle. This would allow users to only install packages which are covered by the prefered individual quality policy. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

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

On Wed, Nov 03, 2010 at 03:10:50PM -0400, Robert Schweikert wrote:

On 11/03/2010 02:52 PM, Robert Schweikert wrote:

...

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,

Or maybe not. The same trick did not work with vtun, a package I just submitted to :Virtualization yesterday and that got accepted. However, I do not have permission to SR it to Factory.

-> osc sr Virtualization vtun openSUSE:Factory Warning: failed to fetch meta data for 'openSUSE:Factory' package 'vtun' (new package?) Server returned an error: HTTP Error 403: Forbidden No permission to create request for package 'vtun' in project 'Virtualization', only maintainers can create requests.

???????

You can submit it if you are marked as maintainer in the package. You are marked as maintainer for perl-B-Keywords, but not for vtun. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Wed, Nov 03, 2010 at 03:27:42PM -0400, Robert Schweikert wrote:

On 11/03/2010 03:22 PM, Marcus Meissner wrote:

...

On Wed, Nov 03, 2010 at 03:10:50PM -0400, Robert Schweikert wrote:

...

On 11/03/2010 02:52 PM, Robert Schweikert wrote:

...

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,

Or maybe not. The same trick did not work with vtun, a package I just submitted to :Virtualization yesterday and that got accepted. However, I do not have permission to SR it to Factory.

-> osc sr Virtualization vtun openSUSE:Factory Warning: failed to fetch meta data for 'openSUSE:Factory' package 'vtun' (new package?) Server returned an error: HTTP Error 403: Forbidden No permission to create request for package 'vtun' in project 'Virtualization', only maintainers can create requests.

???????

You can submit it if you are marked as maintainer in the package.

You are marked as maintainer for perl-B-Keywords, but not for vtun.

Who is responsible for setting the magic marker?

Is this not something that should be set automatically when I create the package in my home: project? Shouldn't this be sticky, i.e. stay with the package until manually changed?

The development group decides it in the end. osc meta prj Virtualization for the list of their maintainers and bugowners. Perhaps they can just take you into their ranks ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Montag, 8. November 2010, 13:51:20 schrieb Robert Schweikert:

On 11/08/2010 07:23 AM, Adrian Schröter wrote:

...

Am Dienstag, 2. November 2010, 21:17:37 schrieb Robert Schweikert: ...

...

One of the gory details would be to skip packages in projects like "bleeding-edge" during the automatic collection. But I beleive there is already a flag for things like that already, if I recall a discussion on this list correctly.

I just want to point out the security impliciation in doing this.

If it is known, that it is done in this way, it is horrible easy to build a package which would get installed in any case, if you add such a repository.

And this package can do anything with your system. Getting root access on any system, sending your credit card number to server X and so on.

Doing this is so horrible dangerous that I would even think that the usual "we are not responsible" agreements in license texts would not help you in court anymore. Simply because this not only careless, but actually more an already prepared attack to all opensuse systems. #

I guess you are saying that our devel projects are not save. So maybe we shouldn't provide repositories for the devel projects? AFAK we do not have an extra disclaimer w.r.t. security or other things for devel projects. Thus your concern would apply today.

It does apply today also. You should be carefull which repo you add to your system. But if you simply create one big repo and copy blindly all stuff from a high number of projects your risk is way higher. Because even maintainers of some simple corner case applications (which you would never install yourself) have root access to your system. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org