Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote: On 04/13/2010 01:25 PM, Peter Volkov wrote: В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. We could abuse git-note May be. I found this mail: http://lists.zerezo.com/git/msg623699.html Was the problem resolved? Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! No. We are humans and thus mistakes are unavoidable. -- Peter.
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 25 June 2010 14:15, Peter Volkov p...@gentoo.org wrote: В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: [...] Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! No. We are humans and thus mistakes are unavoidable. He didn't say don't make mistakes. He said, be careful and if mistakes happen, so be it. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет: On 25 June 2010 14:15, Peter Volkov p...@gentoo.org wrote: В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: [...] Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! No. We are humans and thus mistakes are unavoidable. He didn't say don't make mistakes. He said, be careful and if mistakes happen, so be it. And I disagreed. This is unacceptable since we are talking about credits to our users. It's like paying salary to random person and blaming tools after that. -- Peter.
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Fri, 2010-06-25 at 13:00 +0400, Peter Volkov wrote: В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет: On 25 June 2010 14:15, Peter Volkov p...@gentoo.org wrote: В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: [...] Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! No. We are humans and thus mistakes are unavoidable. He didn't say don't make mistakes. He said, be careful and if mistakes happen, so be it. And I disagreed. This is unacceptable since we are talking about credits to our users. It's like paying salary to random person and blaming tools after that. You can just make a new commit with just a message saying Hey, last time I was wrong, this is from A, not B if you care enough. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 04/13/2010 01:25 PM, Peter Volkov wrote: В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. We could abuse git-note -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote: On 04/13/2010 01:25 PM, Peter Volkov wrote: В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. We could abuse git-note Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Peter Volkov wrote: ?? ??, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??: The traditional ChangeLog that is currently employed in gentoo-x86 (and in other projects) is simply an ugly hack The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used in other projects is I think another very important distinction (that you imply below, but I want to specifically point out here) is that we have *many* per-project ChangeLogs whereas most other projects have a *single* monolithic ChangeLog. Think of it like this: if you make a typo in a commit message, or forget to add something; you can't change it after you've published the commit (cvs/svn commit or git push) to the world. And then it's better to keep ChangeLogs. For developers it was never a problem to script `echangelog log repoman commit -m log` and conflict resolution is really not that hard with git. In spirit of Gentoo, it's better to write some tool to update Manifests after conflict resolution instead of making ChangeLogs less useful for those who uses them. This is a very good point regarding ease of conflict resolution. Further to my other point above, the traditional ChangeLog ugliness really only hits you with a centralized setup+git if *everyone* is editing the *same* ChangeLog: If every commit touches the same file in the same place (ie, prepending to a ChangeLog file in the same location), you are guaranteed to have collisions every time you pull a new version of the file. This is why most projects with a single monolithic changelog auto-generate them, or perhaps just craft them at release time. Our case, though it is a centralized repository model, is quite different. The chance of collisions in a package-specific ChangeLog is, as it is today with CVS, pretty unlikely. In fact, I think the only time it usually happens to me is when an arch stabilizes my package while I'm making a change, and these are very easy to fix. (In fact, it may be possible to help git out with this specific ChangeLog situation by using a custom merge driver, see GITATTRIBUTES(5) for details, though deployment of a custom merge driver can be tricky) BTW as for profiles ChangeLogs... May be it's better to generate them. That's another important distinction and probably a good idea. I think those profile ChangeLogs are also not as user-facing as the per-package ones, so an autogenerated one makes a lot of sense. -- Jim Ramsay Gentoo/Linux Developer (rox/fluxbox/gkrellm) pgpnnsBkS27K2.pgp Description: PGP signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel m...@gentoo.org wrote: I rather like the changelogs auto-generated. A method to link my git commit to bugzie would be awesome. I *do* envy debian and others for the auto bughandling they have. Previewing more than a raw number would also reduce (not eliminate) the errors committed, i guess. I think you will *really* like `git bz`[1][2][3]. It's exactly what you need (needs porting to pybugz and our workflow however). 1. http://blog.fishsoup.net/2009/09/05/git-bz-push/ 2. http://git.fishsoup.net/cgit/git-bz/plain/git-bz 3. http://git.fishsoup.net/man/git-bz.html -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Nirbheek Chauhan wrote: On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel m...@gentoo.org wrote: I rather like the changelogs auto-generated. A method to link my git commit to bugzie would be awesome. I *do* envy debian and others for the auto bughandling they have. Previewing more than a raw number would also reduce (not eliminate) the errors committed, i guess. I think you will *really* like `git bz`[1][2][3]. Actually, I do :) Someone posted a link in a thread I can't remember now and it looks very promising. Though i don't know if there's anything barring us from using it. But I image it would make my life easier a lot. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. -- Peter.
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 13-04-2010 13:25, Peter Volkov wrote: В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. If in kernel.org they don't seem to need to edit changelogs, why would we? Between all of us developers, how many needed to change a ChangeLog after commit? I guess we would be pretty low in number. And lets not forget that we can --amend commits (log included) until we push them to origin. - Angelo
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 13, 2010 at 4:55 PM, Peter Volkov p...@gentoo.org wrote: В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. I didn't know that editing existing ChangeLog entries manually was an accepted practice with CVS. Even if it was to correct typos or something else. The traditional ChangeLog that is currently employed in gentoo-x86 (and in other projects) is simply an ugly hack to cheaply distribute commit messages to users in an offline manner. Think of it like this: if you make a typo in a commit message, or forget to add something; you can't change it after you've published the commit (cvs/svn commit or git push) to the world. Since ChangeLogs are offline commit messages; you shouldn't edit them either; only (app|pre)pend to them. Also, with git, you usually review and double-check your commits and amend/rebase before pushing, so such mistakes can be corrected then. And now that we have the ability to cheaply generate ChangeLogs from the commit messages, there is no reason to keep this ugly hack around. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, 13 Apr 2010, Nirbheek Chauhan wrote: Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. I didn't know that editing existing ChangeLog entries manually was an accepted practice with CVS. Even if it was to correct typos or something else. So far, the ChangeLog is just a normal file. So why should it be forbidden to edit it and correct mistakes? Examples are wrong or forgotten credits, or wrong bug references. It is a service to our users that such information is accurate. Also, with git, you usually review and double-check your commits and amend/rebase before pushing, so such mistakes can be corrected then. This assumes that everybody is perfect. ;-) But mistakes will still happen, even if you double-check. Ulrich
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 13, 2010 at 6:49 PM, Ulrich Mueller u...@gentoo.org wrote: On Tue, 13 Apr 2010, Nirbheek Chauhan wrote: Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. I didn't know that editing existing ChangeLog entries manually was an accepted practice with CVS. Even if it was to correct typos or something else. So far, the ChangeLog is just a normal file. So why should it be forbidden to edit it and correct mistakes? Examples are wrong or forgotten credits, or wrong bug references. It is a service to our users that such information is accurate. So, such changes; where would you document them? Would you ChangeLog an edit to the ChangeLog? CVS log is not an option for documenting anything; access to it is slow, quirky, and time-consuming. From my PoV, editing ChangeLog is like editing history. Complete no-no. Of course, all of this goes out the window with git since access to the log is trivially quick. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Nirbheek Chauhan wrote: From my PoV, editing ChangeLog is like editing history. Complete no-no. It is possible in all major SCMs for a reason. And I (as a user) would laugh at Changelog entries saying um, I got that bug number wrong, it is really #1234. If I (as a developer) log such edits, I'm wasting my users time. So I'll continue to edit and commit Changelogs without additional notice. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 13-04-2010 18:12, Matti Bickel wrote: Nirbheek Chauhan wrote: From my PoV, editing ChangeLog is like editing history. Complete no-no. It is possible in all major SCMs for a reason. And I (as a user) would laugh at Changelog entries saying um, I got that bug number wrong, it is really #1234. If I (as a developer) log such edits, I'm wasting my users time. So I'll continue to edit and commit Changelogs without additional notice. Can't we just create a commit hook that appends the bug summary as a comment if a #X bug string is present on the commit log? Something like: - - Foobar commit Description bl a bla bla # bug 1234: Show summary for those that don't double check the bug # number. # # Other git crap that usually appears at end of log # ... - -
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel m...@gentoo.org wrote: Nirbheek Chauhan wrote: From my PoV, editing ChangeLog is like editing history. Complete no-no. It is possible in all major SCMs for a reason. And I (as a user) would laugh at Changelog entries saying um, I got that bug number wrong, it is really #1234. If I (as a developer) log such edits, I'm wasting my users time. Its not possible in perforce once your change has been submitted. So I'll continue to edit and commit Changelogs without additional notice. I agree that you should do this (it is rather convenient for everyone after all) but I don't think editable changelog entries are really a blocker for this migration. It seems you can append to changelogs in git which is likely sufficient for fixing mistakes that will occur. -A
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Alec Warner wrote: On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel m...@gentoo.org wrote: Nirbheek Chauhan wrote: From my PoV, editing ChangeLog is like editing history. Complete no-no. It is possible in all major SCMs for a reason. And I (as a user) would laugh at Changelog entries saying um, I got that bug number wrong, it is really #1234. If I (as a developer) log such edits, I'm wasting my users time. Its not possible in perforce once your change has been submitted. Oh, missed that one. Maybe that makes perforce more auditble or whatnot. I rather like the changelogs auto-generated. A method to link my git commit to bugzie would be awesome. I *do* envy debian and others for the auto bughandling they have. Previewing more than a raw number would also reduce (not eliminate) the errors committed, i guess. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
В Втр, 13/04/2010 в 17:18 +0530, Nirbheek Chauhan пишет: The traditional ChangeLog that is currently employed in gentoo-x86 (and in other projects) is simply an ugly hack The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used in other projects is that gentoo-x86 ChangeLog is more like NEWS file that summarizes important (affecting package) changes. That is why emerge -l was implemented. And that is why it's better to avoid typos there (fix them), drop redundant messages like comment edits, empty lines removal and etc... Think of it like this: if you make a typo in a commit message, or forget to add something; you can't change it after you've published the commit (cvs/svn commit or git push) to the world. And then it's better to keep ChangeLogs. For developers it was never a problem to script `echangelog log repoman commit -m log` and conflict resolution is really not that hard with git. In spirit of Gentoo, it's better to write some tool to update Manifests after conflict resolution instead of making ChangeLogs less useful for those who uses them. BTW as for profiles ChangeLogs... May be it's better to generate them. -- Peter.
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 04/13/2010 12:33 PM, Matti Bickel wrote: Alec Warner wrote: Its not possible in perforce once your change has been submitted. Oh, missed that one. Maybe that makes perforce more auditble or whatnot. I suspect that is the gist of it. I work with numerous systems that have audit trails that are subject to regulation, and it is pretty typical that the way to correct an audit trail entry is to add an additional audit trail entry (with the old entry still being there - perhaps with a pointer to the new entry). There is no shame in admitting that you made a mistake - the kinds of people who audit these systems look at a lack of mistakes as evidence that something is being hidden. Rich
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, 2010-04-06 at 09:06 -0400, Richard Freeman wrote: 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. I pretty much always use the -l option of portage to include the pertinent changes in the ChangeLog, because this is the only way to know about any changes before the package is merged. Yes, the NEWS from the package usually contains a lot more detail, but I won't be able to read it until after the fact. In my experience plenty of ChangeLogs in our tree at least briefly document what changed in the package as opposed to the ebuild. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 6, 2010 at 04:13, Nirbheek Chauhan nirbh...@gentoo.org wrote: * Use a separator in the commit message like == \n to denote that everything after this is dev-only information and should be skipped from the user ChangeLog I think this is fairly elegant, and a good solution to this problem. Cheers, Dirkjan
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
First, I've been using git to hack Linux for some embedded devices. My development was in sync with upstream linux-omap to which I sent several patches. So, consider yourself that I have some experience with git. On 06-04-2010 08:41, Fabian Groffen wrote: On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote: * It makes zero sense to manually manage ChangeLogs in git[1] - Irritating conflicts while merging branches or remote master + Similar argument for having only distfile manifests; but I digress... - Duplication of effort and information - Saves space for local checkouts This seems to assume a) that we will do branches, and b) that those branches somehow are official and in use In CVS we are not allowed to use branches, as a policy, that somehow makes sense. Our stable tree is visible via keywords instead. Why would we suddenly do branches? It still isn't a good thing. If you talk about branches in the sense of a clone of the entire repo, why would we suddenly do massive concurrent development on the same ebuilds? IMHO repository branching would be greatly useful on Gentoo portage, specially for third-party and other Gentoo-based distros. It will be a lot easier for them to keep their own changes to ebuilds while in sync with main Gentoo tree. This is a big win for everyone. With my experience in Gentoo-embedded I can also present a problem where branching is extremely useful: 1) Package foobar-1.2 is in the tree and keyworded only for ~x86 ~amd64. 2) Some dev at -embedded decides that package is useful and applies his traditional cross-compile hackery. 3) The usual route would be to open a shi*load of bugs, wait a cr*pload of time for the maintainer response and if the weather feels like it, there is authorization to commit. Then there is also need to retest for already keyworded arches so we know we don't break others. 3*) With git, one would just branch (lets call it embedded branch) the package. Apply the patches there and let people using embedded profiles to emerge from that branch instead of master. Benefits? I think they are pretty obvious - people can start putting quick patches in the tree for specific arches while not breaking others. IMHO, the only bottleneck I see on Gentoo development is the massive policy (not saying it is not needed) a -dev has to follow just to commit a simple fix. Git my friends, will be our holly grail. I can tell you from good experience that you only do such things if you really have to, e.g. when you are in an overlay that needs to have modifications to nearly everything and you try to keep that overlay up-to-date with its origin, gentoo-x86. It's no fun, because it conflicts pretty much on lots of things, not ChangeLogs. It seems to me, that if you are in a clone working on something, you just only write the ChangeLog once you merge it with its origin, gentoo-x86. You have to review what happened at that stage anyway. If you really have lots of changes, you will find that many commits on the other side will cause you conflicts, so the ChangeLog is just a very small part of it. Conclusion, if you can, try hard to keep your changes minimal, and preferably zero compared to the origin, gentoo-x86. I don't know why but people seem to have eternal scarring to merge conflicts. Yes, they happen and yes they are trivial to fix if people don't commit crap that touches a lot of stuff. In portage, the tree is very well organized and with some good policies like restricting each commit to one package will pretty much prevent conflicts. I will not comment on if Changelogs are going to give conflicts or not. That would be best answered by the people that is running portage git for some time.
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Wed, 07 Apr 2010 11:58:13 +0200 Angelo Arrifano mik...@gentoo.org wrote: With my experience in Gentoo-embedded I can also present a problem where branching is extremely useful: 1) Package foobar-1.2 is in the tree and keyworded only for ~x86 ~amd64. 2) Some dev at -embedded decides that package is useful and applies his traditional cross-compile hackery. 3) The usual route would be to open a shi*load of bugs, wait a cr*pload of time for the maintainer response and if the weather feels like it, there is authorization to commit. Then there is also need to retest for already keyworded arches so we know we don't break others. 3*) With git, one would just branch (lets call it embedded branch) the package. Apply the patches there and let people using embedded profiles to emerge from that branch instead of master. Benefits? I think they are pretty obvious - people can start putting quick patches in the tree for specific arches while not breaking others. And then you have to keep merging master into your embedded branch every few hours to keep up. It's a waste of time. Instead, you should just put a modified foobar-1.2 in your own repository and rely upon the package manager's extensive and clean handling of multiple repositories to avoid having to do any merging yourself. There are uses for merges, but working around the shortcomings in a package manager shouldn't be one of them. Migrating to Git should be about addressing problems with CVS, not about addressing problems with Portage. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 07-04-2010 00:21, Robin H. Johnson wrote: On Tue, Apr 06, 2010 at 09:06:24AM -0400, Richard Freeman wrote: 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? The major concern with this is users that are NOT connected to the internet always. If you are connected, you can just use --exclude Changelog in your rsync options. That's a good point. But can't we generate the ChangeLogs automatically from git on the main rsync server?
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 04/07/2010 05:58 AM, Angelo Arrifano wrote: 3*) With git, one would just branch (lets call it embedded branch) the package. Apply the patches there and let people using embedded profiles to emerge from that branch instead of master. Benefits? I think they are pretty obvious - people can start putting quick patches in the tree for specific arches while not breaking others. IMHO, the only bottleneck I see on Gentoo development is the massive policy (not saying it is not needed) a -dev has to follow just to commit a simple fix. Git my friends, will be our holly grail. I think that allowing for different levels of QA standards, and accomodating things like this are good reasons to use branches. HOWEVER, we do need to manage this so that it doesn't get out of hand. We really don't want users following 14 different branches and have 10 different variations on every package in the tree - which is how it could get after a year or two of branching without any effort to do pruning and get things merged into a main tree. Having branches to do development and facilitate access and testing seems fine, however we should always have the goal of getting these tested revisions merged back into the main tree. We really don't want divergent development to be the norm.
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote: Just a question: Why do we even need to care about ChangeLog files? Can't we just use the git commit message to generate logs? E.g run a script on server side which will read the whole git shortlog and generate a changelog every $timeframe? -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras hwoar...@gentoo.org wrote: On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote: Just a question: Why do we even need to care about ChangeLog files? Can't we just use the git commit message to generate logs? E.g run a script on server side which will read the whole git shortlog and generate a changelog every $timeframe? You seem to have missed the gist of the situation. I'm quoting it here again to highlight it: * It makes zero sense to manually manage ChangeLogs in git[1] [snip] * 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] [snip] 1. http://live.gnome.org/Git/ChangeLog -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Wednesday 07 April 2010 21:41:49 Nirbheek Chauhan wrote: On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras hwoar...@gentoo.org wrote: On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote: Just a question: Why do we even need to care about ChangeLog files? Can't we just use the git commit message to generate logs? E.g run a script on server side which will read the whole git shortlog and generate a changelog every $timeframe? You seem to have missed the gist of the situation. I'm quoting it here again to highlight it: * It makes zero sense to manually manage ChangeLogs in git[1] [snip] * 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] [snip] 1. http://live.gnome.org/Git/ChangeLog Ah you are right. It seems that I missed that e-mail on my inbox. Thanks for posting it again. It seems we are on the same page :) -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote: * It makes zero sense to manually manage ChangeLogs in git[1] - Irritating conflicts while merging branches or remote master + Similar argument for having only distfile manifests; but I digress... - Duplication of effort and information - Saves space for local checkouts This seems to assume a) that we will do branches, and b) that those branches somehow are official and in use In CVS we are not allowed to use branches, as a policy, that somehow makes sense. Our stable tree is visible via keywords instead. Why would we suddenly do branches? It still isn't a good thing. If you talk about branches in the sense of a clone of the entire repo, why would we suddenly do massive concurrent development on the same ebuilds? I can tell you from good experience that you only do such things if you really have to, e.g. when you are in an overlay that needs to have modifications to nearly everything and you try to keep that overlay up-to-date with its origin, gentoo-x86. It's no fun, because it conflicts pretty much on lots of things, not ChangeLogs. It seems to me, that if you are in a clone working on something, you just only write the ChangeLog once you merge it with its origin, gentoo-x86. You have to review what happened at that stage anyway. If you really have lots of changes, you will find that many commits on the other side will cause you conflicts, so the ChangeLog is just a very small part of it. Conclusion, if you can, try hard to keep your changes minimal, and preferably zero compared to the origin, gentoo-x86. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 6, 2010 at 12:11 PM, Fabian Groffen grob...@gentoo.org wrote: On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote: * It makes zero sense to manually manage ChangeLogs in git[1] - Irritating conflicts while merging branches or remote master + Similar argument for having only distfile manifests; but I digress... - Duplication of effort and information - Saves space for local checkouts This seems to assume a) that we will do branches, and b) that those branches somehow are official and in use No. Conflicts can arise (and I have seen them arise) trivially if you make changes and try to do a pull --rebase; which is then not fast-forward, and you're left with an ugly mess of conflicts on your hands. Say you're moving stuff from an overlay using git format-patch; how do you handle the conflicts it will generate to ChangeLogs and Manifests? Also, this is not the only reason to not use ChangeLogs. Trivial example purely for demonstrative purposes: Without ChangeLog: make change1; commit; test; realise it needs change2; commit; test; rebase commits; push With ChangeLog: make change1; write ChangeLog; commit; test; realise it needs change2; reset --hard ChangeLog HEAD^; rewrite ChangeLog; commit; test; rebase commits; push Now which is easier? Don't forget that the major reason for moving to git was the ability to make several local commits and pushing them in an atomic way; so you are bound to make mistakes and want to rebase. If you really have lots of changes, you will find that many commits on the other side will cause you conflicts, so the ChangeLog is just a very small part of it. I bump an ebuild; arch team member marks older version stable. Two completely orthogonal changes that conflict now. With ChangeLogs, *every* *single* change you make conflicts. You do a rebase; and it conflicts! It's just stupid. Extreme example: profiles/ChangeLog Conclusion, if you can, try hard to keep your changes minimal, and preferably zero compared to the origin, gentoo-x86. With the inevitable increased activity on the gentoo-x86 tree, this will become more and more difficult. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 06-04-2010 12:31:51 +0530, Nirbheek Chauhan wrote: On Tue, Apr 6, 2010 at 12:11 PM, Fabian Groffen grob...@gentoo.org wrote: On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote: * It makes zero sense to manually manage ChangeLogs in git[1] - Irritating conflicts while merging branches or remote master + Similar argument for having only distfile manifests; but I digress... - Duplication of effort and information - Saves space for local checkouts This seems to assume a) that we will do branches, and b) that those branches somehow are official and in use No. Conflicts can arise (and I have seen them arise) trivially if you make changes and try to do a pull --rebase; which is then not fast-forward, and you're left with an ugly mess of conflicts on your hands. Say you're moving stuff from an overlay using git format-patch; how do you handle the conflicts it will generate to ChangeLogs and Manifests? Ehm, you consider pkg-moving packages an operation you do from day to day? I surely hope not. The other changes you talk about sound like a generic problem to me, not related to ChangeLog files at all. Also, this is not the only reason to not use ChangeLogs. Trivial example purely for demonstrative purposes: Without ChangeLog: make change1; commit; test; realise it needs change2; commit; test; rebase commits; push With ChangeLog: make change1; write ChangeLog; commit; test; realise it needs change2; reset --hard ChangeLog HEAD^; rewrite ChangeLog; commit; test; rebase commits; push If you just pull/update before you start your changes and commit/push afterwards there are no problems. I see no branching in your examples. In a branch, I wouldn't make ChangeLog changes until I merge with main and commit there. Now which is easier? Don't forget that the major reason for moving to git was the ability to make several local commits and pushing them in an atomic way; so you are bound to make mistakes and want to rebase. Ohw, was that the major reason... What a nonsense. If you need to push several commits to the same package at the same time, you could have probably done it with a single commit on CVS as well, just using a single ChangeLog entry, which looks much cleaner to me. If you talk about bumping the whole of KDE at the same time, well nice, but then how are you going to solve the problem with the Manifest file? I'd say one of the requirements of a new VCS is the ability to do an atomic commit over multiple directories, which is quite different from making several local commits, to me. If you really have lots of changes, you will find that many commits on the other side will cause you conflicts, so the ChangeLog is just a very small part of it. I bump an ebuild; arch team member marks older version stable. Two completely orthogonal changes that conflict now. With ChangeLogs, *every* *single* change you make conflicts. You do a rebase; and it conflicts! It's just stupid. WHY would you wait a couple of months with pushing your new version out? The conflict chance you get if you'd push immediately, is as big as the conflict chance you get with CVS if this happens. Your argument is more to get rid of the ChangeLog and Manifest file, then to start using git, IMO. Conclusion, if you can, try hard to keep your changes minimal, and preferably zero compared to the origin, gentoo-x86. With the inevitable increased activity on the gentoo-x86 tree, this will become more and more difficult. Do Tove's stats actually show there is an increase in activity? One would have to plot it, but glancing over it, it actually looks about steady to me. Git doesn't solve the problem, you still have a couple of untackled issues standing out. I think Robin tried to address them in previous mails. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
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
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Tue, Apr 06, 2010 at 09:06:24AM -0400, Richard Freeman wrote: 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? The major concern with this is users that are NOT connected to the internet always. If you are connected, you can just use --exclude Changelog in your rsync options. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[gentoo-dev] [git migration] The problem of ChangeLog generation
One of the few remaining problems to be solved for the migration to git for our gentoo-x86/ and gentoo/ trees (besides other projects/overlays) is the problem of how to handle ChangeLogs. Gist: * It makes zero sense to manually manage ChangeLogs in git[1] - Irritating conflicts while merging branches or remote master + Similar argument for having only distfile manifests; but I digress... - Duplication of effort and information - Saves space for local checkouts * 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] Now, there are obviously problems with this. Some of them are documented below alongwith their proposed solutions. If people foresee other problems with this; they are requested to comment. They are also welcome to comment if they have a better solution to the problems listed below. Also, please try to keep this thread on-topic. Problems: * Messages in ChangeLog are not always the same as the commit messages (~1% are different) * Some people place additional information in the commit message which is intended only for developer use - Most of the difference in ChangeLog/commit messages comes from this * Trivial changes are often not documented in ChangeLogs - This is upto the developer's personal preference - Some folks do this because of the extra time it takes + This use-case becomes irrelevant due to automatic generation of ChangeLog Solutions: * Do not re-generate the existing ChangeLog; rather make the ChangeLog generation script smart enough to only append - Solves the messages not same problem for existing commits * Use a separator in the commit message like == \n to denote that everything after this is dev-only information and should be skipped from the user ChangeLog - Solves the problem for people who like to add extra dev-only info in the CVS commit message * Ignore commits with [$tag][trivial] in the tag[2] from being added to ChangeLog - Keeps the wishes of the developer and does not pollute ChangeLog with such info 1. http://live.gnome.org/Git/ChangeLog 2. http://live.gnome.org/Git/CommitMessages -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
