[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#986213: marked as done (RM: ansible/2.9.16+dfsg-1.1)

Your message dated Sun, 16 May 2021 21:03:19 +0200
with message-id <YKFsd7Hm7AaQwYDl@ramacher.at>
and subject line Re: Bug#986213: RM: ansible/2.9.16+dfsg-1.1
has caused the Debian Bug report #986213,
regarding RM: ansible/2.9.16+dfsg-1.1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
986213: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986213
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: rm
X-Debbugs-Cc: debian@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

--- End Message ---
--- Begin Message --- 
On 2021-04-08 10:40:50 +0200, Paul Gevers wrote:
> 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.

ansible 2.10.x is now available in bullseye. Closing this bug report.

Cheers
-- 
Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: