With TFS2010 using the "MSF for Agile Software Development v5" process template, I'm having some difficulty in understanding exactly what an Issue is. The most specific documentation I've been able to find is this. Is an Issue a higher-level item for which we will probably generate a Bug for after some investigation in code/requirements? Or is an Issue something different than a Bug because it has not actually a mistake in code but is more of a critical oversight in design (for example, there was never an attempt to create a datepicker for all date fields and this is a UX issue but not really a bug) and therefore a change request of sorts? Or is it something different?
I think Issue == Impediment
An issue is a problem. After investigation it could become a bug in the software, or a task to change the process and code that supports it.
Related
I have an old Delphi application and i want to migrate it to the newest Delphi version. The problem is that the application is huge and migrating whole app at once would be too complex. I wonder what is the best approach to do this... Maybe form by form, placing a form into a dll and then using older forms in the new Delphi app and replacing them one by one (after clients confirm one form is working ok to continue with the next one). Not sure if this would be possible at all...Any other ideas?
I presume that based on your comments you do not have comprehensive test cases. In that case, you are simply in a world of pain, and there is nothing that will truly mitigate that. Without test cases, any approach you take will generate errors and bugs that will take you quite a while to catch them all. Build that into your expectations. In fact, with those as your expectations then you need to schedule a large testing phase and maybe that is a good approach. Upgrade all at once and test over the course of a few months.
You could first identify all 3rd party components that will eventually be needed and upgrade them to the latest version one at a time. That way you can at least identify bugs in a controlled manner per 3rd party component. Again, since you are relying on manual testing, this also will be error prone, but maybe you can focus on areas that use the upgraded component preferentially.
here my advice.
Before you start migrate, do a refactoring of your existing source-base.
1.) Remove un-used stuff.
2.) Try to move as much as possible to standard delphi components.
3.) Remove "un-used" units from your uses-statements.
4.) If needed, try to do some layering (App-UI,App-Logik,DB-Layer,Libraries)
5.) Look for 3rd-Party Components/Libraries, which might be not needed anymore in the latest Delphi Version, because the functionallity is now included in Delphi. If you spot such components/libraries, try to encapsulate them.
Now you have a new version of your software (still in the old delphi). Test it as exact as possible (Unit-Tests would be perfect).
If this is done, then you start to migrate to newer Delphi. I recommend to do it in one go (instead of dll and one by one).
I do not think there is enough information presented to give you specific advice.
My answer would be to bring in knowledgeable experts to look at your code, talk to your staff, look over your documentation and tests, and then present you with smart options. This can likely all be done via Zoom/Skype online. If you think about how much money you are going to end up spending on the conversion, and how much money you will spend on fixing problems because you went off in the wrong direction (and how many customers you could lose due to bugs/performance issues) this would be an extremely cheap investment.
There are a number of firms with Delphi experience that could help you. (I do not work for one and this is not an ad.) There are some well-known Delphi consultants that would likely have some free, or small flat-fee type, initial conversation.
If you are using a version before the Unicode switch in Delphi 2009, there are a number of online resources to assist. Delphi Conversion Unicode Issues
If you want some real-time advice and chatting about specific issues, check out a Telegram server dedicated to Delphi programming with nearly 800 members. There are nearly always some Delphi experts online answering questions. https://t.me/delphidevelopers You should be able to get some consultancy contacts from that server.
I'm a bit of a novice using JIRA and I don't know why this is happening. Lately, whenever I mark an issue as "Done", the system won't update as it being "Closed" but rather keep them as "Unresolved". Why would this happen? I don't know what information I must provide to solve this issue, except that I'm using JIRA 6.1.3, self-hosted, and no extra plugins.
That issue is neither fully resolved nor necessarily related, but you might want to check into Fix apparent data integrity violation with closed issues not actually being closed (JRA-34222), in particular Andreas Knecht's comment, summarizing potential race conditions during workflow changes:
Yeah so bulk editing while doing workflow changes definitely has the potential to cause this sort of a problem. JIRA doesn't really lock down a project while doing workflow migrations AFAIK so this kind of thing can always happen if concurrent operations are happening during a migration.
It's a complicated problem with an even more complicated solution. For some reading on an analysis we did ages ago see [not accessible link to 'Concurrency+Problems+in+JIRA']. Also [not accessible link to 'Concurrency+bug']. It's a known problem, but the solution has huge performance implications for JIRA and will take considerable effort to implement and test.
The last comment from a Cisco employee seems to confirm Andreas' summary that this might be a generally applicable issue with JIRA for the time being:
JIRA 5.2.8 we have been having an issue like this for months. I can
not view it, but see also: JSP-161469
Recent investigation has correlated "Tried to reopen the IndexReader,
but it threw AlreadyClosedException." message as closely following the
execution of Jython scripts. [...]
Possible Remedy/Workaround
While not addressing the root cause, you an see from the screenshot attached by Michael Knight that Atlassian seems to have been able to fix the integrity issue at hand by Using the Database Integrity Checker:
This aptly named JIRA feature is useful in a number of situations, e.g.
Before migrating a project to a new workflow [emphasis mine]
An external program is modifying JIRA's database
Troubleshooting a server crash
Using such a tool is obviously not without risks itself, so please note that Atlassian strongly recommend[s] taking a backup of your data before correcting any data inconsistencies accordingly
Good luck!
Here is a very good confluence answer that explains why this happens and a few workarounds Confluence Answer to Done issues as Unresolved
I've researched this, but have yet to find a viable answer. I've run into serious problems when trying to upgrade to MVC 3. Without going into a lengthy explanation, I simply need to revert back to MVC 2. Due to restrictions in discussing work projects, I can't list all the "why's", but this is a requirement. I add this in because I saw a similar thread in which all of the answers revolved around why this should happen and suggestions to make changes so MVC 3 could stay. I can't do this.
I used the upgrade utility, so I assume many changes were made that I'm not aware of. I finally got the application to build after changing the project references to System.Web.Mvc version 2, but the page won't load, giving this error:
The view at '~/Some/Shared/View.ascx' must derive from ViewPage, ViewPage, ViewUserControl, or ViewUserControl
I can of course Google this and fix it, but I'm afraid that I'm going to encounter myriad build or runtime errors after doing it, and was hoping for an easier way to revert. Any help in doing this would really be appreciated.
As with any kind of upgrade, it's always best to plan in contingency for any issues that may occur, and back your work up prior to upgrade.
Hindsight, however, is not what you're looking for. Do you not have source control? Can you not roll-back to a previous date or change set? If not, you're pretty much going to have to go through every issue one at a time, and regression test your entire application. I don't know of any software that can revert to a previous major version (i.e. usually includes major breaking changes) without quite a bit of hassle...
Just bite the bullet and put it down to a learning experience, and make sure you get the project in to source control and implement a backup system ASAP. Even my personal projects are backed up to SVN on my NAS!
When you are facing with this kind of dilemma, what do you usually do, and why?
In my case, I want to create a user authorization system that works with facebook connect and openID.
Authlogic is working, but unfortunately authlogic-openid is no longer supported (they really should clean up ancient codes on github!)
Thanks!
It's better to use whatever works.
During the time you're building website, luck of continuous development shouldn't be a problem: you just need to see whether this version works.
And if later in production, for example, facebook outdates part of its API, you'll have lots of time to find solution.
There's general philosophy behind it, which I summarize as "do not solve problem before it appears" :)
I I think the best way is to contribute to the existing plugin with your required code implementation. Advantages are
1 - you will get what you want
2 - Plugin will be more rich and active
3 - You will not repeat the work that plugin authors has done already (which saves your time)
Thanks
cheers
sameera
You're just going to have to make an assessment. It's not like the plugin is going to stop working one day (barring changes to OpenID or something), but it may limit which versions of Rails you'll be able to use it with. If you think that its limitations are a problem, then find another solution.
Thankfully, most plugins aren't that big. You can usually extract the functionality you need and keep it up to date yourself without that much work. But it is work, and it takes time. So whether it's worth it to you is really up to you.
I'm interested in using Subsonic 3.0 for developing a new ASP.Net MVC application that will be going into production use soon. Would this be a feasible option? Does anyone have an idea when 3.0 is going to be released? Is anyone else using it on a production MVC application?
I'm getting there - we're in the clean up phase and I'm happy to say Eric's jumped back into the fray :). I ran perf tests the other day and fixed up some bottle-necks and the core is pretty much where we want it to be.
I have no idea when it will be ready...
I'm not using it on a production site yet, although I am building a future production site with it, but its a hobby project so I can't get fired if the DAL has a bug and SS4 will probably be out before my hobby project.
So far I have not run across any show stoppers or actually any bugs at all and in the past I've found that if you do find an issue Rob is pretty good about getting a patch in pretty quick. So I guess to answer your question it's probably not "production ready", but in playing around with it I felt it was pretty darn solid and chose it over LINQtoSQL or Entity Framework. I'd recommend isolating your DAL (IRepository) that way if you run into something with SS you can swap out with something else fairly quickly.
Regarding as to when it is ready - I'll let Rob chime in on that one. I think he is using it for building out some other app so he's sort of using that to dog-fooding SS3 - my guess is it will be a couple months yet though.
I think for me the only show stopper is the fact that it doesn't run in medium trust.
While for nearly all projects we work on this isnt an issue as its a dedicated environment for fast "get-em up" sites that subsonic is REALLY good for this sucks as it means that a shared host is not possible... :(
but subsonic 2.0 is great for that even if its lacking linq support.
p.s i know they are working on this :)