Yes, let's definitely release more often. Releasing is painful, but I think that's mainly just because we wait so long to do it, and so we have to do things like write these large logs.
Creating a release log as we go is a good idea. Do you have any ideas on good ways to do it, so that we don't forget anything because someone forgot to update the release log (like marking which commits were "logged" somehow)? I don't see how writing better commit messages would help use compile a log at release time any easier. I guess it's easier to see what was actually done in a commit, but you still have to go through and compile the log. By the way, does the kernel have a strict standard for commit messages, or are they all just really good in a general sense? I've seen some of the log for git itself, and it is definitely the latter. Aaron Meurer On Fri, May 13, 2011 at 2:35 AM, Ondrej Certik <[email protected]> wrote: > On Fri, May 13, 2011 at 1:26 AM, Vlada Peric <[email protected]> wrote: >> On Fri, May 13, 2011 at 3:22 AM, Saptarshi Mandal <[email protected]> >> wrote: >>> >>> Doing a git log shows that commit messages typically follow no clear >>> pattern. >>> The same can be said for patches too. >> >> I was playing around with git output last night, and a command such as this >> produces nice, clear output: >> >> git log --pretty=medium --reverse sympy-0.6.7..HEAD >> >> medium is to print the level of detail like in your examples, --reverse is >> to print oldest first (I feel that's a better approach in this case), and >> the last bit prints just the commits between the given tag and HEAD. You can >> add in --stat there to get the files changed, too. After some tinkering >> around, I wrote a following custom output which further condenses (as 20k >> lines and 2k commits is big however you look at it): >> >> git log --pretty=format:'%Cred%h: %an, %ad%n%Creset%+s%n%+b' --reverse >> sympy-0.6.7..HEAD >> >> (check it out, it prints a line in red with the commit shorthash, author >> name and commit date, and the text after. It can be combined with --stat, >> too) >> >> In any case, I intend to go through it all during today and tomorrow, but >> any help is welcome! >> >> As to the bigger issue of actually writing the logs, we could try to write >> more verbose commit messages (ie. kernel-style), we could make people edit >> some changelog file with every change they make (but this would lead to >> plentiful merge commits with that file), or we could simply release more >> often! I prefer the third option, for what it's worth. > > In any case, we should definitely release more often. :) > > Thanks for the git commands, I tried them, and it works great. > > Ondrej > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
