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: debian/watch: How to watch version tags and what to capture?
Hello, "normal" users - like me - should use stable - like I do - neither testing nor unstable. So some days delay are ok for me, because it takes much more time until a new upstreanḿ version will reach stable (via backports) - if all. Kind regards Michael, who is also not a native speaker.
Re: debian/watch: How to watch version tags and what to capture?
On Sun, Sep 17, 2023 at 06:56:58AM +, c.bu...@posteo.jp wrote: > I assume I'm not the first one encountered it. Is there a bug tracker I > can check or report that Issue? The footer of every tracker page says "Report problems to the tracker.debian.org pseudo-package in the Debian BTS."
Re: debian/watch: How to watch version tags and what to capture?
On Sun, Sep 17, 2023 at 11:32:31AM +, c.bu...@posteo.jp wrote: > > i get your point that you want the information fast, but it seems you > > are just using some arbitrary constraint that fits your personal need. > > it appears that for "most" Debian maintainers a lag of "1 or 2 days" > > I'm not a Debian maintainer. [...] > Because of my watch-file problem. The tracker uses watch files provided by Debian maintainers.
Re: debian/watch: How to watch version tags and what to capture?
Dear IOhannes, thanks for your reply and your thoughts. On 2023-09-17 11:11 IOhannes m zmölnig (Debian/GNU) wrote: > i get your point that you want the information fast, but it seems you > are just using some arbitrary constraint that fits your personal need. > it appears that for "most" Debian maintainers a lag of "1 or 2 days" I'm not a Debian maintainer. I do use that tracker page as an upstream maintainer. And I do use it as a usual user because the "usual" package pages (e.g. https://packages.debian.org/source/sid/backintime) are IMHO less comfortable to read. I like the dashboard character of the tracker. But I always try to take into account that there are a lot of different "flavors of users", especially in the context of our world ruling Debian. ;) I'm not the benchmark here. My benchmark is always all users in the world. Of course this is unrealistic. But it can be a goal. I mean, no matter that it is impossible to reach that goal, trying to reach it can improve Debian. > I personally feat at unease when people call other people > "unprofessional" like this. > such accusations just feel... unprofessional :-) English as not my native language but to my understanding when scrolling back to my own messages I never addressed a person or group of person with that word. I addressed the feeling of users. I tried to be emphatic to "my" users and imagined that they would experience it as unprofessional. Please keep calm and step one step back. We all do love Debian and FOSS and most of us invest their free time in it. But please don't take everything personal. We may have different goals in context of usability and quality. But that is what the community is about. We need to talk about such things and evolve. The none-free-firmware thing is a very good (positiv!) example of that process no matter how the decision was at the end. How Debian "discuss" things and comes to conclusions is one thing that makes it so special compared to other distros and FOSS projects. > the tracker's audience is really Debian maintainers, not users. We have no proof for that and I would disagree here. > i don't know what the average user expects Me, too. I don't know. But I try to be empathic to them and also try to keep Debian in a good light to them. > in any case: why do *you* think it of utmost importance to be > informed of a new release on this very page? Because of my watch-file problem. First I thought the watch file is buggy and I invested time to understand what the problem is with it. In the end it was not buggy and I burned time. Kind Christian
Re: debian/watch: How to watch version tags and what to capture?
Dear Étienne, On 2023-09-17 10:53 Étienne Mollier wrote: > $ reportbug tracker.debian.org thanks for pointing this out. Sometimes it is to easy. I am not new to Debian but always forget about "pseudo packages".
Re: debian/watch: How to watch version tags and what to capture?
On 9/17/23 10:41, c.bu...@posteo.jp wrote: Hello, maybe it depends on my non-nativ English that I'm not able to make myself clear. On 2023-09-17 09:56 Mechtilde Stehmann wrote: What do you expect? As I told. Information just in time. Within in a delay of 1 or 2 hours the tracker/dashboard should inform about the new release. hmm. how is "1 or 2 hours" more *just in time* than "1 or 2 days"? i get your point that you want the information fast, but it seems you are just using some arbitrary constraint that fits your personal need. it appears that for "most" Debian maintainers a lag of "1 or 2 days" is just as well (i assume that it is indeed "most" maintainers, as I don't see many complaints; for my *personal* workflow i'm very sure that I do not care to be informed about whether a new release has been made withing the last 2 hours, as I pretend that I like to let the dust settle a bit before starting *my* work). If this is not possible because of technical reasons (server load, etc) then indicate exactly that with a timestamp to make the reader able to validate the information in time. i find the suggestion to add a timestamp on when a given piece of information was updated last in the tracker very useful. possibly as a mouse-over or somesuch, in order to not clutter the already rather full page with even more information that is *usually* not important at all. What do you mean is unprofessional? That the information the "Debian system" is out dated. I personally feat at unease when people call other people "unprofessional" like this. such accusations just feel... unprofessional :-) Try to step into the role of a (new) user or a possible contributor. the tracker's audience is really Debian maintainers, not users. i don't know what the average user expects, but I assume that they are good enough with the information about what Debian actually *ships* (as in: what is packaged; and more likely: what is packaged in Debian/stable or even Debian/testing, and less so Debian/unstable) rather than whether "Debian" has been made aware that there is a new release minutes after it has been made available to the public. as for Debian maintainers: if they need super-short notice of a new package, then I do not see why they cannot track upstream themselves. after all, d/watch files tend to be buggy as well and give false information (or: upstream decided to switch to some new release scheme which simply breaks the existing d/watch) making them only so useful. in any case: why do *you* think it of utmost importance to be informed of a new release on this very page? Most of the maintainers are volunteers and work on packaging in their free time. Why do we have to increase the volume of the list with that topic? Can we just discuss this on an issue tracker about the tracker? ;) fair enough. however, it seems i cannot find your bug report (i checked both the BTS and your emails, but there is no indication of any existing bug report) gcmas IOhannes
Re: debian/watch: How to watch version tags and what to capture?
Hello, c.bu...@posteo.jp, on 2023-09-17: > Why do we have to increase the volume of the list with that topic? Can > we just discuss this on an issue tracker about the tracker? ;) > Isn't this what a tracker is for? Bugs against the package tracker system can be reported against the pseudo package "tracker.debian.org" in the bug tracker system[0] using: $ reportbug tracker.debian.org You can see whether there could be a possibly duplicate issue on the corresponding web page[1]. [0]: https://bugs.debian.org [1]: https://bugs.debian.org/tracker.debian.org Hope this helps, -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Re: debian/watch: How to watch version tags and what to capture?
Hello, maybe it depends on my non-nativ English that I'm not able to make myself clear. On 2023-09-17 09:56 Mechtilde Stehmann wrote: > What do you expect? As I told. Information just in time. Within in a delay of 1 or 2 hours the tracker/dashboard should inform about the new release. If this is not possible because of technical reasons (server load, etc) then indicate exactly that with a timestamp to make the reader able to validate the information in time. > What do you mean is unprofessional? That the information the "Debian system" is out dated. Try to step into the role of a (new) user or a possible contributor. > Most of the maintainers are volunteers and work on packaging in their > free time. Why do we have to increase the volume of the list with that topic? Can we just discuss this on an issue tracker about the tracker? ;) Isn't this what a tracker is for? I also do this in my free time and try to improve Debian and not only my own workflow.
Re: debian/watch: How to watch version tags and what to capture?
Hello Christian Am 17.09.23 um 09:46 schrieb c.bu...@posteo.jp: Dear Felix, thanks for the reply. On 2023-09-17 09:13 Felix Zielcke wrote: Tracker needs a bit of time to update all the infos shown. 1-2 days aren't unusual and not directly a bug in it. Is there a bug tracker for the tracker? The term "tracker" indicates just in time and not two days. A minimal improvement would be to give a timestamp at the tracker site to indicate the last update of all the information shown. I do think in interest of the Debian project. I assume it feels unprofessional to users if things like this happens. What do you expect? This is a dashboard to inform maintainer about new version. What do you mean is unprofessional? Most of the maintainers are volunteers and work on packaging in their free time. If the update interval can not be increased then it should be more transparent. Kind Christian Regards -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature.asc Description: OpenPGP digital signature
Re: debian/watch: How to watch version tags and what to capture?
Hello Christian Am 17.09.23 um 09:46 schrieb c.bu...@posteo.jp: Dear Felix, thanks for the reply. On 2023-09-17 09:13 Felix Zielcke wrote: Tracker needs a bit of time to update all the infos shown. 1-2 days aren't unusual and not directly a bug in it. Is there a bug tracker for the tracker? The term "tracker" indicates just in time and not two days. A minimal improvement would be to give a timestamp at the tracker site to indicate the last update of all the information shown. I do think in interest of the Debian project. I assume it feels unprofessional to users if things like this happens. What do you expect? This is a dashboard to inform maintainer about new version. What do you mean is unprofessional? Most of the maintainers are volunteers and work on packaging in their free time. If the update interval can not be increased then it should be more transparent. Kind Christian Regards -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature.asc Description: OpenPGP digital signature
Re: debian/watch: How to watch version tags and what to capture?
Dear Felix, thanks for the reply. On 2023-09-17 09:13 Felix Zielcke wrote: > Tracker needs a bit of time to > update all the infos shown. 1-2 days aren't unusual and not directly a > bug in it. Is there a bug tracker for the tracker? The term "tracker" indicates just in time and not two days. A minimal improvement would be to give a timestamp at the tracker site to indicate the last update of all the information shown. I do think in interest of the Debian project. I assume it feels unprofessional to users if things like this happens. If the update interval can not be increased then it should be more transparent. Kind Christian
Re: debian/watch: How to watch version tags and what to capture?
Am Sonntag, dem 17.09.2023 um 06:56 + schrieb c.bu...@posteo.jp: > > OK, than what is about tracker.debian.org ? Then there must be a BUG? > I assume I'm not the first one encountered it. Is there a bug tracker > I > can check or report that Issue? > > It is really frustrating when simple things like this do not work. > 1.4.0 was just released yesterday. Tracker needs a bit of time to update all the infos shown. 1-2 days aren't unusual and not directly a bug in it. Now it shows the new upstream version.
