Re: 6.2.0 tag
On Thursday 01 February 2007 02:54, Randy McMurchy wrote: My belief (and I'm quite strong on this one) is that we should use SVN in our best interests, which means for us (at least in my opinion) that tags are a stagnant entity, but branches are meant to be used for merges from trunk. Just to give you my perspective from the LFS Release Manager side of things. I had this exact same discussion a while back with Archaic with regard to the LFS releases. I was mandating we follow the old CVS style workflow, where tags shouldn't/couldn't be updated. Discussing it with Archaic and Ben Collins-Sussman (a Subversion developer, on IRC), I soon got around to the SVN way of working and realized, like Randy, that the tool should be used to support our needs rather than our workflow having to conform to the tool's expectations. As SVN allows tags to be changed, why not make use of that feature? So, in short, I'd say copy trunk to a 6.2 tag, then update general.ent on the tag. That's how things are done on LFS, at least. Randy, if it'd help, I have a release-script.sh file in my home directory on quantum that helps me automate LFS releases. It may be possible to coax it to do a similar job for BLFS, if you think that'd be useful? I can't take the credit for that script though, it's all Archaic's fine work! Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
On 1/31/07, Randy McMurchy [EMAIL PROTECTED] wrote: Bruce Dubbs wrote these words on 01/31/07 20:27 CST: Randy McMurchy wrote: Why not update a tag? You can. You asked for opinions. And I appreciate your comments. And I value them. But in our world of a book that is constantly being updated, SVN *tags* would be worthless. There is never a need to create snapshot of trunk, unless it is being used for backup purposes. In a typical package type repo, where versions are constantly changing, tags are effective. You can update the configure.ac file, tag it and move on in trunk. In a typical package environment, *you would never need to go back to a previous version*, the version is constantly being updated. But in our book environment, SVN trunk is everything, and any deviation from trunk (the annual or semi-annual release) is so infrequent that it doesn't make sense to me to adhere to this stigma of not updating a tag. My belief (and I'm quite strong on this one) is that we should use SVN in our best interests, which means for us (at least in my opinion) that tags are a stagnant entity, but branches are meant to be used for merges from trunk. Is there any real reason to treat our book SVN any different than how I'm proposing? Is there some reason that we shouldn't make *one* commit to a tag, which then identifies it as a unique and unchanging version of our book? To summarize: Tags contain data that won't be changed once the tag is finished. Branches contain data that is expected to be changed. Once a branch is no longer being updated, create a tag, remove the branch and drive on with trunk. At least that's how I look at it. I would love to gather more input from others about my thoughts. As I've always understood release management from other software projects, the tag is meant to be fixed. As in, I can always pull the firefox source with the CVS tag FIREFOX_1_0_5_1_RELEASE and know I'm getting the same thing that's in the tarball. I would like to see a 6.2 branch created and have the tags generated from that branch. But, you're the boss. As long as there's a place to check in 6.2 specific changes. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Dan Nicholson wrote these words on 02/01/07 19:17 CST: In my mind, the tag should be static because it marks some sort of milestone. So, later if I want to find out what's changed since BLFS-6.2.0rc1 got released, I can do that. There won't suddenly be new commits there. That is the plan. In fact, if I would have had my act together, and known there were still so many little nitpicks to fix, there would have only been one commit to the 6.2.0-rc1 tag: a fix to general.ent, the bookinfo and book version files. Nothing even remotely touching actual package instructions. Don't use this 6.2.0-rc1 fiasco as an example of how to go forward. Additionally, please review the email Matthew B. sent about this subject. Not because he agrees with me, but because this issue has been addressed before. It's fine if this is just going to be a practice milestone or some other throwaway, but the milestone should stay fixed. It's more about history than the idea that someone is going to want to actually check out 6.2.0rc1 in a few months. Not Arguing, but providing a different perspectiveBut the tag isn't used for history purposes. The actual SVN repo is used for that. Any changes from SVN release #X to SVN release #Y is easily accomplished using SVN commands. Please don't tell me that someone is going to rely on a tag created 6-18 months apart. That's great for package maintainers (keep in mind my RMLCopyDVD package, where tags actually mean something), but (IMO) worthless in our book world. I think the tag should be used for what is convenient for us, not because someone may say, h, I wonder what's been changed since the release candidate, let me manually compare them. And getting back to what you say about a tag should stay fixed, I think so too, but *after* the tag contains the differences required for the tag to be created in the first place./Not Arguing I'm simply not understanding. A tag from SVN is worthless, except as a backup, right? If indeed we want the ability to see what SVN was like some days/months/whatever ago, there are two choices: 1) create a cron job to create a tag once a week. 2) use SVN commands to compare any two versions you wish Now, I can see your point in creating a tag which is exactly some point in time of SVN, and then creating tags from there, but Dan, that is way too much hassle. For example, say you have three release candidates then an actual release. I don't understand how an original point-in-time tag would be of any value. Please explain. And lastly, it appears Archaic, Matthew and I see it one way, with you and Bruce on the other side of the fence. It may just be that I have to make a command decision and run with it. Please, don't drop the subject thinking you have no input. I'm learning as we go (as is everyone, I hope), and am willing to be flexible. As for branching, it just allows the possibility that some changes are for specific purposes. Not that I'm going to, but now that BLFS-6.2 is relatively static, I could start checking new stuff back into trunk. And I wouldn't want that to get mixed up with things needed for 6.2. I don't know how that would work. If we allow trunk to move on with development, then we must selectively merge (just some of) the commits into some tag. And using your method, it couldn't be into the original tag, it would have to be into another. Seems like a bunch of work for nothing. Bottom line is, I think a tag (with just mods to general.ent, the book version file and the bookinfo file; none of which have anything to do with the actual content) fits the need of having a static version. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 19:39:00 up 22 days, 19:53, 1 user, load average: 0.56, 0.34, 0.39 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Randy McMurchy wrote these words on 01/31/07 18:56 CST: Of course, none of this really has anything to do with today's release of 6.2.0-rc1 which to me is nothing more than an svn copy from trunk to a 6.2.0-rc1 tag, and rendering the various formats of the book and installing them on quantum Of course, before rendering, there must be some edits to the 6.2.0-rc1 tag to resolve the SVN-Date to 6.2.0-rc1 version differences. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 19:05:00 up 21 days, 19:19, 1 user, load average: 0.01, 0.06, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Randy McMurchy wrote: Hi all, Not having done a BLFS release before, and there appears to be no information in the Editor's Guide or elsewhere (I realize Bruce has a personal checklist), I'm sort of winging it as I go. Because the 6.2.0 release will be (hopefully) updated to a 6.2.1 release, I'm thinking the best way to go is as follows: 1. Copy trunk to a 6.2.0 tag 2. Copy trunk to a 6.2.1 branch 3. Make the appropriate edits in the 6.2.0 tag to reflect the changes from SVN-Date to 6.2.0 versioning 4. Render the book in HTML and install it on quantum 5. Render the book in PDF and install it on quantum 6. Make the appropriate messages on the BLFS web site to reflect the 6.2.0 release 7. Send out appropriate messages to the various mailing lists announcing the 6.2.0 release 8. After the 6.2.0 release, all changes will go to trunk, and all changes compatible with LFS-6.2 will be merged into the 6.2.1 branch Of course, none of this really has anything to do with today's release of 6.2.0-rc1 which to me is nothing more than an svn copy from trunk to a 6.2.0-rc1 tag, and rendering the various formats of the book and installing them on quantum, updating the web site and sending out messages to the mailing lists. This message is more geared to the actual 6.2.0 release on 2/14. Please, anyone with experience or thoughts about the plan, jump in and provide your comments. Thanks. That's not the way I'd do it. I looked for a checklist, but I couldn't find it. Sorry. Here is what I'd do: 1. Update general.ent with the blfs-version as -rc1 (or would that be -beta1. I wouldn't call it a -rc until all the current tickets for 6.2.0 are either fixed or moved to another milestone. ). It will be a couple more days for me to get KDE in. 2. Make the *tag*: svn copy svn://svn.linuxfromscratch.org/BLFS/trunk \ svn://svn.linuxfromscratch.org/BLFS/trunk/tags/BLFS-6.2.0-rc1 \ -m Tagging 6.2.0-rc1 We should not update a *tag*. Its just that, a snapshot of where we were when the tag was made. 3. Render the html manually. I have a custom script on quantum called render-blfs-book-6.1.sh that could be updated for 6.2 relatively easily. I wouldn't bother to make a pdf for a -rc? release. 4. Update the web site. 5. Make an announcement on lfs-announce and other lists. Continue to make changes on the trunk and repeat 1-5 for -rc2, -rc3, etc. For final release, create a *branch* for 6.2.0 the same way and then change the trunk blfs-version entity back to svn. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Bruce Dubbs wrote these words on 01/31/07 19:55 CST: 1. Update general.ent with the blfs-version as -rc1 (or would that be -beta1. I wouldn't call it a -rc until all the current tickets for 6.2.0 are either fixed or moved to another milestone. ). It will be a couple more days for me to get KDE in. 2. Make the *tag*: Already created. See -book. We should not update a *tag*. Why not update a tag? It is just a name. Tags and branches are the exact same, other than branches are expected to be updated. Typically tags don't get updated. But one simple commit to the general.ent file in the tag gets us where we want without having to disrupt trunk. Please understand, we're talking *one* simple commit to general.ent. Why do you see harm in that. SVN is to be used as a *convenience* to us, why make it difficult to adhere to some unwritten rule that you shouldn't make commits to tags. Surely, just one commit to general.ent isn't that big of a deal. I do understand your point about the about the current tickets open, but again, why can't we release an rc1 version with the explanation that there are still a few open tickets that *hope* to get resolved by the final release? There are some tickets (assigned or not) that I'm not certain will be addressed before 2/14. I'm not arguing nor defending my position, I'm asking for clarification. I don't buy into the idea that SVN must be used *this way or that way*, I believe it should be used in the manner most convenient to us. For final release, create a *branch* for 6.2.0 the same way and then change the trunk blfs-version entity back to svn. For final release, I'm inclined to create a tag for 6.2.0 and a branch for 6.2.1. Again, not defending my original method, but a branch for 6.2.0 doesn't seem right at all. Again, this should be a tag. The *6.2.1* version is what should be a branch, as this will be the version that all the edits in Trunk will be merged into. Please, let's continue to discuss. I want to get this right. Or at least understand the methodology. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 19:59:00 up 21 days, 20:13, 1 user, load average: 0.25, 0.11, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Randy McMurchy wrote: Bruce Dubbs wrote these words on 01/31/07 19:55 CST: 1. Update general.ent with the blfs-version as -rc1 (or would that be -beta1. I wouldn't call it a -rc until all the current tickets for 6.2.0 are either fixed or moved to another milestone. ). It will be a couple more days for me to get KDE in. 2. Make the *tag*: Already created. See -book. We should not update a *tag*. Why not update a tag? You can. You asked for opinions. I do understand your point about the about the current tickets open, but again, why can't we release an rc1 version with the explanation that there are still a few open tickets that *hope* to get resolved by the final release? There are some tickets (assigned or not) that I'm not certain will be addressed before 2/14. OK. Our approaches would be a bit different, but I can live with yours. I think its just personal preference. I would not get tied to a schedule, however. If it slips a little, it slips. OTOH, I agree that we need to press to get it out. For final release, create a *branch* for 6.2.0 the same way and then change the trunk blfs-version entity back to svn. For final release, I'm inclined to create a tag for 6.2.0 and a branch for 6.2.1. Again, not defending my original method, but a branch for 6.2.0 doesn't seem right at all. Again, this should be a tag. The *6.2.1* version is what should be a branch, as this will be the version that all the edits in Trunk will be merged into. To me tags and branches have different meanings even though they are treated in the same way by subversion. I suppose a 6.2.1 branch is reasonable where the trunk gets updated based on LFS svn and the 6.2.1 branch gets updated based on LFS 6.2. I think that's what you are saying. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Bruce Dubbs wrote these words on 01/31/07 20:54 CST: It came about as the automation of the patches was implemented. We could change the book. The only place the downloads-root entity is used is one place in general.ent. I'll defer to your good judgment on that one. Do what you think is best. :-) -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 21:11:00 up 21 days, 21:25, 1 user, load average: 0.07, 0.05, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Randy McMurchy wrote: Bruce Dubbs wrote these words on 01/31/07 20:54 CST: It came about as the automation of the patches was implemented. We could change the book. The only place the downloads-root entity is used is one place in general.ent. I'll defer to your good judgment on that one. Do what you think is best. :-) I wouldn't worry about it. Leave things the way they are. !ENTITY downloads-root http://www.linuxfromscratch.org/blfs/downloads/svn; is only used here !ENTITY blfs-bootscripts-download downloads-root;/blfs-bootscripts-blfs-bootsc ripts-version;.tar.bz2 however !ENTITY patch-root http://www.lfs-domainname;/patches/blfs/svn; effectively points the same place as downloads-root. It wouldn't make sense to point the blfs-bootscripts-download to patches, so effectively they are the same, but syntactically they make sense the way they are. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Randy McMurchy wrote: I've realized that there are a few other minor details required. Justin's help is critical. 1) Justin needs to create and populate a 6.2.0 version on the master package server. I'll use this for all the rc-1 versions as well. It may mean duplicate updates for Justin for the next couple of weeks, but since there's package freeze, perhaps there won't be anything for Justin to do other than create the 6.2.0 dir structure and populate it one time. Yep, I'll do this tonight. I have a few packages to update still which shouldn't take long, and then since it is a symlink tree just cp -a from svn to 6.2.0. It should be called 6.2.0 then or 6.2? Either way is fine, just let me know. I can symlink 6.2.0-rc1 or whatever to 6.2.0 if it would help with anything as well. So far have gone for just major and minor. [EMAIL PROTECTED] ~/blfs $ ls -l total 20 drwxr-xr-x 28 lfs lfs 4096 Jan 30 23:57 6.1 drwxr-xr-x 394 lfs lfs 12288 Jan 30 23:57 conglomeration drwxr-xr-x 29 lfs lfs 4096 Jan 30 23:57 svn Should all be ready in time for rc1. Justin -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Justin R. Knierim wrote these words on 01/31/07 21:50 CST: Yep, I'll do this tonight. I have a few packages to update still which shouldn't take long, and then since it is a symlink tree just cp -a from svn to 6.2.0. It should be called 6.2.0 then or 6.2? Yes, 6.2.0 would be great. We'll use this for all the release candidate versions, then when the final release is done, it simply takes a one-time make-sure that all the packages are there and we're done. Version 6.2.1 will take an entire new directory, as we won't want to disturb the 6.2.0 dir. Hopefully, I'm making sense here. Either way is fine, just let me know. I can symlink 6.2.0-rc1 or whatever to 6.2.0 if it would help with anything as well. So far have gone for just major and minor. If you want to create symlinks for the rc? versions, then great, however, please do whatever is easiest for you, and still accomplishes the mission. Most of all, thanks for your timely response and willingness to do whatever is necessary. I'm going to try to get the rc1 version out this evening (currently 22:00 hours CST), and point to a 6.2.0 directory for source files on Anduin. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 22:02:00 up 21 days, 22:16, 1 user, load average: 0.04, 0.07, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Randy McMurchy wrote: Yes, 6.2.0 would be great. We'll use this for all the release candidate versions, then when the final release is done, it simply takes a one-time make-sure that all the packages are there and we're done. Version 6.2.1 will take an entire new directory, as we won't want to disturb the 6.2.0 dir. Hopefully, I'm making sense here. Perfect sense, yep. Separate directories with their own symlinks, all should stay as it should. Ok, everything in the svn dir was up to date, only differences: [EMAIL PROTECTED] ~/blfs/svn/x/files $ blfsdiff BLFSDIFF - REPO - BOOK @@@ svn @@@ -MPlayer-essential-20060501.tar.bz2 +MPlayer-essential-20061022.tar.bz2 -libmikmod-3.1.11-a.diff -rp-pppoe-3.8-iproute2-1.patch -wvdial-1.54.0.tar.gz +wvdial_1.54.0.orig.tar.gz MPlayer-essential - couldn't find the older version, used a newer one libmikmod diff - wget-list doesn't parse .diff files, ignored rp-pppoe patch - optional patch, doesn't show in wget-list wvdial - seems http and ftp have different file names, lol, using what I had, the non-orig named one If you want to create symlinks for the rc? versions, then great, however, please do whatever is easiest for you, and still accomplishes the mission. It is only a symlink, not much work. If you have requests, let me know. Ok, so 6.2.0 is setup: [EMAIL PROTECTED] ~/blfs $ ls -l total 24 drwxr-xr-x 28 lfs lfs 4096 Jan 30 23:57 6.1 drwxr-xr-x 29 lfs lfs 4096 Jan 30 23:57 6.2.0 lrwxrwxrwx1 lfs lfs 5 Feb 1 04:19 6.2.0-rc1 - 6.2.0 drwxr-xr-x 394 lfs lfs 12288 Jan 30 23:57 conglomeration drwxr-xr-x 29 lfs lfs 4096 Jan 30 23:57 svn Most of all, thanks for your timely response and willingness to do whatever is necessary. I'm going to try to get the rc1 version out this evening (currently 22:00 hours CST), and point to a 6.2.0 directory for source files on Anduin. You're welcome, glad to help. I've ran the update script so it should be possible to rsync in 5 or so minutes. Any issues, let me know. Justin -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: 6.2.0 tag
Justin R. Knierim wrote: If you want to create symlinks for the rc? versions, then great, however, please do whatever is easiest for you, and still accomplishes the mission. It is only a symlink, not much work. If you have requests, let me know. Ok, so 6.2.0 is setup: Justin, Just a heads up. I'll be committing an update to kde-3.5.6 tomorrow or Friday. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
