Re: exit strategy was Plans for the upcoming 2/14 soft deadline

Tue, 04 Feb 2003 14:49:10 -0800

I think tracking the roadmap in bugzilla is a great idea. Can we get future versions listed in there? Our 1.2 roadmap page can be a link to the bugzilla query for all 1.2 enhancements. On the other hand, anyone can post an enhancement for any version so this might not be representative of our plans.

David



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 17:20:05 -0500

Since we all volunteers, we can only make agreements regarding what we might ourselves do.

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 want

to work on

from LATER to active again, doing the deed, and marked them

resolved again.
I would not be in favor of anything that even smells like a "requirements
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
betas, and then


promoting a beta to a release candidate whenever one seems

solid enough.
If we had been doing that last year, we could have gotten some very handy
taglib changes into production a year ago Christmas, before
we got started


on the module/validator/tiles cycles. (And each of those

should also have


been a release unto itself.)

We simply don't have the resources to pick a feature set in

advance. We
need to go with what we got as soon as we got it. Anything less is a disservice to our community.

We also need to start decoupling the components of the current
distribution. Again, we don't have the resources to
coordinate everything


with everything else. We need to be able to change

something, confirm that


it works with the legacy production code, and get it out

there where people
can use it.

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
that's a just a


documentation issue. As it stands, we have to face the fact

that we have


serious 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



of sending




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




and the *many*




new features (and bugs) introduced.

David







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 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




nested taglib.




All
three indicate incorrect behavior. I'd call these three





our remaining




showstoppers, unless another committer says otherwise.

For 1.2, I'd like to concentrate on applying the patches





we already




have
waiting in the LATER bin, do the Commons Resource





migration, fix any




early 1.1 bug reports, and call it a release. Anything the





least bit new




or controversial could be tagged for 1.3/2.x. Gotta get





the momentum up




=:0)

-T.

Vic Cekvenich wrote:





If I can say ....
Please consider releasing nightly build (w/o EL) very,





very soon, as




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




incubator,




very 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




people can




use
core
tag)
- split struts jar in 2. One for tags(and nested), one





for rest. (So one




day
Struts could move most it's tags to jakarta.taglibs. Thus





people can




render
anyway they want, ex: Faces tag)
- include simple version of Scafolding BaseAction (w/





default disptach)




and
BaseFormBean (w/ beantuils to copy multirow) - This hints





people in a




good
direction.
- better tiles and login example (Container based security)
- filters? listeners?
- please include struts-menu by S. Skyles (in





strutstags.jar), it is




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,




Validator only; no logic, etc. support)
- XML "generator". Have you used JasperReports? "He"





create an XML file




that
"compiles" to something else. So if we create a XML file





(with bands?)




that
"compiles" to JSP and struts.config, ,etc.? Then others





can write XML




generators for any output. Of course, base extension





classes behind.




- 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





for cutting




betas, but to cut a Release Candidate, logically, we need to be 
release-ready. The objective release-ready test is what




shows up in




Bugzilla. 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




page. When




we're ready for R1, make the final revisions and re-post





it under a




new name. Since everything should be done by then, the





freeze date




can be set for +(72 hours), to coincide with the close





of the vote.




At this point, I just don't have any more blood to shed





for 1.1. If




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 more




than enough.




-Ted.

Martin Cooper wrote:





Ted had suggested that we resolve the outstanding items





first, and




then
put together a release plan, complete with tag date. See:







http://archives.apache.org/eyebrowse/ReadMsg?listName=stru





ts-dev@jak




arta.apa

che.org&msgId=612913





However, I don't believe that's working. In fact, as I





believe Ted






himself





said of the 1.1-b3 drive, having a date to aim for is a better







motivator.





Unfortunately, as I mentioned before, I don't have much time to 
help






kill





outstanding bug reports for RC1, due to current "day job" 
pressures.






It'd





be great to see an RC1 on or around Feb 14th, and I can





do the RM




thing,
but I'm going to have to rely on others of you to get





us ready for




that.







Also, what is the status of the idea of separating the contrib
libraries
out of the release?  I'm not certain what the result





was of any vote




on
this, but I had the impression there wasn't enough





response to make a




decision.








IMO, Struts-EL should stay put until we get Struts 1.1 out the 
door.






After





that, 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]






_________________________________________________________________

Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963





---------------------------------------------------------------------

To unsubscribe, e-mail: [EMAIL PROTECTED]

For additional commands, e-mail: [EMAIL PROTECTED]
























					Reply via email to