Todd Rme píše v Po 21. 05. 2018 v 12:09 -0400:

On Mon, May 21, 2018 at 10:45 AM, Tomas Chvatal wrote:

...

Todd Rme píše v Po 21. 05. 2018 v 10:31 -0400:

...

There are still a large number of packages in openSUSE:Factory that are python2-only. Some have not been touched upstream in years. We probably should start thinking about what to do with them.

I think we should break python2-only packages into four categories:

* Those that have python3 support that just hasn't been integrated should be updated.

* Those that upstream has indicated has python3 support in the near-term roadmap should be kept as-is for now (or updated to the latest version).

* Those that are python2-only and have not seen upstream activity since 2016 should be dropped from openSUSE:Factory and dropped from devel:languages:python after a two-week warning period.

* All others, including backports packages, should be moved to a new subproject, devel:languages:python:legacy since they won't need many updates or rebuilds. This project should be built but not published.

I agree with pruning them from TW we will slowly reach that goal as Matej is doing review all those pending in signlespec-staging project. They will either be sloted for removal or updated properly.

Now for those pruned from Factory I wonder what would be best course of action. Pf course having legacy project is nice, but maybe it will be quite large amount of work for almost no gain as the python2 should be really quickly phased out in favor of python3.

What about packages that are maintained but remain python2-only?

And would it really be a large amount of work if we make it clear that no further work on legacy packages will be done by dlp maintainers?

Well there should be no conflict, atm we are pruning only py2 leaf stuff that has no consumers and no updates in a long time, see all the drop requests pending, last update 2009, last update 2014... Nothing is so bugfree to not varrant even one bugfix release :). Anyway we could detect all the py2 only stuff move it to separate subproject and then offer it up for keeping? Thus we can fire up the devel:language:python:legacy at least later on when dropping py2 we will know what to kill with fire :)) We can still prune all those leafs from 200x that didn't have friends but we would keep all py2 love in one spot for everyone to play with if they desire so. Cheers Tom

On Tue, May 22, 2018 at 2:46 AM, Joachim Wagner wrote:

...

[...] last update 2009, last update 2014... Nothing is so bugfree to not varrant even one bugfix release :).

In well tested/aged software, remaining bugs only show when new, unexpected input arrives or the environment changes. 9 years without a bug report is possible for applications with a narrow use case and a small user base.

Joachim

devel:languages:python:singlespec-staging has most of the packages that need to be converted. In fact most of them have already been automatically converted, they just need to be checked since the automatic conversion isn't perfect. But that assumes the package supports python 3 to begin with. There are lots of packages that don't support python 3 and almost certainly never will because they haven't been touched upstream in years. Those are what my current proposal focuses on. devel:languages:python:misc has packages that are not in or submitted to openSUSE:factory. Many of those are in pretty good shape, often just needing and update and a license macro in the files. Others, however, haven't been updated in years. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On mardi, 22 mai 2018 17.23:27 h CEST Matěj Cepl wrote:

On 2018-05-21, 16:09 GMT, Todd Rme wrote:

...

What about packages that are maintained but remain python2-only?

And would it really be a large amount of work if we make it clear that no further work on legacy packages will be done by dlp maintainers?

Let me add one even more controversial comment. I would like to start a discussion on purpose of the packaging Python packages at all. I mean, certainly we need to package all dependencies of applications we ship, and we need to have somehow defined basic platform we can maintain. However, what is the advantage of having packaged PyPI package, which is completely ignored in OpenSUSE repositories, has just minimal number of users?

Just randomly from packages I am going through, what is the value for average OpenSUSE user of maintaining package python-odorik? It is a Python library providing Python interface to the API of tiny Czech mobile phone operator (so small I have never heard about it, even though I am a Czech myself). Would its (I would risk to assume) few users be really that harmed by using pip, and using the package directly?

I guess the original author of the package was/is OpenSUSE user, so he packaged it for the distribution as well, but my point is that maintenance of packages is not free (in terms of time we need to spend on it, not necessarily money), and we should consider the costs of the maintenance.

Best,

Matěj

