Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Within our environment we have a core codebase, and several client-specific implementations of that codebase. When a client raises an issue, we need to determine whether it is a client specific issue, or whether it is a core codebase issue.
We use bugzilla to track our bugs, and we have a bugzilla product for the core codebase, and also for the client implementation (as they have customised the offering to have enhanced functionality). When a client raises a bug that relates to the core codebase, we need to raise that bug in 2 bugzilla products - core and client - so that both teams know about the issue. Ideally, we'd relate these bugs together so that we don't waste effort attempting to fix it twice, and so that the 2 Project Managers are fully informed of the progress of that issue.
My best idea so far is to use a comment/description including the works "Relates to bug " as it appears that the words bug magically become a link to the specified bug making it easy to get to that other bug's detail. This can then be searched for via the "A comment contains the search" criteria.
How do others do this?
I would use depends/blocks fields, if they are enabled in your Bugzilla, with the following workflow, roughly:
a bug X in a client-specific product is filed;
if it is found to be present in the core product, another "core" version of this bug (bug Y) is filed in the core product, and it is made to block the client-specific bug (Y blocks X, X depends on Y);
core team proceeds to fixing core bug Y;
when core bug is fixed, then client-specific bug X can also be fixed (it may or may not require additional effort).
The benefits of using depends/blocks instead of links in comments are:
notifications: when someone changes bug Y, everyone who's watching bug X will also get notifications;
enforcements: Bugzilla can be tuned to disallow closing bugs that depend on at least one open bug, so Y will have to be closed before X is closed.
We used to have a similar setup, with one core product and two production products that get shipped to customers. However, we had a single team for all products, so it's simpler. A bug was usually filed in a production product, after which we either fixed it there, or escalated it to the core product, or made a duplicate bug for the other production product. Whenever two bug records were there for the same problem, they were linked with depends / blocks.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
The company I just joined has a system of products that share a large percentage of their code base (via shared links in Visual SourceSafe). There are about 25 product types in this system as well as a PC interface.
The products network together using proprietary protocols that are largely undocumented. Historically, the method for maintaining this mess is to require that all firmware and software is released as a package. This, of course, causes significant delays in release schedules due to the required regression testing.
Has anyone else had a successful method of dealing with this type of issue? We're really getting beat up over it by management (I honestly can't fault them for feeling this way).
My first thoughts are to try to separate the device releases from each other somehow. Maybe pull shared functionality into libraries which are versioned. Then only update devices that use the libraries that have changed. I see issues with version mismatches from this however.
This is an organizational question. I understand how to keep the house of cards going via testing and processes, but I believe that better organization of the code base could have many good results.
I appreciate the advice.
significant delays in release schedules due to the required regression testing.
That's why folks do a "daily build".
Daily builds typically include a set of tests, sometimes called a
smoke test ( as in where there is smoke there is fire). These tests
are included to assist in determining what may have been broken by the
changes included in the latest build. The critical piece of this
process is to include new and revised tests as the project progresses.
When the organization -- as a whole -- has to keep the daily build working, then people change their responsibilities, points of view, biases, complaints and actions to keep the daily build running.
Daily stand-up meetings become focused on things that might break the build.
Individual developers have to refactor their code more carefully to avoid breaking the build.
Breaking the build becomes an immediate, instantaneous indicator of something being out of sync. Immediate. No delay. If I break the build today, everyone will know it tomorrow morning. No days were wasted assuming (or hoping) that things still worked. We can immediately roll changes back, or apply changes to keep going forward.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
What are some good procedures to follow when handing a project to another developer, in cases of when the original developer will still be around for a couple of months to aid in the transition? Let's assume a medium-sized web application if a concrete example is necessary.
As a junior developer, I have gotten several projects assigned to me for maintainance that were written by others. I believe the easiest projects to continue are the ones where the code is clean and well documented (meaningful var names and formatting as well), the archetecture is relatively strightfoward, and the developer took some time to write some notes on the use of his components. In Java this would include class-level javadoc; in other languages it may include a header at the top of the source code.
Also, if the original developer is available and open to questions, it makes learning the archetecture much simpler - no puzzling out what he was thinking.
I've been on both ends. Taking over a code base and handing it off.
You should:
Identify areas that aren't completely
obvious. So, if you have a directory
called "xml" but all your flash
object get their data from
"flash/swfs/xml" you should document
that.
Identify parts of the database which
are no longer in use. If there are
tables that simply have no use
anymore.
Identify areas of concern such as
speed/performance of certain pages.
If you have some really backwards
logic on certain pages, explain why,
if it's not been commented in the
code directly.
Any third party vendors should be
identified along with their cost and
use on the site. So if you're using
a delivery network to stream your
flash videos, definitely let that be
known.
If you have pages still in the
project, but aren't being used
anymore, identify them, or simply
remove them.
If you know for a fact that your
database was poorly designed,
contains no constraints or indexes
and has no primary keys on many
tables, mention it. It will let the
new developer know they need to
optimize the database.
If you hardcoded e-mail addresses
within the code and didn't put them
in .config files, identify that as
well.
I'm sure there are more but there are things I wish were brought to my attention on a project I had taken over at one point.
If you have written your code from the start so that it is sensibly architected and fairly simple to understand, and provided adequate documentation, transitional problems should be minimal.
But training is always nice.
For anything that requires a build environment (certain compiler, 3rd-party libraries, opensource libraries, paths, etc.,), have the original developer sit down with the new developer, at the new developer's workstation, and walk through the process of making a simple change, committing to the source control, building, smoke test, etc.. Lots of times projects that are out of the mainstream may have odd procedures for testing, or they may come from an unfamiliar repository branch, may need a specific compiler version, libraries, etc.. Bugs may be tracked differently, it may require specific logins or endpoints for testing, etc.. By walking the new dev through the process, on their workstation, you'll uncover all of those issues, saving the new dev lots of frustration.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I found an odd situation at work and I'm trying to figure out where to start with a solution.
We have a custom hardware/software device which contains multiple boards, each with their own function and flavor of software (CPLD, bootloader, application, etc). Additionally, the device interacts with a specific web app and a PC application.
Each one of these components has a revision history, tracked individually. Particular devices (which of course are all featureless black boxes) potentially have different versions of any and all components, hardware and software- we're still in the prototype and test stages.
What I'd like is some kind of unified version tracking, where I can trace software builds against bugs and feature requests, have a history/schematics for the boards, and- most importantly- what versions of components were tested against which other versions of components. In other words, I know that bootloader version 1 passed test in conjunction with board version A, but was not necessarily tested against version B of the same board, even though it was extant at the time.
Individual rev tracking is relatively easy; we have a handful of developers working different software components. It's tying them together and being able to say that "PRODUCT VERSION 1.0" consists of this bag of components, tested against each other and not much else. That way, when we update, say, the bootloader, I can have it regression tested against the current versions of all other components, label the whole "PRODUCT VERSION 1.1", and know what that snapshot is, even though someone comes out with version 1.4 of the application code the same day.
Ideally I'd like to track revision history separately across all components, along with users being able to log bugs against specific components or against the product as a whole, after which developers can re-assign the bugs to whichever subsystem is appropriate.
Something web-based would be ideal as developers aren't physically colocated.
We're currently using Bugzilla, which is nowhere near up to the task. I'm looking at Trac, but I'm not sure it's the right tool from the job. It seems like there are a lot of source control systems, a lot of revision history systems, and a few project management systems out there, but I haven't found anything that handles everything I need.
It may sound more complicated that it is, but it's pretty complicated when we're down in the trenches with it. There has to be a solution to this!
Any ideas?
Have you tried quickbase by intuit? It does a great job at consolidated version tracking and you can add functionality for separate revision history. Trac is good, but lacks the robustness of quickbase (IMHO).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are "upgrading" the systems at the company, moving from SourceSafe/BugNet/... (yeahy!) to some more serious systems. TFS is too expensive. We have come down to comparing OnTime vs Gemini. They both seem OK with an "OK" price-tag. We will of-course download and try them out both, but it would be nice with comments from experienced users. To me, they seem quite equal.
Has anyone used both, and can compare the two against each-other?
If you would recommend one of these, which one, and why?
Any other experiences with these systems? (Especially Gemini, seems hard to find reviews regarding this-one..?)
(We are talking about a smaller dev-team, max 8 dev in a project at a time, a couple of testers and some stakeholders/managers etc... Several projects running simultaneously. Need to be able to integrate to Visual Studio, Subversion with feed-back to the issue tracker etc)
Thanks for your time!
We use OnTime here - it has a good workflow environment but be warned that it does not scale well at all. We currently have 35 licenses with only 10 to 15 users online at any one time and it struggles.
Also be careful of the sales pitch for using the web or "remote" servers for distributed environments - it works fine with the demo/eval database but slows to a crawl once you start getting a decent amount of items in the database. All you have to do is look at a SQL profiler and you'll see the number of calls made to the DB.
If you profile the web services you'll also see that the web and remote environments have not been optimized at all to batch calls, so as soon as you move to an environment where there is any kind of communication latency it crawls.
Axosoft's support has been less than helpful on this as well - they strangely do not view these as bugs and instead view this as something we should expect in these environments. We have contacted their support over a number of other things as well and it is surprising how poor it is over other things as well.
Axosoft's excuse is that we should have found these things out in the eval period, but I don't know how they expected us to scale the data to production environment levels within a 30 day eval period...
We have been forced to revert to using the WinForm client over Citrix for our distributed teams.
Overall - it is a nice application if you have a small team in a single location. But if you have larger teams or people spread out in multiple locations I would avoid it at all costs.
Gemini is great, we selected gemini over many other bug tracking systems...
main features we liked:
user interface
extensibility (API's, REST based)
addon products (visual studio, outlook plugins)
source control integration (subversion)
source code available (asp.net c#), easy to setup and great support.
For a broader comparison with Gemini bug tracker and others in the same space, wikipedias Bug tracking comparison page might be of use. Although I don't know of a direct, in depth Gemini / OnTime comparison.
Take a look at Project Kaiser (short demo available). It is fast, web-based, supports embedded wiki, forums and chats. And it is free for 5 users :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have MS Sharepoint -- which isn't all bad for managing a task list. The data's publicly available, people are notified of changes and assignments.
I think that Bugzilla might be a little easier for management and reporting purposes. While there are some nice Open Source Scrum management tools, I've used up a lot of my political capital and can't ask for too much more than what we've got now. Money isn't the object -- obviously -- it's the idea that my team has too many specialized tools.
Will Bugzilla work out as a more general project management tool -- outside the bug fix use cases?
Will I be bitterly disappointed and wish I'd downloaded something else and made my case for a better project management tool?
Bugzilla Is a great bug tracking system. We have tried to use it for other project management tasks and the results are less then stellar. I would recommend finding something designed with your goals in mind.
Try it for yourself.
Get a $15/month account at wush.net and use it yourself for a while (no business relationship besides satisfied customer).
Bugzilla is powerful and has a lot of configuration options, which can be confusing.
I personally used it three years ago on a project I was working on. I had no project manager and I was the developer, so I needed a very-light-overhead systtem. Bugzilla gave me that. I put my main goal as an enhancement "productionalized system" and then I made dependencies to reach that point. I ended up having 160 nodes all dependent on each other. This essentially was a work breakdown structure. I didn't bother with time estimates, and I didn't bother with creating any other kind of project documentation.
A cool advantage was that as I coded, if I noticed something needed to be done, I would just pop it into bugzilla (20 second process once it's set up), tie it as a dependency, and go back to what I was doing.
Whenever I completed a task, I would look at the dependency diagram and find the outermost leaves (bugs that blocked other but weren't themselves blocked), and work at it.
The advantage of this method for me is that if a task had looked simple and had one node associated with it, but when doing the thing itself I realized it was more complex, I would just split it into different subtasks. This took only a minute and absolutely didn't involve a meeting with a project manager.
Other people on the team could track my progress by looking at open bugs, closed bugs sorted by dates, etc. They saw action, they left me alone. When I had external dependecies, I would make a bug, detail the work, and send that person a link via email. They could then see why this was needed by looking at the dependency diagram.
Note that unless previously agreed upon, I did not assign them the bug.
It worked really well and the system was ready one month early.
How will it work with SCRUM? Having only had a cursory glance at scrum I can't tell you. But that was my experience.
Using a dedicated host will allow you three things:
support
easy upgrades (unless you got gurus in-house, bugzilla management ain't easy--for me at least)
users across organizational boundaries.
Note that bugzilla has all sorts of security features, so it's easy to lock-down the users to what they need to see.
My stand-alone solution is DokuWiki + MantisBT + Subversion + Review Board, which can be integrated with relative ease. Hosted alternative is Bitbucket.org. The rationale is you write user stories on Wiki and can reference them specific tasks. Larger bugs can be collaboratively designed and the "wiki" link is provided on the bug report by Mantis. Review board lets you do peer code reviews against svn diff before change is committed.
We've used Trac and Subversion very successfully for several projects.
The main advantage here is being able to tailor reports, some very Scrum specific, to provide information to management.