1 |
В Вск, 12/09/2010 в 17:01 +0300, Mart Raudsepp пишет: |
2 |
> On L, 2010-09-11 at 23:18 +0300, Petteri Räty wrote: |
3 |
> > On 09/11/2010 11:14 PM, Ryan Hill wrote: |
4 |
> > > On Sat, 11 Sep 2010 22:10:51 +0300 |
5 |
> > > Petteri Räty <betelgeuse@g.o> wrote: |
6 |
> > > |
7 |
> > >>> + |
8 |
> > >>> +*hachoir-parser-1.3.4 (10 Sep 2010) |
9 |
> > >>> + |
10 |
> > >>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis <arfrever@g.o> |
11 |
> > >>> + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild: |
12 |
> > >>> + Version bump. |
13 |
|
14 |
> That's why I tend to spend the time to briefly summarize what the |
15 |
> version bump actually improves for users by upstream (see my gstreamer |
16 |
> bumps for example). I spend the time once, thousands of users get the |
17 |
> information handily with emerge --changelog and the like, without |
18 |
> digging into /usr/share/doc/*/NEWS* _after_ upgrading and already having |
19 |
> had to do the work to decide if its important upgrade for them or not |
20 |
> (in case of conservative upgrading). |
21 |
|
22 |
This ether should became common practice or it'll stay useless and even |
23 |
harmful. It's hard to anticipate upstream NEWS in our ChangeLogs since |
24 |
very few packages do this and as I see logic behind our ChangeLogs they |
25 |
are intended for changes in our package (ebuilds), not for upstream |
26 |
changes. At the same time this additional information makes our |
27 |
ChangeLogs harder to read and find out what was changed in ebuild and |
28 |
why. That said I think it's really useful to have this information with |
29 |
rsync but it's better come with different solution instead of utilizing |
30 |
package's ChangeLogs... |
31 |
|
32 |
-- |
33 |
Peter. |