I'm a bit surprised about this kind of sentences. If I package something for myself (with the required quality, shouldn't be it shared ?) The disavantage of pypi, is sudo pip install bla and get a fucked up system :-) Now the question is are we moving dlp to a strict devel repo for factory and then have somewhere a jungle pypi equivalent for package that exist but have to few interest to be in main Factory, but still are packaged ? The only other solution will be, people interested will keep their own stuff and will not share them. I'm confuse in my brain with the 2 years ago, put everything in factory, one year later we will consolidate to single spec (need work) and now throw the baby, the water and the church But we miss the step, singlespec is now ok. Period of time to submit to factory Once done, start the cleanup and drive contributors Now we learn that we lack resources for dlp, and also for factory review. Then what shall I do as contributor ? Go ahead, no go .... For the moment I'm redoing a lot of work that was done in the last 2 years, Some packages will goes to Factory, because they are key for other stuff (Geo, Cloud and so). But for the others (most of them the req to become maintainer was not followed) will certain move to a personal dontbreakpythonagainyet sub project, but I feel this should not be the right direction. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mike Henry wrote:

I'm not sure why package maintainers would package python packages that are not involved in packages/applications. In some restricted production environments you want to install 3rd-party stuff from outside openSUSE without having to allow Internet access to PyPI or setup your own internal devpi-server.

Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mike Henry wrote:

On Tue, May 22, 2018 at 11:00 AM, Michael Ströder wrote:

...

Mike Henry wrote:

...

I'm not sure why package maintainers would package python packages that are not involved in packages/applications. In some restricted production environments you want to install 3rd-party stuff from outside openSUSE without having to allow Internet access to PyPI or setup your own internal devpi-server.

I hadn't considered that, I guess it depends on where a company wishes to spend their efforts, but it seems easier to host a devpi-server which would give you all the PyPI packages

Even with your own devpi-server you would need a build pipeline, especially for C wrapper modules. With the latter you also have to provide builds for different OS versions. That's not easy too. YMMV. All my customers are different and what's the best way of shipping software can be the cause for religious discussions. Ciao, Michael.

On 23/05/18 00:53, Matěj Cepl wrote:

On 2018-05-21, 16:09 GMT, Todd Rme wrote:

...

What about packages that are maintained but remain python2-only?

And would it really be a large amount of work if we make it clear that no further work on legacy packages will be done by dlp maintainers?

Let me add one even more controversial comment. I would like to start a discussion on purpose of the packaging Python packages at all. I mean, certainly we need to package all dependencies of applications we ship, and we need to have somehow defined basic platform we can maintain. However, what is the advantage of having packaged PyPI package, which is completely ignored in OpenSUSE repositories, has just minimal number of users?

Just randomly from packages I am going through, what is the value for average OpenSUSE user of maintaining package python-odorik? It is a Python library providing Python interface to the API of tiny Czech mobile phone operator (so small I have never heard about it, even though I am a Czech myself). Would its (I would risk to assume) few users be really that harmed by using pip, and using the package directly?

I guess the original author of the package was/is OpenSUSE user, so he packaged it for the distribution as well, but my point is that maintenance of packages is not free (in terms of time we need to spend on it, not necessarily money), and we should consider the costs of the maintenance.

Best,

Matěj

Personally I think that generally the cost of maintenance is relatively low, with exceptions of times like now where there is a move from python2 -> python3, or the first major clean up in many years. In my opinion if someone wants to submit a package that is building and working we shouldn't put any restrictions on it, but if it gets to a point where the package is no longer being maintained by anyone and is either not building or has major bugs that aren't being fixed then there is a good case for removing the package, this is what we have tended to do across the rest of the project and it has worked reasonably well, as once something fails to build in factory/tumbleweed the release managers do a reasonable job of removing it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 2018-05-23, 18:29 GMT, Todd Rme wrote:

The main advantage in my view is having multiple eyes on it. If I maintain my own set of packages I am solely responsible for keeping thing running, up to date, etc. But if it is part of openSUSE, then people can and do work together to do this. It is less work for each individual since any work one person does benefits everyone rather than just themself.

