| 1 |
On 04/05/2010 10:13 PM, Nirbheek Chauhan wrote: |
| 2 |
> * Proposed is to generate ChangeLogs from git commits on the rsync |
| 3 |
> server side when metadata generation is done |
| 4 |
> - Scripts to do this already exist[1] |
| 5 |
|
| 6 |
I haven't seen this discussed, so I'm going to toss this out there and duck: |
| 7 |
|
| 8 |
Why not just get rid of the in-tree Changelogs entirely? The scm logs |
| 9 |
already document this information, so why have it in a file? |
| 10 |
|
| 11 |
It seems like the main purpose for it is for end-users to have some idea |
| 12 |
what changed in an ebuild. However, in my experience the upstream |
| 13 |
changes are far more impactful than the ebuild changes, and those aren't |
| 14 |
in the Changelogs at all. |
| 15 |
|
| 16 |
Instead, why not just create a script that gets distributed with portage |
| 17 |
that will upon request tell a user what changed based on the scm logs? |
| 18 |
I can't imagine that the hit on the servers will be all that large, and |
| 19 |
since this is read-only traffic it might be manageable through replication. |
| 20 |
|
| 21 |
Rich |
Archives