Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Tue, Nov 25, 2008 at 09:02:54PM -0600, Dennis Gilmore wrote: I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make make tag do the build also. The trouble is -- after you make tag(-minor)-release, you should review that commit, then push that commit and that tag, and only then you can do the build. So there is a human action (that review) required in between. Running make tag(-minor)-release is a way the developer marks that part of work finished, and claims he/she is ready to get the rpms built from that tag. Mirek's automatic build setup can then handle that. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
Jan Pazdziora wrote: I'd consider it a feature. The developer should tag the package when he/she feels it is reasonably stable to be built into -candidate. There is however nothing wrong with the developer pushing their work to the public repo (for others to see and work on), even if the thing is not yet stable enough to be usable. That is probably OK with small packages (like nocpulse-common), but it do not work with main packages (like java), which are usually rebuild only once just before the final release. Therefore nobody can test it. Why do you want to build packages from state when they were not tagged (= signed off by developer)? Just wait for the developer to make tag(-minor)-release. That is for what people create nightly builds. You do not want it? Do not use it and wait for QA repo. You want test even partial work. Use it. And the code in git should work. If it do not work, why did you push it there in first place. But again the main reason is stated in my first paragraph of this email. -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Tue, Nov 25, 2008 at 11:56:36AM +0100, Miroslav Suchý wrote: Right now we build into tag dist-5E-sw-0.4-candidate. When I have been working on that nightly repo I find one good reason why we should use tag dist-5E-sw-0.4 and only successful builds tagged there from dist-5E-sw-0.4-candidate. The reason are nightly builds. If the build is not successful, you don't have any build to tag. Now the package get into nightly repo only if you tagged that package in git. I'd consider it a feature. The developer should tag the package when he/she feels it is reasonably stable to be built into -candidate. There is however nothing wrong with the developer pushing their work to the public repo (for others to see and work on), even if the thing is not yet stable enough to be usable. If you do not tagged it there we have two possibility how to build the package. 1) Automatically tag the package in git and current script will then automatically pick it up for rebuild. Honestly - I do not like such option. -1 (or +1 to your dislike). 2) Create tag dist-5E-sw-0.4. Normally build into But we have that tag now. dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. unsuccessful? Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. Why do you want to build packages from state when they were not tagged (= signed off by developer)? Just wait for the developer to make tag(-minor)-release. -1. 3) OK. There is third option. To build .git.longsha1 packages in dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will create only mess. I'm scratching such option. -1. How do you like it? Or do you have another idea how to implement nightly builds? I feel that the setup we have now, when you build any newly tagged package releases to -candidate, is the best way to go, for nightly build purposes. We could certainly use weekly snapshots which would be tagged into dist-5E-sw-0.4 and which would contain a set of rpms that were verified to at least install, configure, and run. So that if someone needs a bleeding edge Spacewalk for further testing or development, they could pick that one. But I do not think that building from untagged commits (those .git.longsha1 created by make test-srpm) is necessary, nor useful. -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Wed, Nov 26, 2008 at 11:29:25AM +0100, Miroslav Suchý wrote: Are we still speaking about nightly builds? Now I only care about final release that way that I do not want to break process of final release. Ok. So make the question straight: Will I break something in your rel-eng realm, if I start building testing packages (like SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636.src.rpm) in dist-5E-sw-0.4-candidate? You are likely to break the nightly repos for other people. The developer / maintainer of SatConfig-installer had a reason not to his/her changes that are there on top of SatConfig-installer-3.24.4-1. Why not wait till the developer / maintainer is confident with the code and then build from new tag that he/she will create? -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
Dennis Gilmore wrote: I think we can assume if its not tagged that means that the work is not complete and not ready to be built or tested. I spoke about make tag-release, which make git tag. Do not mistake it for koji tag. 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. Im assuming that you mean moving successful builds into dist-5E-sw-0.4 No I meant koji tag-pkg dist-5E-sw-0.4 sucessfull-build I really do not see benefit of moving in compare to tag it to final tag as well (beside the -candidate one) I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make make tag do the build also. Are we still speaking about nightly builds? Now I only care about final release that way that I do not want to break process of final release. Ok. So make the question straight: Will I break something in your rel-eng realm, if I start building testing packages (like SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636.src.rpm) in dist-5E-sw-0.4-candidate? -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Tue, Nov 25, 2008 at 09:02:54PM -0600, Dennis Gilmore wrote: I honestly do not like how when you tag something it bumps the release. Well, the primary reason why we have the tag-release and tag-minor-release Makefile targets is to bump the version or release, and then tag that. Could you elaborate why you do not like it? I fell that when we do a release all tarballs should be that release so for 0.4 we should have spacewalk-java-0.4.0.tar.gz or spacewalk-java-0.4.0.tar.bz2 and bug fixes in the 0.4 series get 0.4.1 etc That would mean that when you do a release and then find a problem in Java and want to release package with a fix, you have to bump and rebuild all other packages. Spacewalk is a collection of packages and at least from technical and rpmbuild's POV, they are independent. every other open source project ive worked with (mysql does something simmiliar to how spacewalk is working) uses RCS snapshots for prerelease testingor in the case of gnome and KDE for 0.4 they would use 0.3.85 etc, We could use this. However, does the extra work needed to achieve that justify the benefits? -- Jan Pazdziora Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Wednesday 26 November 2008 04:29:25 am Miroslav Suchý wrote: Dennis Gilmore wrote: I think we can assume if its not tagged that means that the work is not complete and not ready to be built or tested. I spoke about make tag-release, which make git tag. Do not mistake it for koji tag. 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. Im assuming that you mean moving successful builds into dist-5E-sw-0.4 No I meant koji tag-pkg dist-5E-sw-0.4 sucessfull-build I really do not see benefit of moving in compare to tag it to final tag as well (beside the -candidate one) tagging packages like that is the completely wrong thing to do. we should run koji move-tag dist-5E-sw-0.4-candidate dist-5E-sw-0.4 successful build you said unsuucessful build initially which is why i assumed successful build. moving the package out of the candidate tag lets us know that its been though some level of checking. I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make make tag do the build also. Are we still speaking about nightly builds? Now I only care about final release that way that I do not want to break process of final release. Ok. So make the question straight: Will I break something in your rel-eng realm, if I start building testing packages (like SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636.s rc.rpm) in dist-5E-sw-0.4-candidate? If you do that it wont break anything but I really would prefer that you do not do that. packages built in candidate should be builds that could be considered for the final release. how about we set up a dist-5E-sw-0.4- snapshot tag? you can freely build whatever you want in it. since it will not be in consideration for the release. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Nov 2008 14:23:15 +0100 Jan Pazdziora [EMAIL PROTECTED] wrote: To summarize: from my point of view building test-srpm (the .git.longsha1) packages to dist-5E-sw-0.4-candidate is counterinuitive. It has that longsha1 in its name for a reason, to warn everybody that it was built from some random commit, not signed off by the developer (via make tag-release). If you start feeding them to dist-5E-sw-0.4-candidate, before long they will make their way to dist-5E-sw-0.4 and you will see things like SatConfig-general-1.215.38-7.git.4c57d3b9f251dd5dc7113ecf37c30cecbb6d88c1.i386.rpm in our yum repo. Other guys might have different opinion. Just to chime in with my preference, I think I'd prefer to have it remain largely as we do today. - - Require manual package rebuilds. (assign people to keep a loose eye on certain packages if there's a genuine problem with no re-builds taking place) - - Keep the version going up for each internal rebuild. Yes we release spacewalk-package-0.4.159 but I like that each new version signifies a new tarball inside and we don't have to do any fancy patching. Even if we decided on a way to bump versions during devel cycle but then go to 0.4.0 at release would be nice. - - I'm not really keen on test-rpms appearing anywhere. I'd rather just keep using these as a developer tool and anything appearing in repos be versioned normally. Having the devel repo contain only packages that *somebody* decided to manually tag seems good to me. Devan - -- Devan Goodwin [EMAIL PROTECTED] Software Engineer - Spacewalk / RHN Satellite Halifax, Canada650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkktbTYACgkQAyHWaPV9my7WggCfQW/ehHlEXdwtW5YeH19jOtrC 1rEAn2WowCGyPVcoPqFq5+LYWyJz55W9 =Kl2h -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Wed, Nov 26, 2008 at 8:23 AM, Jan Pazdziora [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 01:50:45PM +0100, Miroslav Suchý wrote: That is probably OK with small packages (like nocpulse-common), but it do not work with main packages (like java), which are usually rebuild only once just before the final release. Therefore nobody can test it. I assume guys working on spacewalk-java do not consider it stable enough yet, that's why they did not tag it. It's not that is it unstable, it is mostly because no one asked for them :) most of the folks working on spacewalk-java use the latest code from git and test it as we go along. Sure it doesn't test on an installed system, it just gets used on an on going basis. Another issue is we don't have a clear package owner, I've been the defacto owner but even then I don't consider myself 'THE OWNER' of the package, just the guy who builds it the most :) As far as auto building the rpm, I don't like that idea. I prefer that a developer build it manually. Why do you want to build packages from state when they were not tagged (= signed off by developer)? Just wait for the developer to make tag(-minor)-release. That is for what people create nightly builds. You do not want it? Do not use it and wait for QA repo. You want test even partial work. Use it. And the code in git should work. If it do not work, why did you push it there in first place. Because you are allowed to do so. I'm not that perfect and sometimes things do not work the first time I feel I'm finished. And I have to fix stuff. Agreed. I understand that some projects to nightly builds, but usually it's a tar ball they are building, not a complete set of packages. I have no problem with us building a nightly repo based on built packages from that day. So if I want my changes to be in tonights nightly build, I need to push my changes, *AND* build the packages so they get pulled in by the nightly process. Otherwise, the nightly remains the same if no new packages were built. I don't see what a nightly pull from git will prove except a new bug or two. I certainly don't want to be chasing bugs down in a nightly repo when I didn't want my stuff out there yet. But again the main reason is stated in my first paragraph of this email. Ask developers of packages that don't seem to be tagged (often enough) why they do not tag them. To summarize: from my point of view building test-srpm (the .git.longsha1) packages to dist-5E-sw-0.4-candidate is counterinuitive. It has that longsha1 in its name for a reason, to warn everybody that it was built from some random commit, not signed off by the developer (via make tag-release). If you start feeding them to dist-5E-sw-0.4-candidate, before long they will make their way to dist-5E-sw-0.4 and you will see things like SatConfig-general-1.215.38-7.git.4c57d3b9f251dd5dc7113ecf37c30cecbb6d88c1.i386.rpm in our yum repo. Other guys might have different opinion. +1 I don't like building the git.longsha1 in -candidate tag. To me if I want to build a git.sha1 I'll build it on my workstation so I can test it. If it works, then I can tag and build it, and let it go into the nightly for others to use. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
Just to chime in with my preference, I think I'd prefer to have it remain largely as we do today. - - Require manual package rebuilds. (assign people to keep a loose eye on certain packages if there's a genuine problem with no re-builds taking place) - - Keep the version going up for each internal rebuild. Yes we release spacewalk-package-0.4.159 but I like that each new version signifies a new tarball inside and we don't have to do any fancy patching. Even if we decided on a way to bump versions during devel cycle but then go to 0.4.0 at release would be nice. - - I'm not really keen on test-rpms appearing anywhere. I'd rather just keep using these as a developer tool and anything appearing in repos be versioned normally. Having the devel repo contain only packages that *somebody* decided to manually tag seems good to me. I concur with all of the above. jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
Jesus M. Rodriguez wrote: As far as auto building the rpm, I don't like that idea. I prefer that a developer build it manually. OK. I'm outvoted :) So we keep the nightly repos in current state, where it builds only package, which are git-tagged. Can I politely ask all you folks to do add changelog entry in .spec file make tag-release gitk -all git push git push --tags whenever you finish some bug or feature. Thanks -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Wednesday 26 November 2008 06:24:48 am Jan Pazdziora wrote: On Wed, Nov 26, 2008 at 11:29:25AM +0100, Miroslav Suchý wrote: Are we still speaking about nightly builds? Now I only care about final release that way that I do not want to break process of final release. Ok. So make the question straight: Will I break something in your rel-eng realm, if I start building testing packages (like SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636 .src.rpm) in dist-5E-sw-0.4-candidate? You are likely to break the nightly repos for other people. The developer / maintainer of SatConfig-installer had a reason not to his/her changes that are there on top of SatConfig-installer-3.24.4-1. Why not wait till the developer / maintainer is confident with the code and then build from new tag that he/she will create? that is my thoughts. if its untagged its likely on purpose and we should ignore it until a deliberate action by a developer Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
Right now we build into tag dist-5E-sw-0.4-candidate. When I have been working on that nightly repo I find one good reason why we should use tag dist-5E-sw-0.4 and only successful builds tagged there from dist-5E-sw-0.4-candidate. The reason are nightly builds. Now the package get into nightly repo only if you tagged that package in git. If you do not tagged it there we have two possibility how to build the package. 1) Automatically tag the package in git and current script will then automatically pick it up for rebuild. Honestly - I do not like such option. 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. 3) OK. There is third option. To build .git.longsha1 packages in dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will create only mess. I'm scratching such option. How do you like it? Or do you have another idea how to implement nightly builds? -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Tuesday 25 November 2008 04:56:36 am Miroslav Suchý wrote: Right now we build into tag dist-5E-sw-0.4-candidate. When I have been working on that nightly repo I find one good reason why we should use tag dist-5E-sw-0.4 and only successful builds tagged there from dist-5E-sw-0.4-candidate. The reason are nightly builds. Now the package get into nightly repo only if you tagged that package in git. If you do not tagged it there we have two possibility how to build the package. I think we can assume if its not tagged that means that the work is not complete and not ready to be built or tested. 1) Automatically tag the package in git and current script will then automatically pick it up for rebuild. Honestly - I do not like such option. I do not like that either 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. Im assuming that you mean moving successful builds into dist-5E-sw-0.4 I honestly do not like how when you tag something it bumps the release. I fell that when we do a release all tarballs should be that release so for 0.4 we should have spacewalk-java-0.4.0.tar.gz or spacewalk-java-0.4.0.tar.bz2 and bug fixes in the 0.4 series get 0.4.1 etc every other open source project ive worked with (mysql does something simmiliar to how spacewalk is working) uses RCS snapshots for prerelease testingor in the case of gnome and KDE for 0.4 they would use 0.3.85 etc, I can live with how it currently is though. 3) OK. There is third option. To build .git.longsha1 packages in dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will create only mess. I'm scratching such option. How do you like it? Or do you have another idea how to implement nightly builds? tag dist-5E-sw-0.4 already exists once we get closer to release and start doing QA on the release, i envisioned running koji move-tag on everything in candidate at that time to dist-5E-sw-0.4. we would then sign the packages and do the composes on dist-5E-sw-0.4 which would be what gets pushed out as 0.4. the composes from the candidate tags are testing repos. I expect that the repos from the candidate tags can be used to prove that your build fixes the bugs or adds the features that they are supposed to. and once proven we will move to dist-5E-sw-0.4, sign the package and push it out. I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make make tag do the build also. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
