[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

[Duncan]

Rich Freeman posted on Fri, 17 Jun 2011 07:25:42 -0700 as excerpted:

> On Fri, Jun 17, 2011 at 1:57 AM, Markos Chandras <hwoarang@g.o>
> wrote:
>> Not removing old packages does *NOT* violate the policy.
>
> And this is why nobody likes lawyers.  :)
>
> Leaving around old packages because of a desire to avoid a policy
> doesn't really strike me as an example of exemplary QA either.  There
> are lots of good reasons to keep a few versions of a package in-tree.
> None of them should be used merely as excuses to avoid running the
> "echangelog" command.

Reading a changelog (yes, READING A CHANGELOG!! people actually DO use 
them, and occasionally depend on entries when versions are removed, but 
that's covered territory) at my last update yesterday, something occurred 
to me...

The particular entry in question listed some trivial change in maintained 
ebuilds, then said "Remove old".  There was accordingly a list of a bunch 
of removed versions, along with the versions modified by the update.

What occurred to me in the context of this whole controversy, was that 
not only can devs simply leave old versions for someone else to remove, 
but they can, and routinely do, remove old versions as part of a commit 
changing something in (some of) the remaining ones, as well.

It's worth pointing out that if Mike and others' workflow already 
involves a lot of this, they'd be modifying it very little if they simply 
avoided separate removals.  In fact, in borderline cases where a trivial 
change may not have made it on its own, as it waited for a bigger change 
to come along to be worth doing, the removals combined with the trivial 
change may now trigger the trivial change commit earlier than it would 
have occurred otherwise.

So depending on the individual package and how often minor changes as 
opposed to version removals are necessary, it's entirely possible that 
deliberately abstaining from removal-only commits won't visibly change 
the workflow AT ALL, or that if it does, it's in favor of getting those 
minor changes in faster than they'd otherwise appear.

[Deleted a bunch I 100% agree with.]

> The one thing I hope doesn't come out of this is a Council that is even
> more reluctant to act out of fear of being slapped around by the
> community anytime a developer threatens to quit.

That was worth repeating.  ++

> If we think that tweaking the changelog policy causes pain,
> just wait to see how the git migration goes.

True but scary.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman