From: D M G. <dm...@uv...> - 2009-09-18 21:05:03
|
As you know, the svn repository of panotools is divided in several regions. One of them is libpano. In the last few years Bruno, Jim, Pablo and I have been the main maintainers of libpano. Informally, Bruno has been release manager, Pablo has dealt with many maintenance tasks and integration with Hugin, Jim with Windows dependent code and compilation and I with main maintenance tasks. In an effort to create a policy draft for libpano I suggest the following guidelines. Please let me know what you think? I have added the following text to the file doc/developmentPolicy.txt in libpano --dmg ---------------------------------------------------------------------- * Release management -- Bruno has been mostly responsible for this, and has done a good job. But I believe that many of us (me particularly) have step on his toes and mess his release cycle. Bruno, do you want to add something regarding this? * For any changes: -- Before you start the work, please notify us in the panotools-devel mailing list of your intentions. the message does not to be long, but at least it should contain: * Objective * An expected timeline * Impact (change in functionality, configuration management, fix error, etc) This will avoid conflict with others. -- For each commit: * Well documented ChangeLog: list files changes, and what the work was. * Send the delta of the ChangeLog to the mailist list to inform others of your progress with respect to your intended timeline (whe more ---------------------------------------------------------------------- FOR DIFFERENT TYPES OF CHANGES * Changes to configuration files (Cmake, autoconf, automake, etc). -- Do the changes, commit them, and ask for others to test in different architectures/OSs. * Bug fixes including compiler warnings. -- Do the changes, test the build using make check, and commit. * New features -- Discuss them in advance in the list. We should determine if a branch is required, or the work can be incrementally done without affecting reliability. * Documentation -- Do the changes, commit them. ---------------------------------------------------------------------- -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-09-18 21:16:04
|
On Fri 18-Sep-2009 at 14:04 -0700, Daniel M. German wrote: > >In an effort to create a policy draft for libpano I suggest the >following guidelines. Please let me know what you think? > -- Bruno has been mostly responsible for this, and has done a good > job. But I believe that many of us (me particularly) have step on > his toes and mess his release cycle. > > Bruno, do you want to add something regarding this? The libpano13 releases have been driven mainly by the hugin release schedule (or lack of one). This reflects my priorities, but obviously if there is more libpano13 activity unrelated to hugin then this should change. Currently the only tools I know of that use the libpano13 library are: * PTmender, PToptimizer etc... * hugin * autopano-sift-C > -- For each commit: > > * Well documented ChangeLog: list files changes, and what the work > was. Actually, I've been overwriting the ChangeLog with the output of svn2cl - Luckily your ChangeLog entries are identical to your SVN messages, so there isn't any difference. This does mean that the emphasis should be on writing complete SVN messages. Don't worry about the ChangeLog file, updating this is part of the release process. > * Send the delta of the ChangeLog to the mailist list to inform others > of your progress with respect to your intended timeline (whe more We can send the SVN messages here automatically. -- Bruno |
From: Jim W. <jwa...@ph...> - 2009-09-18 21:58:47
|
Bruno Postle wrote: > On Fri 18-Sep-2009 at 14:04 -0700, Daniel M. German wrote: > >> In an effort to create a policy draft for libpano I suggest the >> following guidelines. Please let me know what you think? >> Very useful! Thank you Daniel. > obviously if there is more libpano13 activity unrelated to hugin > then this should change. > > Currently the only tools I know of that use the libpano13 library > are: > > * PTmender, PToptimizer etc... > * hugin > * autopano-sift-C > There are the Gimp, and hopefully soon, Photoshop plugins. I have a version of of Helmut Dersch's MPremap that I have updated to libpano13. http://webuser.fh-furtwangen.de/~dersch/mp/MotionPanoramas.html This is useful for remapping streams of images. It also gives some insights to the way PTStitcher was written. It is self contained. I need to review the license and I have never compiled the Java portion. -- Jim Watters http://photocreations.ca |
From: Bruno P. <br...@po...> - 2009-09-18 22:11:03
|
On Fri 18-Sep-2009 at 17:58 -0400, Jim Watters wrote: >There are the Gimp, and hopefully soon, Photoshop plugins. Last time I looked even the gimp-plugin-ng branch (which is the one that works) still has a very old version of the library and doesn't link to libpano13. -- Bruno |
From: Kornel B. <Kor...@be...> - 2009-09-19 06:31:23
|
Am Freitag 18 September 2009 schrieb D M German: > In an effort to create a policy draft for libpano I suggest the > following guidelines. Please let me know what you think? Looks reasonable. I can understand, that changes documented in ChangeLog, are handy. But is this information not already available throuh "svn log -v"? Kornel -- Kornel Benko Kor...@be... |
From: D M G. <dm...@uv...> - 2009-09-20 02:08:15
|
Kornel Benko twisted the bytes to say: Kornel> Am Freitag 18 September 2009 schrieb D M German: >> In an effort to create a policy draft for libpano I suggest the >> following guidelines. Please let me know what you think? Kornel> Looks reasonable. Kornel> I can understand, that changes documented in ChangeLog, are handy. Kornel> But is this information not already available throuh "svn log -v"? svn log requires an Internet connection, which is bad in its own way. Also, one delta in the ChangeLog might require several commits (due to errors, missing files, typos, etc). I'll really appreciate if people update the ChangeLog. And they can use the delta of the ChangeLog as the commit log message (which is what I do), but this is not as important. --dmg Kornel> Kornel -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-09-20 09:42:38
|
On Sat 19-Sep-2009 at 19:08 -0700, Daniel M. German wrote: > >I'll really appreciate if people update the ChangeLog. And they can use >the delta of the ChangeLog as the commit log message (which is what I >do), but this is not as important. The current ChangeLog file is created from the SVN commit messages. -- Bruno |
From: D M G. <dm...@uv...> - 2009-09-26 20:16:15
|
Hi Bruno, Since I am the one doing most of the significant changes these days, I'd say let us create a file called ChangeLog.svn that makes it explicit that it is created from svn logs, and leave ChangeLog to be manually. We can then move chunks from the automatic to the manual one when people "forget" but at least it won't override changes. I think RevisionLog.txt is too coarse for the goals of the ChangeLog, but we should maintain it too. It is intended for users, not developers. --dmg >> hi Bruno, run svn2cl with my changes from yesterday. You will see the >> big difference between both. Bruno> Since the ChangeLog is currently automatically generated and has Bruno> some real use as such, how about doing what Tom has done with Bruno> autopano-sift-C and have a separate hand-crafted history file: Bruno> https://hugin.svn.sourceforge.net/svnroot/hugin/autopano-sift-C/trunk/RevisionLog.txt Bruno> -- Bruno> Bruno -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-09-26 20:43:09
|
On Sat 26-Sep-2009 at 13:16 -0700, Daniel M. German wrote: > >Since I am the one doing most of the significant changes these days, I'd >say let us create a file called ChangeLog.svn that makes it explicit >that it is created from svn logs, and leave ChangeLog to be manually. We >can then move chunks from the automatic to the manual one when people >"forget" but at least it won't override changes. I guess you are going to carry on editing the ChangeLog file whatever I do, so I've moved the existing svn2cl generated ChangeLog to ChangeLog.svn. -- Bruno |
From: D M G. <dm...@uv...> - 2009-09-26 21:11:41
|
Thanks Bruno. I can see that the ChangeLog.svn file has its advantages. The way I see it, ChangeLog.svn tell us who is doing what, ChangeLog what was exactly done, and ReleaseLog the changes the user is interested in. --dmg Bruno> I guess you are going to carry on editing the ChangeLog file Bruno> whatever I do, so I've moved the existing svn2cl generated ChangeLog Bruno> to ChangeLog.svn. Bruno> -- Bruno> Bruno -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Kornel B. <Kor...@be...> - 2009-09-20 09:54:17
|
Am Sonntag 20 September 2009 schrieb Bruno Postle: > On Sat 19-Sep-2009 at 19:08 -0700, Daniel M. German wrote: > >I'll really appreciate if people update the ChangeLog. And they can use > >the delta of the ChangeLog as the commit log message (which is what I > >do), but this is not as important. > > The current ChangeLog file is created from the SVN commit messages. How? I made a commit (white space only), but ChangeLog in repository did not change. Kornel -- Kornel Benko Kor...@be... |
From: Bruno P. <br...@po...> - 2009-09-20 10:03:15
|
On Sun 20-Sep-2009 at 11:53 +0200, Kornel Benko wrote: >> >> The current ChangeLog file is created from the SVN commit messages. > >How? I made a commit (white space only), but ChangeLog in repository did not change. It is generated with svn2cl, but I usually only run it before a release. -- Bruno |
From: Bruno P. <br...@po...> - 2009-09-22 12:53:13
|
On Tue 22-Sep-2009 at 01:24 -0700, Daniel M. German wrote: > > Bruno> It is generated with svn2cl, but I usually only run it before a > Bruno> release. > >I think it will be better to maintain manually. The only reason it works >currently is most of us use the ChangeLog delta as the commit log. > >So what you svn2cl is taking the ChangeLog deltas and building the >changelog again :) I don't understand why we should enter the messages twice, the entire current ChangeLog has been created by svn2cl, it guarantees that nothing is missed. Switching to creating it manually will result in a less useful ChangeLog and it will be harder work to maintain. -- Bruno |
From: Kornel B. <Kor...@be...> - 2009-09-22 12:55:30
|
Am Tuesday 22 September 2009 schrieb Bruno Postle: > On Tue 22-Sep-2009 at 01:24 -0700, Daniel M. German wrote: > > > > Bruno> It is generated with svn2cl, but I usually only run it before a > > Bruno> release. > > > >I think it will be better to maintain manually. The only reason it works > >currently is most of us use the ChangeLog delta as the commit log. > > > >So what you svn2cl is taking the ChangeLog deltas and building the > >changelog again :) > > I don't understand why we should enter the messages twice, the > entire current ChangeLog has been created by svn2cl, it guarantees > that nothing is missed. > > Switching to creating it manually will result in a less useful > ChangeLog and it will be harder work to maintain. > +1 Kornel -- Kornel Benko Kor...@be... |
From: D M G. <dm...@uv...> - 2009-09-22 19:35:17
|
Bruno Postle twisted the bytes to say: Bruno> I don't understand why we should enter the messages twice, the Bruno> entire current ChangeLog has been created by svn2cl, it guarantees Bruno> that nothing is missed. Hi Bruno, The main reason that the ChangeLog created by svn2cl looks decent is because I try to maintain it as I go. Then, when I commit, I just cut-and-paste my changes to the svn log. svn2cl bundles all the files in a commit into one change, but it does not know what happens specifically to some of those files. For example, this is an entry I created in the ChangeLog. Notice how I have grouped changes into 3 blocks, and in one, I explicitly state the name of the function: So no, I am not suggesting we do this twice. What I am suggesting is that people update the changelog as they go, and use the delta they create (cut-and-paste) as the commit log. A good changelog is having, for each entry, the name of the file(s) changed, potentially its functions, and the description of the issue. If you canvas the currently generated ChangeLog you will see that many entries that list all the files, and all the changes separately, when it is clear that some of those changes apply to some files only (see the one at the bottom of this message). emacs does changelogs automatically with Meta-x add-change-log-entry --dm ---------------------------------------------------------------------- 2009-08-14 <dm...@uv...> * Updated tests cases to reflect the slight change in the boundaries of the ROI. * adjust.c, math.c, filter.h: The inverse of shear was broken. I have added a shearInv function that takes care of this bug. * PTcommon.c (getROI): Improved its computation of its edges to make it err on the outside rather than on the inside of the actual area. I have also added code to test the inverse computations for any particular function. ---------------------------------------------------------------------- This is what svn2cl converted my log to: 2009-08-14 18:36 dmg * ChangeLog, PTcommon.c, adjust.c, filter.h, math.c, tests/simpleStitch/reference/tiff_m0000.tif, tests/simpleStitch/reference/tiff_m_cropped0000.tif, tests/simpleStitch/reference/tiff_m_cropped0001.tif, tests/simpleTiff16/reference/tiff_m0000.tif, tests/simpleTiff16/reference/tiff_m_cropped0000.tif: 2009-08-14 <dm...@uv...> * Updated tests cases to reflect the slight change in the boundaries of the ROI. * adjust.c, math.c, filter.h: The inverse of shear was broken. I have added a shearInv function that takes care of this bug. * PTcommon.c (getROI): Improved its computation of its edges to make it err on the outside rather than on the inside of the actual area. I have also added code to test the inverse computations for any particular function. ---------------------------------------------------------------------- Example of a bad changelog entry: ---------------------------------------------------------------------- * ChangeLog, Makefile.am, PTcommon.c, TODO, adjust.c, correct.c, doc/Optimize.txt, doc/stitch.txt, filter.c, filter.h, libpano13.def, makefile.linux, makefile.mac, makefile.win32, morpher.c, pano13.def, pano13.rc, panorama.h, parser.c, pteditor.c, ptpicker.c, resample.c, sys_X11.h, sys_ansi.h, sys_mac.h, sys_win.c, sys_win.h, tools/Makefile.am, tools/PToptimizer.c: - Added FastTransform to the data structures removed as global variable - Added FastTransform to the dialog. - Updated the dialogs with some of the newer interpolator. TOTO: update correct.c, morpher.c, perspective.c, and remap to use transFormEx instead of the new transform (required to use new interpolators) Requires adding inverse stacks. - Fixed PTCorrect bug that had wrong order of operations on the image stack, Radial, then H & V shift. - updated the default interpolator to _spline36 - On Windows changed the default location to store parameters file from app folder to folder and file name %APPDATA%\Panotools\APPNAME.prf. This should make the plugins Vista friendly. Changed the default temp file location to %TEMP% ---------------------------------------------------------------------- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-09-22 20:52:13
|
On Tue 22-Sep-2009 at 12:35 -0700, Daniel M. German wrote: > >So no, I am not suggesting we do this twice. What I am suggesting is >that people update the changelog as they go, and use the delta they >create (cut-and-paste) as the commit log. I think this is an unnecessary hurdle for developers, and it leaves us with a ChangeLog that is unreliable - In order to do a release I will have to pick through the entire history and try to insert the inevitable missing entries. If we need a hand-crafted log, maybe it should be a separate NEWS file or a Changes.txt file? -- Bruno |
From: D M G. <dm...@uv...> - 2009-09-26 19:02:25
|
Bruno Postle twisted the bytes to say: >> So no, I am not suggesting we do this twice. What I am suggesting is >> that people update the changelog as they go, and use the delta they >> create (cut-and-paste) as the commit log. Bruno> I think this is an unnecessary hurdle for developers, and it leaves Bruno> us with a ChangeLog that is unreliable - In order to do a release I Bruno> will have to pick through the entire history and try to insert the Bruno> inevitable missing entries. hi Bruno, run svn2cl with my changes from yesterday. You will see the big difference between both. The problem with svn2cl is that it is blind and overwrites the ChangeLog without looking at it. Bruno> If we need a hand-crafted log, maybe it should be a separate NEWS Bruno> file or a Changes.txt file? -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-09-26 19:57:17
|
On Sat 26-Sep-2009 at 12:02 -0700, Daniel M. German wrote: > >hi Bruno, run svn2cl with my changes from yesterday. You will see the >big difference between both. Since the ChangeLog is currently automatically generated and has some real use as such, how about doing what Tom has done with autopano-sift-C and have a separate hand-crafted history file: https://hugin.svn.sourceforge.net/svnroot/hugin/autopano-sift-C/trunk/RevisionLog.txt -- Bruno |
From: D M G. <dm...@uv...> - 2009-09-22 08:24:26
|
>> How? I made a commit (white space only), but ChangeLog in repository did not change. Bruno> It is generated with svn2cl, but I usually only run it before a Bruno> release. I think it will be better to maintain manually. The only reason it works currently is most of us use the ChangeLog delta as the commit log. So what you svn2cl is taking the ChangeLog deltas and building the changelog again :) -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |