As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I want to write (or find) a guide to effective bug reporting in a style similar to ESR's How To Ask Questions The Smart Way
What are your top tips for effective bug reports?
Step-by-step instructions on how to recreate the bug
Make sure you've attempted to isolate the bug to what you are actually writing a bug against, instead of something else that could be the cause.
List attempts to isolate the bug to something other than the software you are writing a bug against
Make yourself available to answer questions and be available to help troubleshoot/recreate the bug
The bottom line is you have to engage some level of critical thinking when the bug is encountered. Once you've exhausted all possibilities that it could be your fault, write up a bug. If you find out its your fault, but the software you are using/testing could have done something more usable to indicate its your fault, still write a bug.
Also, to be a truly great bug-reporter, you must avail yourself to those testing the bug to help them recreate it. Its likely you've just "got the knack" for recreating that bug and there may be steps you are not conscious of. You can't just complain and walk away, participate in the process and help the team out by testing, recreating, and troubleshooting.
Report the observable facts and then your interpretation of those facts.
Sometimes the best bug reports include something that is a gut feel of an understanding of the problem. Facts-only bug reporting discounts this valuable human resource.
Procedure used to re-create the bug including what was being done, what area of the application was being used and what event was happening at the time.
Statement of reproduceability (reliably, not) - helps the developer know how hard it should be to reproduce so they don't give up to quickly
Screen shots or documentation of error message / stack trace produced
Criticality/Priority of the bug (can it be avoid, avoidance steps, is it catastropic, does it have a business impact, what's the business risk, etc)
Environment - which environment was the bug found in. Remote, local, etc.
Too often, our QA people think they can just put in a ticket saying, here's my exception without any backup documentation. Its near impossible to reproduce let alone fix the issue without more information.
Don't assume the reader of your bug report knows the software as well as you do. Even the person who wrote the software may not know what you are talking about if enough time has passed since they wrote it. Write it so that anyone can understand and reproduce the problem.
Recommend this article: How to Report Bugs Effectively
For all the people who won't look at something without steps to reproduce:
My first programming co-op job I was assigned a bug that was essentially a random race condition that was making the system unstable. It happened at any point in the system execution, and all we had were a few stack traces pointing to a section of code that was pretty obviously fine. Somewhere another thread was mucking about with data it shouldn't be and if this thread was at the right point it would crash. Our QA got crashes about once a month. It took two weeks of combing through the system to find the culprit (yup, unchecked access to shared resources, about a 2 line fix) and fix it. There never was a decent steps to reproduce because there was no general way to reproduce it (save shoving a bunch of yield()'s in the right spot). If you're going to work on a multithreaded system, you better be ready to deal with bugs that can't be reproduced reliably, may not have stable steps to reproduce, and not just whine to QA because you couldn't reproduce the bug.
Note that the above is no excuse for QA to not include as much detail as they can when possible, just pointing out that it isn't always possible on modern software.
Write the steps to reproduce the bug. If you can't reproduce it, it won't get fixed.
Always report version number of software under test
Always report versions of any other software (browser, OS, etc.)
Always list all hardware
Steps to reproduce
Symptoms of bug
Screenshots, traces, logs, other attachments (if any)
How critical -- crash, UI, etc.
Report whether reproducible
Anything else tried, that did or did not reproduce the bug
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm working on an application and I needed an API wrapper for it. I noticed that most of the API calls I needed weren't implemented, so I went ahead with adding them in. There are a few bugs that need fixing which I'm planning to fix as well.
My problem is that development of the wrapper is almost non-existant at the moment. A bug submitted with a patch from October 2009 has been ignored so far.
I've emailed the main developer so I can commit my changes or even submit them somewhere, since on the homepage, it said that he's the person to contact with this sort of stuff. I've also asked about this on the discussion board, with no response.
My question is, how long should I wait for a response before forking this wrapper? It's one of only two open source wrappers for this API and listed on the API Doc's page. I hate to see that there's no improvements to it.
So, how long should I wait. What's normal for this kind of thing?
In case it matters: the licence is Simplified BSD
UPDATE:
The original developer finally responded; so I didn't end up forking. Apparently he was just very busy with work.
A good (relevant) article to read for anyone coming across this question: http://dashes.com/anil/2010/09/forking-is-a-feature.html
And thanks to everyone for your answers!
You can fork any time you want. Once I was in similar situation. As I had informed project admin that I'm going to fork, I obtained a response and it wasn't necessary :P
BTW I have written to sourceforge crew (project was hosted on sf) and that was their advice to fork.
Perhaps I am a little late but would like to answer on the level of definition.
The term Forking (branching away) refers to a split between groups and development in different directions. In this case a branching away can not clearly be seen so there was not actually a forking of a product. The action was clearly an alteration (extension) for a personal need. Should a product experience alterations and the result again be returned to the group it comes from is forking also not the proper definition. By definition open source encourages you to alter.
It depends if you plan to maintain your fork. If you do then the chances are it will become a better project than the original. Otherwise maybe wait a couple of weeks. Still, even if you released today there's nothing to stop the original project merging your changes so the community as a whole benefits either way.
There's no protocol, just call your fork something else and give the original prosjekt plenty of kudos for the original work.
Forks happen all the time, it's not necessarily a 'divorce' with the origial maintainers ... just happy coding.
Your additional calls might be usefull for someone else, but then again it might not.
Does the project has a publicly known mailing list/bug tracker, and if is - is it affordable to submit a patch there? Also, can't be a developer - become a maintainer at one of popular Linux distros, (submit a Gentoo bug/Launchpad entry).
If there's no sense in such actions - just fork.
Sounds like you've done the right thing though and tried to stay within the existing branch and now it is appropriate to fork.
If nothing else, forking is a more powerful action than most other things i.e. if you fork and still don't get the original developer's attention then you can be satisfied that you did the right thing. Of course once forked, there's no real reason why there can't be some convergence at a later stage.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
There was discussion in early 2009 about whether Microsoft would release the source for the F# compiler under the MS-PL/another license. A StackOverflow thread mentioned the state as of then.
Since then a lot has happened. We've seen an official release of F# with the .NET Framework 4.0 (and Visual Studio 2010), and for all I know, it's still completely closed-source. Have Microsoft just been quiet on the subject, or have they explicitly stated that they no longer intend to open-source the compiler? Perhaps things are in the process already. Basically, any news/considerations?
(As others have pointed out, the source has always been available, but is not yet under MS-PL, the 'approved open source' license - it currently has a more restrictive license.)
If I were being completely speculative, I might hypothesize that there are a number of things which might have "delayed" an open-source release of the F# compiler, including these:
The compiler code requires a bit of tidying up. The source has always been public, but without an open source license, not too many have looked at it. If you open it, people will look, in which case, it would be nice if the code followed at least some basic style guidelines, like using RecommendedDotNETNamingConventions rather than old_legacy_ones. In a sense, an open-source F# compiler would be one 'canonical F# app', so it would be important for the code to be of high quality with regards to basic things like F# coding conventions (that evolved over time the past 5+ years since the compiler code was originally developed).
The current code is hard to build on any platform. An open-source release would require at least reasonable docs on how to build the compiler (still non-trivial today!) and ideally build scripts for major platforms (e.g. Windows/linux/etc).
Even if IronPython/IronRuby ('open' teams) are "just down the hall" from the F# team at MS, making things 'open' still requires getting a great deal of buy-in/sign-off from management, and re-sign-off from new management if the management changes before you get the first open-source release out the door.
(all the usual 'overhead' of managing an open-source project)
All of the above take manpower, and manpower spent on those things is manpower not spent on other things, like working on the next version of F#. So in practice it may be more feasible for the handful of people doing F# work to nibble away at the work above in free time, rather than devote, say, an entire month to focus on an open-source release. So that might slow things down. (As others have tangentially suggested by pointing at links to job postings, some of the manpower could hypothetically be filled by interns at MSR.)
I emphasize that all of this is completely hypothetical speculation, as there's been no official word from anybody in a long time.
As Robert's comment on your question indicates, the source code is already available as part of each installation, though it does not come with an open source license. Additionally, reading between the lines, I think that things like this blog post by Don Syme still point to an open source release as a priority for the team.
Is it a question? I'm not sure, it's more of a request for any news relating to an existing situation. Adding "considerations" to the request is confusing, what considerations are there? The MS C# compiler is closed source but the C# spec is with ECMA. The F# spec has not been opened to the wider community which is the telling part I feel.
The decision is left with Microsoft, I dont think anyone here can answer that. However, even if it is closed source, we will still probably have all the benefits of the framework, as Microsoft is quite committed to improve and provide more functionalities in the framework. I think even if something is not open sourced or not, but the creator is supporting it or not, that is the biggest concern I have. We have tones of projects in open source but they become code junk after they are not maintained and never improved.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What if I think, that I found a bug in an open-source-app? What steps can I do, to provide as much helpful information for the programmers, as possible? And how I report best, to avoid to be annoying for the programmers?
Addition: As some here say, that the OS-programmers will love the report: Some projects are very picky about bug-reports. They say that are non-bugs or that it is non-reproducable, or the way it behaves is intended or similar things. Some of that critic towards the bug-reports may be justified, but often it isn't. I want to 'optimize' the bug-report to get the best feedback (preferably a fix) out of it.
The minimal information that I as a FOSS developer would like to get from someone submitting a bug report is:
software version
platform
brief description of the bug
sample input that you think is correct
sample output that you think is incorrect (and why you think this)
Exactly how you go about supplying the information will vary enormously from app to app. Before posting the bug, you should take a look a the support newsgroups or mailing lists to se how this kind of thing is handled.
Edit: If the bug is non-reproducible or intended behaviour, I don't think you will be getting a fix, no matter how you optimise the report. But you do always have the option of fixing it yourself if you are utterly convinced it is a bug.
First, go on the project page and check for information on how to report bugs. They might have a preferred way of doing it.
Most projects have mailing lists. Most of them have a user and a developer mailing list. Start by searching the lists to see if the bug you have discovered was already discussed. Maybe it's not a bug and the product simply does not support what you try to do.
If you have already digged in the code and found the cause of the bug (and maybe the fix), subscriber to the developer list and post a message describing the problem. Include a complete description of the problem, the version you use (and the version of other software if needed. ie.: Web server, OS, ...), a test case, what you found in the code and the patch you made. If it's a bug, they will tell you to report it in their bug tracking software (bugzilla, mantis, redmine, track, ...)
If you don't find anything in the code, subscribe to user list and post your problem.
Avoid saying thinks like "please, I really need to fix or I ...". Open source developer are not your employees. If you want something fixed, you can always do it yourself. Avoid ultimatums and rant about the software.
If the bug was already reported, the only thing you can do is watch it or vote it up. Avoid adding comments like "me too!" or "we need this fixed!" or "why is this still not fixed?!?". That is annoying.
Find the bug system (for example, https://bugzilla.mozilla.org/ for firefox) If you can't find any links off the main page or from google, you may have to use one of the projects mailing lists or forums. Poke around a bit and find the most appropriate one to use.
Once you have figured out where bugs should be reported, do a search to see if your bug has already been reported. If it has, see if there is anything you can add that would be helpful (me too! comments are not being helpful, additional information is very helpful)
When it comes what to report, first list your environment (operating system, what version you are using, where you got it from, etc) Describe the bug (what is going wrong), and give detailed steps on how to reproduce it
For general advice about reporting bugs (what information to provide, etc) I recommend Simon Tatham's paper: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
A. They will love to hear from you, this is not annoying.
B. describe exactly how you can reproduce the bug, what steps, what OS, what else is running on the system.
C. look at the open source project's site - it probably has an address to submit this kind of info.
Find the application's website. There is usually information there about bug reporting procedures, as well as bugs that have already been submitted (so that you don't submit a duplicate). Error messages, screenshots, and steps to reproduce are what I always like to have when I am trying to track down/fix a bug.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Has using an acknowledged anti-pattern ever been proven to actually work in a certain specific case? Did you ever solve a problem or gain any kind of benefit in one of your projects by using an anti-pattern?
My understanding of the "anti-pattern" concept is that it encompasses solutions that have drawbacks that only reveal themselves over the long term. Indeed, the primary danger associated with a lot of them---like writing spaghetti code with loads of global variables and gotos every which way, or tossing exceptions into the black hole of an empty catch block---is that they're seductive because they provide an expedient solution to an immediate problem.
EDIT to add: Because of that, sometimes you do derive benefit from these anti-patterns. Sometimes your calculation that you're writing throwaway code that no one will touch again is dead wrong and you wind up with maintenance programmers slandering your heritage and sexual hygiene, but other times you're right and that crummy shell script that's held together with baling wire and spit does the job you intended it to do and is then blessedly forgotten, saving you the considerable time and effort of putting together something decent.
Anti-Patterns are still so widely around just because they solve a particular problem (while creating 10 new ones). Also known as workaround. But how do they say? Nothing lasts longer than a makeshift.
In fact I believe we'd all be jobless if things had been done right from the beginning.
The biggest problem that it has solved in my experience is launching a new application.
When the dev team has scoped the new application thouroughly, the timeline to implement the correct solution is usually too much for management to bear. Therefore, oftentimes, you code to meet the timeline, rather than "correctness" of the solution to get to the launch date, (but have others coding the "correct" solution for the next rev), making it essentially "throw-away" code.
One software anti-pattern is Softcoding, also defined at the daily WTF. Softcoding happens when programmers put material that "should be" inside code into external resources.
I'm working with software that some might say is suffering from softcoding. External files drive the software. Those external files are a micro-language: they must be compiled to XML before the software can use them. This micro-language has its own tools.
But softcoding is always in the mind of the beholder.
Having the material in a micro-language with its own parser has made my life easier. One data source can generate many different outputs: In addition to the version that the main program uses, I am able to extract information into HTML, .csv, and other formats that our customers want. Other programs can generate code in the micro-language, making automation easier.
In our case, softcoding has been a useful pattern, not an anti-pattern.
There is a reason for calling it a pattern rather than a law.
I would surmise that almost everyone has at least one example of a place in code where exactly the wrong thing was done, and it turned out better in the long term than the "right" thing would have.
And a far longer list of examples of anti-patterns causing trouble.
I have used magic pushbuttons a number of times, out of ignorance or laziness, and sometimes it actually worked out just fine, and it turned out that I did not need the extra abstraction of proper MVC.
Duff's Device utilizes the Loop-Switch Sequence (AKA For-Case Paradigm) anti-pattern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When deciding whether you are getting involved in a fairly big open source project in order to contribute to its code base, how significant are the project's issue tracking facilities (i.e. tracking of bugs & feature requests) for your decision to contribute or not?
There are still many non-trivial (huge code base) open source projects out there, that don't formally do issue tracking - and while some contributors may indeed still do this privately in the form of miscellaneous "ToDo" lists, I have personally found the lack of availability and established use of issue tracking to be a fairly reliable indicator for a lack of organization, structure and overall project coordination.
What are other people thinking?
I would say it would be a fairly significant factor.
An open issue tracking system is one component of what I would call having an 'open development process' - where anybody who is so interested can see the developers' decisions as they are being made, and contribute to the discussion.
Some projects don't really have an open issue tracking system (or a good one) but still have publicly visible discussion lists, maybe an IRC channel where there are always people on, maybe a forum/bulletin board, etc. In my opinion such projects are still fairly attractive in terms of contributing to them.
What I have personally found is that while I work with very many different open source projects out there, I don't ever really become part of a larger group. However I do find bugs and would like to report them and would like to find out if the issue was found before, and when and if it is going to be fixed.
For myself personally, an open bug tracker or mailing list where I can shoot a one-off email to notify people of the bug is better than having to signup for the mailing list or register for the bug tracker. I already have enough accounts all over the place, I don't need yet another one for the piece of software.
So the friction involved in reporting a bug is definitely an issue, also being able to view the status of bugs and having them be searchable is a big help in determining on whether or not I will report my issues to the project or not.
So yes, open issue tracking, easy to use, easily visible (digging through a page for 20 minutes is not my idea of fun) and best of all with as little friction to get a report of a feature wanted/bug in.
A number of projects that I'm involved with still do everything on the mailing lists. If a bug comes in (and gets confirmed, and can be fixed) its put in some kind of BUGS file within the repository. As things get fixed, the entry in the file is noted.
Not my preference, but its what other contributors are accustomed to and like. It could be that someone doesn't want the hassles of hosting the bug system, dealing with the SPAM it might attract, etc. Could it be that the project doesn't get very many bug or feature requests?
The real question of 'should you' really revolves around the code, no? Or how much you could learn / teach by working with any particular group? If you begin contributing and show yourself to be friendly and useful, you might meet no resistance when suggesting something like trac or bugzilla.
The only thing that would make me consider steering clear of any given project would be a total lack of any kind of version control. But, even then, I'd have to weigh what I'd be given up against the hassle of managing patches with racy merges.