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