Of course, that’s standard theory why Linux distros are useful. However, what about the situation when there are actually less eyes on openSUSE package than on the upstream project (shared by all operating systems and distributions, and either number is not very high in the first place)? Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Home is where ~/.bashrc is. -- from Usenet -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, May 23, 2018 at 5:43 PM, Matěj Cepl wrote:

On 2018-05-23, 18:29 GMT, Todd Rme wrote:

...

The main advantage in my view is having multiple eyes on it. If I maintain my own set of packages I am solely responsible for keeping thing running, up to date, etc. But if it is part of openSUSE, then people can and do work together to do this. It is less work for each individual since any work one person does benefits everyone rather than just themself.

Of course, that’s standard theory why Linux distros are useful. However, what about the situation when there are actually less eyes on openSUSE package than on the upstream project (shared by all operating systems and distributions, and either number is not very high in the first place)?

Matěj

But when it comes to keeping my packages up-to-date, it isn't really a matter of upstream vs. openSUSE, it is a matter of me alone vs. openSUSE including me. In my experience this tends to result in the packages I need being kept more up-to-date than if I had to handle it all completely by myself. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, May 24, 2018 at 3:44 AM, Michael Ströder wrote:

Todd Rme wrote:

...

But when it comes to keeping my packages up-to-date, it isn't really a matter of upstream vs. openSUSE, it is a matter of me alone vs. openSUSE including me. In my experience this tends to result in the packages I need being kept more up-to-date than if I had to handle it all completely by myself.

This argument comes repeatedly by OS package maintainers.

But sorry, I have to repeat that I've constantly updated numerous Python packages in the past. To help I also updated the accompanying PY3 package before single-spec even though I personally have a big PY2-only code base and packaging is just a side effect of my other free software activities.

But I got strongly discouraged by the way PY2 is fought by you and others here. So I'm kind of fed up by this whining that there are not enough contributors.

Ciao, Michael.

Did you reply to the wrong email? This has nothing to do with this thread or my post. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/21/2018 10:03 AM, Simon Lees wrote:

On 22/05/18 00:01, Todd Rme wrote:

...

There are still a large number of packages in openSUSE:Factory that are python2-only. Some have not been touched upstream in years. We probably should start thinking about what to do with them.

I think we should break python2-only packages into four categories:

* Those that have python3 support that just hasn't been integrated should be updated.

* Those that upstream has indicated has python3 support in the near-term roadmap should be kept as-is for now (or updated to the latest version).

* Those that are python2-only and have not seen upstream activity since 2016 should be dropped from openSUSE:Factory and dropped from devel:languages:python after a two-week warning period.

* All others, including backports packages, should be moved to a new subproject, devel:languages:python:legacy since they won't need many updates or rebuilds. This project should be built but not published.

What does everyone think of this plan?

Sounds good to me.

This thread was enough for me to start converting VirtualBox to use Python 3.6 instead of 2.7. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Todd Rme wrote:

On Mon, May 21, 2018 at 12:06 PM, Michael Ströder wrote:

...

Todd Rme wrote:

...

* Those that are python2-only and have not seen upstream activity since 2016 should be dropped from openSUSE:Factory and dropped from devel:languages:python after a two-week warning period.

I see no compelling reason to be so over-aggressive to PY2 code base.

What would you propose we do instead?

Keep those packages. Ciao, Michael. P.S.: Personally I'm pretty much frustrated regarding the Python stuff in openSUSE. Although I still have a large PY2 code base I've updated in the past many Python modules also for PY3 even before the single-spec approach. With all these confusing changes I gave up on this and focus on doing my own private stuff now. P.P.S.: Helping maintaining python2 updates would be easier if all the patches were better documented. P.P.P.S.: After all this repo moving packages cannot be found anymore in search form on https://build.opensuse.org => greatly degraded usability of all this. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Todd Rme wrote:

The openSUSE python team isn't very large.

So why are you frustating contributors effectively reducing the set of contributors? Ciao, Michael.

Todd Rme wrote:

On Mon, May 21, 2018 at 12:50 PM, Michael Ströder wrote:

...

Todd Rme wrote:

...

The openSUSE python team isn't very large.

So why are you frustating contributors effectively reducing the set of contributors?

