Hi, I have cleaned up the branch and the corresponding parts in the trunk to fix for missing header files. Here is an updated RAT report.
http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Nash wrote: > Comments inline. > > Simon > > ant elder wrote: > >> On 6/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: >> >> <snip> >> >> as long as something works, I'm not sure why we would exclude it from a >> >>> Tuscany release. >> >> >> >> I think we need a bit more clarity about what it means to include >> something >> in the release. Is it just having the code included in the src >> distro, or >> included in the src distro as part of the build, or also included in the >> binary distro, or included in both distro's along with itests, samples, >> readme's or web site doc, and mention of the new thing in the release >> notes? >> > My take is that included in the release means included in both distros > along with itests, samples, readmes or web site doc, and mention of the > new thing in the release notes. > +1 from me. I'm expecting the itest suite to grow over time as not all extensions are covered yet. I just added a sample for the implementation-resource extension, and am still working on a sample for the implementation-spring extension. >> >>> From the 0.90 release things were pulled out for not being quite >>> there, a >> >> lot of the time spent before the final release artifacts got done was >> because people reviewing the distro's wanted all things up to a certain >> standard. Getting all this done can take a lot of work. Last minute >> changes >> often cause unexpected blocking problems in the distributions >> resulting in >> respins and more delay. >> >> If we just include everything "that works" is someone reviewing a >> release RC >> going to complain that some new sample is missing a readme, that a demo >> should have an Ant build script, or that some new extension doesn't even >> have a sample? If things must be of a certain standard then I don't >> think >> its reasonable to expect the release manager to do all the work to get >> things there. >> > I agree that these things are needed and that the burden of doing them > should not fall on the RM. > +1 that's what I had in mind as well when I said "works", as samples and a readme are the basic requirements for a user to be able to get an extension to work. >> How about: >> - by default everything is kept in the src distro unless there's some >> reason >> not to > > > I'm not sure about this. What is the value of including modules in the > source distro but exluding them from the build? The latest levels of > this code (presumably better) are available in trunk. Since these things > weren't built or tested as part of the release, the snapshot state they > were in on release date has no particular significance. > > I also recall a discussion some time ago (not specific to Tuscany but on > [EMAIL PROTECTED] IIRC) in which it was said that the source distro > is what really defines the content of the release, and the binaries are > included for convenience. For all of these reasons, it seems better for > the source and binary distros to have matching contents unless there's > some reason not to. > Matching source and bin distros make more sense to me as well. >> - only the things mentioned on the release wiki page get included in the >> build, binary distribution, and mentioned in the release notes > > > This seems OK for new function. I'm not sure what process we use for > JIRA fixes. They don't seem to be listed on this page. I would expect > that marking the "Fix version field" accordingly is all that is needed. Not sure that it's realistic. > >> - after the brn is cut we need to ask on the ML before adding new >> things to >> the wiki release page > Agreed. +1 > >> - adding something to the wiki release page implies some commitment >> to help >> get it to the required standard in line with the release schedule. > > > Agreed. +1 > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
