On Fri, May 13, 2011 at 4:10 AM, Vlada Peric <[email protected]> wrote:
> On Fri, May 13, 2011 at 11:09 AM, Aaron Meurer <[email protected]> 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).
I'm not sure how well it does with that. The auto-merging tends to be
for code that is completely separate (all the diff including the
context is the same).
> The ways not to forget anything is to simply not accept commits which don't
> make a corresponding change to the changelog file.
I'm not sure how I would feel about that kind of policy. I think
having it on the wiki would be better, for one thing.
>
>>
>> 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.
No. Unless everyone enforces these rules always, it would be no good,
because there would be some commits that would not follow it. And,
like I said before, I'm not really a fan of real strict commit message
rules.
>
>>
>> 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.
Definitely, though your example is kind of a bad one, because trivial
fixes like whitespace fixes should actually usually just be squashed
into some other commit.
By the way, another idea other than looking at the git log would be to
take a look at all the issues that have been closed since the last
release. You would still have to go through each one to see what was
done, but it might be a little more informative than the commit
messages. Anyway, just an idea.
Aaron Meurer
>
>>
>> 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.
>>
>
>
>
> --
> Vlada Perić
>
> --
> 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.
