Re: Suggesting change in DPT policy
+1 for this policy change too, I went through the same hurdles & thinking progress, but it's much fresher in py head because I m only contributing to DPT since 1/1/2024, doing exactly what I said I would do on my membership application mail. Before this talk happened I would not have recommended anybody to join the team. I m glad it is being resolved. Greetings Le dim. 3 mars 2024, 00:30, Emmanuel Arias a écrit : > +1 for this DPT policy change. > > When I started to contribute I received these kind of comments that made > me think if I could really start contributing to Debian. As time went by, > I learned to read first who is the maintainer of the package before read > the bug reported, no matter if the package is (apparently) under the DPT > umbrella. > -- > cheers, > Emmanuel Arias
Re: Suggesting change in DPT policy
On 3/2/24 21:29, Andreas Tille wrote: sphinxtesters (0.2.3-4) unstable; urgency=medium * Revert attempt by a rogue developer to hijack this package -- Sandro Tosi Sun, 14 Jan 2024 01:25:23 -0500 I wonder how the attribute 'rogue' is supported by the discussion above, nor where the intention to hijack the package is inferred from. On 3/2/24 21:29, Andreas Tille wrote: > In my view, this crosses the line It does cross the line. On 3/2/24 21:29, Andreas Tille wrote: > and I am grateful to have been part of teams where such > incidents were not tolerated. IMO, this shouldn't be tolerated in this team either. Even if Sandro is doing awesome work in the team. I'm btw hereby sending warm thanks to Sandro for his huge work that I very much respect, despite all of this thread and other events. I remember the huge amount of uploads when we removed Python 2 from Debian, tirelessly doing things on the correct order, in a technically near perfect way, when I didn't dare to touch this puzzle ... But it's not an excuse to create a toxic atmosphere. This has been hashed multiple times in many areas in Debian: doing a lot of (good) packaging work doesn't grant anyone the right to disrespect others. On 3/2/24 22:11, Scott Kitterman wrote: > I understand your argument to be: > > I did not follow the team policy and didn't care about the other > people involved to rectify the error. They were upset about this, so > clearly this mess is all their fault. We should change the rules so > that I won't have been wrong. > > I absolutely do not know how to respond to that level of entitlement. > Hopefully I have misunderstood what you are trying to communicate? I strongly do not agree with the above. You wrote it as if what triggered Sandro was Andreas not willing to "rectify the error". That's not what's happened: Sandro was harsh with Andreas to begin with, and that is the reason Andreas wasn't motivated to "fix" what he saw as cosmetic metadata in d/control for a weird policy of packages "half belonging to the team", rather than an important bugfix. The way you wrote it, it feels like you're only blaming Andreas for what he did: I wouldn't do that, but that is ok, it's your opinion. But it feels you're saying his bad behavior is an excuse for changing the policy, and that, I do not agree, this isn't what's happening. We should change the policy, but that's not so that Andreas "won't have been wrong". It is because at least 3 persons (including myself and Andreas) in this thread missed the point we're willing to remove. It is because having a package "half in the team" doesn't make sense. And it is because of many other points we already discussed in this thread. I don't understand why are you making such a shortcut, when you already agreed to these other points. I'm sure you also notice part of this thread is also about Sandro's communication style. My view (which I believe is shared by others) is that Andreas is a nice person that deserves respect. It's unfortunate that the sphinxtesters uploads were the tiger of this policy change, though we need to take a step back, and understand the policy was bad anyways. So indeed, we have read the same things, but have very different perspectives. None of them are completely wrong, we simply have very different feelings. And despite all of this, it's a good thing you also agree to get rid of this part of this policy. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 3/2/24 23:09, Christian Kastner wrote: Not going to name names, but I've seen this with packages I've worked on: I put a lot of effort into cleaning things up, making things robust, getting docs to build, tests to pass, collaborating with upstream, fixing reverse dependencies, and then someone spends a few minutes to upload a new version with total disregard for what the other maintainer(s) were doing. Things like "oh, documentation doesn't build anymore, I'll just disable it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll just disable them", rather than looking into the regression. "Oh, my upload triggered a transition, I'm no longer interested in this". (This are all things that have happened to me.) All that stuff is then left for others to clean up. And if one is unlucky enough, this doesn't just cause work for the package, but for all reverse dependencies. I've seen careless uploads and mistakes too (and done my part of bad uploads a few times as well). There's one thing that can save us all from this: a lot of autopkgtest in every package, and uploading packages with a lot of reverse dependencies to Experimental first, then fixing the excuse page before an upload to unstable. I did this for flask 2.2 and werkzeug, and saw Carsten Schoenert doing the same with flask 3. It's a proven safe workflow. For this, you don't really need to know the said transitioning package. I very much hope we all move into this direction, even if that means more work and follow-up with reverse dependency maintainers. Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On 3/3/24 00:37, Christian Kastner wrote: For example, I also often skip tests -- it's just that I do it under conditions that I'm happy to defend (cause isolated, reported upstream, etc.), but others may not be aware of that. There are many cases where skipping tests is ok. As you wrote, when reported upstream, and when the thing that's broken is the test itself (but the functionality is not broken). The best practice is to document somewhere in the package (in d/rules?) why it's been disabled. I have to admit I often don't do that extra documentation work myself though (though mostly on packages I maintain alone, for OpenStack for example). Unfortunately, when dealing with a large amount of packages, at some point, one may be tired and skip some of the documentation/reporting upstream work, because there's so much to do... I have to admit that sometimes, I just do the quick fix by myself in debian/ptaches, and don't have enough energy to report or fix upstream, thinking that upstream will hit the (python 3.x for example) bug themselves, and fix anyways. :/ Cheers, Thomas Goirand (zigo)
Re: Suggesting change in DPT policy
On March 3, 2024 6:12:09 AM UTC, Andreas Tille wrote: >Hi Christian, > >Am Sat, Mar 02, 2024 at 11:48:57PM +0100 schrieb Christian Kastner: >> On 2024-03-02 23:11, Andreas Tille wrote: >> > I'm curious why you believe I didn't care. I likely would have reverted >> > my change if I didn't have more urgent matters to attend to. >> > Re-uploading a package just to revert the Maintainer and Uploader is >> > lower on my priority list than fixing other RC bugs. >> >> To add another perspective: what if reverting is not about "fixing" the >> package again, but a courtesy or sign of respect towards the person that >> was upset by this action. Wouldn't that change the priority entirely? > >Thanks for pointing this out. I agree I failed here. I hope to not >fail the same way in future again since in this very case I can't fix >this any more. > >The lesson I hopefully learned now is that this kind of failures seems >to put other arguments I gave for a policy change in the shadow at least >for those team members I would love to reach for a constructive >discussion. Thanks both for your response and for Christian for doing a much better job than I managed trying to communicate this. Scott K
Re: Suggesting change in DPT policy
On 2024-03-03 17:32, Thomas Goirand wrote: > On 3/3/24 00:37, Christian Kastner wrote: >> For >> example, I also often skip tests -- it's just that I do it under >> conditions that I'm happy to defend (cause isolated, reported upstream, >> etc.), but others may not be aware of that. > > There are many cases where skipping tests is ok. As you wrote, when > reported upstream, and when the thing that's broken is the test itself > (but the functionality is not broken). > > The best practice is to document somewhere in the package (in d/rules?) > why it's been disabled. I have to admit I often don't do that extra > documentation work myself though (though mostly on packages I maintain > alone, for OpenStack for example). I agree and have no issue with this. On the contrary, I consider this proper. I do it myself all the time. I've also temporarily disabled doc builds (for some transition). But I make note of these things in d/rules (or wherever it makes sense), and/or file bugs, etc. In the case I'm talking about, this was more of just disabling large parts (or maybe it was all, I don't remember) of tests with no attempt at even looking what the problem was. I should have framed my complaints better. I don't have any issue at all with workarounds or pragmatism when they're implemented somewhat carefully and/or reasonably, like the test-skip-handling you describe above. Best, Christian
Help with the Cython 3.0 failures in Ceph
Hi, I'm long overdue for an upload of Ceph 18.2.x in Unstable. I'm currently stuck with the below build failure: Error compiling Cython file: ... """ name = cstr(name, 'name') cdef: rados_ioctx_t _ioctx = convert_ioctx(ioctx) char *_name = name librbd_progress_fn_t _prog_cb = &no_op_progress_callback ^ rbd.pyx:760:44: Cannot assign type 'int (*)(uint64_t, uint64_t, void *) except? -1' to 'librbd_progress_fn_t'. Exception values are incompatible. Suggest adding 'noexcept' to type 'int (uint64_t, uint64_t, void *) except? -1'. THere's like a dozen of these in the build log, always with the same thing, with the same kind of assignation of a reference the op progress callback address. I tried a few dumb things, but can't find out what to do to fix. Does anyone know what's going on, and how I can patch Ceph to have rbd.pyx to build? Cheers, Thomas Goirand (zigo)
Re: Help with the Cython 3.0 failures in Ceph
On 3/3/24 21:08, Thomas Goirand wrote: Hi, I'm long overdue for an upload of Ceph 18.2.x in Unstable. I'm currently stuck with the below build failure: Error compiling Cython file: ... """ name = cstr(name, 'name') cdef: rados_ioctx_t _ioctx = convert_ioctx(ioctx) char *_name = name librbd_progress_fn_t _prog_cb = &no_op_progress_callback ^ rbd.pyx:760:44: Cannot assign type 'int (*)(uint64_t, uint64_t, void *) except? -1' to 'librbd_progress_fn_t'. Exception values are incompatible. Suggest adding 'noexcept' to type 'int (uint64_t, uint64_t, void *) except? -1'. THere's like a dozen of these in the build log, always with the same thing, with the same kind of assignation of a reference the op progress callback address. I tried a few dumb things, but can't find out what to do to fix. Does anyone know what's going on, and how I can patch Ceph to have rbd.pyx to build? Cheers, Thomas Goirand (zigo) Sorry for the noise, looks like I found a commit upstream (in the master branch) that fixes the issue. Cheers, Thomas Goirand (zigo)
