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
On 11/02/2010 04:24 PM, Marcus Rueckert wrote:
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
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.
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
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
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?
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.
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" ("easier" ~ filing _2_ SRs) to get stuff into Contrib or
since it would just lead to loads of "dead" / unmaintained packages (which
lowers the promised quality) drop & forget style. And for anyone who seriously
considered the required policy and tends to comply with it filing the 2nd SR
should be pretty trivial.
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org