Jody,
At the present time, There are a good number of uDig versions on the JIRA site with which a user may report against. However, and as we know, these versions also have the further distinction of their respective operating system(PPC OS X, x86 OS X, Windows XP, Windows Vista, and Linux). It would be useful if the JIRA allowed the user to post/address this distinction, especially when reporting and when closing a report.
Within JIRA, is there a way to create a means by which a bug may be closed for one particular build/os version, whilst allowing it to remain open for another build/os version? In other words, let's say a bug or feature request is now working on x86 OS X, but is not working on PPC OS X, if the user could close the ticket for the x86 OS X, whilst not effecting the ticket for PPC OS X(etc.), that would be useful.
Also, looking at this even deeper, if a rule were established at the JIRA, wherein any new bugs that are posted are first reviewed by one/some members, wherein the bug is tested against all the other builds and respective operating systems. For example; John Doe files a ticket on uDig JIRA, reports a bug on x86 OS X operating system, uDig version 1.1.1. Upon ticket submission, one/some dedicated users would receive an email report of the ticket, asking them to check this bug against their respective uDig version and operating system. Upon one/some of the dedicated users checking this bug on these other respective uDig versions/OS', they would report if the bug exists or does not exist on that respective uDig version and operating system, thus making the ticket complete and accurate across the board. In this scenario, I would be happy to volunteer as one of the dedicated users who checks against x86 OS X and PPC OS X operating systems and my respective uDig version I have installed on these operating systems.
Regarding the uDig builds themselves, right now I have build 1.1.1 and a Trunk build that Martin was kind enough to compile/provide to me a month or two back. However, in the About > uDig menu it does not say the exact build version. I understand that it is difficult to create builds against each operating system, but I do feel it important that priority be given to this, so that when a build does get released, it gets released for Windows, OS X, and Linux in a uniform manner. By first making sure this is constant, and then making sure a dedicated group of bug checkers is active, can then the JIRA process be made more clean and efficient.
If you take notice of the below attached screenshots, you will see how there are older listed in the JIRA as when compared to those that are listed on the uDig download page. Perhaps you can better explain to me(and others) how the transformation/evolution process occurs? Meaning, when a uDig release makes it to the uDig downoad page(e.g.- uDig 1.1.1), should the JIRA references to 1.1.1 be then changed/converted to uDig 1.1.2 for example? Meaning, when a release is made, like uDig 1.1.1, users now have that release, and any such user that indeed files a JIRA bug report, will indeed be filing it against that 1.1.1 version. So, the JIRA should in fact have the option for the user to report against 1.1.1 in the selection process, and in the versions section of the JIRA, the active reference should be 1.1.2(or whatever ascending version number is used after 1.1.1), correct?
When I look at the JIRA, and see uDig 1.1-RC13, 1.1RC14, 1.1SC1, and 1.2.M3, 1.1.2M4, it provides a bit of confusion for me, because there are both older versions and newer version being listed when compared to my 1.1.1 release version being used. I understand that there are specific efforts/builds that are satisfying individual interests/projects, but in general, and for the sake of simplicity for the end-user(meaning assuming a person has no previous experience with uDig, it's development, or it's developers-active or not), would it not be beneficial to reduce this to merely and only the subsequent version(1.1.2 for example), with reporting options for 1.1.1 and 1.1.1 only? If a user is using an earlier version of uDig(1.1.0 for example), s/he should not be given the opportunity to report a bug on that version... it causes to much overhead. Users should be made aware on the JIRA that any and all tickets should only be filed against the latest release build(1.1.1 for example), and in the JIRA those tickets are applied/attached to the 1.1.2 version. Any specific or individual efforts that employ a particular version, should also have their own specific area for ticket filing(uDig 1.1-RC13 for example). Also, uDig should also make as a rule that only the latest(or last) version of the respective operating system is the one that is considered when checking/testing against filed tickets(bugs).
If possible, the JIRA should be setup/configured so that the first menu selection the user choses is the OPERATING SYSTEM(Windows XP, Windows Vista, PPC OS X, x86 OS X, Linux, etc.). In fact, the user should be prompted to push a button, which in turn queries the system information of the user's computer, auto-populating the JIRA with OS version, Java version, applicable hardware(amount of memory, # of processors/speed, etc.). In general, the only version that should be having tickets filed against it should be the latest release version(1.1.1 for example), and the only version it should be applied towards should be the current development version(1.1.2 for example). For all other release versions and development versions, those should be isolated and made distinctly different/separate, because in fact they ARE distinct and specific, and serve a specific individual or group of individuals(or a company/project), instead of the entire uDig community/project/software application as a whole. Again, I've said this many times before... the JIRA should be constructed with the assumption that the person filing the ticket has absolutely no prior knowledge of the uDig project or it's history/inner-workings. It should be dead-simple, and should pose the structured questions so the user need not have to know anything about the project, but instead merely and easily select a few pre-defined answers to the few posed questions, and then type in their ticket(bug or feature request) details explaining the bug/feature request, and press submit. Upon pressing submit, the dedicated users who test against specific operating systems receive an email with the ticket, so they can read it, understand it, and then test it against their respective operating system version, which should be the latest, as should be their Java installation, as should be their uDig application release. If these dedicated uDig system-specific ticket checkers are unable to understand the ticket, the dedicated users should be able to easily send a message to the person who filed a ticket as to get further clarification, and in the event the dedicated uDig ticket checker does not get a timely response from the person who filed the ticket, the dedicated uDig ticket checker should have the one-click option of being able to delete that ticket all together.
Right now any John or Jane Doe that goes to the uDig download site is given the opportunity to download release 1.1.1, 1.1.0, and 1.0.6. However, it should only be users of 1.1.1 that need file JIRA tickets. uDig is not a large enough project, and does not have enough resources, to be managing all these release versions. Until it matures to such a point, it should, by design, only ever at any one time, provide users with the ability to file against the latest release version(1.1.1), and in general should only have one development version(1.1.2) to which those tickets are applied. For all other release and development versions, those individuals(projects/businesses) who are actively using/working on those specific versions, should in fact have their own project/version-specific section in the JIRA, that is clearly not commingled with the staple/base/general uDig release & development application. Perhaps the JIRA has menu selection that instructs the user if they are using a version other then the current release version, that they are in effect using a version that is part of 'project x' or 'project y' or 'project z' for example. And these project x's are specific to a particular effort or collaboration for a particular user base/project/company/etc., hence their existence, hence their clear separation and distinction.
Also, it is very important that the builds for each operating system always remain uniform and standard. Release versions(1.1.1 for example) should always install normally, placing the respective uDigWorkspace folder into the user's Documents folder(as is the case on OS X for example), whilst development releases(1.1.2/trunk for example) should contain said folder(s) in the package itself, or in it's own uDig folder, so that the testers/checkers can easily be running the release version and the development version at the same time, without either of them interrupting with the other's files/configurations. This will allow testers/checkers the ability to easily download the latest development build from the main programmers efforts, install it, and then test/check it against all the respective tickets they have on their plate from previous JIRA ticket filings, which they have served as tester/checker.
This process is repeated until the bug is fixed across all platforms. In this scenario, we make sure that the latest Release version of uDig is the primary focus, and we make sure that when a uDig programmer fixes(or attempts to fix) a Bug, s/he makes builds for OS X, Windows, and Linux, so that the dedicated testers/checkers may download latest Development version, check any Bug tickets, and report back accordingly.
Thoughts/Opinions/Ideas?
Eric Jarvies
On Mar 7, 2009, at 5:46 AM, Jody Garnett wrote:
I am failing at the 5 min code sprint; I find myself fixing the bugs rather than just organizing them (especially when they are documentation bugs such as this one):
With this in mind I have updated the page on running uDig to describe how to switch languages:
I will try and resist.
I am finding that many of these bug reports may already be fixed; and we will need to either talk to Jesse to confirm; or ask a tester to try and reproduce the problem (so testing is going to be very important for this code sprint).
Jody
On Sat, Mar 7, 2009 at 11:06 AM, Jody Garnett
<jody.garnett@xxxxxxxxx> wrote:
For this code sprint ha- ving testers available to verify fixes is going to be amazingly important.
Andrea and myself have been putting some time into reviewing the bugs in Jira and organizing what bugs we think can be fixed in 10 minuets. Many of these bugs we think are already fixed - but we need a tester to verify.
When we are done organizing Jira the following link should provide a good overview of what is going on.
Thanks to GeoServer for the good idea of presenting a road map of critical bug fixes and new features.
Jody
On Sat, Mar 7, 2009 at 1:51 AM, andrea antonello
<andrea.antonello@xxxxxxxxx> wrote:
Dear community of udig developers and users.
We are delighted to propose you the 10 minutes bug sprint!!
_What is the 10 minutes code sprint?_
A code sprint in which bugs and feature requests will be fixed that
are supposed to take only 10 minutes to the involved developer (in a
perfect world).
_What will it gain?_
Many small bugs fixed that make users very happy.
Lots of satisfaction for the developers that are involved that will
smash lots of bugs.
A nice and clean JIRA list.
All in all a happy community.
_When will it be?_
The sprint cover Saturday and Sunday the 14th and 15th, as usual,
all-around-the-world, with Sydney giving the good start push. :)
We set up a page on the osgeo wiki, please visit it for further information:
http://wiki.osgeo.org/wiki/Udig_the_10_minutes_bug_sprint
Join and enjoy,
The PSC of uDig
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
