On Thu, Nov 24, 2016 at 10:11 AM, jan matejek
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: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org