So, a couple more thoughts for consideration as we move to git. Opinions, thoughts, etc appreciated
* Get rid of the ChangeLog. We have the information in the commit history and git makes it nice and easy to get that. If we want to still have a ChangeLog in the tarball, we could generate one when creating the archive. Doing this leads to a need to ensure we have good commit messages, but that's largely the case already
* Don't carry the RPM spec file in the repository; have it just in the packaging repo instead.
Jeremy
Jeremy Katz (katzj@redhat.com) said:
So, a couple more thoughts for consideration as we move to git. Opinions, thoughts, etc appreciated
- Get rid of the ChangeLog. We have the information in the commit
history and git makes it nice and easy to get that. If we want to still have a ChangeLog in the tarball, we could generate one when creating the archive. Doing this leads to a need to ensure we have good commit messages, but that's largely the case already
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Won't this break cvs-import.sh?
Bill
On Thu, 2007-11-01 at 17:43 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Won't this break cvs-import.sh?
It breaks rpm -ta of the tarball. But that's not how I've been updating things at least. Instead, make archive, cp tarball, make new-source FILES=, .. etc by hand
Jeremy
Jeremy Katz (katzj@redhat.com) said:
On Thu, 2007-11-01 at 17:43 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Won't this break cvs-import.sh?
It breaks rpm -ta of the tarball. But that's not how I've been updating things at least. Instead, make archive, cp tarball, make new-source FILES=, .. etc by hand
True. I still find it useful to have the spec in with the main package for things like tweaking Requires, file lists, etc. - it's easier to change it along with the source changes that make the updates necessary.
Bill
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
On Fri, 2007-11-02 at 08:20 +0900, John Summerfield wrote:
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
Bit duplication and having to sync changes across between where the packages are built (which requires the spec file) and the upstream repo is a bit annoying at times
Jeremy
On Fri, 02 Nov 2007 09:05:03 -0400 Jeremy Katz katzj@redhat.com wrote:
On Fri, 2007-11-02 at 08:20 +0900, John Summerfield wrote:
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
Bit duplication and having to sync changes across between where the packages are built (which requires the spec file) and the upstream repo is a bit annoying at times
I would vote for not having the spec file in the git repository for anaconda. It's only relevant to the packaging and that lives in the package CVS for Fedora or RHEL.
Having to keep both spec files in sync is annoying and we have messed that up at various points so the actual spec file that goes out in the SRPM doesn't match what is in the upstream repo.
On the other hand, the spec file for anaconda does contain a lot of BuildRequires and other such things that are probably useful to those packaging it for other distributions. Maybe we could provide a spec file template in the git repo and not necessarily the whole changelog and specifics? Just to catch buildrequires and those kinds of things.
Jeremy Katz wrote:
On Fri, 2007-11-02 at 08:20 +0900, John Summerfield wrote:
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
Bit duplication and having to sync changes across between where the packages are built (which requires the spec file) and the upstream repo is a bit annoying at times
Jeremy
If I were to pull it from git, I'd be fairly put out to find I didn't have the build instructions as embodied in the spec file. I see the spec file as the primary "scripts used to control compilation and installation of the executable."
Why can't packaging use the spec file from the repo?
On Sat, 03 Nov 2007 08:16:55 +0900 John Summerfield debian@herakles.homelinux.org wrote:
Jeremy Katz wrote:
On Fri, 2007-11-02 at 08:20 +0900, John Summerfield wrote:
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
Bit duplication and having to sync changes across between where the packages are built (which requires the spec file) and the upstream repo is a bit annoying at times
Jeremy
If I were to pull it from git, I'd be fairly put out to find I didn't have the build instructions as embodied in the spec file. I see the spec file as the primary "scripts used to control compilation and installation of the executable."
It only runs 'make' and 'make install', so the Makefile(s) are actually the scripts used to control compilation and installation of the executable.
What is useful from the spec file is the BuildRequires, but we could fix that by having a ./configure script that checks the environment we are about to build on.
On Sat, 2007-11-03 at 11:41 -0400, David Cantrell wrote:
On Sat, 03 Nov 2007 08:16:55 +0900 John Summerfield debian@herakles.homelinux.org wrote:
Jeremy Katz wrote:
On Fri, 2007-11-02 at 08:20 +0900, John Summerfield wrote:
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
Bit duplication and having to sync changes across between where the packages are built (which requires the spec file) and the upstream repo is a bit annoying at times
Jeremy
If I were to pull it from git, I'd be fairly put out to find I didn't have the build instructions as embodied in the spec file. I see the spec file as the primary "scripts used to control compilation and installation of the executable."
It only runs 'make' and 'make install', so the Makefile(s) are actually the scripts used to control compilation and installation of the executable.
What is useful from the spec file is the BuildRequires, but we could fix that by having a ./configure script that checks the environment we are about to build on.
Keeping autoconf updated is easier/better than a spec file? I don't think so.
-sv
On Sat, 03 Nov 2007 13:44:36 -0400 seth vidal skvidal@fedoraproject.org wrote:
On Sat, 2007-11-03 at 11:41 -0400, David Cantrell wrote:
On Sat, 03 Nov 2007 08:16:55 +0900 John Summerfield debian@herakles.homelinux.org wrote:
Jeremy Katz wrote:
On Fri, 2007-11-02 at 08:20 +0900, John Summerfield wrote:
Jeremy Katz wrote:
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
Why?
Bit duplication and having to sync changes across between where the packages are built (which requires the spec file) and the upstream repo is a bit annoying at times
Jeremy
If I were to pull it from git, I'd be fairly put out to find I didn't have the build instructions as embodied in the spec file. I see the spec file as the primary "scripts used to control compilation and installation of the executable."
It only runs 'make' and 'make install', so the Makefile(s) are actually the scripts used to control compilation and installation of the executable.
What is useful from the spec file is the BuildRequires, but we could fix that by having a ./configure script that checks the environment we are about to build on.
Keeping autoconf updated is easier/better than a spec file? I don't think so.
I didn't say autoconf. I said a configure script. But I was just throwing the idea out there.
The problem we have right now is that in order to get a system set up to build anaconda, you have to either rely on the source RPM or read the spec file and pick and choose packages to install on your system and then you can run make. Personally, I don't like this because it's relying on RPM to be as integral to the build structure for anaconda as the Makefile.
If we were to offer some sort of configure script, either using autoconf/automake or not, it helps us detach anaconda from the RPM build system a bit more and make it more of a standalone project.
Again, just an idea.
Jeremy Katz wrote:
So, a couple more thoughts for consideration as we move to git. Opinions, thoughts, etc appreciated
- Get rid of the ChangeLog. We have the information in the commit
history and git makes it nice and easy to get that. If we want to still have a ChangeLog in the tarball, we could generate one when creating the archive. Doing this leads to a need to ensure we have good commit messages, but that's largely the case already
+
Don't like doing the log thing twice (Change Log and then cvs or git log :) Lets just do it once !!!
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
IMO, its kinda nice having there, although it doesnt *really* belong there. I would leave it there. :)
Jeremy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Fri, Nov 02, 2007 at 10:21:55AM +0100, Joel Andres Granados wrote:
Jeremy Katz wrote:
So, a couple more thoughts for consideration as we move to git. Opinions, thoughts, etc appreciated
- Get rid of the ChangeLog. We have the information in the commit
history and git makes it nice and easy to get that. If we want to still have a ChangeLog in the tarball, we could generate one when creating the archive. Doing this leads to a need to ensure we have good commit messages, but that's largely the case already
+
Don't like doing the log thing twice (Change Log and then cvs or git log :) Lets just do it once !!!
Git can also give you the list of modified files and I've been actually using this approach for some time now to generate the changelog and commit message template.
(It involved some bash hacking, but worked pretty well ;)
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
It does not hurt to have it there just in case we need to build some non-standard rpm... even if we do not I would leave it in the upstream repo.
On Fri, 2007-11-02 at 13:16 +0100, Martin Sivak wrote:
On Fri, Nov 02, 2007 at 10:21:55AM +0100, Joel Andres Granados wrote:
Jeremy Katz wrote:
So, a couple more thoughts for consideration as we move to git. Opinions, thoughts, etc appreciated
- Get rid of the ChangeLog. We have the information in the commit
history and git makes it nice and easy to get that. If we want to still have a ChangeLog in the tarball, we could generate one when creating the archive. Doing this leads to a need to ensure we have good commit messages, but that's largely the case already
Don't like doing the log thing twice (Change Log and then cvs or git log :) Lets just do it once !!!
Git can also give you the list of modified files and I've been actually using this approach for some time now to generate the changelog and commit message template.
(It involved some bash hacking, but worked pretty well ;)
Yeah, it can be done, but it's mostly busy work. Also, it makes merging work less well. Especially if you do it frequently across branches.
- Don't carry the RPM spec file in the repository; have it just in the
packaging repo instead.
It does not hurt to have it there just in case we need to build some non-standard rpm... even if we do not I would leave it in the upstream repo.
The main reason I lean towards not is (as my other reply states) that syncing changes between two places for the same file is a little annoying. I don't feel too strongly either way, though
Jeremy
Okay, so based on the feedback on the thread, I'm going to nuke the ChangeLog later today from the repo and set up auto-generation of it when we build the archive tarball. We'll keep the spec file in the repo for now and see how it goes
Jeremy
On Mon, 2007-11-05 at 09:51 -0500, Jeremy Katz wrote:
Okay, so based on the feedback on the thread, I'm going to nuke the ChangeLog later today from the repo and set up auto-generation of it when we build the archive tarball. We'll keep the spec file in the repo for now and see how it goes
And on the related note of commit message formatting...
Now that commits should be smaller, doing the per-file breakdown formatting isn't entirely necessary. Important things for the log messages are to have the first line of the commit be a short summary as this is what is shown in git shortlog, gitweb and other similar places.
Following that should be a more detailed change description. If you want to break this down per-file and function, you can or you can make it more descriptive. Note that comments in code are better than documenting the details of how a function works in the commit message :-)
Jeremy
anaconda-devel@lists.fedoraproject.org
-
Bill Nottingham -
David Cantrell -
Jeremy Katz -
Joel Andres Granados -
John Summerfield -
Martin Sivak -
seth vidal