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