My suggestion would be that if there's something we want or plan to do, then we should enter an enhancement for it and then assign the ticket to ourselves.
If we want to map out our longer term plans, then we should add some future versions to Bugzilla so that we can tag the tickets there. Today, we probably need 1.2, 1.3, and 2.x. (Don't have the karma for this myself).
The roadmap for planned releases can then be reduced to a Bugzilla link. If there's something on our plate that we decide to postpone, then we can just update Bugzilla and skip the pain of updating a static document.
The roadmap we have now simply lists "features under discussion", which people on the user list are now calling "promises". Putting a bald statement on a roadmap page seems to breed false expectations. Perhaps we should open a ticket for each of these and summarize the list discussions there to give people a better idea of where some of these (very hypotethical) features stand.
-Ted.
Byrne, Steven wrote:
These kinds of things should definitely be in the roadmap document, both
as a declarative statement of agreement amongst the developers, as well
as an expectation setting mechanism for the rest of the struts
community.
-----Original Message-----
From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 12:11 PM
To: [EMAIL PROTECTED]
Subject: Re: exit strategy was Plans for the upcoming 2/14 soft deadline
I knew the "requirements list" phrasing would irritate you ;-). I just meant that we need to know what we're shooting for in 1.2. If we call it a "roadmap", that's fine with me.
I am overwhelmed by trying to figure out bugs on all the new features that I don't even use myself and then worrying that I've inadvertantly broken something. Less major changes/additions per release would be good.
Dave
From: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: exit strategy was Plans for the upcoming 2/14 soft deadline
Date: Tue, 04 Feb 2003 15:03:06 -0500
Sure. Put in a ticket and link it the post-mortem list.
I'm thinking for 1.2 we can start by moving whatever we wantto work onfrom LATER to active again, doing the deed, and marked themresolved again.I would not be in favor of anything that even smells like a "requirementsbetas, and then
list".
As soon as we have something worth releasing, we should start the release
cycle. Personally, post 1.1, I'd like to consider monthly
promoting a beta to a release candidate whenever one seemssolid enough.If we had been doing that last year, we could have gotten some very handywe got started
taglib changes into production a year ago Christmas, before
on the module/validator/tiles cycles. (And each of thoseshould also have
been a release unto itself.)
We simply don't have the resources to pick a feature set inadvance. Weneed to go with what we got as soon as we got it. Anything less is a disservice to our community.coordinate everything
We also need to start decoupling the components of the current
distribution. Again, we don't have the resources to
with everything else. We need to be able to changesomething, confirm that
it works with the legacy production code, and get it outthere where people
can use it.that's a just a
If, for example, Tiles is unstable become of some new work, we can't let
that hold up a release of Struts EL, or whatever else. There will be questions of which release of what works with what, but
documentation issue. As it stands, we have to face the factthat we have
of sendingserious production issues, which, like security, trumps. -Ted. David Graham wrote:Ted,
I agree with you but want to add the item Craig and I discussed earlier
regarding the standard actions throwing exceptions instead
and the *many*error codes to the user.
We need a small requirements list for 1.2 and ship it when we've completed
those items. I don't want to relive the lengthy 1.1 cycle
nested taglib.new features (and bugs) introduced. DavidFrom: Ted Husted <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: exit strategy was Plans for the upcoming 2/14 soft deadline
Date: Tue, 04 Feb 2003 13:34:34 -0500
I made a pass on Bugzilla, and we seem to be down to three tickets.
http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html
Two seem module related and the third relates to the
our remainingAll
three indicate incorrect behavior. I'd call these three
we alreadyshowstoppers, unless another committer says otherwise.
For 1.2, I'd like to concentrate on applying the patches
migration, fix anyhave
waiting in the LATER bin, do the Commons Resource
least bit newearly 1.1 bug reports, and call it a release. Anything the
the momentum upor controversial could be tagged for 1.3/2.x. Gotta get
very soon, as=:0) -T. Vic Cekvenich wrote:If I can say ....
Please consider releasing nightly build (w/o EL) very,
incubator,a
RC1;
+ plus a note of the know bugs.
(I know it's not ideal, but it's an *exit* strategy).
As soon as the bugs are fixed, release.
Of course if something *new* shows up in RC1, then have RC2.
At this point I would rather have 1.1a if something new shows up; other Jakarta projects have.
Note: I plant to try to take basicPortal.com to Jakarta
people canvery soon, coments welcome.
And if anyone wants to contribute to an online class (people only pay "WebEx" charges), coming up very soon.
vc at basebeans.com
Then my 1.2 wishlist (Craig?)
- HTML-el
- ship with JSTL (Maven?)
- deprecate templates
- deprecate (means will be gone after 2.0) beans tag (so
for rest. (So oneuse
core
tag)
- split struts jar in 2. One for tags(and nested), one
people canday
Struts could move most it's tags to jakarta.taglibs. Thus
default disptach)render
anyway they want, ex: Faces tag)
- include simple version of Scafolding BaseAction (w/
people in aand
BaseFormBean (w/ beantuils to copy multirow) - This hints
strutstags.jar), it isgood
direction.
- better tiles and login example (Container based security)
- filters? listeners?
- please include struts-menu by S. Skyles (in
popular
as any tag and singe point for navigations.
- faces "extension"
- multi row example app in contrib ?
- master/detail example app in contrib ?
- Servlet 2.3
(be glad to do half of any of above)
Past 2.0 wish list:
- Axis controller
- Commons-SQL or Castor (or RowSet) example app w/Struts.
- DAO interface/factory (in Commons?)
- Deprecate most tags (let people use taglibs for render,or Velocity, or
faces....) but support JSP 2.0 in this release (HTML-EL,Faces, Tiles,create an XML fileValidator only; no logic, etc. support)
- XML "generator". Have you used JasperReports? "He"
(with bands?)that
"compiles" to something else. So if we create a XML file
that
"compiles" to JSP and struts.config, ,etc.? Then otherscan write XMLgenerators for any output. Of course, base extensionclasses behind.for cutting- JDK1.4 required
- Servlet 2.4
- There were a lot of 2.0 ideas.... I can't recall them.
It is more exciting past 1.1.
.V
"Ted Husted" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
I would agree with Craig that dates are good motivators
shows up inbetas, but to cut a Release Candidate, logically, we need to be release-ready. The objective release-ready test is what
page. WhenBugzilla. So, someone has to either fix or defer (in good conscious) any outstanding tickets.
As for the Release Plan, we can continue to amend the B3
it under awe're ready for R1, make the final revisions and re-post
freeze datenew name. Since everything should be done by then, the
can be set for +(72 hours), to coincide with the closeof the vote.for 1.1. IfAt this point, I just don't have any more blood to shed
we can't get this thing out the door in February, then we should look for some more comitters who can.
Either way, come March, I say it's time to get a fresh, test-first-design start on 2.x. A year of FUD is morethan enough.-Ted. Martin Cooper wrote:Ted had suggested that we resolve the outstanding itemsfirst, andthen put together a release plan, complete with tag date. See:http://archives.apache.org/eyebrowse/ReadMsg?listName=struts-dev@jakarta.apa che.org&msgId=612913However, I don't believe that's working. In fact, as Ibelieve Tedhimselfsaid of the 1.1-b3 drive, having a date to aim for is a bettermotivator.Unfortunately, as I mentioned before, I don't have much time to help
killoutstanding bug reports for RC1, due to current "day job" pressures.
It'dbe great to see an RC1 on or around Feb 14th, and I cando the RMus ready forthing,
but I'm going to have to rely on others of you to get
was of any votethat.Also, what is the status of the idea of separating the contrib
libraries
out of the release? I'm not certain what the result
on
this, but I had the impression there wasn't enoughresponse to make adecision.
IMO, Struts-EL should stay put until we get Struts 1.1 out the door.
Afterthat, we can discuss how to incorporate contrib code into the release
as
part of a broader discussion of how to factor distributions.
--
Martin Cooper
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html>---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:[EMAIL PROTECTED]-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> ---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
---------------------------------------------------------------------
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]
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
