I was not involved in the prior Junit discussions. Can someone tell me what the planned method of dealing with layered Java packages is going to be? Would it be acceptable to install into /usr/findbugs-1.3.6 with a symbolic link from /usr/bin/findbugs to /usr/findbugs-1.3.6/bin/findbugs?
As to the API, looking at the findbugs site, it appears to be an incidental thing. It is not mentioned in the manual on the website. I suspect that it exists primarily as a method of creating plugins for various IDE's. Since the jar file will be delivered, so too will the API be available. But since it does not have any documentation provided in the standard installation package, neither would we deliver such. Of course, having a version number on the directory makes everything but the command line essentially uncommitted interfaces, since they will not be changing in place but might not be included in the future. Is that the expected situation with the proposed versioning, assuming that what I outlined is the proposed plan? The timer was extended until Friday on this case to match the timer for the Junit case, but if we don't get direction as to what the Junit case will document, obviously we will not be able to provide an updated spec by then. I think the project team is amenable to any reasonable plan, but they do need to know what the plan should be. Tom Childers wrote: > Brian, > > We discussed this case, and the junit case, in our OpenARC meeting this > morning. We are extending the timer on this fast-track to Friday: > > 1. we will be writing an opinion for the junit case, 2008/633, and the > content will impact the location of your deliverables. We are talking > about putting all java tools into /usr/share/lib/java, but the > discussion is not finished. > > 2. we are curious about the programmatic interface for findbugs, and if > that is available in this project. If so, it needs to be an exported > interface; if not, other ARC members would like to know why it's not > available. > > I'm sure more email is forthcoming :-) > Thanks, > -tdc > > > On Oct 27, 2008, at 11:50 AM, Brian Utterback wrote: > >> I disagree. The incremental advantage of using a slightly later >> version than the one installed is unlikely to persuade developers to >> download a later one. Looking the changelog for findbugs, the features >> are evolutionary, not revolutionary from one rev to the next. >> >> Lloyd Chambers wrote: >>> Petr, >>> From my viewpoint as a developer, I'm prepared to download the >>> current version, which I want preferentially because it will have the >>> latest goodies. I'm not all that interested in having a >>> pre-installed versions, because I can just as well keep my own >>> version of choice around. So from my point of view, I just don't see >>> the value. >>> In short, who is the "customer"? Developers probably won't care. In >>> fact, if the version is aggressively moved forward, it may be a >>> nuisance more than anything else (eg paths). >>> Which leads me to another "customer": QA. These folks might want a >>> specific version. So unless we can support more than one version, QA >>> is probably going to keep their own copies around. >>> So who is the customer here? And why would they care? >>> Lloyd >>> ............................................. >>> Lloyd Chambers >>> lloyd.chambers at sun.com >>> GlassFish team, LSARC member >>> On Oct 21, 2008, at 2:13 PM, Petr Slechta wrote: >>>> Tom Childers wrote: >>>>> On Oct 21, 2008, at 11:54 AM, Dean Roehrich wrote: >>>>>> On Tue, Oct 21, 2008 at 10:57:54AM -0700, Tom Childers wrote: >>>>>>> Petr, >>>>>>> >>>>>>> I have several questions about this project. Since this is an open >>>>>>> case, I'm changing the cc: to lsarc-ext at sun.com. >>>>>>> >>>>>>> I am wondering what requirement we are trying to fill with this >>>>>>> project. FindBugs is downloadable, gets updated frequently, and >>>>>>> is not >>>>>>> prepackaged on any other platform I know of. The version you are >>>>>>> shipping is already out of date; the 1.3.6 release became >>>>>>> available a >>>>>>> few days ago. >>>>>> >>>>>> If frequency of release of the upstream project is a component of >>>>>> the ARC's >>>>>> decision to accept or reject said project, then those guidelines >>>>>> should be >>>>>> recorded somewhere. We have seen other FOSS cases which admit to >>>>>> porting the >>>>>> version which was current at the time of the OSR but are out of >>>>>> date by the >>>>>> time the ARC cases are submitted. >>>>> >>>>> Obviously, this is not a part of ARC guidelines. But the question >>>>> remains, how will the project team keep up the frequent release >>>>> schedule? And support multiple versions, since there seems to be >>>>> some dependency between test cases and junit releases? I agree that >>>>> we have absolutely seen other ARC cases where this becomes a major >>>>> issue; if we are going to create this dependency, how will we >>>>> address the issue? >>>>> -tdc >>>> >>>> We do not plan to support multiple versions. We may change it if it >>>> is a requirement. >>>> So is it usual that developer needs to have more versions of >>>> findbugs installed? >>>> Can you describe the dependency between test cases and junit releases? >>>> >>>> Thanks! >>>> >>>> Petr >> >> -- >> blu >> >> "Murderous organizations have increased in size and scope; they are >> more daring, they are served by the most terrible weapons offered by >> modern science, and the world is nowadays threatened by new forces >> which, if recklessly unchained, may some day wreck universal >> destruction." - Arthur Griffith, 1898 >> ---------------------------------------------------------------------- >> Brian Utterback - Solaris RPE, Sun Microsystems, Inc. >> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreck universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
