| 1 |
Rich Freeman: |
| 2 |
> On Tue, Sep 16, 2014 at 6:18 AM, hasufell <hasufell@g.o> wrote: |
| 3 |
>> Ulrich Mueller: |
| 4 |
>>> |
| 5 |
>>> ChangeLogs are aimed at users |
| 6 |
>> |
| 7 |
>> Did any1 ask them if they care? |
| 8 |
>> |
| 9 |
> |
| 10 |
> I'm sure somebody will reply and say that they care. |
| 11 |
> |
| 12 |
> It still seems like a lot of overhead to me for a very one-off |
| 13 |
> workflow. Maybe if portage automatically output the relevant |
| 14 |
> changelog entries in pretend mode we could pretend that they're news |
| 15 |
> or something like that. Most likely, if you stick something important |
| 16 |
> in the changelog it will be read by maybe 0.1% of our users before |
| 17 |
> emerging the package. Maybe if you're lucky 20% of people running |
| 18 |
> into some kind of breakage will read the changelog after the fact. I |
| 19 |
> imagine that 19.5% of those 20% would check the git log if the |
| 20 |
> changelog didn't exist. |
| 21 |
> |
| 22 |
> If we actually move to a model where many users actually sync their |
| 23 |
> trees from git, then I'd expect the changelogs to be even less useful. |
| 24 |
> After all, git will actually tell you what changed since your last |
| 25 |
> sync. |
| 26 |
> |
| 27 |
|
| 28 |
And git allows you to _properly_ check for changes, because all changes |
| 29 |
are in one history, so you don't have to grep 3+ ChangeLogs (e.g. in |
| 30 |
eclasses, profiles and licenses) in order to know what happened. |
| 31 |
Even easier... related changes might just go in one commit and when you |
| 32 |
look for it you'll also see the other files that have been modified as |
| 33 |
part of a version bump (e.g. a useflag mask or whatever). |
| 34 |
|
| 35 |
The only place I actually look for changes is the gentoo-commits ML |
| 36 |
which is kind of the poor version of a git history. |
Archives