On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto <[email protected]> wrote: > On 01-06-2011 19:50, Nirbheek Chauhan wrote: >> The current situation is: >> >> (a) Not dire. >> (b) Not urgent. > > (c) has irked enough developers and users that people pushed council to > update the policy about the use of ChangeLogs.
Yes, and I'm surprised that these same developers pushed towards a negative solution (kick productive people out) rather than a positive solution (move to git). >> And if we decide, hey, let's move to git instead of having this >> discussion, the current situation is also: >> >> (c) A waste of everyone's time. >> >> So no, future plans are not independent of the current situation, and >> a move to git *is* a way to deal with the current situation. >> >> In effect, we kill (at least) two birds with one stone and prevent a >> lot of argument and bad blood. > > To be clear I support the goal to move our tree to git. > However, I'd like to point out that simply moving to git will leave us > in the same state. Assuming everyone agrees that git is far more useful > than cvs to check for changes in the tree, a simple but important issue > remains: the plan is to move the "development tree" to git, but to keep > the rsync mirrors for users. So the "move to git" doesn't fix the issue > for users or developers using an rsync tree. Arguably, if developers want to know the history they should use the copy of the git tree that they're supposed to be having. Relying on ChangeLogs for history is just silly if you have the complete history at your fingertips with git. > One solution that has been proposed before and that was raised again in > this thread is to generate ChangeLogs directly from scm commit messages. > That is already a solution with cvs, so moving to git won't help here. This is not true. One of the main problems of generating ChangeLog messages from cvs/svn is that you don't have much control over the `cvs log` output, cvs itself is extremely slow, and cvs maintains log information *per-file*. Hence ChangeLog generation in the format we want would be slow/impractical. There's tens of thousands of packages. How long do you think it'll take to generate ChangeLogs from cvs for all of them? Notice how every project that did a move to git from cvs/svn started auto-generating ChangeLogs[1]. One reason was that ChangeLogs will *always* cause merge conflicts, and they're duplicate information, so there's no point keeping them in the local tree. The other reason is that with git it takes a fraction of a second to generate a ChangeLog from the commit messages. 1. https://live.gnome.org/Git/ChangeLog > The same objections that have been raised about doing it for cvs, not > being able to use different messages for the commit message and in > ChangeLog (something I understand but admit have hardly used before), > are also valid if we move to git. > Not really. This problem has been raised and the solution is to add a '[trivial]' or '#trivial' etc tag to the commit message (either subject of body), and it won't be included in the auto-generated ChangeLog. The main issue that people have with not writing ChangeLog messages for removals is that developers can't figure out when, why, and by whom an ebuild was removed; because there's no ChangeLog entry, and cvs log/cvs diff is too painful to use. This makes it hard to fix breakage. There's a fringe issue of users wanting to know why an 'old' ebuild was removed while they're offline in a train or something (and don't want to keep a cloned git repo around), but that's not reason enough to kick our second-most-hardworking developer. In essence, the most basic issue here is *not* users who want to have all information offline, but the fact that /developers/ rely on ChangeLog for information because cvs log/diff suck. Note that the developer in question always wrote proper commit messages, so `git log` WOULD solve all our problems. Cheers, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
