

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
17 messages in org.apache.maven.devRe: how we handle JIRA versions| From | Sent On | Attachments |
|---|---|---|
| Brett Porter | Aug 1, 2007 9:47 am | |
| Dennis Lundberg | Aug 1, 2007 12:31 pm | |
| Brett Porter | Aug 1, 2007 7:00 pm | |
| Jason van Zyl | Aug 1, 2007 8:21 pm | |
| Christian Gruber | Aug 1, 2007 8:25 pm | |
| Brett Porter | Aug 1, 2007 8:37 pm | |
| Jason van Zyl | Aug 1, 2007 8:51 pm | |
| Brett Porter | Aug 1, 2007 8:55 pm | |
| Brian E. Fox | Aug 1, 2007 9:01 pm | |
| Brett Porter | Aug 1, 2007 11:11 pm | |
| jaso...@gmail.com | Aug 1, 2007 11:24 pm | |
| Brett Porter | Aug 1, 2007 11:37 pm | |
| Dennis Lundberg | Aug 2, 2007 3:11 am | |
| Dennis Lundberg | Aug 2, 2007 3:20 am | |
| Jason Dillon | Aug 2, 2007 3:28 am | |
| Brett Porter | Aug 2, 2007 3:29 am | |
| Vincent Siveton | Sep 12, 2007 3:54 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: how we handle JIRA versions | Actions... |
|---|---|---|
| From: | Dennis Lundberg (denn...@apache.org) | |
| Date: | Aug 2, 2007 3:11:45 am | |
| List: | org.apache.maven.dev | |
Brett Porter wrote:
On 02/08/2007, at 5:31 AM, Dennis Lundberg wrote:
Excellent stuff Brett. Let me know if I can help.
Most of this is equally important for plugins and other maven sub projects. We should try to make an additional, more general, description of "versions" that is not tied to MNG.
Agreed, I figured I'd just start here. I can probably change the 2's to 1's and for the rest folks can do the math :)
- [ ] Backlog - issues that have not been reviewed for a version assignment (and may be duplicates, won't fix, unreproducible, etc.) - [ ] Unscheduled - new issues that haven't been reviewed yet
Hmm, has anyone looked at issues that are in Backlog? If not, what is the difference between Backlog and Unassigned?
I assume you mean Unscheduled, not Unassigned?
Yes.
Some people have given it a once over, it just needs to keep going until empty. Backlog is really for things that pre-date being diligent with JIRA :) We should aim to reduce and eventually remove it.
OK, sounds good. So in the long run we'd keep Unscheduled (as a version), which is a good name - easy to understand what it means for all.
- [ ] actions - [ ] rename 2.1.x to 2.1 - [ ] create 2.1.x after 2.1
Don't we need 2.1.x *before* 2.1 is released so that we can move "known issues" to it before the release?
Hmm, do you mean need it before as in it must exist to use, or it is scheduled before 2.1?
It's currently used as things that might go into 2.1, but I've seen it look confusing because it behaves differently to 2.0.x (clearly after 2.0, where 2.0 is already released). So I'm suggesting we reverse the naming and use "2.1" for things going into 2.1, and 2.1.x for things we know will remain issues in 2.1 and will be fixed in 2.1.x. I agree that it needs to exist as a version in JIRA whenever 2.1 does.
Yes, that's what I meant - need to exist as a version in JIRA.
How do we educate our users (and ourselves for that matter) on the difference between documentation and site? Perhaps we can make the pages look slightly different: a special title prefix/suffix, color scheme, menu struture.
my hope is that docs are distributed, site is not :)
What is your definition of site and documentation. I'm not sure I see how you mean. For me site is project related and documentation is product related.
I think it will be a case that users rarely care about the site, and only the docs, so they'll file in the right place. And if we can put links on all pages that say how to report an issue with that page, that'd be even better :)
Now that'd be a cool feature. Wouldn't it be possible for a skin to access the issueManagement element of the pom? Then we could add an optional link on every generated page that goes to the issue managing system:
<a href="url/to/issuemanagement/create/new/issue">Report an error with this page</a>
Can a skin have a configuration section like a plugin? Otherwise we might use a property from the pom. Would be nice to be able to switch this on/off in some way.
But we don't have that separation yet anyway...
- [ ] If an issue is too large - clone it to create smaller and more manageable issues
Sounds good. I prefer this to subtasks (which should be reserved for when a big task is composed of a set of steps that are all required to complete it).
Yea, I just stumbled across such an issue in MPIR. I'll just clone it.
Thanks! Brett
-- Dennis Lundberg







