| 1 |
On 06/17/2011 09:18 PM, Duncan wrote: |
| 2 |
> Mike Frysinger posted on Fri, 17 Jun 2011 12:44:52 -0400 as excerpted: |
| 3 |
> |
| 4 |
>> On Friday, June 17, 2011 11:31:43 Duncan wrote: |
| 5 |
>>> It's worth pointing out that if Mike and others' workflow already |
| 6 |
>>> involves a lot of this, they'd be modifying it very little if they |
| 7 |
>>> simply avoided separate removals. In fact, in borderline cases where a |
| 8 |
>>> trivial change may not have made it on its own, as it waited for a |
| 9 |
>>> bigger change to come along to be worth doing, the removals combined |
| 10 |
>>> with the trivial change may now trigger the trivial change commit |
| 11 |
>>> earlier than it would have occurred otherwise. |
| 12 |
>> |
| 13 |
>> if you look at my commit behavior, this is exactly the sort of thing i |
| 14 |
>> avoid. |
| 15 |
>> my cvs commits are pretty logically clean to the point where importing |
| 16 |
>> into git would result in nice behavior. which means i make one commit |
| 17 |
>> to remove, one commit to fix a specific bug, one commit to version bump, |
| 18 |
>> etc... |
| 19 |
> |
| 20 |
> Good point and exactly the behavior best on git as it makes for far |
| 21 |
> easier and more effective git bisects when necessary. Unfortunately (for |
| 22 |
> oh so many reasons!!), Gentoo's main tree and workflow isn't "git-ified" |
| 23 |
> yet. But I can certainly commend someone whose personal standards demand |
| 24 |
> that same one-thing-and-one-thing-only commit separation, modern dVCS or |
| 25 |
> not. |
| 26 |
> |
| 27 |
> Meanwhile, case-in-point of why changelogging removals matters. My last |
| 28 |
> post was to a kde list, helping someone trying to build kdelibs on RHEL. |
| 29 |
> He was missing the libdbusmenu-qt dependency, which I was able to point |
| 30 |
> out, and I went on to describe the version info. Gentoo's kdelibs-4.6.4 |
| 31 |
> dependency for that library is >= libdbusmenu-qt-0.3.2, but I have 0.8.2 |
| 32 |
> installed. |
| 33 |
> |
| 34 |
> Because the information was in the changelog, I was able to tell him that |
| 35 |
> my current 0.8.2 was introduced in April, the other available version on |
| 36 |
> gentoo, 0.6.2, was introduced in Sept. 2010, there was a version jump (at |
| 37 |
> least on gentoo) between 0.3.5 (from June, 2010) and 0.6.2, and the 0.3.2 |
| 38 |
> that's gentoo's minimum requirement was introduced on Gentoo in April |
| 39 |
> 2010 and removed in Sept, 2010. So even 0.3.2 isn't much more than a |
| 40 |
> year old (on RHEL 5 it's likely an upgrade!), but was already considered |
| 41 |
> old enough to remove ~6 months later. |
| 42 |
> |
| 43 |
> That information on 0.3.2 removal wouldn't have been available to me (at |
| 44 |
> least not without making a huge project of it, checking Gentoo's viewCVS |
| 45 |
> logs on the web) had someone not put it in the changelog. Users DO find |
| 46 |
> that information useful and there have been quite a number of times I |
| 47 |
> personally have found it useful in helping people not necessarily on |
| 48 |
> gentoo (tho I believe I've spotted hugely outdated based on changelogs |
| 49 |
> versions of packages on gentoo-users systems, too), but in other parts of |
| 50 |
> the FLOSS community. |
| 51 |
> |
| 52 |
> Having that information not available locally on my system, either by |
| 53 |
> changelog as now, or by git whatchanged, if users finally get access to |
| 54 |
> direct git-pull once the main tree is git-upgraded, would be a serious |
| 55 |
> regression. |
| 56 |
> |
| 57 |
|
| 58 |
I'm sorry, but honestly, did you have a point in there somewhere? |
Archives