Mailinglist Archive: opensuse-buildservice (272 mails)

< Previous Next >
Re: [opensuse-buildservice] The disconnect
  • From: Robert Schweikert <rschweikert@xxxxxxxxxx>
  • Date: Wed, 03 Nov 2010 09:49:17 -0400
  • Message-id: <4CD1685D.4030808@xxxxxxxxxx>


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@xxxxxxxxxx
781-464-8147

Novell
Making IT Work As One
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >