Berin Loritsch wrote:
1. Infrastructure ----------------- - refactor CVS (or move to svn! Apache Commons is getting svn!)Really? Then we might want to upgrade for Avalon!
looks like it. Greg asked the infrastructure peeps to prepare for it.
I'm actually not sure what the term means....I ment the stuff @ http://jakarta.apache.org/site/guidelines.html- write avalon project docs (ie something like the jakarta 'bylaws' but shorter and referring to "default" where possible)
+1 -- But not quite like 'bylaws'. Apache has a set of Bylaws which all projects have to abide by. It is more the guidelines to which we adhere (fitting within the bylaws).
that too. Also the 'mentoring' of new committers. For example, Peter (the Donald variant) proposed me as a committer and after that looked after me (cleaned up code I messed up, answered spoken and unspoken questions...). Like a new project has a sponsoring ASF member, a new committer can benefit from a sponsoring committer. When you think about how a committer becomes part of the group....it's a good idea to describe such an informal process. It makes a community transparent.- committer 'internship'+1 Are you referring to the de facto standard of 6 months involvement in most projects before comit rights are granted?
Anyway, I'll know precisely what I mean when I get to write the docs on it :D
(for the people wondering or with an itch, there's conversion to forrest left and then more doccing, like updating for new containers 'n stuff, also Berin never got to his "part 2" of talking more about cornerstone and phoenix; Peter explained to me some time ago how to go about the forrest conversion and I responded mostly with shamefully not handling it after I got angry at the tools not working)4. Work on existing code ------------------------ - do needed maintainance on "Developing with Avalon"+10
Merlin 2.0 (which becomes the new "Fortress") - Merge the best parts of Fortress into Merlin - Provide migration tools and compatibility. - Provide docs
I'll add:
- clean up merlin to a stage where it looks more like phoenix (ie
interface/impl seperation, client+bootstrap+impl jar....),
perhaps throwing in some of the existing phoenix interfaces
I don't want to discount them at all! I'm just saying that I myself have no interest in this area (for now). With "big compromise" I mean stuff like giving up xml for config. I love XML. Hope that clarifies :DI for one don't believe J2ME wants or needs avalon, and I don't feel like making big compromises for it.
Our primary goal is making development easier. Simplifying. There are folks who would like to use J2ME, they are new to our fold and seem genuinely interested. I don't think we should discount them so quickly. We can (as I demonstrated) make interfaces that are J2ME friendly and do not block providing a compatibility layer for A4 components.
Hey Berin, what are you using avalon for atm, and what will you likely be using it for in the future? Are you able to talk about that?
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
