Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On 9/15/23 09:38, Thomas Goirand wrote: Hi, As you may know, the upstream author for pysnmp passed away last year. As a result, the whole suite was forked by "lextudio". I packaged it, and the result is this list of source packages: python-pyasn1-lextudio python-pyasn1-modules-lextudio python-pysmi-lextudio python-pysnmp-lextudio Appart from the OpenStack packages, here's the list of reverse dependencies for the old python3-pysnmp4 binary package: * patator * pdudaemon * pysmi * snimpy * changeme * python3-snimpy * python3-pysnmp4-apps * python3-pysnmp4-mibs * snmpsim My plan is to file bugs against these packages, asking to transition to the newer packages. We're just below the threshold for asking debian-devel about mass bug-filling, so I figured out I would only send a mail to the Python list. Do you guys approve my plan? Should we make transition dummy packages? Also to Adam Cécile: can you make your pull request against the new Salsa repository? Hello, Regarding my lexstudio patch to fix double awaitable bug ? Cheers, Thomas Goirand (zigo)
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On September 17, 2023 9:48:38 PM UTC, Thomas Goirand wrote: >Scott & everyone, > >On 9/16/23 19:04, Scott Kitterman wrote: >> It's pretty relevant to your question. If you had instead updated the >> existing packages from the new upstream, no transition would be needed. > >I'm not entirely sure that no transition is needed, no. The major version was >bumped to version 5, and I have no clue if this represent some >incompatibility. This needs to be tested at least (see below). > >> Did you check with the existing maintainers to see what they thought? > >Hum ... why do you think I've opened this thread? > >> As is usually the case in Debian, I think the answer is you work with the >> maintainers to figure out the best solution. Ignoring them and hijacking >> the packages is not the right answer. > >Ditto. > >Plus I really dislike that you write the word "hijacking". That's not at all >my intention, and /me opening this thread proves it. > >Anyways, let's try to be more productive... I thought it was kind of obvious >why I did things the way I did, but let me try to be more explicit. > >It is my understanding that "pysnmp4" doesn't match "pysnmp-lextudio" released >as version 5.0.20. We could rename the binary as "python3-pysnmp" (ommiting >the "4"), and have a transition package, yes. But I have no confidence that >they are drop-in replacements (I just don't know yet...). > >The packages that I maintain do need the lextudio modules *now* (OpenStack >moves fast, I cannot afford to wait 6 months), so I thought it was faster to >address the current situation first with my uploads, so I can offer a >continuity of what I already packaged (ie: Ironic and other OpenStack stuff). >Though believe me, I want to do the things properly, and I have no intention >of hijacking anyone's work. If someone wants to work on this with me, we can >move the 4 new lextudio packages back in the team, of course. I have already >too many packages under my responsibility, I'd love to have others working on >them. Then I can act on the OpenStack part of things quickly once we agree on >the way to go. > >So let me ask once more the persons involved and/ore volunteering on this: >what's your suggestion? There's actually 2 paths (and yes, I had the 2 paths >in mind before Scott suggested replacing the older packages): > >1/ We get the lextudio packages replace the older packages like Scott >suggested. This would be a transition anyways, since we're moving to version 5 >and there's a year of commits. If we're to do like this, then we need to make >sure that: >- the lextudio replacing packages are staged in experimental first, and look >at the pseudo-excuse >- the reverse dependencies have meaningful autopkgtest, otherwise uploading to >experimental first is pointless, and then 2/ below becomes the best solution > >2/ The other possibility, is what I suggested and envisioned first, by >uploading the lextudio packages: open 9 bugs, and let maintainers switch to >the new packages. This is IMO the safest path, as it wont create any breakage, >though we'd have conflicting packages for a while, which can be annoying. We >got to make sure the transition finishes quickly enough then (meaning, >probably make the bugs RC after some time, so we make sure we can remove the >older pysnmp/asn1 packages before Trixie freeze). > >I don't think 2/ is an inferior way of doing things. I am still convinced that >I did the right way, that uploading the *-lextudio packages was correct, so >that current maintainers of reverse dependencies can at least test and see if >everything goes well with the new packages, without destroying them. I also >continue to have OpenStack packages working this way, and I'm not destroying >reverse dependencies carelessly. > >Please share your thoughts on how to do it, >Cheers, > >Thomas Goirand (zigo) > I think if you propose to maintain these packages as part of the Debian Python Team, then it's not a hijack, but that is not what you are doing. I'd suggest that if you don't like the word, then don't hijack the packages. Perhaps new packages are needed, but it's usual to have the conversation first. Openstack moves fast isn't a good excuse to skip collaboration. Scott K
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
Scott & everyone, On 9/16/23 19:04, Scott Kitterman wrote: It's pretty relevant to your question. If you had instead updated the existing packages from the new upstream, no transition would be needed. I'm not entirely sure that no transition is needed, no. The major version was bumped to version 5, and I have no clue if this represent some incompatibility. This needs to be tested at least (see below). Did you check with the existing maintainers to see what they thought? Hum ... why do you think I've opened this thread? As is usually the case in Debian, I think the answer is you work with the maintainers to figure out the best solution. Ignoring them and hijacking the packages is not the right answer. Ditto. Plus I really dislike that you write the word "hijacking". That's not at all my intention, and /me opening this thread proves it. Anyways, let's try to be more productive... I thought it was kind of obvious why I did things the way I did, but let me try to be more explicit. It is my understanding that "pysnmp4" doesn't match "pysnmp-lextudio" released as version 5.0.20. We could rename the binary as "python3-pysnmp" (ommiting the "4"), and have a transition package, yes. But I have no confidence that they are drop-in replacements (I just don't know yet...). The packages that I maintain do need the lextudio modules *now* (OpenStack moves fast, I cannot afford to wait 6 months), so I thought it was faster to address the current situation first with my uploads, so I can offer a continuity of what I already packaged (ie: Ironic and other OpenStack stuff). Though believe me, I want to do the things properly, and I have no intention of hijacking anyone's work. If someone wants to work on this with me, we can move the 4 new lextudio packages back in the team, of course. I have already too many packages under my responsibility, I'd love to have others working on them. Then I can act on the OpenStack part of things quickly once we agree on the way to go. So let me ask once more the persons involved and/ore volunteering on this: what's your suggestion? There's actually 2 paths (and yes, I had the 2 paths in mind before Scott suggested replacing the older packages): 1/ We get the lextudio packages replace the older packages like Scott suggested. This would be a transition anyways, since we're moving to version 5 and there's a year of commits. If we're to do like this, then we need to make sure that: - the lextudio replacing packages are staged in experimental first, and look at the pseudo-excuse - the reverse dependencies have meaningful autopkgtest, otherwise uploading to experimental first is pointless, and then 2/ below becomes the best solution 2/ The other possibility, is what I suggested and envisioned first, by uploading the lextudio packages: open 9 bugs, and let maintainers switch to the new packages. This is IMO the safest path, as it wont create any breakage, though we'd have conflicting packages for a while, which can be annoying. We got to make sure the transition finishes quickly enough then (meaning, probably make the bugs RC after some time, so we make sure we can remove the older pysnmp/asn1 packages before Trixie freeze). I don't think 2/ is an inferior way of doing things. I am still convinced that I did the right way, that uploading the *-lextudio packages was correct, so that current maintainers of reverse dependencies can at least test and see if everything goes well with the new packages, without destroying them. I also continue to have OpenStack packages working this way, and I'm not destroying reverse dependencies carelessly. Please share your thoughts on how to do it, Cheers, Thomas Goirand (zigo)
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On September 16, 2023 4:48:46 PM UTC, Thomas Goirand wrote: >On 9/15/23 14:03, Scott Kitterman wrote: >> Why did you hijack this from the Python team instead of just working with the >> existing maintainers to update the existing packages from the new upstream >> location? >> >> Scott K > >Thanks for replying to the original question ... :) > >If the current maintainer was interested, they had plenty of time to work on >this (it's been nearly a year that lextudio took over). It doesn't seem to be >the case unfortunately. > >If someone wants to take over my work, please do (and write in this thread >saying you're working on it...), it's not too late. I take care of too many >packages already, I'd love if someone stepped in. > It's pretty relevant to your question. If you had instead updated the existing packages from the new upstream, no transition would be needed. Did you check with the existing maintainers to see what they thought? Were they even aware of the new upstream work (it's happened to me before that I was unaware of such a switch)? As is usually the case in Debian, I think the answer is you work with the maintainers to figure out the best solution. Ignoring them and hijacking the packages is not the right answer. Scott K
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On 9/15/23 14:03, Scott Kitterman wrote: Why did you hijack this from the Python team instead of just working with the existing maintainers to update the existing packages from the new upstream location? Scott K Thanks for replying to the original question ... :) If the current maintainer was interested, they had plenty of time to work on this (it's been nearly a year that lextudio took over). It doesn't seem to be the case unfortunately. If someone wants to take over my work, please do (and write in this thread saying you're working on it...), it's not too late. I take care of too many packages already, I'd love if someone stepped in. Cheers, Thomas Goirand (zigo)
Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On Friday, September 15, 2023 3:38:05 AM EDT Thomas Goirand wrote: > Hi, > > As you may know, the upstream author for pysnmp passed away last year. > As a result, the whole suite was forked by "lextudio". I packaged it, > and the result is this list of source packages: > > python-pyasn1-lextudio > python-pyasn1-modules-lextudio > python-pysmi-lextudio > python-pysnmp-lextudio > > Appart from the OpenStack packages, here's the list of reverse > dependencies for the old python3-pysnmp4 binary package: > > * patator > * pdudaemon > * pysmi > * snimpy > * changeme > * python3-snimpy > * python3-pysnmp4-apps > * python3-pysnmp4-mibs > * snmpsim > > My plan is to file bugs against these packages, asking to transition to > the newer packages. We're just below the threshold for asking > debian-devel about mass bug-filling, so I figured out I would only send > a mail to the Python list. Do you guys approve my plan? Should we make > transition dummy packages? > > Also to Adam Cécile: can you make your pull request against the new > Salsa repository? Why did you hijack this from the Python team instead of just working with the existing maintainers to update the existing packages from the new upstream location? Scott K signature.asc Description: This is a digitally signed message part.
Transitionning to the lextudio pysnmp / pyasn1 ecosystem
Hi, As you may know, the upstream author for pysnmp passed away last year. As a result, the whole suite was forked by "lextudio". I packaged it, and the result is this list of source packages: python-pyasn1-lextudio python-pyasn1-modules-lextudio python-pysmi-lextudio python-pysnmp-lextudio Appart from the OpenStack packages, here's the list of reverse dependencies for the old python3-pysnmp4 binary package: * patator * pdudaemon * pysmi * snimpy * changeme * python3-snimpy * python3-pysnmp4-apps * python3-pysnmp4-mibs * snmpsim My plan is to file bugs against these packages, asking to transition to the newer packages. We're just below the threshold for asking debian-devel about mass bug-filling, so I figured out I would only send a mail to the Python list. Do you guys approve my plan? Should we make transition dummy packages? Also to Adam Cécile: can you make your pull request against the new Salsa repository? Cheers, Thomas Goirand (zigo)
