All valid, I don't have a master plan on this, and I may just be using JIRA incorrectly.
On Jan 3, 2008 7:14 AM, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > I've been bitten by the release not generator as well and decided to > not generate release notes anymore until ~after~ I had marked the > particular version in question as released. (and subsequently used > the move all open issues to fix version <next> during the process) > > On T4 we've been using a process of trying to keep two future versions > in jira - one for the current phase of development and one for bugs > that we want to fix but "won't be looking at anytime soon". This > second version is helpful for quickly deciding which general bucket > things go in to and also helps keep the list of current version bugs > smaller for me to browse through when deciding what to fix. > > No one has freaked out and complained when I moved their bugs marked > for fix in current release to next release when they didn't make it > in, but maybe they'll hold Howard's feet to the fire more because of > his role in the project. > > Either way - he who does the work decides how the work gets done - so > I support whatever he wants to do from that pov. ;) > > > On Jan 3, 2008 9:38 AM, Kevin Menard <[EMAIL PROTECTED]> wrote: > > Clearly your the project lead, so up to you. In my experience, I've found > > it helpful. I typically have two or three versions open and scope out the > > work. If you want to focus on Ajax for 5.0.8, you can group all those > > issues there and 5.0.9 can be validation clean-ups or what have you. IMHO, > > it's nicer than just having a huge bucket of open issues that you cherry > > pick from. It also makes it nicer for your consumers to see what the plan > > is (it might help with all the "when is 5.0 final coming out?"). > > > > -- > > Kevin > > > > > > On 1/2/08 3:56 PM, in article > > [EMAIL PROTECTED], "Howard Lewis > > > > Ship" <[EMAIL PROTECTED]> wrote: > > > > > The roadmap is a good idea, but I have a problem with JIRA's release > > > note generator, since it generates a line for every bug with the > > > release number, whether its been fixed, resolved, marked duplicate, or > > > is still open. > > > > > > Roadmap is nice, but it really is about "geez, time for a release, > > > what can we fit in?" :-) > > > > > > On Jan 2, 2008 12:10 PM, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > >> That's what I thought it was supposed to be used for.. > > >> > > >> > > >> On Jan 2, 2008 3:08 PM, Kevin Menard <[EMAIL PROTECTED]> wrote: > > >>> Is there any particular reason for that? It seems to me that if you > > >>> defined > > >>> a fix version you could start using JIRA's roadmap feature. If the item > > >>> isn't resolved by the time you want to cut the release, JIRA has an easy > > >>> means of migrating all remaining issues to another fix version. > > >>> > > >>> -- > > >>> Kevin > > >>> > > >>> > > >>> On 1/2/08 2:55 PM, in article [EMAIL PROTECTED], > > >>> "Howard M. Lewis Ship (JIRA)" <[email protected]> wrote: > > >>> > > >>>> > > >>>> [ > > >>>> https://issues.apache.org/jira/browse/TAPESTRY-1643?page=com.atlassian.jira > > >>>> .pl > > >>>> ugin.system.issuetabpanels:all-tabpanel ] > > >>>> > > >>>> Howard M. Lewis Ship updated TAPESTRY-1643: > > >>>> ------------------------------------------- > > >>>> > > >>>> Fix Version/s: (was: 5.0.8) > > >>>> > > >>>> We don't define a fix version until a fix is committed. > > >>>> > > >>>>> @Mixin should accept parameters > > >>>>> ------------------------------- > > >>>>> > > >>>>> Key: TAPESTRY-1643 > > >>>>> URL: > > >>>>> https://issues.apache.org/jira/browse/TAPESTRY-1643 > > >>>>> Project: Tapestry > > >>>>> Issue Type: Bug > > >>>>> Components: tapestry-core > > >>>>> Affects Versions: 5.0.5 > > >>>>> Reporter: Dan Adams > > >>>>> > > >>>>> With @Mixin there is no way to use a mixin that requires parameters > > >>>>> within > > >>>>> a > > >>>>> component. For instance if you have a Confirm mixin that has a > > >>>>> required > > >>>>> parameter you can't use it like this: > > >>>>> @Mixin > > >>>>> private Confirm confirm; > > >>> > > >>> > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>> For additional commands, e-mail: [EMAIL PROTECTED] > > >>> > > >>> > > >> > > >> > > >> > > >> -- > > >> Jesse Kuhnert > > >> Tapestry / OGNL / Dojo team member/developer > > >> > > >> Open source based consulting work centered around > > >> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > Jesse Kuhnert > Tapestry / OGNL / Dojo team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
