From: Brendan M. <mc...@cs...> - 2005-06-23 21:44:05
|
Joe Mundy said: > I don't like solution 2). Maybe we could more broadly share the work of > a release according to solution 1) in some way. I don't have a good > understanding of what is involved. How did the process go last time? > Joe Well, the process is basically a pain in the proverbial IMO. I made a few mistakes along the way (hence the reason we have a 1.1.0.1, and not just a 1.1). But basically I just followed the instruction list passed on by Ian Scott - I'm not a cvs expert so most of it was voodoo to me, but it seemed to do the trick. The most effort if I remember correctly is the downloading and compiling which needs to be done a few times on at least two platforms - the scariest bit is getting the tags right, I think I had to undo what I'd done once or twice ... I presume you don't like 2) because of the apparent difficulty of entry for newcomers? But I think at the moment the difficulty of entry is even greater because newcomers download an old version of the library, spend some effort trying to compile it, then ask one of the lists how to fix it only to be told that they should get the CVS version... My suggestions were (in increasing order of personal preference): 1) maintain the status quo, but making some effort to make releases on a semi-regular basis (perhaps every 12 mths) 2) remove the releases from public view, and tell everyone to get the latest CVS version as that is stable 3) automatically tar up a new release on a regular time frame (say once a month, once a week, every day - if it's automatic, who cares?), and just make that the current release (possibly changing only a minor version number, eg 1.1.1, 1.1.2, ...). Instructions (From Ian): -------------- 1. Download everything first onto at least two platforms and test the current CVS HEAD. THe dashboards can be wrong (They never noticed that the root configure filres had been removed!) This includes updating CHANGES.txt. * Need to commit changes here before making branch point etc. 2. The following is a description of how to make a branch point and branch (Thanks to Brad for the info)(This only applies to making a new minor version release, not a patch release) cd vxl cvs up -PdA cvs tag vxl-1-0-bp cvs tag -b vxl-1-0 3. Move to the branch cvs up -r vxl-1-0 4. Do some release specific work Make sure that core/vxl_version.h is correct. Update CHANGES.txt to mention the new release. Copy in an INSTALL.html (e.g. from the website) 5. Tag the 1.0.0 release: cvs tag vxl-1-0-0 5A. If you end up in a mess (e.g. because SF will not recognise that configure really shouldn't be in the CVS attic) you can abandon the branches and tags you have made so far. You can fix everything in the main CVS branch, and commit it there. Then simply retag everything with the -F option, which will make it forget about the previous locations of the tags. It is not recommended to do this if these tags have had any other users but yourself. cd vxl cvs up -PdA cvs tag -F vxl-1-0-bp cvs tag -bF vxl-1-0 6. Create a vxl download into directory. Do this on a Unix box so that the execute permissions are preserved. use cvs export to strip the CVS directories. cd /tmp cvs export -r vxl-1-0-0 -d vxl-1.0.0 vxl 7. Tar it up, and test the tar file from scratch on at least two platforms. 8. Submit it to the Sourceforge File Release system. 9. Get a copy of the documentation build, tar it up, and submit it to the File Release System. 10. Did I mention that testing is good. Try downloading the files from SourceForge. It can go wrong even now. 11. Submit a email describing the release to vxl-users, vxl-announce, and submit a news item at VXL's SourceForge project page. Ian. ------------- -- Cheers, Brendan. ---------------------------------------------------------------------------- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. |
From: Brendan M. <mc...@cs...> - 2005-07-08 03:16:59
|
On Thu, 2005-07-07 at 18:25 -0400, Joseph L Mundy wrote: > Hi Brendan, > By all means, go ahead with the minor release. It will take some time > to realize the movement of these libraries. With luck they will be in > core by the next release in Sept.-October. > Joe Right. Minor release still scheduled for Monday. Please make sure all your checkins are good before then. -- Cheers, Brendan. ---------------------------------------------------------------------------- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. |
From: Joseph L M. <mu...@le...> - 2005-06-24 12:54:49
|
Brendan, I did ask around in our group at Brown, which has a steady flow of new vxl users. The predominant opinion is that a stable release is valuable to get started, even if it is a bit out of date (months not years). The problem expressed about solution 2) is that while vxl is stable it can have build errors. So downloading that state exposes a new user to fixing bugs or commenting CMake files, which is precisely what a new user doesn't know how to do. Joe -----Original Message----- From: vxl...@li... [mailto:vxl...@li...] On Behalf Of Brendan McCane Sent: Thursday, June 23, 2005 5:44 PM To: vxl...@li... Cc: Joseph L Mundy Subject: RE: [Vxl-maintainers] vxl releases etc Joe Mundy said: > I don't like solution 2). Maybe we could more broadly share the work of > a release according to solution 1) in some way. I don't have a good > understanding of what is involved. How did the process go last time? > Joe Well, the process is basically a pain in the proverbial IMO. I made a few mistakes along the way (hence the reason we have a 1.1.0.1, and not just a 1.1). But basically I just followed the instruction list passed on by Ian Scott - I'm not a cvs expert so most of it was voodoo to me, but it seemed to do the trick. The most effort if I remember correctly is the downloading and compiling which needs to be done a few times on at least two platforms - the scariest bit is getting the tags right, I think I had to undo what I'd done once or twice ... I presume you don't like 2) because of the apparent difficulty of entry for newcomers? But I think at the moment the difficulty of entry is even greater because newcomers download an old version of the library, spend some effort trying to compile it, then ask one of the lists how to fix it only to be told that they should get the CVS version... My suggestions were (in increasing order of personal preference): 1) maintain the status quo, but making some effort to make releases on a semi-regular basis (perhaps every 12 mths) 2) remove the releases from public view, and tell everyone to get the latest CVS version as that is stable 3) automatically tar up a new release on a regular time frame (say once a month, once a week, every day - if it's automatic, who cares?), and just make that the current release (possibly changing only a minor version number, eg 1.1.1, 1.1.2, ...). Instructions (From Ian): -------------- 1. Download everything first onto at least two platforms and test the current CVS HEAD. THe dashboards can be wrong (They never noticed that the root configure filres had been removed!) This includes updating CHANGES.txt. * Need to commit changes here before making branch point etc. 2. The following is a description of how to make a branch point and branch (Thanks to Brad for the info)(This only applies to making a new minor version release, not a patch release) cd vxl cvs up -PdA cvs tag vxl-1-0-bp cvs tag -b vxl-1-0 3. Move to the branch cvs up -r vxl-1-0 4. Do some release specific work Make sure that core/vxl_version.h is correct. Update CHANGES.txt to mention the new release. Copy in an INSTALL.html (e.g. from the website) 5. Tag the 1.0.0 release: cvs tag vxl-1-0-0 5A. If you end up in a mess (e.g. because SF will not recognise that configure really shouldn't be in the CVS attic) you can abandon the branches and tags you have made so far. You can fix everything in the main CVS branch, and commit it there. Then simply retag everything with the -F option, which will make it forget about the previous locations of the tags. It is not recommended to do this if these tags have had any other users but yourself. cd vxl cvs up -PdA cvs tag -F vxl-1-0-bp cvs tag -bF vxl-1-0 6. Create a vxl download into directory. Do this on a Unix box so that the execute permissions are preserved. use cvs export to strip the CVS directories. cd /tmp cvs export -r vxl-1-0-0 -d vxl-1.0.0 vxl 7. Tar it up, and test the tar file from scratch on at least two platforms. 8. Submit it to the Sourceforge File Release system. 9. Get a copy of the documentation build, tar it up, and submit it to the File Release System. 10. Did I mention that testing is good. Try downloading the files from SourceForge. It can go wrong even now. 11. Submit a email describing the release to vxl-users, vxl-announce, and submit a news item at VXL's SourceForge project page. Ian. ------------- -- Cheers, Brendan. ------------------------------------------------------------------------ ---- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ian S. <ian...@st...> - 2005-06-24 13:19:53
|
Joseph L Mundy wrote: > Brendan, > I did ask around in our group at Brown, which has a steady flow of new > vxl users. The predominant opinion is that a stable release is valuable > to get started, even if it is a bit out of date (months not years). The > problem expressed about solution 2) is that while vxl is stable it can > have build errors. So downloading that state exposes a new user to > fixing bugs or commenting CMake files, which is precisely what a new > user doesn't know how to do. It would be very easy for us maintainers to manually tag versions that appear good according to the dashboard. Then we could tell people to download the latest known good snapshot using cvs -d ... -r last_known_good_snapshot vxl Of course, as I noted during my descrition of the release process, fresh checkouts from the repository may not always be strictly identical to those tested by the dashboard, or used by the maintainers. But such cases should be fairly rare. Ian. |
From: Brendan M. <mc...@cs...> - 2005-06-27 00:57:12
|
G'day Ian, Joe and maintainers, On Fri, 2005-06-24 at 14:19 +0100, Ian Scott wrote: > It would be very easy for us maintainers to manually tag versions that > appear good according to the dashboard. > > Then we could tell people to download the latest known good snapshot using > cvs -d ... -r last_known_good_snapshot vxl This seems like a good compromise position, although if we're doing that why not just tar up that snapshot as well? Certainly just tagging an apparently good version and tarring it up is a fairly straight forward process (which I'd be happy to do on a semi-regular basis). What do you think Joe? The advantages are the release process is fairly light weight, and can be done fairly often (say every two months?). The disadvantages are that lest explicit testing of the releases is done, being more reliant on the dashboard, and on new users for detecting errors. To improve the robustness of the releases would require more testing by maintainers. I'd be happy to tag, tar and test on my system, but would want/need other maintainers to download and test before going public. Further thoughts? -- Cheers, Brendan. ---------------------------------------------------------------------------- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. |
From: Joseph L M. <mu...@le...> - 2005-07-01 10:05:21
|
Hi Brendan, I talked over the latest proposal with developers here at Brown, and we are willing to check out and test tagged releases. It does seem if the dashboard was in good shape when the tag was executed that the release should also build without error, but we will see. Perhaps we would do a tag and tar once every 3 months. Perhaps someone who is a CVS wizard could create the script. Joe -----Original Message----- From: vxl...@li... [mailto:vxl...@li...] On Behalf Of Brendan McCane Sent: Sunday, June 26, 2005 8:57 PM To: Ian Scott Cc: Joseph L Mundy; vxl...@li... Subject: Re: [Vxl-maintainers] vxl releases etc G'day Ian, Joe and maintainers, On Fri, 2005-06-24 at 14:19 +0100, Ian Scott wrote: > It would be very easy for us maintainers to manually tag versions that > appear good according to the dashboard. > > Then we could tell people to download the latest known good snapshot using > cvs -d ... -r last_known_good_snapshot vxl This seems like a good compromise position, although if we're doing that why not just tar up that snapshot as well? Certainly just tagging an apparently good version and tarring it up is a fairly straight forward process (which I'd be happy to do on a semi-regular basis). What do you think Joe? The advantages are the release process is fairly light weight, and can be done fairly often (say every two months?). The disadvantages are that lest explicit testing of the releases is done, being more reliant on the dashboard, and on new users for detecting errors. To improve the robustness of the releases would require more testing by maintainers. I'd be happy to tag, tar and test on my system, but would want/need other maintainers to download and test before going public. Further thoughts? -- Cheers, Brendan. ------------------------------------------------------------------------ ---- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Brendan M. <mc...@cs...> - 2005-07-04 04:35:07
|
Hi Joe, Great. So here is the final proposal: 1) every 3 months I will tag, tar and test on my system a release candidate for vxl (checking with the dashboard first, and giving maintainers fair warning - say 1 week). 2) Assuming all goes well, I'll add it as a release candidate to the sourceforge site 3) Some other groups (eg Brown and perhaps others) should then download and test on their system. 4) Assuming all goes well, make it an official release. OK? I also propose to number the releases by incrementing the minor number within each calendar year - eg 1.2 will be the next release (which I will initiate soon if I don't get objections to this process), then 1.3 in Oct. And increment the major number at the start of each calendar year (so the Jan/Feb release will be 2.0). Does that sound OK, or would you northern hemisphere types prefer to sync with your academic year (so next release is 2.0, and major numbers increase each July). Or some other scheme? On Fri, 2005-07-01 at 06:05 -0400, Joseph L Mundy wrote: > Hi Brendan, > I talked over the latest proposal with developers here at Brown, and we > are willing to check out and test tagged releases. It does seem if the > dashboard was in good shape when the tag was executed that the release > should also build without error, but we will see. Perhaps we would do a > tag and tar once every 3 months. Perhaps someone who is a CVS wizard > could create the script. > Joe -- Cheers, Brendan. ---------------------------------------------------------------------------- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. |
From: Peter V. <pet...@ya...> - 2005-07-04 06:17:32
|
> ... increment the major number at the start of each calendar year Well, I would propose to only increment the minor number automatically, and chose for a new major number only when some "big changes" did happen. -- Peter. |
From: Ian S. <ian...@st...> - 2005-07-04 11:05:34
|
Peter Vanroose wrote: >>... increment the major number at the start of each calendar year > > > Well, I would propose to only increment the minor number automatically, > and chose for a new major number only when some "big changes" did > happen. I'd support this. Ian. |
From: Brendan M. <mc...@cs...> - 2005-07-04 21:42:43
|
On Mon, 2005-07-04 at 08:17 +0200, Peter Vanroose wrote: > > ... increment the major number at the start of each calendar year > > Well, I would propose to only increment the minor number automatically, > and chose for a new major number only when some "big changes" did > happen. > > > -- Peter. OK I can live with that. I didn't suggest it because I can see some pretty big minor numbers happening, but I guess that isn't a big problem. I guess a prerequisite for a big change is something being added to core or some serious change to core (eg the vil change). OK, given all that I intend starting the process off Monday 11th July at about 9am, NZ time (21:00 hrs, Sunday 10th July, GMT). I notice the dashboard is currently free of compile errors and free of major testing errors (the only test errors are for: brip_test_fourier, bsta_test_histogram, rgrl_estimator). Please ensure any changes you want are committed this week (and that they don't cause any errors). Since there haven't been major changes since 1.1 (I don't think?) I'll make the new version 1.2. -- Cheers, Brendan. ---------------------------------------------------------------------------- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. |
From: Joseph L M. <mu...@le...> - 2005-07-05 11:21:58
|
Brendan, I agree that the quarterly releases are minor releases if they just reflect bug fixes and small improvements. A major release would be warranted with the addition of a new library to core, which, by the way, we are very sluggish in doing. I can think of several very useful libraries that should go into core right away: 1) rrel - a robust optimization library: ransack etc. 2) vimt - associate a transform with images. Perhaps should be compatible with vgl_h_matrix so that users can specify vimt_transform_*d from a vgl_h_matrix_*d and vice-versa. 3) vsol - a shared geometry library where objects are represented as pointers. For example, the same point can be shared by two adjacent curve segments. Extends vgl. At Brown, we use these libraries extensively in our more specialized applications. We would be willing to move vsol up to core and maintain it. Hopefully the developers of rrel and vimt would be willing to move their libraries to core. Thanks, Joe -----Original Message----- From: vxl...@li... [mailto:vxl...@li...] On Behalf Of Brendan McCane Sent: Monday, July 04, 2005 12:35 AM To: Joseph L Mundy Cc: mc...@at...; vxl...@li... Subject: RE: [Vxl-maintainers] vxl releases etc Hi Joe, Great. So here is the final proposal: 1) every 3 months I will tag, tar and test on my system a release candidate for vxl (checking with the dashboard first, and giving maintainers fair warning - say 1 week). 2) Assuming all goes well, I'll add it as a release candidate to the sourceforge site 3) Some other groups (eg Brown and perhaps others) should then download and test on their system. 4) Assuming all goes well, make it an official release. OK? I also propose to number the releases by incrementing the minor number within each calendar year - eg 1.2 will be the next release (which I will initiate soon if I don't get objections to this process), then 1.3 in Oct. And increment the major number at the start of each calendar year (so the Jan/Feb release will be 2.0). Does that sound OK, or would you northern hemisphere types prefer to sync with your academic year (so next release is 2.0, and major numbers increase each July). Or some other scheme? On Fri, 2005-07-01 at 06:05 -0400, Joseph L Mundy wrote: > Hi Brendan, > I talked over the latest proposal with developers here at Brown, and we > are willing to check out and test tagged releases. It does seem if the > dashboard was in good shape when the tag was executed that the release > should also build without error, but we will see. Perhaps we would do a > tag and tar once every 3 months. Perhaps someone who is a CVS wizard > could create the script. > Joe -- Cheers, Brendan. ------------------------------------------------------------------------ ---- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ian S. <ian...@st...> - 2005-07-05 11:52:47
|
Joseph L Mundy wrote: > At Brown, we use these libraries extensively in our more specialized > applications. We would be willing to move vsol up to core and maintain > it. Hopefully the developers of rrel and vimt would be willing to move > their libraries to core. > We're happy for vimt to go up to the core. Ian. |
From: Brendan M. <mc...@cs...> - 2005-07-06 21:26:19
|
On Tue, 2005-07-05 at 12:52 +0100, Ian Scott wrote: > Joseph L Mundy wrote: > > > At Brown, we use these libraries extensively in our more specialized > > applications. We would be willing to move vsol up to core and maintain > > it. Hopefully the developers of rrel and vimt would be willing to move > > their libraries to core. > > > We're happy for vimt to go up to the core. > > Ian. OK, so far we have proposals to move vsol, vimt and rrel up to core. Sounds good to me. So should I still make a minor release on Monday? Or do you want to move those libraries up in the next week or two, and I'll make a major release after that? -- Cheers, Brendan. ---------------------------------------------------------------------------- Brendan McCane Email: mc...@cs... Department of Computer Science Phone: +64 3 479 8588/8578. University of Otago Fax: +64 3 479 8529 Box 56, Dunedin, New Zealand. |
From: Amitha P. <pe...@cs...> - 2005-07-07 01:17:25
|
On Wed 06 Jul 2005, Brendan McCane wrote: > OK, so far we have proposals to move vsol, vimt and rrel up to core. > Sounds good to me. So should I still make a minor release on Monday? Or > do you want to move those libraries up in the next week or two, and I'll > make a major release after that? I think you should make a minor release on Monday. Your proposed plan schedules the next release for a few months from Monday, and I think that's early enough to deal with any migrated libraries. Amitha. |