Removing SLE 11 from devel:languages:python

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing SLE 11 from devel:languages:python

todd rme
I propose we remove the SLE 11 repository from devel:languages:python.
Most spec files require special workaround to build at all with this
target and it requires backporting a bunch of system-critical packages
that no other release requires, and even then many packages fail to
build.  And the scheduler punishes the repo for having failures.

The amount of effort needed to keep basic, key dependencies working is
growing constantly.  And these workarounds means that it will be
essentially infeasible to support it in the upcoming single spec file
system, which means most key packages will no longer be able to
support it anyway.

Anyone who really needs specific packages can always link to them and
build them in their home repo.

So I think we should go ahead and remove it.  Once it is removed,
packages that are updated can have the workarounds deleted
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Alberto Planas Dominguez
On Tue, 2016-11-22 at 10:52 -0500, Todd Rme wrote:
> I propose we remove the SLE 11 repository from
> devel:languages:python.

For what is worth, I agree.

--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Richard Brown
On 22 November 2016 at 16:59, Alberto Planas Dominguez <[hidden email]> wrote:
> On Tue, 2016-11-22 at 10:52 -0500, Todd Rme wrote:
>> I propose we remove the SLE 11 repository from
>> devel:languages:python.
>
> For what is worth, I agree.

For what it's worth, I agree also
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Robert Schweikert-6
In reply to this post by todd rme
On 11/22/2016 10:52 AM, Todd Rme wrote:

> I propose we remove the SLE 11 repository from devel:languages:python.
> Most spec files require special workaround to build at all with this
> target and it requires backporting a bunch of system-critical packages
> that no other release requires, and even then many packages fail to
> build.  And the scheduler punishes the repo for having failures.
>
> The amount of effort needed to keep basic, key dependencies working is
> growing constantly.  And these workarounds means that it will be
> essentially infeasible to support it in the upcoming single spec file
> system, which means most key packages will no longer be able to
> support it anyway.
>
> Anyone who really needs specific packages can always link to them and
> build them in their home repo.
>
> So I think we should go ahead and remove it.  Once it is removed,
> packages that are updated can have the workarounds deleted
>
I agree that it is a pain. I also agree that going forward things will
become ever more painful.

However the approach of "link to the project" where needed is not really
a good solution either. If we drop SLE_11 builds and then remove the
special SLE_11 handling in the spec file the person that has linked to
the package MUST carry a local diff in addition to the link to re-add
the SLE_11 special handling. Chances are that the local diff will be
broken every time the package in d:l:p gets updated. Consequently people
will probably make copies meaning a possibly significant increase of
builds in OBS.

So if we turn of SLE_11 in d:l:p we should agree to keep the SLE_11
special code in the spec files until EOL of SLE_11, sometime in 2019,
rather than penalizing those that need/want to help users that still use
SLE_11, for whatever reason.

As proposed I oppose the change.

Later,
Robert

--
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
Public Cloud Architect                         LINUX
[hidden email]
IRC: robjo


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Christian
Am 22.11.2016 um 17:29 schrieb Robert Schweikert:
>
> As proposed I oppose the change.

I oppose the change, too.


--

Christian
----------------------------------------------------
   - Please do not 'CC' me on list mails.
          Just reply to the list :)
----------------------------------------------------
  http://www.sc24.de - Sportbekleidung
----------------------------------------------------
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Bruno Friedmann-2
In reply to this post by todd rme
On mardi, 22 novembre 2016 10.52:37 h CET Todd Rme wrote:

> I propose we remove the SLE 11 repository from devel:languages:python.
> Most spec files require special workaround to build at all with this
> target and it requires backporting a bunch of system-critical packages
> that no other release requires, and even then many packages fail to
> build.  And the scheduler punishes the repo for having failures.
>
> The amount of effort needed to keep basic, key dependencies working is
> growing constantly.  And these workarounds means that it will be
> essentially infeasible to support it in the upcoming single spec file
> system, which means most key packages will no longer be able to
> support it anyway.
>
> Anyone who really needs specific packages can always link to them and
> build them in their home repo.
>
> So I think we should go ahead and remove it.  Once it is removed,
> packages that are updated can have the workarounds deleted

I'm 50% in favor of (ease also the transition to a unified d:l:p) as dlp3
didn't have SLE11 as target.

But in the same time, supporting users with SLE11 is also important.

