These are the things that I can think of that still need to be done before we release 0.5.0:
NEWS/CHANGELOG (jdulaney) Git tagging and updating (tflink, kparal) Spec file update (jlaska) Announcements (?) Final Doc Check (everyone)
Please correct me if I missed or misunderstood anything.
Tim
On Mon, 2011-06-27 at 10:34 -0600, Tim Flink wrote:
These are the things that I can think of that still need to be done before we release 0.5.0:
NEWS/CHANGELOG (jdulaney) Git tagging and updating (tflink, kparal)
Spec file update (jlaska)
PUSHED and tagged. I can change the tag should any additional changes destined for 0.5.0 land in master.
Announcements (?) Final Doc Check (everyone)
Please correct me if I missed or misunderstood anything.
Good idea to send this out to the list for coordination.
Thanks, James
Ok, the current ChangeLog is up (1).
What I'm thinking is two things:
It may be a good idea to modify the script at (2) to automagically replace 'Ticket #x' with the ticket URL. Of course, that would require that from now on, that specific format for referencing the tickets will be a must.
The other thing I'm considering is how to automate ChangeLog creation. Maybe add the script to the server and include running it in the merge to master process? The issue becomes how to include the ChangeLog in the Git repository, but make it so that the Git log doesn't wind up getting ChangeLog modified type messages. Maybe just not git add the file in the master? But then, how to keep the ChangeLog when master is cloned?
(1) http://jdulaney.fedorapeople.org/autoqa/ChangeLog (2) https://binarystatic.wordpress.com/2010/02/18/how-to-convert-git-log-to-chan...
On Mon, 2011-06-27 at 14:00 -0400, John Dulaney wrote:
The other thing I'm considering is how to automate ChangeLog creation. Maybe add the script to the server and include running it in the merge to master process? The issue becomes how to include the ChangeLog in the Git repository, but make it so that the Git log doesn't wind up getting ChangeLog modified type messages. Maybe just not git add the file in the master? But then, how to keep the ChangeLog when master is cloned?
I'm partial to the idea used by some GNOME teams (http://live.gnome.org/Git/ChangeLog) to link the ChangeLog generation into the Makefile.
There's another example of a sample script used to convert git logs to ChangeLog at http://blog.cryos.net/archives/202-Git-and-Automatic-ChangeLog-Generation.ht.... It'd be nice to not required another "script" but to generate the content using the appropriate git-log arguments (if possible). An example that generates something close to your example is ...
# git log --date=short --no-merges --pretty="%an <%ae> %ad%n%n% s%n%+b" v0.5.0-0.2.pre..origin
Thanks, James
On 06/27/2011 12:00 PM, John Dulaney wrote:
Ok, the current ChangeLog is up (1).
What I'm thinking is two things:
It may be a good idea to modify the script at (2) to automagically replace 'Ticket #x' with the ticket URL. Of course, that would require that from now on, that specific format for referencing the tickets will be a must.
The other thing I'm considering is how to automate ChangeLog creation. Maybe add the script to the server and include running it in the merge to master process? The issue becomes how to include the ChangeLog in the Git repository, but make it so that the Git log doesn't wind up getting ChangeLog modified type messages. Maybe just not git add the file in the master? But then, how to keep the ChangeLog when master is cloned?
Cool, I assume that was all generated using the script you linked to?
I guess I was thinking of something different for the NEWS/ChangeLog than that - just something describing the high-level changes to the project since the last release instead of a description of all the commits.
I'm not sure there is a whole lot of utility out of keeping messages like these in a file:
Kamil Páral kparal@redhat.com 2011-06-13
pretty_log: colorize result
Tim Flink tflink@fedoraproject.org 2011-06-10
detect python version in runtests.sh instead of assuming 2.7
Tim Flink tflink@fedoraproject.org 2011-06-10
removing finally block that doesn't work on el5
James Laska jlaska@redhat.com 2011-06-10
More missing BuildRequires
If someone really wanted that level of detail, I think that git log would be a much better route (easier to filter, colorized, customizable etc.).
Thoughts?
Tim
On Mon, 2011-06-27 at 14:53 -0400, James Laska wrote:
On Mon, 2011-06-27 at 14:00 -0400, John Dulaney wrote:
The other thing I'm considering is how to automate ChangeLog creation. Maybe add the script to the server and include running it in the merge to master process? The issue becomes how to include the ChangeLog in the Git repository, but make it so that the Git log doesn't wind up getting ChangeLog modified type messages. Maybe just not git add the file in the master? But then, how to keep the ChangeLog when master is cloned?
I'm partial to the idea used by some GNOME teams (http://live.gnome.org/Git/ChangeLog) to link the ChangeLog generation into the Makefile.
There's another example of a sample script used to convert git logs to ChangeLog at http://blog.cryos.net/archives/202-Git-and-Automatic-ChangeLog-Generation.ht.... It'd be nice to not required another "script" but to generate the content using the appropriate git-log arguments (if possible). An example that generates something close to your example is ...
# git log --date=short --no-merges --pretty="%an <%ae> %ad%n%n% s%n%+b" v0.5.0-0.2.pre..origin
Actually, the more I think about it, the more I'm inclined to recommend we do this properly, and not cram it in at the last minute. By properly I mean figure out what we're trying to accomplish here. Creating a script/Makefile to generate a ChangeLog shouldn't be hard ... but do we really need one?
Unless there are no objections, I propose we figure out the most sustainable ChangeLog approach post-release. I don't think this should stand in the way of getting 0.5.0 out the door.
Thanks, James
On 06/27/2011 10:34 AM, Tim Flink wrote:
These are the things that I can think of that still need to be done before we release 0.5.0:
NEWS/CHANGELOG (jdulaney) Git tagging and updating (tflink, kparal) Spec file update (jlaska) Announcements (?) Final Doc Check (everyone)
I went through and did a merge of master into stable in order to bring it up to date.
As a test run, I pushed it up to github instead of the fedorahosted repo:
https://github.com/tflink/autoqa-devel
If this change is OK, I can push to the fedorahosted repo.
Tim
Final Doc Check (everyone)
I read the new depcheck doc, trying to face it as if I was previously unfamiliar package maintainer (a fact that I tried to keep my hands as far away from depcheck afairs as possible before certainly helped :-) ). It's short(won't dis-persuade from reading) and simple and well written! I followed reading the wwoods' blog to dig into more details on how the depcheck works, but I'd say the doc establishes the need-to-know for maintainers well.
I guess it won't help understand failures *of* depcheck, but that is a whole other story :)
-- Vita Humpa Fedora QA
# git log --date=short --no-merges --pretty="%an <%ae> %ad%n%n% s%n%+b" v0.5.0-0.2.pre..origin
Actually, the more I think about it, the more I'm inclined to recommend we do this properly, and not cram it in at the last minute. By properly I mean figure out what we're trying to accomplish here. Creating a script/Makefile to generate a ChangeLog shouldn't be hard ... but do we really need one?
Unless there are no objections, I propose we figure out the most sustainable ChangeLog approach post-release. I don't think this should stand in the way of getting 0.5.0 out the door.
Thanks, James
I agree to discuss this later, it's not really necessary for 0.5.0.
I guess I was thinking of something different for the NEWS/ChangeLog than that - just something describing the high-level changes to the project since the last release instead of a description of all the commits.
If someone really wanted that level of detail, I think that git log would be a much better route (easier to filter, colorized, customizable etc.).
I have exactly the same opinion. There is no sense in copying git log into a separate file. Anyone wanting to see the list of commits can look into git directly, with much more detail and possibilities than we can offer in a single file.
This file should contain only high-level list of changes. It can be just a few lines about features added, bugs fixed, etc. No need to list every single typo-related commit that happened. It can also speak in much more human language than commit messages usually do.
It is important to ask ourselves what we are trying to accomplish. I would like to give people a short list of important changes in a release, similarly to what I do when announcing new release in my blogposts. We can also include a recipe how to display the full commit log.
On 06/27/2011 10:34 AM, Tim Flink wrote: I went through and did a merge of master into stable in order to bring it up to date.
As a test run, I pushed it up to github instead of the fedorahosted repo:
https://github.com/tflink/autoqa-devel
If this change is OK, I can push to the fedorahosted repo.
Tim
Hey Tim, could you please next time push to some branch in our git repo instead? I don't understand the reason to push to another repo. It's much easier to look at a particular branch than to add a new remote repo.
Now that I know how to do it:-), I'll share with others:
$ git remote add tf git://github.com/tflink/autoqa-devel.git $ git fetch tf
Now when I do:
$ git diff origin/master tf/stable
I see some weird differences, I don't think the code is ok. You tried to merge it, right? That's the reason why I suggested diff-patch approach [1], to be sure that stable is exactly same as 0.5.0 as tagged in master.
If there are no further changes waiting, I'll gladly tag the release and update the stable branch.
On 06/28/2011 05:00 AM, Kamil Paral wrote:
On 06/27/2011 10:34 AM, Tim Flink wrote: I went through and did a merge of master into stable in order to bring it up to date.
As a test run, I pushed it up to github instead of the fedorahosted repo:
https://github.com/tflink/autoqa-devel
If this change is OK, I can push to the fedorahosted repo.
Tim
Hey Tim, could you please next time push to some branch in our git repo instead? I don't understand the reason to push to another repo. It's much easier to look at a particular branch than to add a new remote repo.
I did it that way because I can share code and there is no way it can unintentionally affect the main repo and adding remotes in git is easy. I can also delete all history of the merge without affecting other people in a meaningful way.
Now that I know how to do it:-), I'll share with others:
$ git remote add tf git://github.com/tflink/autoqa-devel.git $ git fetch tf
Now when I do:
$ git diff origin/master tf/stable
I see some weird differences, I don't think the code is ok. You tried to merge it, right? That's the reason why I suggested diff-patch approach [1], to be sure that stable is exactly same as 0.5.0 as tagged in master.
Yes, I did do a merge instead of extract/patch. I don't have an explanation for what shows up in that diff but if you look at the files or do a diff with their common ancestor (instead of between the branch heads), they're the same.
I thought that my crash course on git internals yesterday would have been enough to figure this out but perhaps not.
I don't understand why preserving history isn't important, why tagging on stable is better or the lack of release branches. My lack of understanding isn't enough to argue and delay 0.5.0's release, though. The right code will end up being released.
If there are no further changes waiting, I'll gladly tag the release and update the stable branch.
Go for it. James tagged master yesterday (if that's what you were talking about) and I don't think that there have been changes since then.
Tim
Now when I do:
$ git diff origin/master tf/stable
I see some weird differences, I don't think the code is ok. You tried to merge it, right? That's the reason why I suggested diff-patch approach [1], to be sure that stable is exactly same as 0.5.0 as tagged in master.
Yes, I did do a merge instead of extract/patch. I don't have an explanation for what shows up in that diff but if you look at the files or do a diff with their common ancestor (instead of between the branch heads), they're the same.
They're not, e.g. see: https://github.com/tflink/autoqa-devel/blob/stable/autoqa.spec#L94
That is a remnant of a merge that's displayed when diffing the branches, and it's really included in that file.
I don't understand why preserving history isn't important, why tagging on stable is better or the lack of release branches. My lack of understanding isn't enough to argue and delay 0.5.0's release, though. The right code will end up being released.
Let's do it my way this time and we can develop better approaches in the future. I'll send some explanation soon.
On 06/28/2011 07:32 AM, Kamil Paral wrote:
Now when I do:
$ git diff origin/master tf/stable
I see some weird differences, I don't think the code is ok. You tried to merge it, right? That's the reason why I suggested diff-patch approach [1], to be sure that stable is exactly same as 0.5.0 as tagged in master.
Yes, I did do a merge instead of extract/patch. I don't have an explanation for what shows up in that diff but if you look at the files or do a diff with their common ancestor (instead of between the branch heads), they're the same.
They're not, e.g. see: https://github.com/tflink/autoqa-devel/blob/stable/autoqa.spec#L94
That is a remnant of a merge that's displayed when diffing the branches, and it's really included in that file.
Not sure how I missed that one when merging :-/. All the more reason to delete it.
As a bit of explanation behind my assertion,the follwing command shows no changes (diff between the two branches and their common ancestor, AFAIK) git diff origin/stable...upstream/master
but this (diff between the heads) does
git diff origin/stable..upstream master
it turns out that reversing the order of the branches for the common ancestor diff also shows changes: git diff upstream/master...origin/stable
(note that in this case origin -> github, upstream -> fedorahosted)
Like I said, it looks like I have more learning to do on how to use some parts of git.
I don't understand why preserving history isn't important, why tagging on stable is better or the lack of release branches. My lack of understanding isn't enough to argue and delay 0.5.0's release, though. The right code will end up being released.
Let's do it my way this time and we can develop better approaches in the future. I'll send some explanation soon.
Yep, that's pretty much what I was thinking.
Tim
As a bit of explanation behind my assertion,the follwing command shows no changes (diff between the two branches and their common ancestor, AFAIK) git diff origin/stable...upstream/master
but this (diff between the heads) does
git diff origin/stable..upstream master
it turns out that reversing the order of the branches for the common ancestor diff also shows changes: git diff upstream/master...origin/stable
(note that in this case origin -> github, upstream -> fedorahosted)
Like I said, it looks like I have more learning to do on how to use some parts of git.
In your examples you use two fullstops and three fullstops. Be very careful about that, they have different meaning. Furthermore, they have different meaning in generic git commands from the meaning in git diff command (extremely confusing). It's probably a good topic for the next "git tip of the day".
On 06/28/2011 08:01 AM, Kamil Paral wrote:
As a bit of explanation behind my assertion,the follwing command shows no changes (diff between the two branches and their common ancestor, AFAIK) git diff origin/stable...upstream/master
but this (diff between the heads) does
git diff origin/stable..upstream master
it turns out that reversing the order of the branches for the common ancestor diff also shows changes: git diff upstream/master...origin/stable
(note that in this case origin -> github, upstream -> fedorahosted)
Like I said, it looks like I have more learning to do on how to use some parts of git.
In your examples you use two fullstops and three fullstops. Be very careful about that, they have different meaning. Furthermore, they have different meaning in generic git commands from the meaning in git diff command (extremely confusing). It's probably a good topic for the next "git tip of the day".
The different number of stops was intentional and sourced from the git book: http://book.git-scm.com/3_comparing_commits_-_git_diff.html
Tim
autoqa-devel@lists.fedorahosted.org
-
James Laska -
John Dulaney -
Kamil Paral -
Tim Flink -
Vitezslav Humpa