Today we discovered a problem in JIRA where new users were not allowed to log into the system even though they already created accounts. We think this is only affecting new users to the system. We also found that if you do have a problem logging in, its tough to contact anyone about it! What a pain?
By the way, once you sign up for a JIRA account, you will be sent a confirmation email. Sometimes this email will get caught in spam filters. Or… maybe you mis-typed your email address. If any of these things happen, you won’t be able to login until you confirm the email address.
Anyways, if you have trouble logging into JIRA, leave a comment here and I’ll try to get to it ASAP and try to resolve your problem. We don’t want you to give up on filing bugs!
In our open community meeting a few weeks ago, our team mentioned a “Feature bug base” that was used to determine some of the features in Flex 4. Most of the community didn’t know what this “Feature Bug Base” was. In fact, it is Jira. However, logging a feature is just a little bit different from logging a bug. The form options that you will fill out are different. Voting, watching and commenting on these feature requests is the same.
Here are the steps to file a feature request:
1. Login into Jira at http://bugs.adobe.com/flex
2. Go to the “Create Issue” tab (at the top).
3. Select “Flex SDK” from the “Project” dropdown
4. Select “Feature Request” from the Issue Type. Note, if your request is just a small addition, please file it as a “Minor Request” instead. In general, Minor requests take a developer a few days to implement while Features take a few weeks.
5. Fill in the form for the Feature Request and submit it.
At the beginning of each release, we will look at these feature requests and how many votes they have gotten. If its possible, we will try to honor the most requested features in the following release. For Flex 4, at least two features came from this feature request database: Two-way Binding and Advanced CSS. These were two of the most requested features in Jira.
By the way, it is probably too late to get any feature requests into Flex 4, but, there is always Flex 5…
Wow, I just found out about this decision at the same time as the rest of the community. Our product manager, Matt Chotin just posted this to the Adobe Forums:
Subject: Kittens saved, Fx prefix will go away
A new discussion was started by Matt Chotin in
Kittens saved, Fx prefix will go away
Thanks everyone for your extended feedback. We will plan on removing the Fx prefix and implementing the multiple namespace solution. The details will need to be worked out (and specs will be posted) over the next few weeks.
Our goal is to have this all implemented by the time of our first beta which is planned for mid-May. The high-level plan (which is subject-to-change based on further spec and investigation and re-reading of all the posts plus requests for additional feedback) is:
– 3 namespaces for MXML, the MXML 2009 language namespace, the Halo namespace, the Spark namespace
– We will not turn on the option for merging namespaces as a) most customers are actually saying that they don’t mind the separation and b) this is what ends up causing all the future headaches with tooling, source portability, and future issues. We can consider the namespace merging/importing a future feature.
– CSS will need to support namespaces which means that FB will need to support CSS with namespaces. Work needs to be scoped/spec’d.
There are obviously lots of details to be worked out, and rather than getting your immediate input I’d ask that you hold off on detailed suggestions until we can get the right engineers assigned who can then start asking for feedback on specific issues. We will also probably roll this work into our normal API scrub class refactoring that often happens before a beta. So please do not expect to see instant turnaround on this change, but it will happen.
We certainly needed our team to have thick skins over the last few weeks but this also served to remind us just how passionate and great the community is. It’s nice working on a product that so many people care about!
Enjoy the weekend!
I really thought we’d closed the discussion, so, this goes to show that we do listen to the community. I’m glad to see it! Cheers to Adobe. On the other hand, I’m not looking forward to all the havoc this will cause us in testing land for the Flex SDK… but, its all for you guys 🙂 Have a great weekend!
For every bug that is in the “Open” status, there will be a “Milestone” associated with it. This milestone will tell you one of two things: When will this bug be fixed? Or, when was this bug fixed and checked in? In the example above, this bug will get fixed in the SDK Gumbo – Feature Complete milestone.
Here is a list of milestones that we have in our bug base and what they mean:
1. “SDK Gumbo – Feature Complete” : This bug will be fixed (or was already fixed) before a feature signed off. A “sign-off” means that a feature is complete and doesn’t have anymore high priority bugs open. This milestone isn’t used as often by our team anymore.
2. SDK Flex 3.3.0 : This milestone means that this bug is targeted for our next update to Flex 3. This release should come in a short amount of time. There are already 20+ bugs fixed for this next update of Flex 3.
3. SDK Gumbo Iteration 11 : Our team works in six week iterations. We are in iteration 11, right now. The iteration began this past Monday. So, if a bug is targeted for this milestone, it should get fixed in the next five weeks.
4. SDK Gumbo – Release: This bug is targeted for sometime within the release of Flex 4.
5. SDK Community Fix Candidates: These bugs are good candidates for the community to submit patches for. However, if no one from the community fixes this bug, it may not get fixed.
6. SDK Flex 3.4.0: This bug is targeted for another Flex 3 update following our 3.3 build.
All of the other milestones are past milestones, so, the bugs in these milestones should have already been fixed (or they were deferred).
Note that bugs that are not “Open” don’t get a “Milestone” set. For example, bugs in “Community” or “New” status will not have the “Milestone” set.
Deferred bugs is a tough topic. Someone is always unhappy because it means that a bug is valid and still exists in the our product. When you see that a bug you filed has the status “Deferred”, it means that we will very likely not fix it in the current release that we are working on. For example, bugs that are currently in “Deferred” status will probably not get fixed in Flex 4 (Gumbo). In fact, we may never fix it. Ah…it hurts me to say that, but, I’ll be honest.
In each release, we usually look at deferred bugs at the beginning or a few months in. We will take some time out to review what we might want to open for the release. This sometimes happens multiple times. We will likely look at bugs with the following characteristics:
1. Regressions – Bugs that broke something in an older build.
2. Votes – Bugs with a lot of votes.
3. Date filed – Because we are more aggressive about deferring bugs at the end of a product cycle, we might have deferred more severe bugs. Therefore, we usually revisit all the bugs logged a few months before our last release.
4. Bugs brought to our attention by customers. – We usually hear about bugs if people have blogged about it and word has spread or if our Adobe Support team brings it to our attention.
So, now that you have an idea of the bugs that we’ll consider re-opening after they have hit the “Deferred” status, I’ll talk a little about why we defer bugs. There are many, many reasons and my opinion probably differs from the other voices on my team. (Remember, this is not an official Adobe blog 🙂 ).
Reasons we probably differ a bug:
1. There is a workaround. Some of you hate this word, but, honestly, we are more likely to fix bugs that people cannot get around and may be blocking their development.
2. Few votes. If no one has commented on a bug or voted for it, it looks like not too many people care about the bug.
3. It seems like a corner case. We often get bugs that are very hard to reproduce because they only happen in a scenario that is very specific to one person. In other words the “discoverability” is low. This brings up the important point that all bugs should have an simple reproducible case attached to them. This makes figuring out a bug easier.
4. It has existed for several release (combined with #2).
5. It is late in our product cycle and the fix is risky.
Being in QA, my team has filed a lot of bugs, and like others, our bugs are often deferred. It hurts, I know. I wish our developers could fix every bug that comes to our team, but, the reality is that there are too many. I personally know that our Internal Review queue is pretty high right now because we are deciding what bugs to open and what to defer. My QA manager and I were just discussing how hard it is to tell someone (in a bug) that we just can’t fix it right now.
There are a lot of the bugs that have been filed by our Flex community since we launched the public bug base. For that, we say “Thank You”! However, we just don’t have enough resources on our team to fix all of the bugs. After two votes, someone on our QA team reviews the bug. Then, after they have reproduced the bug and deemed it a valid bug, it is sent to our “Internal Review Board” (IRB). In IRB, a small group of people decide which bugs get opened. These are often very tough decisions. Many of these bugs which we would really like to see fixed, but, just don’t have the time in the schedule to do it go into a “Community Milestone”. These are bugs that our team believe would be great candidates for the community to fix. And… we really hope you fix them. Please!!!!
Some of the bugs in the milestone are simple while some are probably more complicated. I have to be honest, however, few List class related bugs make it into this milestone. We don’t want to torture you by getting you well acquainted with these classes. The complexity of these classes make it much harder to submit patches that get accepted. But, we have taken patches in some List based classes, so, if you feel up for the challenge, do it! The community is free to fix any bug, but, this list of bugs is a good starting place if you are just looking to contribute.
To see this list, go to the “Home” tab when you first login to JIRA. Under the “Saved Filters” table, click on the “SDK Community Bug Fix Candidates” link. Check out the bugs and help fix one!
If you want to know how to submit a patch for the SDK, check out this blog entry: Submitting a patch to the Flex SDK
First and foremost, what does the ‘Closed’ status on a bug mean?
1. Fixed – Closed
These bugs have been fixed in a Flex SDK build. The ‘Closed’ status means that someone on the QA team has confirmed the fix in a build. Once closed, these bugs will probably not get looked at again by our team.
2. External – Closed
These are either Flash Player or AIR bugs. In general, these bugs are filed in a different bug repository. After the other bug has been filed with another team, the bug is closed. The flex team is unlikely to look at this bug again. However, we sometimes comment in the bug when we see that the corresponding player or AIR bug has been fixed.
3. Deferred – Closed
Deferred Bugs are valid bugs that an internal review team has decided not to fix for the current release. These bugs are usually looked at once during every release cycle. However, with the volume of deferred bugs, we often don’t get a chance to look at all of them. Instead, we’ll review at deferred bugs with many votes or particular severity.
4. Other status (Cannot Reproduce, Not A Bug) – Closed
These bugs have been closed by QA for the reason specified in the “Resolution” field. These are not likely to get re-opened unless the person filing the bug refutes the resolution. (see below about getting these re-opened).
Now that we are clear on what a “Closed” bug means, here are some suggestions on how to get a bug re-opened for review by the team.
1. Comment in a bug and state your case for why this bug should be re-opened. If someone is subscribing to the bug, they will get an email when you comment on the bug. In general, we are encouraging our team to subscribe to any bugs that they close that have been filed by a customer.
2. Sometimes no one is subscribed to the bug, so, #1 won’t work. Then, post the bug on flexcoders or the adobe forums and talk about it. A few people on our team watch flexcoders and the other forum and often respond to issues on there.
3. Blog about the bug. Again… the more exposure the better.
4. Vote on a bug (especially with Deferred bugs). When we are reviewing bugs to re-open every release, we will search for the deferred bugs with the most votes.
Good luck, we will try our best to hear your calls for help.
This post is courtesy of Peter DeHaan who writes the Flex Examples blog. He sent these out as a tip to our QA team and I thought I would share it with the community.
You can do a fancy search (for example, Flex SDK bugs in “Community” status filed by users in the past 24h):
If you want to convert that into an RSS feed, there is an “XML” link above the search result table (there is also some Excel file output and Chart view – but I’ve never really used those). The XML feed seems to be a fairly standard RSS 0.92 style. The RSS should give you titles, bug numbers, assignee, reporter, component, number of votes/attachments, etc.
Now, if you want to save that search as a filter, there is a “Save it as a filter” link in the upper-left below the navigation. You can give it a fancy name and description.
You can manage your filters by clicking the Manage button just above that “Save it as a filter” link. You can subscribe to filters by clicking the “subscribe” link next to the filter name. This page now lets you specify whether you want to email it to yourself or others, how frequently to send emails (hourly, daily, etc), as well as do you want an email if there are zero results.
In the community forum, there were quite a few comments regarding filing bugs. Some of the process around bug filing and the status of these bugs didn’t seem to be clear to everyone, so, I thought I would try to clear up some of the questions that people had in a series of posts about Jira and Flex’s bug filing process.
Why is voting so important?
1. When you file a bug, it goes into “Community” status. Bugs in “Community” status don’t necessarily get looked at by our team. Once a bug gets as little as TWO votes, it moves into “New” status. Every bug in “New” status will get looked at by someone on the Flex SDK QA team (like me).
2. Voting on bugs (and commenting in them) let’s us know that this bug is important to you. When we are deciding what bugs to fix or defer, the votes often sway our decisions. Now, just because a bug has a lot of votes does not mean it will get fixed. As you know, schedule, feasibility of a fix and other factors come into play as well. However, votes definitely help a bug’s chance of getting fixed.
3. You can still vote on bugs in the “Deferred” status. At some point in a release (usually the beginning), we will review some Deferred bugs. The ones with the most votes usually get reviewed again.
How do I vote on a bug?
1. You must be logged in to Jira to vote. If you are not logged into Jira, you will NOT see the “Vote” link. Instead, you will see a message (like the one below) telling you to login to see more links:
2. Once you are logged in, look at the links on the left most column of the bug and click on the “Vote for it” link under the “Operations” section.
3. After you have voted for a bug, commenting on the bug also helps us understand why this is important to you. Let us know if you have found a workaround for the bug or if it is blocking you from having some type of functionality in your application.
Now, go out there and vote! It really is one of the few ways that we can sift through all of the filed bugs to see what is the most important to the community.