Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Control: tags -1 wontfix Hi, On 08-04-2021 09:54, Christian Kastner wrote: > On 01.04.21 10:49, Raphael Hertzog wrote: >> Shipping bullseye without a core system administration tool like ansible >> is not something that we should do. Our users are the clear losers of this >> situation (and thus Debian as a whole).> >> Graham, can you please reconsider your position in #984557? Maybe have >> some broader discussion within the release team on whether an exception >> is to be made? >> >> I know exceptions are the doors to more arbitrary unblock requests but >> in general I have the feeling that we are too strict with such requests. > I would also greatly appreciate if a alternative solutions could be > discussed. > > Mistakes have been made and the policy is clear on the consequences. > However, from a user's perspective, strictly adhering to policy here > would appear to have an even bigger downside, in the sense that a 2.10.x > ansible of at least certain quality would be better than no ansible. > > If there is room for discussion and if there is any way that I can help > with this effort (especially with testing), please let me know. There's a way. ansible is not a key package, so, with passing (non-trivial) autopkgtest and src:ansible-base merged into src:ansible you have a way to carry this into bullseye. Yes, not conforming our freeze policy, but we won't block you. However, we *also* set freeze rules to make the release process manageable for the release team. ansible clearly missed to follow the rules. Making an exception is opening the doors for much more request for an exception that we just can't handle appropriately. We'll not act on this RM now as there's already the autoremoval process in place for bug 983140 which ensure that maintainers of reverse dependencies are warned and can help out if they want. Can we please stop this discussion? It's draining our energy. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
On 01.04.21 10:49, Raphael Hertzog wrote: > Shipping bullseye without a core system administration tool like ansible > is not something that we should do. Our users are the clear losers of this > situation (and thus Debian as a whole).> > Graham, can you please reconsider your position in #984557? Maybe have > some broader discussion within the release team on whether an exception > is to be made? > > I know exceptions are the doors to more arbitrary unblock requests but > in general I have the feeling that we are too strict with such requests. I would also greatly appreciate if a alternative solutions could be discussed. Mistakes have been made and the policy is clear on the consequences. However, from a user's perspective, strictly adhering to policy here would appear to have an even bigger downside, in the sense that a 2.10.x ansible of at least certain quality would be better than no ansible. If there is room for discussion and if there is any way that I can help with this effort (especially with testing), please let me know. Best, Christian
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Hi Bas, On 31/03/2021 20:20, Sebastiaan Couwenberg wrote: > On 3/31/21 7:30 PM, Lee Garrett wrote: >> Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried >> getting the unit tests from 2.9.16 to work with python 3.9, but I had to give >> up. I don't feel comfortable with maintaining such a large package over the >> lifecycle of bullseye without unit tests, official py3.9 support, and >> security >> support running out in a few months, so please remove ansible from bullseye. > > Shipping bullseye without ansible is going to make many users unhappy. > > Will you actively maintain the package in bullseye-backports instead? Up until now Pierre-Elliott Bécue has provided versions for backports, and I'm happy to regulary upload ansible to backports, too. However, ansible has a somewhat active deprecation cycle for modules/features, meaning that backports users will be forced to adapt their playbooks and roles with every feature release to avoid breakage. Adding to this, there have been times where ansible in testing/unstable was broken for a while due to moving python packages (the month long breakage due to jinja2 which broke templating in many ansible modules comes to mind). So I don't think those users who have previously depended on ansible from stable will be happy with using ansible from backports. I can only say that I screwed up the migration process due to making a few wrong assumptions about the finer details of the freeze process, and I'm somewhat embarrassed about causing the release team additional work. I had been working on packaging ansible 2.10 since December, and my intention was to get ansible 2.10 into bullseye. Had I known what I know now, I would have set my personal deadline differently, or raised the issue with the release team earlier. Those things said, I agree with Raphaël that ansible 2.10 is a good fit for bullseye, and I'd maintain it over the life cycle of our next release if the release team chooses to unblock it. Kind regards, Lee
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Hello, On Wed, 31 Mar 2021, Lee Garrett wrote: > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried > getting the unit tests from 2.9.16 to work with python 3.9, but I had to give > up. I don't feel comfortable with maintaining such a large package over the > lifecycle of bullseye without unit tests, official py3.9 support, and security > support running out in a few months, so please remove ansible from bullseye. I know everybody is trying to do their best, in one side with ansible maintainance and on the other side with release management but this outcome is really not desirable. Shipping bullseye without a core system administration tool like ansible is not something that we should do. Our users are the clear losers of this situation (and thus Debian as a whole). Graham, can you please reconsider your position in #984557? Maybe have some broader discussion within the release team on whether an exception is to be made? I know exceptions are the doors to more arbitrary unblock requests but in general I have the feeling that we are too strict with such requests. It is important for maintainers of software that don't have intractable reverse dependencies to be able to push the last upstream release that can be reallistically supported for 5 years even when the release schedule is not 100% aligned with Debian (IMO sometimes we should even encourage the packaging of release candidates with the right to push the final releases through a stable update soon after). And when the upstream release schedule is not at fault, but something else is at fault, instead of punishing the maintainer that failed to act on time, maybe have some "recovery" mechanism where X DD can support the fact that having the (updated) package is important. By doing so they would sign up to help if anyhing goes wrong with this update during the release process. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
On Wed, Mar 31, 2021 at 08:20:09PM +0200, Sebastiaan Couwenberg wrote: > On 3/31/21 7:30 PM, Lee Garrett wrote: > > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried > > getting the unit tests from 2.9.16 to work with python 3.9, but I had to > > give > > up. I don't feel comfortable with maintaining such a large package over the > > lifecycle of bullseye without unit tests, official py3.9 support, and > > security > > support running out in a few months, so please remove ansible from bullseye. > > Shipping bullseye without ansible is going to make many users unhappy. > > Will you actively maintain the package in bullseye-backports instead? And always remember, you can only update ansible in bpo with the version that is in testing. Alex
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
On 3/31/21 7:30 PM, Lee Garrett wrote: > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried > getting the unit tests from 2.9.16 to work with python 3.9, but I had to give > up. I don't feel comfortable with maintaining such a large package over the > lifecycle of bullseye without unit tests, official py3.9 support, and security > support running out in a few months, so please remove ansible from bullseye. Shipping bullseye without ansible is going to make many users unhappy. Will you actively maintain the package in bullseye-backports instead? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#986213: RM: ansible/2.9.16+dfsg-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: deb...@rocketjump.eu Hi, Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried getting the unit tests from 2.9.16 to work with python 3.9, but I had to give up. I don't feel comfortable with maintaining such a large package over the lifecycle of bullseye without unit tests, official py3.9 support, and security support running out in a few months, so please remove ansible from bullseye. Thanks in advance, Lee
