Re: [Mono-dev] github workflow proposals
On Fri, Jul 30, 2010 at 3:12 AM, Mark Probst wrote: > If nobody objects I'll push that to the public repository and never > write a ChangeLog entry again. Which is what I've just done. The last commit with a compulsory ChangeLog entry was this: http://github.com/mono/mono/tree/last-commit-with-compulsory-changelog-entry Ironically, it doesn't have a ChangeLog entry. Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Thu, Jul 29, 2010 at 5:44 PM, Geoff Norton wrote: > I think this looks great, but before we can get rid of them we probably need > to integrate this into make dist so that its automatic, so we need some way > of determining the start commit programatically if at all possible. Alright, so I've implemented this as well: http://github.com/schani/mono/commit/89bc1e27704126919891b3219895d1f13cd2f1f9 All that's required now is setting the tag "last-commit-with-compulsory-changelog-entry" and everything should be taken care of automatically. If nobody objects I'll push that to the public repository and never write a ChangeLog entry again. Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Thu, 2010-07-29 at 11:44 -0400, Geoff Norton wrote: > On 2010-07-29, at 11:29 AM, Mark Probst wrote: > > > On Wed, Jul 28, 2010 at 5:12 PM, Mark Probst wrote: > >> If nobody else does it I'm volunteering - I really, really want to get > >> rid of ChangeLogs :-) > > > > > > These will be put into the corresponding ChangeLog files. If a > > comment specifies files in directories with separate ChangeLogs, the > > comments will be put in each of them, but only with the relevant files > > in the comment. > > > > If there are no comments mentioning files for a particular ChangeLog > > in whose directory some file has been touched, then whatever comes > > before the first per-file comment will be put into that ChangeLog. In > > the extreme case (no per-file comments) that means the whole comment. > > > > Please see the test cases for details. > > > > Comments, suggestions? Is this enough to get rid of ChangeLog entries > > in commits? > > I think this looks great, but before we can get rid of them we probably need > to integrate this into make dist so that its automatic, so we need some way > of determining the start commit programatically if at all possible. > > Thoughts? You can always use http://live.gnome.org/Git/ChangeLog as reference. - Mario ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-29, at 11:29 AM, Mark Probst wrote: > On Wed, Jul 28, 2010 at 5:12 PM, Mark Probst wrote: >> If nobody else does it I'm volunteering - I really, really want to get >> rid of ChangeLogs :-) > > These will be put into the corresponding ChangeLog files. If a > comment specifies files in directories with separate ChangeLogs, the > comments will be put in each of them, but only with the relevant files > in the comment. > > If there are no comments mentioning files for a particular ChangeLog > in whose directory some file has been touched, then whatever comes > before the first per-file comment will be put into that ChangeLog. In > the extreme case (no per-file comments) that means the whole comment. > > Please see the test cases for details. > > Comments, suggestions? Is this enough to get rid of ChangeLog entries > in commits? I think this looks great, but before we can get rid of them we probably need to integrate this into make dist so that its automatic, so we need some way of determining the start commit programatically if at all possible. Thoughts? -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Wed, Jul 28, 2010 at 5:12 PM, Mark Probst wrote: > If nobody else does it I'm volunteering - I really, really want to get > rid of ChangeLogs :-) And here is the script: http://github.com/schani/mono/tree/commit-to-changelog Here are a few test cases: http://github.com/schani/mono/commits/commit-to-changelog-tests It works like this: The script will add ChangeLog entries for all files that a commit touches. All commits that touch any ChangeLog file are ignored. You can write per-file comments like so: --- * sgen-gc.c: Whatever. --- Or, more elaborately: --- * sgen-gc.c (major_do_collection), sgen-gc.h: Something. --- These will be put into the corresponding ChangeLog files. If a comment specifies files in directories with separate ChangeLogs, the comments will be put in each of them, but only with the relevant files in the comment. If there are no comments mentioning files for a particular ChangeLog in whose directory some file has been touched, then whatever comes before the first per-file comment will be put into that ChangeLog. In the extreme case (no per-file comments) that means the whole comment. Please see the test cases for details. Comments, suggestions? Is this enough to get rid of ChangeLog entries in commits? Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
Hello, For commit messages, how about gnome style ones? > > http://live.gnome.org/Git/CommitMessages > > We'll end up with messages like this: > http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2:) > This is a great suggestion, I have added it here: http://mono-project.com/Coding_Guidelines#Source_Code_Control Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Wed, Jul 28, 2010 at 5:01 PM, Miguel de Icaza wrote: > As soon as someone writes the tool that generates the ChangeLog from the > commit messages when producing a tarball, I am fine with dropping the > ChangeLog-on-commit. If nobody else does it I'm volunteering - I really, really want to get rid of ChangeLogs :-) The question is what kind of format we want: Do we want to keep the per-file comments? Let's say my commit touches metadata/sgen-gc.c and metadata/sgen-gc.h. Do we want --- 2010-07-28 Mark Probst * sgen-gc.c, sgen-gc.h: Important change. --- or are we happy with --- 2010-07-28 Mark Probst * Important change. --- If it's the former, the question is whether we want to have that format in the commit message, as well. If not, the script can only generate a message with all touched files in one comment, i.e. we won't be able to do --- 2010-07-28 Mark Probst * sgen-gc.c: Important change. * sgen-gc.h: Other part of the important change. --- I'd be perfectly happy with a commit message that doesn't mention the files, letting the script put them into the ChangeLog message. I.e. what I propose is making this commit message: --- Important change. This change was necessary because it's really, really important, so I changed some files to make it happen. --- into this ChangeLog entry: --- 2010-07-28 Mark Probst * sgen-gc.c, sgen-gc.h: Important change. This change was necessary because it's really, really important, so I changed some files to make it happen. --- Of course if the commit touches files in multiple directories, more than one ChangeLog will get an entry with the (same) message (modulo the filenames). Comments? Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
Hello, > I have another proposition to make. Can we stop using Changelog files? > Those can be generated from the commit logs for tarballs and releases > without losing anything at all. Commit messages would still have to be at > least as informative as they currently are. > As soon as someone writes the tool that generates the ChangeLog from the commit messages when producing a tarball, I am fine with dropping the ChangeLog-on-commit. The commit should remain as informative as it used to be. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 10:10 PM, Rodrigo Kumpera wrote: > One thing to notice is that we are not used to feature branches, we are used > to get things on trunk in small pieces in a way that keeps things working. > > Let's not change this healthy behavior as otherwise we would have big features > landing and all the suddenly tons of things would break. Agreed 100%, but lets also not be afraid of the concept of feature branches where they are applicable. I dont think we need to embrace them to one extreme or shun them to another. I think we can live in a middle ground where certain modules can have certain things go on in feature branches, see toshoks gc-fixes for moon. This stuff makes sense on a feature branch in a fork so others can review while it progresses without breaking all of trunk in the interim. Another great example from the runtime side is Linear IR, this basically was a feature branch until merge time, just in SVN context. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Tue, Jul 27, 2010 at 7:27 PM, Mark Probst wrote: > On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan > wrote: > > +1 on the commit message change > > > > I'd also like to vote, along with work branches be in user's forks, to > use > > this model: > > > > http://nvie.com/git-model > > One detail I really like about this is the non-fast-forwarding merge > for feature branches. This makes a whole lot of sense and I think we > should adopt it - of course only for multi-commit features. > One thing to notice is that we are not used to feature branches, we are used to get things on trunk in small pieces in a way that keeps things working. Let's not change this healthy behavior as otherwise we would have big features landing and all the suddenly tons of things would break. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
I always figured that [Tag] was just a simple thing to help you relate a commit to a very general area. i.e. [corlib] or [debugger] or [wcf]. I don't think we should, or could, define a whitelist of all usable tags. Hackers in each area would settle on a couple which would make sense. Alan. On Tue, Jul 27, 2010 at 11:47 PM, Marek Habersack wrote: > On Tue, 27 Jul 2010 18:41:46 -0400 > Geoff Norton wrote: > > > > > On 2010-07-27, at 6:21 PM, Alan wrote: > > > > > For commit messages, how about gnome style ones? > > > > > > http://live.gnome.org/Git/CommitMessages > > > > This is actually very nice. My only concern is maintaining the list of > [Tag]'s. > My sentiment as well. I think the [Tag] is pretty useless in our case. > > marek > > > > -g > > > > > > > > We'll end up with messages like this: > > > > http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2:) > > > > > > Alan. > > > > > > On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst > wrote: > > > On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera > wrote: > > > > I have another proposition to make. Can we stop using Changelog > files? Those > > > > can be generated from the commit logs for tarballs and releases > without > > > > losing anything at all. Commit messages would still have to be at > least as > > > > informative as they currently are. > > > > Not having Changelog files resolve 90%+ of our sources of conflicts > and make > > > > the forkqueue much more useful. If we are to move to a DVCS style of > > > > development, this will be a big barrier otherwise. > > > > > > I totally agree with this. A few days ago I wanted to merge a simple > > > commit Sanjoy made, and the fork queue would have been perfect for > > > this. Unfortunately it didn't grok the ChangeLog conflict, so I had > > > to pull the change myself, rebase it on master and then push it by > > > hand. > > > > > > I also agree with the one-line summaries and work branches in private > > > repositories. > > > > > > Mark > > > ___ > > > Mono-devel-list mailing list > > > Mono-devel-list@lists.ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > ___ > > > Mono-devel-list mailing list > > > Mono-devel-list@lists.ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Tue, 27 Jul 2010 18:41:46 -0400 Geoff Norton wrote: > > On 2010-07-27, at 6:21 PM, Alan wrote: > > > For commit messages, how about gnome style ones? > > > > http://live.gnome.org/Git/CommitMessages > > This is actually very nice. My only concern is maintaining the list of > [Tag]'s. My sentiment as well. I think the [Tag] is pretty useless in our case. marek > > -g > > > > > We'll end up with messages like this: > > http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2 > > :) > > > > Alan. > > > > On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst wrote: > > On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera wrote: > > > I have another proposition to make. Can we stop using Changelog files? > > > Those > > > can be generated from the commit logs for tarballs and releases without > > > losing anything at all. Commit messages would still have to be at least as > > > informative as they currently are. > > > Not having Changelog files resolve 90%+ of our sources of conflicts and > > > make > > > the forkqueue much more useful. If we are to move to a DVCS style of > > > development, this will be a big barrier otherwise. > > > > I totally agree with this. A few days ago I wanted to merge a simple > > commit Sanjoy made, and the fork queue would have been perfect for > > this. Unfortunately it didn't grok the ChangeLog conflict, so I had > > to pull the change myself, rebase it on master and then push it by > > hand. > > > > I also agree with the one-line summaries and work branches in private > > repositories. > > > > Mark > > ___ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 6:21 PM, Alan wrote: > For commit messages, how about gnome style ones? > > http://live.gnome.org/Git/CommitMessages This is actually very nice. My only concern is maintaining the list of [Tag]'s. -g > > We'll end up with messages like this: > http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2 :) > > Alan. > > On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst wrote: > On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera wrote: > > I have another proposition to make. Can we stop using Changelog files? Those > > can be generated from the commit logs for tarballs and releases without > > losing anything at all. Commit messages would still have to be at least as > > informative as they currently are. > > Not having Changelog files resolve 90%+ of our sources of conflicts and make > > the forkqueue much more useful. If we are to move to a DVCS style of > > development, this will be a big barrier otherwise. > > I totally agree with this. A few days ago I wanted to merge a simple > commit Sanjoy made, and the fork queue would have been perfect for > this. Unfortunately it didn't grok the ChangeLog conflict, so I had > to pull the change myself, rebase it on master and then push it by > hand. > > I also agree with the one-line summaries and work branches in private > repositories. > > Mark > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 6:27 PM, Mark Probst wrote: > On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan > wrote: >> +1 on the commit message change >> >> I'd also like to vote, along with work branches be in user's forks, to use >> this model: >> >> http://nvie.com/git-model > > One detail I really like about this is the non-fast-forwarding merge > for feature branches. This makes a whole lot of sense and I think we > should adopt it - of course only for multi-commit features. Right, that is very nice. I dont think the development/master segmentation fits our workflow tho. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
For commit messages, how about gnome style ones? http://live.gnome.org/Git/CommitMessages We'll end up with messages like this: http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2:) Alan. On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst wrote: > On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera > wrote: > > I have another proposition to make. Can we stop using Changelog files? > Those > > can be generated from the commit logs for tarballs and releases without > > losing anything at all. Commit messages would still have to be at least > as > > informative as they currently are. > > Not having Changelog files resolve 90%+ of our sources of conflicts and > make > > the forkqueue much more useful. If we are to move to a DVCS style of > > development, this will be a big barrier otherwise. > > I totally agree with this. A few days ago I wanted to merge a simple > commit Sanjoy made, and the fork queue would have been perfect for > this. Unfortunately it didn't grok the ChangeLog conflict, so I had > to pull the change myself, rebase it on master and then push it by > hand. > > I also agree with the one-line summaries and work branches in private > repositories. > > Mark > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan wrote: > +1 on the commit message change > > I'd also like to vote, along with work branches be in user's forks, to use > this model: > > http://nvie.com/git-model One detail I really like about this is the non-fast-forwarding merge for feature branches. This makes a whole lot of sense and I think we should adopt it - of course only for multi-commit features. Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera wrote: > I have another proposition to make. Can we stop using Changelog files? Those > can be generated from the commit logs for tarballs and releases without > losing anything at all. Commit messages would still have to be at least as > informative as they currently are. > Not having Changelog files resolve 90%+ of our sources of conflicts and make > the forkqueue much more useful. If we are to move to a DVCS style of > development, this will be a big barrier otherwise. I totally agree with this. A few days ago I wanted to merge a simple commit Sanjoy made, and the fork queue would have been perfect for this. Unfortunately it didn't grok the ChangeLog conflict, so I had to pull the change myself, rebase it on master and then push it by hand. I also agree with the one-line summaries and work branches in private repositories. Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 5:42 PM, Rodrigo Kumpera wrote: > > > > It doesn't make any sense to have work/feature branches on the central > repository given we're using git. It's much easier and cleaner to simply have > them on personal forks. One might not like dealing with extra remotes, but > that would be a burnen only to mantainers merging code from contributors. > Miguel has agreed with my suggestion, so I'll document this in more detail on the workflow changes page after dinner. > I have another proposition to make. Can we stop using Changelog files? Those > can be generated from the commit logs for tarballs and releases without > losing anything at all. Commit messages would still have to be at least as > informative as they currently are. > > Not having Changelog files resolve 90%+ of our sources of conflicts and make > the forkqueue much more useful. If we are to move to a DVCS style of > development, this will be a big barrier otherwise. I strongly support this as well, but in fact I'd like to suggest that we all strive to do a better job of commit messages. I'm guilty of this as much as anyone, but we have a lot of things that say "Fix bla"; without describing why its broken, or what the fix is. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On Tue, Jul 27, 2010 at 6:22 PM, Geoff Norton wrote: > Github takes the first line from the commit message to build this page: > > http://github.com/mono/mono/commits/master > > I think we should modify our current commit messages to not just be the > change log entries, but have a 1 line summary of the patch first like this: > > http://github.com/mono/mono/commit/5ab946450584e127878d7abbedeeca2688ef032f > I like this change, otherwise github's build page is pretty unusable. > > Additionally, I think we should implement a policy that all "work > branches" are made in user forks; and the only people who should be making > branches in the mainline github are QA for release managment practices. > > thoughts? > > It doesn't make any sense to have work/feature branches on the central repository given we're using git. It's much easier and cleaner to simply have them on personal forks. One might not like dealing with extra remotes, but that would be a burnen only to mantainers merging code from contributors. I have another proposition to make. Can we stop using Changelog files? Those can be generated from the commit logs for tarballs and releases without losing anything at all. Commit messages would still have to be at least as informative as they currently are. Not having Changelog files resolve 90%+ of our sources of conflicts and make the forkqueue much more useful. If we are to move to a DVCS style of development, this will be a big barrier otherwise. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
+1 on the commit message change I'd also like to vote, along with work branches be in user's forks, to use this model: http://nvie.com/git-model -Dale > Github takes the first line from the commit message to build this page: > > http://github.com/mono/mono/commits/master > > I think we should modify our current commit messages to not just be the > change log entries, but have a 1 line summary of the patch first like > this: > > http://github.com/mono/mono/commit/5ab946450584e127878d7abbedeeca2688ef032f > > Additionally, I think we should implement a policy that all "work > branches" are made in user forks; and the only people who should be making > branches in the mainline github are QA for release managment practices. > > thoughts? > > -g > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] github workflow proposals
Github takes the first line from the commit message to build this page: http://github.com/mono/mono/commits/master I think we should modify our current commit messages to not just be the change log entries, but have a 1 line summary of the patch first like this: http://github.com/mono/mono/commit/5ab946450584e127878d7abbedeeca2688ef032f Additionally, I think we should implement a policy that all "work branches" are made in user forks; and the only people who should be making branches in the mainline github are QA for release managment practices. thoughts? -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
