On Sun, 2013-04-07 at 17:54, Peter wrote: > Greg, why have you repeated this message? >
First time I sent it was from the wrong email address, so it got hung up in moderation. I sent it again from my subscribed address. I'm guessing someone just moderated the original through. Anyway, let's address one or two of your points... I see you writing inflammatory statements about my leadership skills and I think you're upset because you think I was questioning the quality of your work. I understand. You've put a lot of effort into the codebase. I feel sorry that you feel that way - it wasn't what I intended. Apache doesn't recognize any kind of a "project leader" position, and I don't pretend to hold any such influence over River. I'm speaking as a committer and PMC member. I certainly don't think I "hold the future of the project in my hands". If anyone does hold individual control over the future of the project, then it doesn't qualify as an Apache project, and we need to remedy that. Really, what I'm trying to do is answer this question for myself - "Can I vote +1 on a release based on the trunk?". There have been a lot of changes to the trunk code. Yes, many that I don't understand. I've done more management than you thnk. I don't require that I understand everything. That leads me to ask "How can I be confident about a release?" The best answer I have is to ask "does it pass the regression tests?". But that implies another question - "Do I trust the tests?" And the answer to that is "currently, no, because from what I can see there have also been changes to the tests". I'm honestly and truly not passing judgement on the quality of the code. I honestly don't know if it's good or bad. I have to confess that, given that Jini was written as a top-level project at Sun, sponsored by Bill Joy, when Sun was at the top of its game, and the Jini project team was a "who's-who" of distributed computing pioneers, the idea that it's riddled with concurrency bugs surprises me. But mainly, I'm still trying to answer that question - "How do I know if it's good?" Here's what I'm doing: - I'm attempting to run the tests from "tags/2.2.0" against the "2.2" branch. When I have confidence in the "2.2" branch, I'll publish the results, ask anyone else who's interested to test it, and then call for a release on "2.2.1" - After that, the developers need to reach consensus about how to move forward. Cheers, Greg. > I think this is a deliberate attack on the project because you haven't > been following development in trunk and now you're scared because you > see changes you don't understand. > > I've been following your developments in surrogates, an impressive > amount of productivity. Although I think you should consider > upgrading apache.commons vfs to version 2 before releasing. > > Open your mind and ask questions, the code isn't set in stone, you > have an obligation as project lead to encourage and nurture > development, not stifle it. > > You strike me as someone who's a very good programmer, but still > learning leadership because you lack faith in others and must do > everything yourself. Remember I offered to assist with Surrogates, > but you wanted to work alone? > > You need to let go and give others a go too. > > How you handle this matter will be a test for your own personal > development and an opportunity to grow as a leader. > > You also hold the future of this project in your hands, so I hope you > find strength to let go. > > Regards, > > Peter. > > ----- Original message ----- > > > > OK, so in my last message I talked about how (speaking only for > myself) I'm a > > little nervous about the state of the trunk. > > > > So what now? > > > > Problems we need to avoid in this discussion: > > ------------------------------------------------------------- > > > > - Conflation of source tree structure issues with build tool > selection. > > - Conflation of Maven build, Maven as codebase provider (artifact > urls), and > > posting artifacts to Maven Central - Wish lists of pet features > > - Bruised egos and personal criticisms. > > > > Issues I see, in no particular order: > > ---------------------------------------------- > > - We've done changes both to the test framework and the code, and > lots of them. > > We should do one or the other, or small amounts of coevolution, if > absolutely > > necessary. - Really, I'd like to see a completely separate > integration test, and > > have the TCK tests separated out again. - The source tree is > incomprehensible - > > The tests appear to be awfully sensitive to their environment. > Insofar as when > > I run them locally on an untouched source tree, I get 280 failures. > - There have > > been changes to class loading and security subsystems. These > subsystems are > > core to Jini, and the changes were made to the existing source, so > there's no > > way to "opt-out" of the changes. I'd like to see radical changes be > optional > > until proven in the field, where possible. In the case of policy > providers and > > class loaders, that should be easy to do. - Similarly, it seems > there have been > > some changes to the JERI framework. - There are ".jar" files in our > repository. > > I'll stipulate that the licensing has been checked, but it smells > bad. > > > > Discussion > > ----------------- > > I guess the biggest thing I'd like to see is stability in the test > framework. > > Perhaps it needs refactoring or reorganization, but if so, we need > to be very > > careful to separate it from changes to the core functionality. > > > > Next, I'd like for it to be easier to comprehend the source tree. I > think a > > good way to do that is to separate out (carefully) the core Jini > package > > (basically the contents of jsk-platform.jar) and the service > implementations. > > There's no reason that we have to have one huge > everything-but-the-kitchen-sink > > distribution. That's just a holdover from how Sun structured the > JTSK - It was > > literally a "starter kit". To me it would be fine to have separate > deliverables > > for the platform and the services. > > > > While we're separating out the services, it might also be a decent > time to > > implement Maven-based builds if we think that's a good idea. I'd > start with > > Reggie. It would also be a good time to get rid of the > "com.sun.jini" packages. > > > > Aside: I'm personally ambivalent on Maven (which is to say I'm > nowhere near as > > negative on it as I once was). I do agree with Dennis, though, that > the jars > > and appropriate poms need to be published to Maven Central. There's > no doubt > > that users will appreciate that. > > > > Once we have a stable set of regression tests, then OK, we could > think about > > improving performance or using Maven repositories as the codebase > server. > > > > I realize this won't be popular, but my gut feel is that we need to > step back to > > the 2.2 branch and retrace our steps a little, and go through the > evolution > > again in a more measured fashion. > > > > Proposal > > ------------ > > > > 1 - Release version 2.2.1 from the 2.2 branch. > > 2 - Create a separate source tree for the test framework. This > could come from > > the "qa_refactor" branch, but the goal should be to successfully > test the 2.2.1 > > release. Plus it should be a no-brainer to pull it down and run it > on a local > > machine. 3 - Release 2.2.2 from the pruned jtsk tree. Release 1.0.0 > of the test > > framework. 4 - Pull out the infrastructure service implementations > (Reggie, > > Outrigger, Norm, etc) from the core into separate products. Release > 1.0.0 on > > each of them. Release 2.2.3 from the pruned jtsk tree. 5 - Adopt a > fixed > > release cycle. Not sure if it should be quarterly or biennial, or > whether it > > should be all products at once or staggered releases. We'll need to > discuss. 6 > > - Then we can start making changes if necessary to the individual > products. And > > also try to deal with making it easier for new users to use the > technology. > > > > So there you go. Opinions? > > > > Greg Trasuk. > > >