Isn't it possible de copy/link dlp for SLE11 in the actual version.
Make it build once, and then let a specific repository.
(I don't know if those users need a absolute fresh package).

Didn't we have a backport repository for SLE11 where we can add those packages
?

Then all needed changes can occurs in d:l:p, and people wanting to refresh
SLE11 backports would be able to do it on their own repository (I guess with a
lot less rebuilds)

thoughts?

--

Bruno Friedmann
 Ioda-Net Sàrl www.ioda-net.ch
 Bareos Partner, openSUSE Member, fsfe fellowship
 GPG KEY : D5C9B751C4653227
 irc: tigerfoot


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Alberto Planas Dominguez
In reply to this post by Christian
On Tue, 2016-11-22 at 17:43 +0100, Christian wrote:
> Am 22.11.2016 um 17:29 schrieb Robert Schweikert:
> >
> > As proposed I oppose the change.
>
> I oppose the change, too.

Can we extend a bit more? As I see in monitoring[1] there are several
packages that do not build in sle11 anymore. According to the page
there are

 * succeeded: 1386
 * failed: 154
 * unresolvable: 175
 * broken: 3
 * disabled: 239

So a significant portion of the packages are not working.

I really doubt that SLE11 users are using d:l:p anymore (but I can be
wrong).


[1] https://build.opensuse.org/project/monitor/devel:languages:python
--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Simon Lees-3


On 11/23/2016 03:47 AM, Alberto Planas Dominguez wrote:

> On Tue, 2016-11-22 at 17:43 +0100, Christian wrote:
>> Am 22.11.2016 um 17:29 schrieb Robert Schweikert:
>>>
>>> As proposed I oppose the change.
>>
>> I oppose the change, too.
>
> Can we extend a bit more? As I see in monitoring[1] there are several
> packages that do not build in sle11 anymore. According to the page
> there are
>
>  * succeeded: 1386
>  * failed: 154
>  * unresolvable: 175
>  * broken: 3
>  * disabled: 239
>
> So a significant portion of the packages are not working.
>
> I really doubt that SLE11 users are using d:l:p anymore (but I can be
> wrong).
>
>
> [1] https://build.opensuse.org/project/monitor/devel:languages:python
>
Maybe we can take a half step instead.

Keep the repo's enabled but advise maintainers that they are not obliged
to keep SLE-11 building if it requires additional effort on there
behalf, in that way the people that do care about having package X
available on SLE-11 and that are willing to make it work can do so.
Packages that are unresolvable, known to have bugs that stop them
working in a significant manner or will have security issues under
SLE-11 should be disabled for build on SLE-11 with the reason documented
somewhere so people know what it takes to get re enabled. We could
extend this further to packages not building (when someone branches the
package its easy enough to see why it was disabled). These packages
could then be reenabled for build if someone steps up to fix them.

If we get to a point in the future where say 75% (or any other agreed
number) of packages are disabled or failing to build we could then
question again whether its worth dropping the repo as a whole.

Cheers

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                            Adeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Ralf Lang-3
On 23.11.2016 01:51, Simon Lees wrote:

>
>
> On 11/23/2016 03:47 AM, Alberto Planas Dominguez wrote:
>> On Tue, 2016-11-22 at 17:43 +0100, Christian wrote:
>>> Am 22.11.2016 um 17:29 schrieb Robert Schweikert:
>>>>
>>>> As proposed I oppose the change.
>>>
>>> I oppose the change, too.
>>
>> Can we extend a bit more? As I see in monitoring[1] there are several
>> packages that do not build in sle11 anymore. According to the page
>> there are
>>
>>  * succeeded: 1386
>>  * failed: 154
>>  * unresolvable: 175
>>  * broken: 3
>>  * disabled: 239
>>
>> So a significant portion of the packages are not working.
>>
>> I really doubt that SLE11 users are using d:l:p anymore (but I can be
>> wrong).
>>
>>
>> [1] https://build.opensuse.org/project/monitor/devel:languages:python
>>
>
> Maybe we can take a half step instead.
>
> Keep the repo's enabled but advise maintainers that they are not obliged
> to keep SLE-11 building if it requires additional effort on there
> behalf, in that way the people that do care about having package X
> available on SLE-11 and that are willing to make it work can do so.
> Packages that are unresolvable, known to have bugs that stop them
> working in a significant manner or will have security issues under
> SLE-11 should be disabled for build on SLE-11 with the reason documented
> somewhere so people know what it takes to get re enabled.

Yes, this should also keep copies of the last successful build in the
repo - which is exactly what best serves SLES11 users. SP4 is still in
wide usage and support.


--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: [hidden email]
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Jason Craig-3
In reply to this post by Simon Lees-3
On 11/22/2016 05:51 PM, Simon Lees wrote:

> Maybe we can take a half step instead.
>
> Keep the repo's enabled but advise maintainers that they are not obliged
> to keep SLE-11 building if it requires additional effort on there
> behalf, in that way the people that do care about having package X
> available on SLE-11 and that are willing to make it work can do so.
> Packages that are unresolvable, known to have bugs that stop them
> working in a significant manner or will have security issues under
> SLE-11 should be disabled for build on SLE-11 with the reason documented
> somewhere so people know what it takes to get re enabled. We could
> extend this further to packages not building (when someone branches the
> package its easy enough to see why it was disabled). These packages
> could then be reenabled for build if someone steps up to fix them.
>
> If we get to a point in the future where say 75% (or any other agreed
> number) of packages are disabled or failing to build we could then
> question again whether its worth dropping the repo as a whole.
>
> Cheers

This sounds extremely reasonable and better to me than actively removing
all SLE11 compatibility workarounds, at least at the present time.

--
Jason Craig
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

jan matejek-4
In reply to this post by Simon Lees-3
On 23.11.2016 01:51, Simon Lees wrote:
> Maybe we can take a half step instead.

how about a three-quarters-step?

Keep the repo and disable building by default. IIUC this should also
keep built packages intact, and allow people who use SLE11 to enable
support as required.

This would also show how many packages the SLE11 people actually care about.

regards
m.

>
> Keep the repo's enabled but advise maintainers that they are not obliged
> to keep SLE-11 building if it requires additional effort on there
> behalf, in that way the people that do care about having package X
> available on SLE-11 and that are willing to make it work can do so.
> Packages that are unresolvable, known to have bugs that stop them
> working in a significant manner or will have security issues under
> SLE-11 should be disabled for build on SLE-11 with the reason documented
> somewhere so people know what it takes to get re enabled. We could
> extend this further to packages not building (when someone branches the
> package its easy enough to see why it was disabled). These packages
> could then be reenabled for build if someone steps up to fix them.
>
> If we get to a point in the future where say 75% (or any other agreed
> number) of packages are disabled or failing to build we could then
> question again whether its worth dropping the repo as a whole.
>
> Cheers
>


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

todd rme
In reply to this post by Simon Lees-3
On Tue, Nov 22, 2016 at 7:51 PM, Simon Lees <[hidden email]> wrote:

>
>
> On 11/23/2016 03:47 AM, Alberto Planas Dominguez wrote:
>> On Tue, 2016-11-22 at 17:43 +0100, Christian wrote:
>>> Am 22.11.2016 um 17:29 schrieb Robert Schweikert:
>>>>
>>>> As proposed I oppose the change.
>>>
>>> I oppose the change, too.
>>
>> Can we extend a bit more? As I see in monitoring[1] there are several
>> packages that do not build in sle11 anymore. According to the page
>> there are
>>
>>  * succeeded: 1386
>>  * failed: 154
>>  * unresolvable: 175
>>  * broken: 3
>>  * disabled: 239
>>
>> So a significant portion of the packages are not working.
>>
>> I really doubt that SLE11 users are using d:l:p anymore (but I can be
>> wrong).
>>
>>
>> [1] https://build.opensuse.org/project/monitor/devel:languages:python
>>
>
> Maybe we can take a half step instead.
>
> Keep the repo's enabled but advise maintainers that they are not obliged
> to keep SLE-11 building if it requires additional effort on there
> behalf, in that way the people that do care about having package X
> available on SLE-11 and that are willing to make it work can do so.
> Packages that are unresolvable, known to have bugs that stop them
> working in a significant manner or will have security issues under
> SLE-11 should be disabled for build on SLE-11 with the reason documented
> somewhere so people know what it takes to get re enabled. We could
> extend this further to packages not building (when someone branches the
> package its easy enough to see why it was disabled). These packages
> could then be reenabled for build if someone steps up to fix them.

From what I recall this is already the policy.  The problem is that
"the people that do care" aren't stepping up to do the work, but
failing packages keep getting re-enabled and left failing.

SLE-11 is the only supported platform that doesn't support Python 3
and, more importantly, the only supported platform that doesn't
support noarch Python packages.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

todd rme
In reply to this post by jan matejek-4
On Thu, Nov 24, 2016 at 10:11 AM, jan matejek <[hidden email]> wrote:

> On 23.11.2016 01:51, Simon Lees wrote:
>> Maybe we can take a half step instead.
>>
>> Keep the repo's enabled but advise maintainers that they are not obliged
>> to keep SLE-11 building if it requires additional effort on there
>> behalf, in that way the people that do care about having package X
>> available on SLE-11 and that are willing to make it work can do so.
>> Packages that are unresolvable, known to have bugs that stop them
>> working in a significant manner or will have security issues under
>> SLE-11 should be disabled for build on SLE-11 with the reason documented
>> somewhere so people know what it takes to get re enabled. We could
>> extend this further to packages not building (when someone branches the
>> package its easy enough to see why it was disabled). These packages
>> could then be reenabled for build if someone steps up to fix them.
>>
>> If we get to a point in the future where say 75% (or any other agreed
>> number) of packages are disabled or failing to build we could then
>> question again whether its worth dropping the repo as a whole.
>>
>> Cheers
>>
>
> how about a three-quarters-step?
>
> Keep the repo and disable building by default. IIUC this should also
> keep built packages intact, and allow people who use SLE11 to enable
> support as required.
>
> This would also show how many packages the SLE11 people actually care about.
>
> regards
> m.

This sounds more reasonable.  But the fact that more than 1/3 of the
packages are already either failing, unresolvable, or disabled
suggests to me that people don't care that much about SLE-11.  And
keep in mind the number of failing packages is going to go up once the
packages that currently are only present in devel:languages:python3
are merged into devel:languages:python.

The question I guess is how easy it will be to handle the lack of
python 3 and noarch support in the single spec file system.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing SLE 11 from devel:languages:python

Simon Lees-3


On 11/29/2016 06:06 AM, Todd Rme wrote:

> On Thu, Nov 24, 2016 at 10:11 AM, jan matejek <[hidden email]> wrote:
>> On 23.11.2016 01:51, Simon Lees wrote:
>>> Maybe we can take a half step instead.
>>>
>>> Keep the repo's enabled but advise maintainers that they are not obliged
>>> to keep SLE-11 building if it requires additional effort on there
>>> behalf, in that way the people that do care about having package X
>>> available on SLE-11 and that are willing to make it work can do so.
>>> Packages that are unresolvable, known to have bugs that stop them
>>> working in a significant manner or will have security issues under
>>> SLE-11 should be disabled for build on SLE-11 with the reason documented
>>> somewhere so people know what it takes to get re enabled. We could
>>> extend this further to packages not building (when someone branches the
>>> package its easy enough to see why it was disabled). These packages
>>> could then be reenabled for build if someone steps up to fix them.
>>>
>>> If we get to a point in the future where say 75% (or any other agreed
>>> number) of packages are disabled or failing to build we could then
>>> question again whether its worth dropping the repo as a whole.
>>>
>>> Cheers
>>>
>>
>> how about a three-quarters-step?
>>
>> Keep the repo and disable building by default. IIUC this should also
>> keep built packages intact, and allow people who use SLE11 to enable
>> support as required.
>>
>> This would also show how many packages the SLE11 people actually care about.
>>
>> regards
>> m.
>
> This sounds more reasonable.  But the fact that more than 1/3 of the
> packages are already either failing, unresolvable, or disabled
> suggests to me that people don't care that much about SLE-11.  And
> keep in mind the number of failing packages is going to go up once the
> packages that currently are only present in devel:languages:python3
> are merged into devel:languages:python.
>
Yeah I guess it comes down to what those packages are rather then just
looking at the numbers, each person (presuming they exist) may only have
a few packages that they care about and they are probably keeping these
working but don't care as much about the rest of the packages in the repo.

> The question I guess is how easy it will be to handle the lack of
> python 3 and noarch support in the single spec file system.
>

Yeah I carefully worded what I wrote above to try and say if there is
big issues there then it would be good grounds for dropping everything
if know one can fix it but I guess we will wait and see. If we did have
to drop it we could always create a SLE-11 repo and move everything that
builds there before applying the change.

--

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                            Adeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B


signature.asc (499 bytes) Download Attachment