On Fri, May 13, 2011 at 11:09 AM, Aaron Meurer <asmeu...@gmail.com> wrote:
> 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.
>
Well, by my (not-completely-accurate) count, there's about 2000 commits
since the release some 14 months ago. If there was a release quarterly, it
would have been some 400-500 commits, which is much easier to handle. As
SymPy generally follows the "it's always summer in trunk" release model,
there's really no reason not to have a regular quarterly release.
>
> 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)?
>
The problem is that it leads to tons of (trivial) merge conflicts. Say both
you and me add some small feature, and write it to the end of the changelog.
Then whoever gets pushed in second will have a merge conflict. Sure, it's
simple enough to fix, but it's going to happen every single time (then
again, maybe git is smart enough to handle it automatically, I don't know).
The ways not to forget anything is to simply not accept commits which don't
make a corresponding change to the changelog file.
>
> 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.
>
Well, yeah, you're right, it would just make it easier to do the same thing.
Writing good commit messages is important, though. Alternatively, we could
try using some keywords so that we know what to look for when making the
log. So, if there is some functionality added, the commit message must
contain "add" or "added" or "implemented", if something is renamed then use
"renamed" or "changed" etc. Then, one could just grep for the keywords when
writing the log. Not really that robust of a solution on it's own, though.
>
> 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.
>
Well, I was under the impression there's a formal standard, but I can't find
anything now. The important things, in my opinion, are to follow the
subject/body standard (so, a one line description, a blank line, then a
detailed explanation). This is what's the usual case in SymPy (though
there's a lot of commits with no real explanation, just the subject line).
The kernel people also refer to the subsystem affected, which I think is
good practice (so, we'd have: "polys: fix error when..." as a subject). Yes,
you can get this information by looking at the files changed, but it's more
cumbersome (what if I changed a thousand files?). Finally, and this relates
to commits in general: changes ought to be atomic. So, a commit should do
one thing and one thing only (no "Added sqrt, fixed bug 123, fix whitespace
errors"). However, if a commit is a single logical change, it should be a
single commit regardless of how many files it affects ("physics: removing
unused imports"). Well, those are some general thoughts at least - perhaps a
new thread would be a good idea to further discuss this? I could write some
draft guidelines after going through our history, and we could work from
there.
>
> Aaron Meurer
>
> On Fri, May 13, 2011 at 2:35 AM, Ondrej Certik <ond...@certik.cz> wrote:
> > On Fri, May 13, 2011 at 1:26 AM, Vlada Peric <vlada.pe...@gmail.com>
> wrote:
> >> On Fri, May 13, 2011 at 3:22 AM, Saptarshi Mandal <
> sapta.iit...@gmail.com>
> >> 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 sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> > 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 sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>
--
Vlada Perić
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
