[opensuse-packaging] heads-up: dropping SLE11 compatibility in d:l:python and python3
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Folks, I'll be disabling builds for SLE11 in the following repositories: devel:languages:python devel:languages:python3 The SLE11 repository will not be removed; if you *want* to build for SLE11, you can explicitly enable it for your package. I have also already started declining requests to these repos that contain SLE11 compatibility conditionals (%if %suse_version < 1230 or lower). This only applies to newly-added conditionals, and new package submits: If you're only updating a package that already has this in the spec file, the request will be accepted. I'll still accept requests with conditionals, IF you ask for it in the request message; our goal is simply to make this an exception and not the default. (Fellow d:l:py reviewers, please consider adopting this policy too.) The py2pack tool currently generates some compatibility conditionals like this, i'll try to get it updated so that a newly generated spec will be acceptable. In other words, feel free to submit packages that don't build on SLE11. m. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU6y3jAAoJEIskb84DCy7LiK0QAIYODvyw5yHeKIxyKEPHRdCm BkqxLp8eALZCfngURzodCytj7qODTWo8IRr/W6LWUGqrPDwwwLmw1X2Yd5dl2fQw Ozw9Kcz+pt0MBKuR6Xp9ypRRUqcdGCjqDehO5TG5rGgJguWRNu2YcV3qPsGLEfGW u2M74Qw3b/ILpmUTXJlV7gHAayUAJ1d0QhvtWNp0XDaDkGsl5+rKSaoY/3CJ7rwZ 889w82SiPvdh4nMAegu7uZYXtZFkd+xePl9OwKeG8I2o2IqVg/mb2Wr1/asIoTNq nikOdyZbjpSXWDVH2uPKTG7SkHrSAE+CfadOWv8mEuO4cdhD0Uj9GubcJ6e9eSU/ HPfeGe/DFi0EXq57uG70gW/8SKkM33yet6l3ulqaiHgqYIfz8k6YovceHQGT8pHb V5G+nGWld2Sn79g6WibPZOfMuS9dMU07nQFiUAioddekJyEwTSVlT7BVS+AhiM/g ZhP8lZXnHBB7EA0PgsgRJfm9OqcNZETyyk6VWcSm0PyKQFzBPcGiQcKKWU4Vfq3/ J2HdBT518zCJurVKfNU4c/rBye2Q/gSQAUoa+ITUSZRyqeVIIyt00DX/MTPkYzPN Yy0eUIW9pPBuAcbZnofqwL9ljasYOcYCM6GvmJ6uBTAIe4kHAcaPC7UArA9A7M90 IIMPKmcfr6CpZ/jYcBT8 =mJBy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/23/2015 08:40 AM, Jan Matějek wrote:
Folks,
I'll be disabling builds for SLE11 in the following repositories: devel:languages:python devel:languages:python3 The SLE11 repository will not be removed; if you *want* to build for SLE11, you can explicitly enable it for your package.
I have also already started declining requests to these repos that contain SLE11 compatibility conditionals (%if %suse_version < 1230 or lower). This only applies to newly-added conditionals, and new package submits: If you're only updating a package that already has this in the spec file, the request will be accepted. I'll still accept requests with conditionals, IF you ask for it in the request message; our goal is simply to make this an exception and not the default.
Well the following clearly indicates that this should be handled differently.
(Fellow d:l:py reviewers, please consider adopting this policy too.)
If there is a change to the policy for d:l:python and d:l:python3 at the devel project level than this is something that should be, should have been, discussed in the open prior to an announcement and should have also been discussed and agreed upon by devel project maintainers prior to an announcement. We cannot be in a position where the acceptance of a submit request to a devel project depends on the mood of one specific maintainer. How you handle the packages you maintain is of course up to you. But making devel project wide announcements without a prior discussion and at least listening to what other maintainers of Python packages have to say is rude at best. Why is it so difficult to have a discussion and not hit people over the head. This kind of behavior has caused some many problems in the past, will continue to cause problems. Why is it so hard to figure out that people do not like to be hit over the head with uni-lateral announcements? Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJU6z4DAAoJEE4FgL32d2UkShUIAIGMQoF1f1SZnCmZxpTidxRb kL1cV9Ff0NuukTQ93a0pBTF72TO7q9Z1zeOxZcqj0xFOBPi9syGEI4Sxokpp+BJ6 rSniEUpHQBV/ZLuOs6k99mo25+BDqhl01imSnLjhu1K/dbFZo5un6PPZj8MK3Qzk AsstnCjJTl3UIA+kRvyD41GgKYmNPdfgYhGeG8VVUSJo9cyv1w+CXqVfSpJ406vE A9Xdnl/wWQ4xQrLkNvucWP6Fx+HgrsCPGv9JtwrNevqjucyQg7mqueQZNVeWOiM3 YVfCzq8ziShfAJdjUmPfvxgpSikRKt+6DqQurrtWUfryCfPeeRFLF1YCaQSV3tY= =O3Hd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 02/23/2015 03:49 PM, Robert Schweikert wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
On 02/23/2015 08:40 AM, Jan Matějek wrote:
Folks,
I'll be disabling builds for SLE11 in the following repositories: devel:languages:python devel:languages:python3 The SLE11 repository will not be removed; if you *want* to build for SLE11, you can explicitly enable it for your package.
I have also already started declining requests to these repos that contain SLE11 compatibility conditionals (%if %suse_version < 1230 or lower). This only applies to newly-added conditionals, and new package submits: If you're only updating a package that already has this in the spec file, the request will be accepted. I'll still accept requests with conditionals, IF you ask for it in the request message; our goal is simply to make this an exception and not the default. Well the following clearly indicates that this should be handled differently.
(Fellow d:l:py reviewers, please consider adopting this policy too.) If there is a change to the policy for d:l:python and d:l:python3 at the devel project level than this is something that should be, should have been, discussed in the open prior to an announcement and should have also been discussed and agreed upon by devel project maintainers prior to an announcement.
We cannot be in a position where the acceptance of a submit request to a devel project depends on the mood of one specific maintainer. How you handle the packages you maintain is of course up to you. But making devel project wide announcements without a prior discussion and at least listening to what other maintainers of Python packages have to say is rude at best.
Why is it so difficult to have a discussion and not hit people over the head. This kind of behavior has caused some many problems in the past, will continue to cause problems. Why is it so hard to figure out that people do not like to be hit over the head with uni-lateral announcements?
Later, Robert
- -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJU6z4DAAoJEE4FgL32d2UkShUIAIGMQoF1f1SZnCmZxpTidxRb kL1cV9Ff0NuukTQ93a0pBTF72TO7q9Z1zeOxZcqj0xFOBPi9syGEI4Sxokpp+BJ6 rSniEUpHQBV/ZLuOs6k99mo25+BDqhl01imSnLjhu1K/dbFZo5un6PPZj8MK3Qzk AsstnCjJTl3UIA+kRvyD41GgKYmNPdfgYhGeG8VVUSJo9cyv1w+CXqVfSpJ406vE A9Xdnl/wWQ4xQrLkNvucWP6Fx+HgrsCPGv9JtwrNevqjucyQg7mqueQZNVeWOiM3 YVfCzq8ziShfAJdjUmPfvxgpSikRKt+6DqQurrtWUfryCfPeeRFLF1YCaQSV3tY= =O3Hd -----END PGP SIGNATURE----- Personally, I just would like to say I disagree with that decision. It doesn't require any extra work from us, why disabling SLE11 support ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hello, Dne 23.2.2015 v 16:06 Benjamin Denisart napsal(a):
Personally, I just would like to say I disagree with that decision. It doesn't require any extra work from us, why disabling SLE11 support ?
on the vast majority of packages, the only "extra work" is the conditional definition of "BuildArch: noarch" and the %python_sitelib/sitearch macros. This seems minor, but there is also no good reason to keep doing it. On some more complicated packages, however, there is significant work in keeping things like lists of requirements and %pre/%post scriptlets up to date and working. It's this kind of work that we want to get rid of -- ideally everywhere, not just for python. Dropping SLE11 is a step in that direction. Again, feel free to continue supporting SLE11 if you feel that it's worth the effort, just please let us know that you're doing it deliberately and not only because "it's something that we always did". regards m. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU6278AAoJEIskb84DCy7LlxcQAIoFCIob+MtdQoD5Y+PgPA33 unFisHOs9KsLROQ7r+TILxiDCynbGjOZeuEqLCg3030R+9L0/uzfNaozbqQfh5cq FTJxt4uivZX5ygB4UOW1rsEpby+5CEeCiSenyprqom26xA8hF77Ytmect0YnLipX IyYSyFpdf4iQ0ImsfH3SZJWsgccKFb3iprwjEHxKf0Suxffn3+zt7G+XS0zbb1le nOWW9aYPB/a0aakt2fEytWgZNOmC5NgTvzg1sBUDPV4Pgg9f80iqjSITlPkKs7Ow +cZ0/t569yl+pbG37I0H38rTDI2iMyQUBdL27dZP+MwP5myHwhl8bruPHBtxbeO0 1H/F2SJFzd2d3WYAiRyBL2+kC2iwYCHE4/vBuo9phqcl9Yu/sFcs6Ivp8j0HqwHx 3SKxLdE9KJcTNG2vu5N1XSTwam8KuqbgW3BNKHSPJhLTraIq+epuuotDvETSSuCI 0+Qsflp9NrNGKWe9qye5vx3MsD+ZD+Mbgos0MJhRt2tggFCIPRgHJCf/binLvQZX JnX+7B0RY9+5HpXOANqZgoIlLGxdARwGEbwkFkUJl6FUPVrAQtL/D788ZUwlxF6t I7v8KLL0kdvz/QQOJwG0vjIsyCeTUiNEEwmtRq6RssFyp+b03sE/FZWHl+bdqDLZ OSoc8o98ulpRR1d9jDja =Scp1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 02/23/2015 07:18 PM, Jan Matějek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
hello,
Dne 23.2.2015 v 16:06 Benjamin Denisart napsal(a):
Personally, I just would like to say I disagree with that decision. It doesn't require any extra work from us, why disabling SLE11 support ? on the vast majority of packages, the only "extra work" is the conditional definition of "BuildArch: noarch" and the %python_sitelib/sitearch macros. This seems minor, but there is also no good reason to keep doing it.
On some more complicated packages, however, there is significant work in keeping things like lists of requirements and %pre/%post scriptlets up to date and working. It's this kind of work that we want to get rid of -- ideally everywhere, not just for python. Dropping SLE11 is a step in that direction.
Again, feel free to continue supporting SLE11 if you feel that it's worth the effort, just please let us know that you're doing it deliberately and not only because "it's something that we always did".
regards m. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJU6278AAoJEIskb84DCy7LlxcQAIoFCIob+MtdQoD5Y+PgPA33 unFisHOs9KsLROQ7r+TILxiDCynbGjOZeuEqLCg3030R+9L0/uzfNaozbqQfh5cq FTJxt4uivZX5ygB4UOW1rsEpby+5CEeCiSenyprqom26xA8hF77Ytmect0YnLipX IyYSyFpdf4iQ0ImsfH3SZJWsgccKFb3iprwjEHxKf0Suxffn3+zt7G+XS0zbb1le nOWW9aYPB/a0aakt2fEytWgZNOmC5NgTvzg1sBUDPV4Pgg9f80iqjSITlPkKs7Ow +cZ0/t569yl+pbG37I0H38rTDI2iMyQUBdL27dZP+MwP5myHwhl8bruPHBtxbeO0 1H/F2SJFzd2d3WYAiRyBL2+kC2iwYCHE4/vBuo9phqcl9Yu/sFcs6Ivp8j0HqwHx 3SKxLdE9KJcTNG2vu5N1XSTwam8KuqbgW3BNKHSPJhLTraIq+epuuotDvETSSuCI 0+Qsflp9NrNGKWe9qye5vx3MsD+ZD+Mbgos0MJhRt2tggFCIPRgHJCf/binLvQZX JnX+7B0RY9+5HpXOANqZgoIlLGxdARwGEbwkFkUJl6FUPVrAQtL/D788ZUwlxF6t I7v8KLL0kdvz/QQOJwG0vjIsyCeTUiNEEwmtRq6RssFyp+b03sE/FZWHl+bdqDLZ OSoc8o98ulpRR1d9jDja =Scp1 -----END PGP SIGNATURE----- I don't really care of SLE11 support. It's just that in d:l:p, it is less a mess to maintain it than in other projects. Please, go ahead and remove it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 23 February 2015 at 14:40, Jan Matějek <jmatejek@suse.cz> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Folks,
I'll be disabling builds for SLE11 in the following repositories: devel:languages:python devel:languages:python3 The SLE11 repository will not be removed; if you *want* to build for SLE11, you can explicitly enable it for your package.
I have also already started declining requests to these repos that contain SLE11 compatibility conditionals (%if %suse_version < 1230 or lower). This only applies to newly-added conditionals, and new package submits: If you're only updating a package that already has this in the spec file, the request will be accepted. I'll still accept requests with conditionals, IF you ask for it in the request message; our goal is simply to make this an exception and not the default. (Fellow d:l:py reviewers, please consider adopting this policy too.) The py2pack tool currently generates some compatibility conditionals like this, i'll try to get it updated so that a newly generated spec will be acceptable.
In other words, feel free to submit packages that don't build on SLE11.
m.
Jan, I'm not going to comment on the merits (or lack thereof) of this decision, but I am compelled to comment on one aspect of this announcement.
(Fellow d:l:py reviewers, please consider adopting this policy too.)
We're a community. And for that community, the various groups within it need to work together. That requires communication and consultation. Based on the above quoted line, it seems you are arbitrarily making a decision regarding d:l:py without consulting your colleagues who also review d:l:py The userlist of d:l:py suggests there are 8 other individuals besides yourself who should have been involved in a decision like this before any announcement like this should have been made. If you've decided to do this on your own, without consulting *at least* your colleagues in that development group (ideally major changes with a wide impact should also be discussed with wider community before actions are taken) then I consider this announcement invalid, inappropriate, madness, and I could probably use stronger language. Please clarify whether this announcement is a formal agreed upon decision of the current maintainers of devel:languages:python and python3 If it is not, then please synchronise your practices with your fellow maintainers before making any announcements. Regards, Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hello Richard, thank you for your comment. You are right that this should have been handled differently, and I'll know that the next time an issue like this arises. I want to apologize to anyone who feels slighted by not being included, and I promise to do better. To answer your question and clarify the announcement: the decision to drop "official" support for SLE11 is agreed upon within the internal packager team. The main point of the announcement is that we want to switch off SLE11 builds (unless the users object, but ISTM the community doesn't care all that much about SLE?), and that we (meaning the internal maintainers) no longer care about SLE11 compatibility in d:l:py. I agree that I should have discussed this with fellow d:l:py maintainers first, but I hope that when stated like this, the announcement is not as controversial. sorry again m. Dne 23.2.2015 v 18:16 Richard Brown napsal(a):
We're a community. And for that community, the various groups within it need to work together. That requires communication and consultation. Based on the above quoted line, it seems you are arbitrarily making a decision regarding d:l:py without consulting your colleagues who also review d:l:py
The userlist of d:l:py suggests there are 8 other individuals besides yourself who should have been involved in a decision like this before any announcement like this should have been made.
If you've decided to do this on your own, without consulting *at least* your colleagues in that development group (ideally major changes with a wide impact should also be discussed with wider community before actions are taken) then I consider this announcement invalid, inappropriate, madness, and I could probably use stronger language.
Please clarify whether this announcement is a formal agreed upon decision of the current maintainers of devel:languages:python and python3
If it is not, then please synchronise your practices with your fellow maintainers before making any announcements.
Regards,
Richard
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU62eeAAoJEIskb84DCy7LDG0P/2NPtc1zYd/zuKYsCtnnoPV1 TLFrlZYl85UDphiPOXgM+yCaH4cUYBVEDWe4D9WP5WD+yegUY/+v1XgDoSNHf/q1 ovW5Yf4YyzmQZfPCy5sQZRzfBvN/Fk/+jXcOLNUKqliFAu3oy6Hk65R98ZpbzLdG wwRoPorEwt2NLAUeT/zjIGu53nHrGcb3dK/qDGQxEjLuULTKcd6v9w34b+jqSiJz u++i/aBTHxM0ut44P3SU8MkkwPWjHoaDkbL1ydemjMdjer8A5u0kju2/6KBww9Ye LYBQRhHZ3gYgOnU+lXdCs9to4gWRNnnSbatOnD28S94MzYHxZiX+F6GA0dNqnXco KeNwZktV8yFfYH5hJFHXheqOUZhko4bxAPRJ4aGt9udf1GPqASMxgry5BFnPHl9j xhMmIgqvKErKja3e3qcIP/30WbPKcmMiWVWrljumBe4sqAwgRJc4XBgZZi/ZdchE vIOSkOnQC5TF+WL9RnEdKvprNoTAbgh951ACrcDefQ15Kb/pJVbXYkyTxxNS9pWz VibcgMS7/FP3nQYN9V7U+d5huoSAQgbspUK/3F+4Fc/gu13ZNXVjxg1TXaMeyXpO ni68DhPJDqgTFJto4yucAfAotfmy0Bb7XpELf9SHA1GUwjgxVn0pWjtoQTILfyRi rOTA5fzMRLq1dago/ZUB =te0z -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, On 02/23/2015 12:47 PM, Jan Matějek wrote:
hello Richard,
thank you for your comment. You are right that this should have been handled differently, and I'll know that the next time an issue like this arises. I want to apologize to anyone who feels slighted by not being included, and I promise to do better.
To answer your question and clarify the announcement: the decision to drop "official" support for SLE11 is agreed upon within the internal packager team.
And how is this relevant for openSUSE? You guys can certainly disable SLE 11 builds for the packages you maintain. That does not mean everyone else has to follow suit. Nor is it fair to expect other people to do extra work because of a decision made by a hand full of guys behind the corporate fire wall.
The main point of the announcement is that we want to switch off SLE11 builds (unless the users object, but ISTM the community doesn't care all that much about SLE?), and that we (meaning the internal maintainers) no longer care about SLE11 compatibility in d:l:py.
That is your prerogative.
I agree that I should have discussed this with fellow d:l:py maintainers first, but I hope that when stated like this, the announcement is not as controversial.
Well, hope is the last to die. Explaining how a corporate decision in a private room leads to such an announcement actually has the opposite effect, at least for me. Anyway, Benjamin already stated his disagreement and thus I'd say lets just consider this a snafu and move on and keep things as they are. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJU629OAAoJEE4FgL32d2UktlkIAKC012wcKcepsPW8X9nom/P2 aXXc96ArMe5vKQolAY2MIPpTnF8i7tuWSkvXOJQ4Uwllb1OszooaFbF/YhBraGk5 36Ifzk8vY/o1Gnmmo67ErQI/MC1LKWSbTlAmT81wqVNso3ULf2rQpCgL0Y/otDi4 y/TaBh0ElGEi23g04uNJn5VzA3g2YlF0KG8ts8DMfBfQ1WfJrbh6+lhvDvhxjm0x yd+WIvQutBPLqFYyzjhtYUAM8QQ3+MJtPMf+DKgmkdbb+DfvzbnuJyGQFA+UZN/i oIp3o2KBgdgtEVx1NXzc/zigsm4iCoBWy7Kdzysn/6Bv+T9FdNnUPV8zrFhA1iI= =2DGK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, Feb 23, 2015 at 1:19 PM, Robert Schweikert <rjschwei@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Jan,
On 02/23/2015 12:47 PM, Jan Matějek wrote:
hello Richard,
thank you for your comment. You are right that this should have been handled differently, and I'll know that the next time an issue like this arises. I want to apologize to anyone who feels slighted by not being included, and I promise to do better.
To answer your question and clarify the announcement: the decision to drop "official" support for SLE11 is agreed upon within the internal packager team.
And how is this relevant for openSUSE? You guys can certainly disable SLE 11 builds for the packages you maintain. That does not mean everyone else has to follow suit. Nor is it fair to expect other people to do extra work because of a decision made by a hand full of guys behind the corporate fire wall.
The main point of the announcement is that we want to switch off SLE11 builds (unless the users object, but ISTM the community doesn't care all that much about SLE?), and that we (meaning the internal maintainers) no longer care about SLE11 compatibility in d:l:py.
That is your prerogative.
I agree that I should have discussed this with fellow d:l:py maintainers first, but I hope that when stated like this, the announcement is not as controversial.
Well, hope is the last to die. Explaining how a corporate decision in a private room leads to such an announcement actually has the opposite effect, at least for me.
Anyway, Benjamin already stated his disagreement and thus I'd say lets just consider this a snafu and move on and keep things as they are.
Consider this a second disagreement. I manage a heavily mixed openSUSE and SLE_11 environment and while ideally I'd only be running openSUSE, I use SLE_11 to fulfill requirements from 3rd party vendors who only support "Enterprise" distribution. I suppose I could switch to RHEL or Ububtu TLS, but that's more pain than I'd like to experience ;-). Also has any thought been given to the consequences of disabling/removing the SLE_11 repo for people running private OBS instances who link against the public OBS repos for building packages? This is going to affect those installations/setups as well, which I've found out first hand since another top-level repo removed SLE_11 target and effectively broke all my private SLE_11 pacakges. Finally, while SLE_11 may no longer be a priority for SUSE since SLE_12's release, it will be supported by SUSE until 2019 or 2022. I think it's safe to assume people will continue running it and utilizing the public build service for SLE_11 packages which are not distributed with it, or are so old they want/need newer releases.
Later, Robert
- -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJU629OAAoJEE4FgL32d2UktlkIAKC012wcKcepsPW8X9nom/P2 aXXc96ArMe5vKQolAY2MIPpTnF8i7tuWSkvXOJQ4Uwllb1OszooaFbF/YhBraGk5 36Ifzk8vY/o1Gnmmo67ErQI/MC1LKWSbTlAmT81wqVNso3ULf2rQpCgL0Y/otDi4 y/TaBh0ElGEi23g04uNJn5VzA3g2YlF0KG8ts8DMfBfQ1WfJrbh6+lhvDvhxjm0x yd+WIvQutBPLqFYyzjhtYUAM8QQ3+MJtPMf+DKgmkdbb+DfvzbnuJyGQFA+UZN/i oIp3o2KBgdgtEVx1NXzc/zigsm4iCoBWy7Kdzysn/6Bv+T9FdNnUPV8zrFhA1iI= =2DGK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Darin Perusich wrote:
Finally, while SLE_11 may no longer be a priority for SUSE since SLE_12's release, it will be supported by SUSE until 2019 or 2022. I think it's safe to assume people will continue running it and utilizing the public build service for SLE_11 packages which are not distributed with it, or are so old they want/need newer releases.
Whatever enterprise Linux you're using you have to be prepared to only receive updates of existing packages maintained by the vendor in its enterprise repo. The vendor will usually not add new packages and will usually only back-port small changes to existing packages. So the main objective of any enterprise Linux is to keep old software running while especially providing security updates. If you need significant upgrades of software packages you usually have to consider an upgrade of your enterprise Linux. I think the IMHO understandable intention of the original poster was to reduce the amount of work needed for adding/maintaining packages in development repos usually targeted for newer distribution releases. Given the growing differences (e.g. because of systemd etc.) you cannot expect package maintainers to keep all new bleeding edge things working for SLES11 in development repos until 2019 or 2022. The amount of work for this would just be crazy and therefore keep away people from starting serious upgrade work. Ciao, Michael.
Dne Po 23. února 2015 18:16:04, Richard Brown napsal(a):
(Fellow d:l:py reviewers, please consider adopting this policy too.)
We're a community. And for that community, the various groups within it need to work together. That requires communication and consultation. Based on the above quoted line, it seems you are arbitrarily making a decision regarding d:l:py without consulting your colleagues who also review d:l:py
The userlist of d:l:py suggests there are 8 other individuals besides yourself who should have been involved in a decision like this before any announcement like this should have been made.
If you've decided to do this on your own, without consulting *at least* your colleagues in that development group (ideally major changes with a wide impact should also be discussed with wider community before actions are taken) then I consider this announcement invalid, inappropriate, madness, and I could probably use stronger language.
Please clarify whether this announcement is a formal agreed upon decision of the current maintainers of devel:languages:python and python3
If it is not, then please synchronise your practices with your fellow maintainers before making any announcements.
Hello guys, the general problem is that after Sasha as the guy who kept the sle11 part always rolling left SYSE nobody cared much about dlp and it got kinda muddy. I can vouch for that from the factory-maintainer PoV where most reviews were open and had to be acked by me which I didn't enjoy that much as the python is bit too active for my liking. Also I am not saying there are not active people there, sometimes they pop up, but it is for sure not the list we show up on the OBS. *EXTRA What Jan should've changed in his message was to make it more in way "I am no longer going to enforce sle11 support as the effort will be spent on redoing the packaging a bit" (see mails on -packaging wrt the things he wants to do there). And he simply recommends the others to do so, or chip in more actively to maintain the sle11 thingy. Which he already did clarify while I am writing this mail... So no more to this topic :-) * EXTRA The lists of users allowed to commit we have in obs are completely broken and can bring one to false conclusions (like package is maintained, need not to bother much) and another fancy issues. We do not have any way how to determine if people actually abandoned packages or projects and nobody checks them too much. The oldest request opened against some devel projects is 9 months old and I guess if one day I won't kick myself to accept/decline it somehow it will be opened for bit longer... :) To ilustrate I shall borrow databases project [1], there is list of active members, where from the guys really active there it is kstreitova, miska (when bribed as usual ;)) and I didn't notice much anyone else. Just looking on it you think there are some people and reviewers, but quite the oposite is the reality... And this funky thing we have in most projects, and don't get me started on individual packages ;-) Sadly I don't have any obvious solution to this situation, one would be to have some "heartbeat" monitor that would show when last time person touched in specified area, and if it would be without activity for couple of months he would get mail telling him that he would be removed from group unless active in some time again... Cheers Tom [1] https://build.opensuse.org/project/users/server:database
On Monday, February 23, 2015 07:02:39 PM Tomáš Chvátal wrote:
What Jan should've changed in his message was to make it more in way "I am no longer going to enforce sle11 support as the effort will be spent on redoing the packaging a bit" (see mails on -packaging wrt the things he wants to do there).
Actually this is the part that I don't get. SLE11-SP3 still have 2.6 and IDK if SP4 will have the last 2.7 branch. Even thought 2.6 is old and unsupported from python.org since the end of 2013, most of the packages works OK with this version. But the key argument is that SLE11 is still a supported SLE version, and most SLE users and developers (and this include SUSE itself) will feel the pain of this decision. For example, OpenStack is a huge set of Python packages that, because SUSE OpenStack Cloud product, support SLE11 and all the openSUSE versions. If the project decide to drop d:l:p SLE11 support, this will we translated of a more pain for SLE11 users / developers and a bit of less contributions for those developers that belong to both sets (SLE11 && Python), and there are some of them creating new PRs right now. Thanks, Alberto Planas -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany
On 02/24/2015 02:09 PM, Alberto Planas Dominguez wrote:
On Monday, February 23, 2015 07:02:39 PM Tomáš Chvátal wrote:
What Jan should've changed in his message was to make it more in way "I am no longer going to enforce sle11 support as the effort will be spent on redoing the packaging a bit" (see mails on -packaging wrt the things he wants to do there). Actually this is the part that I don't get. SLE11-SP3 still have 2.6 and IDK if SP4 will have the last 2.7 branch. Even thought 2.6 is old and unsupported from python.org since the end of 2013, most of the packages works OK with this version.
But the key argument is that SLE11 is still a supported SLE version, and most SLE users and developers (and this include SUSE itself) will feel the pain of this decision. For example, OpenStack is a huge set of Python packages that, because SUSE OpenStack Cloud product, support SLE11 and all the openSUSE versions.
If the project decide to drop d:l:p SLE11 support, this will we translated of a more pain for SLE11 users / developers and a bit of less contributions for those developers that belong to both sets (SLE11 && Python), and there are some of them creating new PRs right now.
Thanks, Alberto Planas
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tuesday, February 24, 2015 02:19:29 PM Benjamin Denisart wrote:
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory.
Quite radical! : ) I kind of like the idea, but maybe makes more sense after the default Python version installed in Factory is only Python 3. After that, we can make Factory an only Python 3 distribution, removing packages like in your proposal. Thanks, Alberto Planas -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 02/24/2015 02:42 PM, Alberto Planas Dominguez wrote:
On Tuesday, February 24, 2015 02:19:29 PM Benjamin Denisart wrote:
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory. Quite radical! : )
I kind of like the idea, but maybe makes more sense after the default Python version installed in Factory is only Python 3. After that, we can make Factory an only Python 3 distribution, removing packages like in your proposal.
Thanks, Alberto Planas
Sure, but not before a long time so ! Cause a lot of packages still doesn't support py3. And because we don't have final specifications for unified specfile. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dne Út 24. února 2015 14:44:00, Benjamin Denisart napsal(a):
On 02/24/2015 02:42 PM, Alberto Planas Dominguez wrote:
On Tuesday, February 24, 2015 02:19:29 PM Benjamin Denisart wrote:
If we want doing something to reduce mass of work, we should
instead
decide what to do with python2 and 3 packages. I purpose that each
time
a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory.
Quite radical! : )
I kind of like the idea, but maybe makes more sense after the default Python version installed in Factory is only Python 3. After that, we can make Factory an only Python 3 distribution, removing packages like in your proposal.
Thanks, Alberto Planas
Sure, but not before a long time so ! Cause a lot of packages still doesn't support py3. And because we don't have final specifications for unified specfile.
For this Jan was quite busy with other tasks, so he will now start working in this direction. (And it is the actual reason for his mail to -factory, to show that the things start moving :)) So I would recommend first finishing up unified spec idea and then deciding how to reduce it on Factory. Also funny part will be to ensure the unified specs to work on SLE11 if someone is interested, as it will probably need quite backports of macro declarations/etc. Cheers Tom
Alberto Planas Dominguez wrote:
On Tuesday, February 24, 2015 02:19:29 PM Benjamin Denisart wrote:
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory.
Quite radical! : )
Somewhat understandable but it's pretty hard to decide whether both conditions are really met. Especially the condition "is not a dependency of a py2-only package" is likely a moving target. => Probably this approach would lead to a much bigger mess. Ciao, Michael.
Le 24/02/2015 17:48, Michael Ströder a écrit :
On Tuesday, February 24, 2015 02:19:29 PM Benjamin Denisart wrote:
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory. Quite radical! : ) Somewhat understandable but it's pretty hard to decide whether both conditions are really met. Especially the condition "is not a dependency of a py2-only
Alberto Planas Dominguez wrote: package" is likely a moving target. => Probably this approach would lead to a much bigger mess.
Ciao, Michael.
I think the hardest part is how we could handle it. Does It require we stop providing python3-x and just provide python-x under python3 ? Or a provide/obsolete from each py3 packages ? I don't know. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
denisart benjamin2 wrote:
Le 24/02/2015 17:48, Michael Ströder a écrit :
On Tuesday, February 24, 2015 02:19:29 PM Benjamin Denisart wrote:
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory. Quite radical! : ) Somewhat understandable but it's pretty hard to decide whether both conditions are really met. Especially the condition "is not a dependency of a py2-only
Alberto Planas Dominguez wrote: package" is likely a moving target. => Probably this approach would lead to a much bigger mess.
I think the hardest part is how we could handle it. Does It require we stop providing python3-x and just provide python-x under python3 ? Or a provide/obsolete from each py3 packages ? I don't know.
The hardest part is how to handle new dependencies introduced by py2-only packages added *after* making the decision for the providing a py3-only package. => IMHO it's not worth the effort thinking about all the corner-cases. Please leave it like it is. Ciao, Michael.
On 24.02.2015 14:19, Benjamin Denisart wrote:
On 02/24/2015 02:09 PM, Alberto Planas Dominguez wrote:
On Monday, February 23, 2015 07:02:39 PM Tomáš Chvátal wrote:
What Jan should've changed in his message was to make it more in way "I am no longer going to enforce sle11 support as the effort will be spent on redoing the packaging a bit" (see mails on -packaging wrt the things he wants to do there). Actually this is the part that I don't get. SLE11-SP3 still have 2.6 and IDK if SP4 will have the last 2.7 branch. Even thought 2.6 is old and unsupported from python.org since the end of 2013, most of the packages works OK with this version.
But the key argument is that SLE11 is still a supported SLE version, and most SLE users and developers (and this include SUSE itself) will feel the pain of this decision. For example, OpenStack is a huge set of Python packages that, because SUSE OpenStack Cloud product, support SLE11 and all the openSUSE versions.
If the project decide to drop d:l:p SLE11 support, this will we translated of a more pain for SLE11 users / developers and a bit of less contributions for those developers that belong to both sets (SLE11 && Python), and there are some of them creating new PRs right now.
Thanks, Alberto Planas
If we want doing something to reduce mass of work, we should instead decide what to do with python2 and 3 packages. I purpose that each time a package is py3-compatbile and is not a dependency of a py2-only package, we provide py3 version only in Factory.
I would like to see that py2 and py3 packages are build from the same source (where possible, like all major distros are doing it) instead of having 2 different versions for py2 and py3. Cheers, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (10)
-
Alberto Planas Dominguez -
Benjamin Denisart -
Darin Perusich -
denisart benjamin2
-
Jan Matějek -
Michael Ströder -
Richard Brown -
Robert Schweikert -
Thomas Bechtold -
Tomáš Chvátal