We have been streamlining the project and development workflow to make it easier to maintain long-term. The previous situation was simply unsustainable, especially with such large upstream changes that we need to deal with.

I translate this PR statement to more clear words: "I have my own agenda and therefore I don't care about other contributers needs." So why do you wonder that not more people want to help? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 21 May 2018 12:10:34 -0400 Todd Rme wrote:

On Mon, May 21, 2018 at 12:06 PM, Michael Ströder wrote:

...

Todd Rme wrote:

...

* Those that are python2-only and have not seen upstream activity since 2016 should be dropped from openSUSE:Factory and dropped from devel:languages:python after a two-week warning period.

I see no compelling reason to be so over-aggressive to PY2 code base.

Ciao, Michael.

P.S.: And yes, I know the dates and Python clock web site, blah...

P.P.S.: And yes, I know 2to3 (which might help in some trivial cases).

What would you propose we do instead?

*Wild blue-sky idea* Port to Tauthon? It doesn't look to be disappearing any time soon. Active, lots of contributors and commits. https://github.com/naftaliharris/tauthon -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 22, 2018 at 3:21 AM, Joachim Wagner wrote:

...

* Those that are python2-only and have not seen upstream activity since 2016 should be dropped [...] [...] after a two-week warning period.

Where can we see a list of all affected packages, including packages that depend on an affected package? Similarly to Larry for VirtualBox, users with good python knowledge might step forward to volunteer converting their favourite package to python 3.

Joachim

devel:languages:python:singlespec-staging has most of the packages that need to be converted. In fact most of them have already been automatically converted, they just need to be checked since the automatic conversion isn't perfect. But that assumes the package supports python 3 to begin with. There are lots of packages that don't support python 3 and almost certainly never will because they haven't been touched upstream in years. Those are what my current proposal focuses on. devel:languages:python:misc has packages that are not in or submitted to openSUSE:factory. Many of those are in pretty good shape, often just needing and update and a license macro in the files. Others, however, haven't been updated in years. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, May 24, 2018 at 10:27:00PM +0200, Matěj Cepl wrote:

On 2018-05-24, 06:56 GMT, Takashi Iwai wrote:

...

Last but not least, IMO, two weeks are too short for such a transition. One may have a vacation for two weeks easily if living in Europe :)

Well, I guess the best protection against removal is to show some signs of life in the package. If package has not been touched in the last two years (https://is.gd/lCVFbz and the last upstream release in Jul 13, 2015), my restraint against removal is significantly lower.

Not every package requires continuous development. There are simple utilities or libraries which "just work" and there is no point releasing updates every few months (or even weeks), even if it is considred "modern" or even "sign of life" by some. So in the example above, the question you should ask shoudn't be "when was last upstream release?" but rather "does it still work?" or "are there ignored serious bugs?". An example of twinkle comes to my mind - it hasn't seen an upstream release from 2009 to 2015 and it still had many happy users who would have become very unhappy if it was just dropped from the distribution with two week's notice. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, May 24, Michal Kubecek wrote:

Not every package requires continuous development. There are simple utilities or libraries which "just work" and there is no point releasing updates every few months (or even weeks), even if it is considred "modern" or even "sign of life" by some.

I fully agree, there is software developed over 20 years ago, so you can assume that meanwhile the bugs are found and fixed. Only every few years an update for adjustements to the latest gcc is necessary. Only because no bugs were found and got fixed, this does not mean the project is dead or unuseable. I know several of such cases. But on the other side, if such projects use DES or bigcrypt encryption, you should seriously consider to drop the usage of such software, because today this are really no serious and secure algorithm anymore. I also know several of such cases. I wouldn't add any of them today to openSUSE. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Reality is that the only justification for DES is that it is cheap and easy.

The ability to decrypt old archives / backup data is a good reason to keep support for legacy ciphers. I agree that software that only supports old ciphers needs new contributors and/or maintainers to modernise the software and failing this we shouldn't spend valuable resources on creating packages for such software. If the package creating effort is minimal and the main concern is to not promote usage of old, dangerous software an alternative to dropping the package is to include a warning message in the description field and "legacy" in the package name. Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org