Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: app-office/calcurse/

[Rich Freeman]

On Fri, Mar 13, 2020 at 1:29 AM Chí-Thanh Christopher Nguyễn
<chithanh@g.o> wrote:
>
> Alec Warner schrieb:
> > On Thu, Mar 12, 2020 at 9:54 AM Andreas K. Huettel <dilfridge@g.o
> > <mailto:dilfridge@g.o>> wrote:
> >
> >     Someone needs to grow up here.
> >
> >
> > Meh, to me (someone who can't commit to ::gentoo) I have a few concerns here.
> > First, I don't see a lot of QA reverts on the gentoo-dev list. Is it common
> > practice to post reverts publicly? Second, I'm not aware that we would revert
> > for things like this. Most of the items you mention look fairly minor (maybe
> > the python comment looks impactful?) Why can't we fix these items in a future
> > commit, rather than revert? What did Patrice's commit break?
>
> If the issues are so serious that we have to prevent any breakage/regressions
> from reaching users, I guess an alternative response would have been to
> p.mask the offending new ebuild. Unless the commit caused some tree-wide
> breakage which I can't see here however.

Don't really want to comment on where the line should have been drawn
on this particular case, but the idea of reverting commits doesn't
seem particularly abhorrent, and certainly commits that don't create a
new ebuild couldn't be addressed with masking unless we want to impact
end users.

It seems like the drama here is mostly about how this ended up on the
lists vs just being a discussion between QA and the committer/etc.
Reading between the lines I'm not sure if it was ever intended to be
on the list at least initially.

If this was intended for public consumption it probably wouldn't hurt
to note why (hey, we're singling out this commit because it has this
error we've been seeing a lot of lately and you can see how this sort
of thing could sneak in...).  Otherwise it just seems like it causes
drama without actually achieving the desired impact.

-- 
Rich