From: Brad K. <bra...@ki...> - 2009-03-18 14:22:19
|
Hi Folks, The migration from cvs to svn on sourceforge is complete. Repo Web Browser: http://vxl.svn.sourceforge.net/viewvc/vxl/ Anonymous checkout: svn co http://vxl.svn.sourceforge.net/svnroot/vxl/trunk vxl Developer checkout: svn co https://vxl.svn.sourceforge.net/svnroot/vxl/trunk vxl svn co https://vxl.svn.sourceforge.net/svnroot/vxl/www/trunk vxl-www I've converted the daily version number robot script and committed today's version. I've also enabled the commit hooks: check-mime-type.pl = ensure svn:mime-type and svn:eol-style are set check-case-insensitive.py = ensure files do not conflict on case-insensitive fs Remaining tasks include the following: - Create trac tickets for the rest of this task list -- Amitha - Final commit to cvs to remove all files and replace with a README pointing at svn instructions -- volunteer? - Prune developer list -- Amitha (Disable cvs commit access for all, prune svn access) - Update dashboard clients to use svn -- initially Brad, then all (I'm working on new generic scripts to be shared by all clients) - Update web pages to replace cvs instructions with svn -- volunteer? (Also check out the pages from svn instead of cvs) - Server configuration to disallow commits to tags -- volunteer? (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html) - Add 'svnnotify' commit hook to send commit notifications -- volunteer? - Do we need any book updates? -- volunteer? If anyone sees a task I missed please post it. Also, the core/vxl_version.h file needs updating. Currently it has: //: This can either be "RELEASE" or "CVS" #define VXL_SOURCE "CVS" Instead of changing "CVS" to "SVN", I propose we use "DEVEL" to be more specific. Furthermore, since the 1.12 milestone is tagged, shouldn't the trunk use #define VXL_VERSION_MINOR 13 // currently 12 ? -Brad |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-03-18 16:55:36
|
On Wed, Mar 18, 2009 at 10:22 AM, Brad King wrote: > Hi Folks, > > The migration from cvs to svn on sourceforge is complete. > <snip> Thanks!! > I've also enabled the commit hooks: > > check-mime-type.pl = ensure svn:mime-type and svn:eol-style are set > check-case-insensitive.py = ensure files do not conflict on case-insensitive fs > > Remaining tasks include the following: > > - Update web pages to replace cvs instructions with svn -- volunteer? > (Also check out the pages from svn instead of cvs) I can volunteer for this. > - Server configuration to disallow commits to tags -- volunteer? > (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html) I can volunteer for this. > - Add 'svnnotify' commit hook to send commit notifications -- volunteer? I can volunteer for this. <snip> > Also, the core/vxl_version.h file needs updating. Currently it has: > > //: This can either be "RELEASE" or "CVS" > #define VXL_SOURCE "CVS" > > Instead of changing "CVS" to "SVN", I propose we use "DEVEL" to be more specific. > Furthermore, since the 1.12 milestone is tagged, shouldn't the trunk use > > #define VXL_VERSION_MINOR 13 // currently 12 > > ? IMHO, yes (i.e., it should use 13). --Miguel |
From: Matthew L. <mat...@gm...> - 2009-03-18 17:38:21
|
Brad, Thank you for all the effort you've put in to this. And thanks to Ian for laying the groundwork. On Mar 18, 2009, at 10:22 AM, Brad King wrote: > Remaining tasks include the following: > > - Final commit to cvs to remove all files and replace with a README > pointing at svn instructions -- volunteer? I can do this when the time is right, but it should wait until everything else is working with subversion. > > - Do we need any book updates? -- volunteer? I don't think the book needs any updates with respect to version management. As far as I can see there is no mention of CVS. I think the book assumes that the user has already obtained the code by some means. We do still need to get the book building again. Kitware is linked to as the primary source for the online VXL book and Doxygen documentation, but all of Kitware's documentation builds have not been updated since January 2008. Links for "Latest Release" documentation do not correspond to the latest release. Peter has fixed the Book makefile so it builds again, but someone needs to restart the scheduled build jobs. > Furthermore, since the 1.12 milestone is tagged, shouldn't the trunk > use > > #define VXL_VERSION_MINOR 13 // currently 12 > > ? I agree that the trunk should not use the previous release version number. While we are on the topic, does anyone else think that we should soon have a new major release? In addition to the subversion switch, there will be a couple of major changes to core: 1) vpdl added to core 2) vidl2 moving into core to replace vidl. 3) vidl renaming to vidl1 I'm also thinking now that we can easily move files it might be a good time to clean up and move deprecated libraries into a designated place like "core/unmaintained" or "core/deprecated". Libraries that should be moved are vil1, vidl1, and vidl_vil1 (old vidl that uses vil1). Later we can disable them with the existing CMake option: BUILD_UNMAINTAINED_LIBRARIES It also might be about time to bump the minimum CMake version to 2.6.0. Thoughts on these changes? Would this be enough to warrant VXL 2.0? Matt |
From: Amitha P. <ami...@us...> - 2009-03-19 16:53:00
|
Matthew Leotta wrote: > We do still need to get the book building again. What is the long term plan for the book? Is the book going to remain as both PDF and HTML? Is it going to be pure HTML? Is it going to be wiki-fied? Amitha. |
From: Brad K. <bra...@ki...> - 2009-03-18 18:00:05
|
Brad King wrote: > Remaining tasks include the following: [snip] > If anyone sees a task I missed please post it. - Fix scripts in vxl tree that grep "CVS" dirs to be ".svn" -- volunteer? > Also, the core/vxl_version.h file needs updating. Currently it has: > > //: This can either be "RELEASE" or "CVS" > #define VXL_SOURCE "CVS" > > Instead of changing "CVS" to "SVN", I propose we use "DEVEL" to be more specific. On second thought, perhaps we should just remove VXL_SOURCE completely. Nothing else in the vxl tree uses it. No preprocessor tests can be performed against its value because it is a string. The other version macros provide all necessary info. Objections? -Brad |
From: Matthew L. <mat...@gm...> - 2009-03-19 17:08:40
|
On Mar 19, 2009, at 12:52 PM, Amitha Perera wrote: > Matthew Leotta wrote: >> We do still need to get the book building again. > > What is the long term plan for the book? Is the book going to > remain as both PDF and HTML? Is it going to be pure HTML? Is it > going to be wiki-fied? I don't know. It could be moved to the wiki, but then (as Fred pointed out) it's not really a "book" anymore. I think it is useful to have an online user guide that is always available and that can be easily edited. But maybe that is separate from the book concept. For now I am still writing the vidl2 and vpdl chapters in texinfo. I've written a script that will convert a subset of texinfo into latex so I can append these chapters to my thesis. I think we should keep the texinfo book running for now (at least in HTML) until we see how useful the wiki proves to be. Matt |
From: Amitha P. <ami...@us...> - 2009-03-19 16:49:22
|
Brad King wrote: > - Create trac tickets for the rest of this task list -- Amitha I created a set of tickets, and assigned some to Miguel and Matt (to the tasks they volunteered to do). I didn't receive any email when a task was assigned to me. Is that expected? Is there a way to designate a set of people to be notified whenever new tickets are created? Miguel, is there a direct tie between the SourceForge developer list and the trac developer list? Or do we have to add a new person explicitly to both? Amitha. |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-03-19 23:25:20
|
On Thu, Mar 19, 2009 at 12:49 PM, Amitha Perera wrote: > Brad King wrote: >> - Create trac tickets for the rest of this task list -- Amitha > > I created a set of tickets, and assigned some to Miguel and Matt (to the > tasks they volunteered to do). I didn't receive any email when a task > was assigned to me. Is that expected? Is there a way to designate a > set of people to be notified whenever new tickets are created? Yes, it seems this is expected, since it is not enabled by default in the trac.ini. I opened a ticket for this and assigned it to myself as it will require to submit a support request at sourceforge. People are welcome to comment on: https://apps.sourceforge.net/trac/vxl/ticket/14 There is an issue there of whether we want to have a list such as vxl...@li... to collect the ticket notifications as we do with the commits. I personaly don't think it is necessary as long as the owner, reporter, updater, and watchers (people in the cc line) get emailed. > Miguel, is there a direct tie between the SourceForge developer list and > the trac developer list? Or do we have to add a new person explicitly > to both? Yes, we need to add them to both. The authentication is the same account, but the sourceforge project roles are not mapped to the trac ones. Note however that the difference between the permissions of an authenticated user and a developer is very minimal. Both can create and edit wiki pages, and both can create tickets. The only difference is that an authenticated user can only append to a ticket, while a developer can modify it. What this means is that if we are willing to allow unprivileged users (but authenticated) to modify tickets (i.e., change priorities, close the ticket, etc.), then we wouldn't need to maintain the parallel list of users. We would only need to maintain the administrators list in trac. Having said that, I'm not sure I want non-developers modifying tickets... although it seems that it would be somewhat unlikely to have much cases like this. --Miguel |
From: Amitha P. <ami...@us...> - 2009-03-19 19:17:12
|
I am wondering if we should just pick LaTeX (and therefore PDF), and not bother with the HTML. Given that it is a "book". But, like the Subversion book and the CVS book, having an HTML version may be useful. Amitha. |
From: Matthew L. <mat...@gm...> - 2009-03-19 19:45:38
|
On Mar 19, 2009, at 3:17 PM, Amitha Perera wrote: > I am wondering if we should just pick LaTeX (and therefore PDF), and > not bother with the HTML. Given that it is a "book". > > But, like the Subversion book and the CVS book, having an HTML > version may be useful. > I see no reason to port everything from texinfo to LaTeX. I think it's nice to have an HTML version. In fact, I've never even looked at the PDF version. When I was learning VXL I read the whole book in HTML. I think the HTML version would be even better if we could apply some CSS to make the formatting a little easier on the eye. My biggest concern with texinfo is that is requires a build process and is often out of date. Plus it is more complicated for the average developer to edit. I think we should either keep the book in texinfo as it is, or replace it with two parts: 1) A wiki that provides some of the same information, but not in "book" form. 2) A "real" book in LaTeX form, maybe more like a textbook. This idea has come up before. I think we ultimately need three things for documentation 1) an FAQ for things like obtaining source code, compilation, how to do simple tasks, as well as overall design concepts for VXL (wiki would be good for this) 2) A library design overview explaining the general concepts of each library and the appropriate way for developers to extend each library. (Doxygen intro pages are good for this) 3) A tutorial or textbook on how to use VXL, maybe with examples of real vision problems (This is probably where the LaTeX book for print comes in). Matt |
From: Matthew L. <mat...@gm...> - 2009-03-20 01:21:02
|
On Mar 19, 2009, at 3:45 PM, Matthew Leotta wrote: > On Mar 19, 2009, at 3:17 PM, Amitha Perera wrote: > >> I am wondering if we should just pick LaTeX (and therefore PDF), >> and not bother with the HTML. Given that it is a "book". >> >> But, like the Subversion book and the CVS book, having an HTML >> version may be useful. >> <snip> > > I think the HTML version would be even better if we could apply some > CSS to make the formatting a little easier on the eye. </snip> I just check in a simple CSS for the Book to make it a little easier to read in HTML format. It still needs some work, but it's a start. Matt |
From: Peter V. <pet...@ya...> - 2009-03-19 20:03:59
|
Brad, I successfully checked out vxl "trunk", but can't seem to get the following work: svn co https://vxl.svn.sourceforge.net/svnroot/vxl/branches/build-makefiles (It worked, with an extra "/vxl", with the trial version last week.) -- Peter. __________________________________________________________ Låna pengar utan säkerhet. Jämför vilkor online hos Kelkoo. http://www.kelkoo.se/c-100390123-lan-utan-sakerhet.html?partnerId=96915014 |
From: Brad K. <bra...@ki...> - 2009-03-19 21:06:42
|
Peter Vanroose wrote: > Brad, > > I successfully checked out vxl "trunk", but can't seem to get the following work: > svn co https://vxl.svn.sourceforge.net/svnroot/vxl/branches/build-makefiles > (It worked, with an extra "/vxl", with the trial version last week.) https://vxl.svn.sourceforge.net/svnroot/vxl/branches/vxl-build-makefiles ^^^^ All branch names now start in "vxl-". It makes it easier to checkout without specifying a directory name argument. -Brad |
From: Peter V. <pet...@ya...> - 2009-03-19 21:32:25
|
> https://vxl.svn.sourceforge.net/svnroot/vxl/branches/vxl-build-makefiles > ^^^^ OK, that works. Thanks! -- Peter. __________________________________________________________ Går det långsamt? Skaffa dig en snabbare bredbandsuppkoppling. Sök och jämför priser hos Kelkoo. http://www.kelkoo.se/c-100015813-bredband.html?partnerId=96914325 |
From: Amitha P. <ami...@us...> - 2009-03-19 22:52:03
|
Miguel A. Figueroa-Villanueva wrote: > There is an issue there of whether we want to have a list such as > vxl...@li... to collect the ticket notifications > as we do with the commits. I personaly don't think it is necessary as > long as the owner, reporter, updater, and watchers (people in the cc > line) get emailed. I agree. However, how do the maintainers know when a user creates a new ticket? Do we need to monitor the list? [...] > Having said that, I'm not sure I want non-developers modifying > tickets... although it seems that it would be somewhat unlikely to > have much cases like this. I agree. It's easy enough to add the person to both lists. Amitha. |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-03-19 23:41:13
|
On Thu, Mar 19, 2009 at 6:51 PM, Amitha Perera wrote: > Miguel A. Figueroa-Villanueva wrote: >> >> There is an issue there of whether we want to have a list such as >> vxl...@li... to collect the ticket notifications >> as we do with the commits. I personaly don't think it is necessary as >> long as the owner, reporter, updater, and watchers (people in the cc >> line) get emailed. > > I agree. However, how do the maintainers know when a user creates a new > ticket? Do we need to monitor the list? Well, if the reporter selects a ticket component from core, then automatically it is owned by a maintainer, so I would presume that with notifications activated he would get an e-mail. However, to see all the new tickets created there are two options: - monitor the particular report that your interested in; possibly {1} or {8} (this can be seen when you click the ViewTickets tab), but you could also customize a report with a MySQL query. - subscribe to the RSS feed for the report that your interested and then you'll receive a notification with your news reader. > [...] >> >> Having said that, I'm not sure I want non-developers modifying >> tickets... although it seems that it would be somewhat unlikely to >> have much cases like this. > > I agree. It's easy enough to add the person to both lists. > > Amitha. ok. --Miguel |
From: Amitha P. <ami...@us...> - 2009-03-20 02:41:15
|
Miguel A. Figueroa-Villanueva wrote: > Well, if the reporter selects a ticket component from core, then > automatically it is owned by a maintainer, so I would presume that > with notifications activated he would get an e-mail. Ah, I see. I just created a test ticket on core/vbl, and it was assigned to Fred. So, each component should then have a owner. This person can then delegate the ticket to someone else. I think it is unlikely that we will monitor the tickets daily, and so it'd be good for *someone* to be notified if a user creates a ticket. Any volunteers for this Master Of The Universe role? > - subscribe to the RSS feed for the report that your interested and > then you'll receive a notification with your news reader. Ah! All these new fangled technologies, I tell you. I just tested this, and it seems to work. It doesn't seem to send update messages as the ticket is updated; is there a concept of monitoring a ticket? Do you just add yourself to the cc line? Given this, maybe we don't need a default owner for all the categories. However, I think it is a good idea to have a MOTU role, to make sure that tickets are not ignored. Amitha. |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-03-20 10:12:24
|
On Thu, Mar 19, 2009 at 10:41 PM, Amitha Perera wrote: > Miguel A. Figueroa-Villanueva wrote: >> >> Well, if the reporter selects a ticket component from core, then >> automatically it is owned by a maintainer, so I would presume that >> with notifications activated he would get an e-mail. > > Ah, I see. I just created a test ticket on core/vbl, and it was assigned to > Fred. > > So, each component should then have a owner. This person can then delegate > the ticket to someone else. I think it is unlikely that we will monitor the > tickets daily, and so it'd be good for *someone* to be notified if a user > creates a ticket. > > Any volunteers for this Master Of The Universe role? You mean for the components that don't already have a default owner (which can then delegate the ticket or bring it up in the list, of course)? >> - subscribe to the RSS feed for the report that your interested and >> then you'll receive a notification with your news reader. > > Ah! All these new fangled technologies, I tell you. I just tested this, > and it seems to work. It doesn't seem to send update messages as the ticket > is updated; is there a concept of monitoring a ticket? Yes, I had the same experience. It seems it alerts when tickets are created. However, if you go to timeline and you select only "ticket changes", you get an rss feed for ticket creation and closing. > Do you just add > yourself to the cc line? I understand like this, yes. To monitor a ticket (if your not the reporter nor the owner, which monitor it by default) you should add yourself to the cc. However, this doesn't seem to be working... I think we still need to get the trac.ini configured before it works. <snip> --Miguel |
From: Ian S. <ian...@st...> - 2009-03-20 13:08:13
|
Brad King wrote: > Hi Folks, > > The migration from cvs to svn on sourceforge is complete. Brad (and Kitware), Thank-you very much for running this conversion - I'm sure that the VXL community will benefit from the better revision support provided by svn. The significant upcoming changes (vidl1 rename, etc) have been delayed too long by the meagre time I have been able to put into the conversion effort and I am very grateful to no longer be the road block to these improvements. Regards, Ian. |
From: Amitha P. <ami...@us...> - 2009-03-20 19:31:03
|
Amitha Perera wrote: > Miguel, is there a direct tie between the SourceForge developer list and > the trac developer list? Or do we have to add a new person explicitly > to both? I justed re-added Vishal Jain, and he was automatically added to the trac as in the developers group. Just presenting one sample point. Amitha. |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2009-03-20 20:40:27
|
On Fri, Mar 20, 2009 at 3:30 PM, Amitha Perera wrote: > Amitha Perera wrote: >> Miguel, is there a direct tie between the SourceForge developer list and >> the trac developer list? Or do we have to add a new person explicitly >> to both? > > I justed re-added Vishal Jain, and he was automatically added to the > trac as in the developers group. Just presenting one sample point. > > Amitha. I added him as developer to trac after you added him to the sourceforge list; yeah, I'm that fast ;) No, seriously, he sent me an e-mail and since he was in the list (now I see that it was probably an unrefreshed list in the browser) of sourceforge developers I added him to the trac list. --Miguel |