Here is my take ... We all agree on the meaning of the "affects version" field meaning the version reported against. So there always needs to be a "Nightly" version to reflect problems with the lastest and greatest source code.
The "fix version" field has traditionally been used (by MyFaces) to mark the version the bug was *actually* fixed in. So historically we have been marking things fixed as nightly and then right when we release (or at the point of a branch) we change nightly to the next version number and add a new "nightly" version. The release notes are also built of this scheduled version so IMO its important to have the stuff marked as version x to be only what's actually fixed in that version. In theory you could change the ones you don't fix back to "nightly" if they don't get fixed but that is a *tedious* process that generates a lot of spurious emails. (I'm looking at setting up a custom email notification scheme for our project btw that might cut down on some of this.) I think it would be good to have a free text field for "scheduled to be fixed: " and have it be editable only by committers. We can then create custom filters and reports in JIRA that essentially do what Howard is trying to do here. Ultimately I think 3 fields are required: reported, scheduled and actual. Since we are already using the field in question for "actual" I think the new field should be used for scheduled. I also don't think its possible to have a separate version list for the two existing fields so IMO its better to keep the non-existent version numbers out of the list of choices presented to the average user. sean On 11/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Yes, it does. > > in this case, we have been using this field in the wrong way so far. > > Sean, can you confirm? > > regards, > > Martin > > On 11/22/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > The field I changed is called 'fix-for' as in 'we should fix it for'. > > There is a separate field to mark what version the bug was reported > > against. AFAIK, there is no 'is fixed in'; that information in implied > > by having a bug marked as 'fixed' or 'closed' and being marked 'fix-for' > > a particular version. > > > > In other words, if the bug is fixed and is in a particular version of > > the roadmap, you know what version it was "fixed in". While the issue is > > open, you know what version we are planning to fix it in. > > > > Does that make sense? > > > > > -----Original Message----- > > > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > > > Sent: Monday, November 21, 2005 9:45 PM > > > To: MyFaces Development > > > Subject: Re: Plan for 1.1.2? > > > > > > The confusion seems to be - is this version number a: > > > > > > is fixed in - version number or a > > > is reported against - version number > > > > > > indeed, there should be two fields in jira to reflect this, right? > > > > > > regards, > > > > > > Martin > > > > > > On 11/22/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > > > I think there are several points of confusion here, and I'm not sure > > on > > > > whose part. > > > > > > > > The version number in JIRA is listed as 'fix-for', which to me meant > > > > that is the version we plan to fix the issue in. The 'road map' > > lists > > > > future versions and the issues that are planned for each. One > > version > > > > does not a roadmap make. :) > > > > > > > > Without listing what issues we are planning on fixing in the future > > and > > > > when, those who depend on MyFaces have no insight into what is going > > on, > > > > and no basis to express the priority of an issue or know when to > > expect > > > > a fix. My categorization of what issue was to be fixed when was > > meant > > > > only as a starting point for a conversations on prioritizing the > > issues. > > > > Those on the dev list could look at the two version and make > > reasonable > > > > informed opinions on what should be moved when. > > > > > > > > But what I'm most confused about is the state of JIRA now; There was > > a > > > > 'nightly' version which I numbered (because we aren't planning on > > fixing > > > > those in the nightly, we're planning on fixing them in the next > > > > version). Now it's been archived and the next versions (1.1.3, which > > > > isn't the upcoming version) ahs been listed as nightly. I think that > > was > > > > a mistake, no? I think if you meant to put things back, you would > > have > > > > renamed 1.1.2 to nightly, right? > > > > > > > > So, after all this, we're back to the original question: Which bugs > > are > > > > to be fixed before we can start to release 1.1.2? And how would a > > > > user/developer know unless they are listed in the "Road Map"? > > > > > > > > > > > > > -----Original Message----- > > > > > From: Sean Schofield [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, November 21, 2005 12:03 PM > > > > > To: MyFaces Development > > > > > Subject: Re: Plan for 1.1.2? > > > > > > > > > > OK I changed 1.1.3 back to nightly for now. I also "archived" the > > > > > 1.1.2 release. This way users can't report issues against this > > > > > version but the issues that Howard assigned to 1.1.2 have been > > > > > preserved. > > > > > > > > > > sean > > > > > > > > > > On 11/21/05, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > > > > > I do also think that this can create confusion if we don't go to > > a > > > > > > discussion process first. We should consider which are the > > criteria > > > > to > > > > > > define which are the more important bugs to be fixed or features > > to > > > > be > > > > > > implemented for the next version (although, I recall that it was > > > > > > decided that votes on an issue was the most important > > criterium). +1 > > > > > > For changind 1.1.3 to nightly in the meanwhile... > > > > > > > > > > > > Regards, > > > > > > > > > > > > Bruno > > > > > > > > > > > > 2005/11/21, Sean Schofield <[EMAIL PROTECTED]>: > > > > > > > I also think we should get rid of the 1.1.3 version (change it > > > > back to > > > > > > > nightly.) This is going to cause a lot of confusion. > > > > > > > > > > > > > > We need to have a group dicussion on how we might change JIRA > > to > > > > give > > > > > > > better information. Perhaps a field for the "scheduled" > > version > > > > which > > > > > > > is independent of the version fixed field ... > > > > > > > > > > > > > > For now I say change 1.1.3 to nightly and create a 1.1.2 > > branch in > > > > > > > order to minimize confusion. Someone has already asked me > > offlist > > > > > > > which version to report their bug against (they were using the > > > > nightly > > > > > > > build but now there is 1.1.2 and 1.1.3). > > > > > > > > > > > > > > sean > > > > > > > > > > > > > > On 11/21/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > > > Well I disagree slightly with how this is being handled. I > > > > think we > > > > > > > > should have created a 1.1.2 branch before getting rid of the > > > > nightly > > > > > > > > version. And we probably should have taken an informal poll > > > > before > > > > > > > > doing that. > > > > > > > > > > > > > > > > I agree that we should have a roadmap before 1.1.2. I agree > > > > with > > > > > > > > Manfred that we should release tomahawk along with the > > > > implementation. > > > > > > > > That should be the policy until we have a compelling reason > > to > > > > do > > > > > > > > otherwise. If anything there are more useful fixes in > > tomahawk > > > > than > > > > > > > > the implementation. > > > > > > > > > > > > > > > > In the meantime, without a nightly version label in JIRA and > > > > without a > > > > > > > > 1.1.2 branch, basically every fix that goes into SVN will be > > > > part of > > > > > > > > the 1.1.2 release. On the other hand, we don't want to be > > on > > > > the > > > > > > > > branch for too long either because we will have to merge > > down > > > > and > > > > > > > > people using the nightly won't be able to access the last > > minute > > > > > > > > branch changes until that is done. > > > > > > > > > > > > > > > > At this point, the 1.1.2 JIRA changes have already been made > > so > > > > I > > > > > > > > guess we leave them alone and not add a nightly label until > > we > > > > make > > > > > > > > the branch. I suggest we branch soon but not until we all > > agree > > > > that > > > > > > > > its time for a new release. > > > > > > > > > > > > > > > > sean > > > > > > > > > > > > > > > > On 11/21/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > > > > > > > > I've done a quick and dirty pass through the open issues, > > and > > > > made the > > > > > > > > > following changes: > > > > > > > > > > > > > > > > > > * Renamed 'Nightly' to '1.1.2' > > > > > > > > > * Added a few seemingly very important issues to 1.1.2 > > > > > > > > > * Left any open issues already marked for 1.1.2/nightly > > as-is, > > > > > > > > > regardless of my opinion of them (in theory they should be > > > > removed > > > > > > > > > because non api/impl issues shouldn't hold up a release, > > > > right?) > > > > > > > > > * Created a new 1.1.3 version > > > > > > > > > * Added remaining issues that looked reasonably important > > to > > > > 1.1.3. > > > > > > > > > > > > > > > > > > I think the next step is for the community to take a look > > and: > > > > > > > > > * Nominate any issues that should be added to 1.1.2 or > > 1.1.3 > > > > > > > > > * Nominate any issues that should be removed from 1.1.2 or > > > > 1.1.3 > > > > > > > > > > > > > > > > > > Then I think we should vote on the 1.1.2 list, and if/when > > > > approved, > > > > > > > > > move forward with fixing the remaining issues and > > preparing > > > > for a > > > > > > > > > release. > > > > > > > > > > > > > > > > > > Thoughts? Suggestions? > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > > > > > > > > > > Sent: Monday, November 21, 2005 2:26 AM > > > > > > > > > > To: MyFaces Development > > > > > > > > > > Subject: Re: Plan for 1.1.2? > > > > > > > > > > > > > > > > > > > > Howard, > > > > > > > > > > You are now member of "myfaces-developers" group on > > Jira. > > > > Can you > > > > > > > > > > please check if this gives you enough rights? > > > > > > > > > > Thanks, > > > > > > > > > > Manfred > > > > > > > > > > > > > > > > > > > > 2005/11/21, Abrams, Howard A <[EMAIL PROTECTED]>: > > > > > > > > > > > If you're certain that issues on the custom/extended > > > > components have > > > > > > > > > no > > > > > > > > > > > chance of holding up a release (other than taking > > > > resources away > > > > > > > > > from > > > > > > > > > > > fixing issue in the api/impl), then you're right, > > there > > > > isn't a > > > > > > > > > need. > > > > > > > > > > > However, I think that without a clear plan the issue > > is > > > > confused. > > > > > > > > > > > > > > > > > > > > > > I think we can use the 'road map' feature of JIRA to > > pick > > > > issues for > > > > > > > > > > > each upcoming minor release. I'll volunteer to take a > > stab > > > > at > > > > > > > > > creating a > > > > > > > > > > > 'road map' for 1.1.2, (if someone can give me any > > access > > > > required). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Manfred Geiler > > [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > Sent: Monday, November 21, 2005 1:05 AM > > > > > > > > > > > > To: MyFaces Development > > > > > > > > > > > > Subject: Re: Plan for 1.1.2? > > > > > > > > > > > > > > > > > > > > > > > > Well, there is nothing to argue against quicker > > release > > > > cycles. > > > > > > > > > EXCEPT > > > > > > > > > > > > the fact that a new release (not a build!) does not > > > > emerge alone, > > > > > > > > > ie. > > > > > > > > > > > > cannot be fully automated. There are things like > > release > > > > candidate > > > > > > > > > > > > voting, testing (!), release notes, homepage > > updates, > > > > > > > > > announcements. > > > > > > > > > > > > Which takes time. > > > > > > > > > > > > Sean and Bill have spent much much time in releasing > > so > > > > far > > > > > > > > > (thanks!) > > > > > > > > > > > > and many have helped to make it as easy as possible. > > But > > > > of > > > > > > > > > course: > > > > > > > > > > > > Any additional help is welcome! > > > > > > > > > > > > The more volunteer helpers and testers we have, the > > > > faster we can > > > > > > > > > have > > > > > > > > > > > > our cycles. > > > > > > > > > > > > > > > > > > > > > > > > As Howard did mention, a release plan would be good. > > Any > > > > volunteer > > > > > > > > > who > > > > > > > > > > > > is willing to look over the open Jira issues and > > > > classify them? > > > > > > > > > > > > Any thoughts about future milestones? > > > > > > > > > > > > > > > > > > > > > > > > -0.5 from my side for releasing the API/impl > > separately: > > > > > > > > > > > > There is no need IMHO. API/Impl are the most > > important > > > > parts. So, > > > > > > > > > if > > > > > > > > > > > > there really is a showstopper, this alone would > > > > legitimate a new > > > > > > > > > > > > release. Regardless of small bugs in one of the > > addons > > > > or sub > > > > > > > > > > > > projects. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Manfred > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2005/11/20, Travis Reeder <[EMAIL PROTECTED]>: > > > > > > > > > > > > > +1 for the quicker release cycle. > > > > > > > > > > > > > > > > > > > > > > > > > > Travis > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/05, James Mitchell > > <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > Not sure about the release plan, but +1 for a > > > > quicker release > > > > > > > > > > > cycle. > > > > > > > > > > > > > > Let's not get caught up in the same slow cycle > > that > > > > has > > > > > > > > > affected > > > > > > > > > > > > > > Struts for so long. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > James Mitchell > > > > > > > > > > > > > > 678.910.8017 > > > > > > > > > > > > > > Skpe: jmitchtx > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Nov 19, 2005, at 11:19 PM, Abrams, Howard A > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there a release plan for 1.1.2? It seems > > there > > > > are a > > > > > > > > > > > significant > > > > > > > > > > > > > > > number of issues on the trunk; some of which > > may > > > > not be > > > > > > > > > marked > > > > > > > > > > > as > > > > > > > > > > > > > > > such in JIRA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, now that we've gotten passed the TCK, > > moved > > > > to SVN, > > > > > > > > > and > > > > > > > > > > > > > > > broken out the various sub projects, I'd like > > to > > > > revisit the > > > > > > > > > > > > > > > subject of releasing the API/impl separately > > from > > > > the > > > > > > > > > > > components. > > > > > > > > > > > > > > > There are many of us who do not use any of the > > sub > > > > projects, > > > > > > > > > so > > > > > > > > > > > it > > > > > > > > > > > > > > > seems silly to hold back a release of the impl > > due > > > > to a bug > > > > > > > > > in > > > > > > > > > > > some > > > > > > > > > > > > > > > random fancy component. Any +1's out there? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > h. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > > > > > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
