[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Editing RDEPEND without a new revision (again)
From:       Michael Everitt <gentoo () veremit ! xyz>
Date:       2019-10-25 18:20:26
Message-ID: cd046f14-2c0b-f20c-2299-f1f83ed315d7 () veremit ! xyz
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 25/10/19 14:43, Michael Orlitzky wrote:
> On 10/24/19 10:03 PM, Michael Everitt wrote:
>> Forgive my lack of git-fu, but which commit did this? Can we name & sh=
ame
>> the author and committer publicly, and in front of QA, so that this ki=
nd of
>> violation is highlighted to all, and noted for future reference?
>>
> I left it out on purpose. This isn't a one-person problem, and my anger=

> isn't only targeted at the last person who was unlucky enough to do it
> right before I snapped and wrote the email.
>
> This comes up on the -dev list several times a year. We've fought about=

> ecosystems adding dependencies to stable packages via eclass USE flags.=

> We fight about the revision policy in the devmanual. We've been fightin=
g
> about dynamic dependencies in the package manager for 10+ years. The
> portage team basically quit once over this. A few years later we fought=

> about it again and finally turned them off, but the commit got reverted=

> when users complained that developers were constantly breaking things.
> That contributed to a fork of the package manager...
>
> Point is, it's not a new thing. And it's a huge waste of time for
> everyone involved. It's also simple to avoid. Just make a new revision
> when you change something. You shouldn't be changing stable ebuilds
> *anyway*, but if you're already going to violate that policy, it doesn'=
t
> do any more harm to move it to -r1 in the process.
>
I think the policy on this in the devmanual/etc is a little too vague. My=

impression is that changes to an ebuild which make a material difference =
to
the files installed, should definitely be rev-bumped, but certain other
changes, and bug fixes, don't need this as they result in missing
functionality being rectified/restored.

Personally, because I have yet to see any revbumps beyond about -r5 I don=
't
think we would have a problem in reality if everyone bumped the revision
*regardless* on *any* change, and we dealt with the consequences *that*
way. When/If we get to -r99 on a package perhaps we can revisit this topi=
c,
and why so many updates are necessary to a "stable release" (!).

I sense that the problem boils down to a lack of 'warm bodies' and people=

making poor decisions or lazy decisions because of a need to move somethi=
ng
forward, without properly considering the wider implications of their
'shortcuts'. This isn't a problem likely to be solved soon, however, and
becomes a meta-problem of another sort.

However, I'm noting a number of quite angry posts arriving on the public
lists, because we have Hard Problems that are creating issues for those
attempting to contribute. I think that if you find you're reaching this
threshold, perhaps its time for you to take a break, get some air, and
consider whether you have the resources to fix the underlying problem, or=

whether you can tolerate the status quo. Nothing is going to change fast,=

and will likely require a lot of compromises on the way. That said, there=

is no harm in trying new things, and accepting that some ideas may have t=
o
be reversed. But let's not continue to throw too many daggers across the
lists, as it doesn't do anybody any favours, beyond venting frustrations.=


</my2cents>



["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]