Re: [general] Incubator graduation update
Lets stuff the whole thing in there... robert burrell donkin wrote: On 10/23/06, Matt Benson <[EMAIL PROTECTED]> wrote: --- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: [SNIP] > First, there are minor 'nits' here and there related > to license and > license headers. For example, we're missing the > antlr license in our > NOTICE file. wrt this particular "nit", antlr 2.x.x versions are public domain... text: --- ANTLR 2 License We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed. --- so any form of acknowledgement is probably good enough to satisfy Terence. the public domain has become difficult in recent times. in some jurisdictions (in europe), i believe that an explicit license is required. (yes, i know it's daft.) copyright may also now be primarily criminal matter between the state and the copier. the opinions of the author matter little. so, it's best to include the statement. and a note to the notice file to acknowledge Terence :-) - robert
Re: [general] Incubator graduation update
--- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On 10/23/06, Matt Benson <[EMAIL PROTECTED]> > wrote: > > --- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > [SNIP] > > wrt this particular "nit", antlr 2.x.x versions > are > > public domain...> > the public domain has become difficult in recent > times. in some > jurisdictions (in europe), i believe that an > explicit license is > required. (yes, i know it's daft.) copyright may > also now be primarily > criminal matter between the state and the copier. > the opinions of the > author matter little. so, it's best to include the > statement. > > and a note to the notice file to acknowledge Terence > :-) FWIW, when ANTLR3 is fully baked, these issues will be easier as it's under a sane and relatively easy-to-interpret BSD license as compared to "custom OSS or PD license." :) -Matt > > - robert > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [general] Incubator graduation update
On 10/23/06, Matt Benson <[EMAIL PROTECTED]> wrote: --- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: [SNIP] > First, there are minor 'nits' here and there related > to license and > license headers. For example, we're missing the > antlr license in our > NOTICE file. wrt this particular "nit", antlr 2.x.x versions are public domain... text: --- ANTLR 2 License We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed. --- so any form of acknowledgement is probably good enough to satisfy Terence. the public domain has become difficult in recent times. in some jurisdictions (in europe), i believe that an explicit license is required. (yes, i know it's daft.) copyright may also now be primarily criminal matter between the state and the copier. the opinions of the author matter little. so, it's best to include the statement. and a note to the notice file to acknowledge Terence :-) - robert
Re: [general] Incubator graduation update
--- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: [SNIP] > First, there are minor 'nits' here and there related > to license and > license headers. For example, we're missing the > antlr license in our > NOTICE file. wrt this particular "nit", antlr 2.x.x versions are public domain... text: --- ANTLR 2 License We reserve no legal rights to the ANTLR--it is fully in the public domain. An individual or company may do whatever they wish with source code distributed with ANTLR or the code generated by ANTLR, including the incorporation of ANTLR, or its output, into commerical software. We encourage users to develop software with ANTLR. However, we do ask that credit is given to us for developing ANTLR. By "credit", we mean that if you use ANTLR or incorporate any source code into one of your programs (commercial product, research project, or otherwise) that you acknowledge this fact somewhere in the documentation, research report, etc... If you like ANTLR and have developed a nice tool with the output, please mention that you developed it using ANTLR. In addition, we ask that the headers remain intact in our source code. As long as these guidelines are kept, we expect to continue enhancing this system and expect to make other tools available as they are completed. --- so any form of acknowledgement is probably good enough to satisfy Terence. -Matt __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [OT] [general] Incubator graduation update
On 20 October 2006 at 12:52, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> Mark Hindess wrote:
> > On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> >>
> >> Mark Hindess wrote:
> >>> On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote:
> FWIW: Below are the results of running RAT on a windows snapshot.
> For some reason it complained about lack of ASF block comments in
> DLLs, and proceeded to dump them to the console, so I chopped them out
> of the report. Looks like mainly missing block comments in emconf
> files.
>
> I suspect that it will be helpful to do this on an HDK snapshot, plus
> on a source drop (that we don't produce at present, but should IMO).
> >>> I'm looking at modifying the federation build to have a source drop
> >>> target. It looks like doing:
> >>>
> >>> svn export . target/src
> >>>
> >>> and modifying the build.xml to cope with the lack of svn files might
> >>> be a good start. I'll probably take a little more work but I'll get
> >>> something checked in so we have something to work with.
> >> Wait.
> >
> > I don't think I have much choice. It's more likely you'll be waiting
> > for me. ;-) It's not as trivial as it sounds[0] so I'm sure this
> > discussion will be done before I'm ready to check anything in. ;-(
> >
> >> Why not just do a tar/zip on the working_classlib and working_vm with
> >> a filter to keep out the generated stuff?
> >
> > This was my first thought but it didn't take long before I decided I had
> > to think again. I think it is much too error prone. Consider figuring
> > out which .so files are generated/downloaded and which are in svn.
> > Repeat for dll files, jar files, etc. Then keep this up to date. It'd
> > be a full-time job.
>
> A *real* unix hacker would walk the tree looking at .svn/entry files ;)
> In Perl. in less than 20 lines.
;-) It's Friday night so I'll bite...
It'd be a (longish) one-line on unix, perhaps something like:
find . -name 'entries' -print|while read e; do
sed -e '/ name=\"/!d;s:.*name=\":'${e%.svn/entries}':;s/\".*//' <$e; done
but I'd be trickier under Windows (unless we assume everyone has Perl
which even I know is unrealistic).
But I disagree, a *real* hacker would:
a) look for a tool that is meant for the job,
b) look for a tool that is meant for something entirely different but
which happens to do the job very well, or
c) writes it in sh, awk, sed, or Perl
If I always rushed straight to step c) I'd never be able to make a cup
of tea in the morning. (My house is quite automated so Perl can put
the kettle on but can't yet make the tea.)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Incubator graduation update
>A *real* unix hacker
Two years of release engineering is more than enough:
find . -name .svn -exec grep -H name {}/entries \; | sed -e
's/\.svn\/entries: name="//; s/"$//' | egrep -i
'\.(gif|jar|png|dat|class|tif|jpg|jpeg|ico|dll|so|exe|doc|wav|pdf|zip)$'
:-)
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-Original Message-
>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>Sent: Friday, October 20, 2006 8:52 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [general] Incubator graduation update
>
>
>
>Mark Hindess wrote:
>> On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]>
wrote:
>>>
>>> Mark Hindess wrote:
>>>> On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]>
wrote:
>>>>> FWIW: Below are the results of running RAT on a windows snapshot.
>>>>> For some reason it complained about lack of ASF block comments in
>>>>> DLLs, and proceeded to dump them to the console, so I chopped them
out
>>>>> of the report. Looks like mainly missing block comments in emconf
>>>>> files.
>>>>>
>>>>> I suspect that it will be helpful to do this on an HDK snapshot,
plus
>>>>> on a source drop (that we don't produce at present, but should
IMO).
>>>> I'm looking at modifying the federation build to have a source drop
>>>> target. It looks like doing:
>>>>
>>>> svn export . target/src
>>>>
>>>> and modifying the build.xml to cope with the lack of svn files
might
>>>> be a good start. I'll probably take a little more work but I'll
get
>>>> something checked in so we have something to work with.
>>> Wait.
>>
>> I don't think I have much choice. It's more likely you'll be waiting
>> for me. ;-) It's not as trivial as it sounds[0] so I'm sure this
>> discussion will be done before I'm ready to check anything in. ;-(
>>
>>> Why not just do a tar/zip on the working_classlib and working_vm
with
>>> a filter to keep out the generated stuff?
>>
>> This was my first thought but it didn't take long before I decided I
had
>> to think again. I think it is much too error prone. Consider
figuring
>> out which .so files are generated/downloaded and which are in svn.
>> Repeat for dll files, jar files, etc. Then keep this up to date.
It'd
>> be a full-time job.
>
>A *real* unix hacker would walk the tree looking at .svn/entry files ;)
> In Perl. in less than 20 lines.
>
>>
>> svn export does just the right thing. It takes only the stuff you
get
>> from svn but without the .svn files. This seems much less likely to
>> turn around and bite us. (Though even this isn't without issues.)
>
>Otay.
>
>geir
>
>>
>> Regards,
>> Mark.
>>
>> [0] not as trivial as I was expecting that's for sure
>>
>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>
>
>-
>Terms of use : http://incubator.apache.org/harmony/mailing.html
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
Mark Hindess wrote: On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: Mark Hindess wrote: On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote: FWIW: Below are the results of running RAT on a windows snapshot. For some reason it complained about lack of ASF block comments in DLLs, and proceeded to dump them to the console, so I chopped them out of the report. Looks like mainly missing block comments in emconf files. I suspect that it will be helpful to do this on an HDK snapshot, plus on a source drop (that we don't produce at present, but should IMO). I'm looking at modifying the federation build to have a source drop target. It looks like doing: svn export . target/src and modifying the build.xml to cope with the lack of svn files might be a good start. I'll probably take a little more work but I'll get something checked in so we have something to work with. Wait. I don't think I have much choice. It's more likely you'll be waiting for me. ;-) It's not as trivial as it sounds[0] so I'm sure this discussion will be done before I'm ready to check anything in. ;-( Why not just do a tar/zip on the working_classlib and working_vm with a filter to keep out the generated stuff? This was my first thought but it didn't take long before I decided I had to think again. I think it is much too error prone. Consider figuring out which .so files are generated/downloaded and which are in svn. Repeat for dll files, jar files, etc. Then keep this up to date. It'd be a full-time job. A *real* unix hacker would walk the tree looking at .svn/entry files ;) In Perl. in less than 20 lines. svn export does just the right thing. It takes only the stuff you get from svn but without the .svn files. This seems much less likely to turn around and bite us. (Though even this isn't without issues.) Otay. geir Regards, Mark. [0] not as trivial as I was expecting that's for sure - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote: > > > Mark Hindess wrote: > > On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> FWIW: Below are the results of running RAT on a windows snapshot. > >> For some reason it complained about lack of ASF block comments in > >> DLLs, and proceeded to dump them to the console, so I chopped them out > >> of the report. Looks like mainly missing block comments in emconf > >> files. > >> > >> I suspect that it will be helpful to do this on an HDK snapshot, plus > >> on a source drop (that we don't produce at present, but should IMO). > > > > I'm looking at modifying the federation build to have a source drop > > target. It looks like doing: > > > > svn export . target/src > > > > and modifying the build.xml to cope with the lack of svn files might > > be a good start. I'll probably take a little more work but I'll get > > something checked in so we have something to work with. > > Wait. I don't think I have much choice. It's more likely you'll be waiting for me. ;-) It's not as trivial as it sounds[0] so I'm sure this discussion will be done before I'm ready to check anything in. ;-( > Why not just do a tar/zip on the working_classlib and working_vm with > a filter to keep out the generated stuff? This was my first thought but it didn't take long before I decided I had to think again. I think it is much too error prone. Consider figuring out which .so files are generated/downloaded and which are in svn. Repeat for dll files, jar files, etc. Then keep this up to date. It'd be a full-time job. svn export does just the right thing. It takes only the stuff you get from svn but without the .svn files. This seems much less likely to turn around and bite us. (Though even this isn't without issues.) Regards, Mark. [0] not as trivial as I was expecting that's for sure - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
Egor Pasko wrote: On the 0x208 day of Apache Harmony Tim Ellison wrote: FWIW: Below are the results of running RAT on a windows snapshot. For some reason it complained about lack of ASF block comments in DLLs, and proceeded to dump them to the console, so I chopped them out of the report. Looks like mainly missing block comments in emconf files. I fixed *.emconf block comments in HARMONY-1928. OK? Thank you, and thanks to Paulex for committing it. (Now, lets see what we can do about those dll's. ;) geir I suspect that it will be helpful to do this on an HDK snapshot, plus on a source drop (that we don't produce at present, but should IMO). Regards, Tim --- Notes:3 Binaries: 39 Archives: 44 Standards: 72 27 Apache Licensed 45 Unknown Licenses Analysing Documents... Files with ASL headers will be marked L Binary files (which do not require ASL headers) will be marked B Compressed archives will be marked A Notices, licenses etc will be marked N D \harmony-jre-r450941 !? COPYRIGHT N INCUBATOR_NOTICE.txt N LICENSE N NOTICE !? THIRD_PARTY_NOTICES.txt !? readme.txt D \harmony-jre-r450941\bin !? ICUInterface34.dll !? Win32Wrapper.dll !? accessors.dll !? fontlib.dll !? gl.dll ASL harmony.properties ASL harmony_ca.properties ASL harmony_cs.properties ASL harmony_de.properties ASL harmony_es.properties ASL harmony_fr.properties ASL harmony_hu.properties ASL harmony_it.properties ASL harmony_ja.properties ASL harmony_ko.properties ASL harmony_pl.properties ASL harmony_pt_BR.properties ASL harmony_ru.properties ASL harmony_sk.properties ASL harmony_sl.properties ASL harmony_tr.properties ASL harmony_zh.properties ASL harmony_zh_TW.properties !? hyarchive.dll !? hyauth.dll !? hyinstrument.dll !? hyluni.dll !? hynio.dll !? hyprefs.dll !? hyprt.dll !? hysecurity.dll !? hysig.dll !? hytext.dll !? hythr.dll !? hyzlib.dll !? icudt34.dll !? icuin34.dll !? icuuc34.dll B java.exe B javaw.exe !? jpegdecoder.dll !? lcmm.dll !? msvcr71.dll D \harmony-jre-r450941\bin\default !? client.emconf !? eclipse.bat !? em.dll !? encoder.lib !? gc.dll !? harmonyvm.dll !? harmonyvm.lib !? harmonyvm.properties !? hythr.dll !? interpreter.dll !? jet.emconf !? jitrino.dll !? opt.emconf !? server.emconf !? server_static.emconf !? ti.emconf !? vmi.dll !? zlib1.dll D \harmony-jre-r450941\doc ASL GettingStarted.htm !? drl.css D \harmony-jre-r450941\doc\images B DRL_structure.gif B EM_interfaces.gif B Stack.gif B Stack_managed.gif B Stack_native.gif B VM_core.gif B bytecode_to_native.gif B code_selector.gif B compilation_process.gif B debug_java_application.gif B debug_result.gif B debugging_code.gif B final_alloc_all.gif B final_final_queue.gif B final_graph.gif B final_queques.gif B final_threads.gif B final_unmarked_queue.gif B log_categories.gif B monitor_structure.gif B new_java_class.gif B new_project.gif B operand_depth.gif B operand_to_memory.gif B package_explorer.gif B print_hello_world.gif B reference_count.gif B run_java_application.gif B selecting_code.gif B toggle_breakpoint.gif B vCRC.gif B workspace1.gif B workspace_launcher.gif D \harmony-jre-r450941\include ASL jni.h ASL jni_types.h ASL jvmti.h ASL jvmti_types.h D \harmony-jre-r450941\lib ASL logging.properties D \harmony-jre-r450941\lib\boot A accessibility.jar A annotation.jar A antlr-2.7.5.jar A applet.jar A archive.jar A auth.jar A awt.jar A beans.jar ASL bootclasspath.properties A concurrent.jar A crypto.jar A icu4jni-3.4.jar A instrument.jar A jndi.jar A kernel.jar A lang-management.jar A logging.jar A luni-kernel-stubs.jar A luni.jar A math.jar A misc.jar A nio.jar A nio_char.jar A prefs.jar A regex.jar A rmi.jar A security-kernel-stubs.jar A security.jar A sound.jar A sql.jar A suncompat.jar A swing.jar A text.jar A x-net.jar D \harmony-jre-r450941\lib\boot\bcel-5.2 A bcel-5.2.jar D \harmony-jre-r450941\lib\boot\icu4j_3.4.4 A icu4j_3_4_4.jar D \harmony-jre-r450941\lib\boot\icu4j_3.4.4\META-INF B MANIFEST.MF D \harmony-jre-r450941\lib\boot\mx4j_3.0.1 A mx4j-remote.jar A mx4j.jar D \harmon
Re: [general] Incubator graduation update
Mikhail Loenko wrote: 2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: For those that haven't been following along Graduating from the Incubator is a "dynamic" process, as there's no really hard and fast rules to satisfy. On one hand, this is a good thing, because determining the health and prospect of future success of an Apache community is a difficult job, and it therefore relies on the experience and judgment of the Incubator PMC members. (It also allows the process to be adapted for different kinds of podlings - we're a weird one...) On the other hand, it can result it individual Incubator PMC members using different "filter" criterion. Now, I'm really proud to be a part of this community - I think we work very well together, collaboratively, in a positive and friendly atmosphere, and have demonstrated time and again the ability to vote, deal with issues that arise in voting, deal with differences of opinion, amass great hunks of software into an orderly project, etc. That said, I'm not very optimistic that we'll be able to bring this to a close in time for this month's board meeting. It's a shame, but that's ok - we're really in no rush, and if not this month, then next month. There are no major problems - it's partially because of the rather short timelines we tried, and partially because there are a few issues under discussion on the general@incubator.apache.org list, a list I encourage all of you to subscribe to and participate in. First, there are minor 'nits' here and there related to license and license headers. For example, we're missing the antlr license in our NOTICE file. Patch anyone? Also, there are other minor things here and there which can be found with this tool : http://code.google.com/p/arat/ Anyone interested in running it ASAP and giving us a set of patches to get a clean bill of health? Second, we're having a discussion on the general@ list (in which we all can participate) regarding the necessity of a project going through a release. This isn't actually an Incubator requirement, but the case where information on community health and dynamics is absent or scarce, it's a reasonable exercise. However... for Harmony, that isn't the case. I've been arguing that there's plenty of information on us. All four of us mentors (Stefano, Leo, Dims and myself) reported very positive independent assessments of the community (go read on general@) and we have 18 months of consistent, positive interaction with each other. My thinking was that 1) A release is something that we haven't wanted to do yet as a project, as our interest is in producing a more complete and stable implementation first. We have a roadmap, it's been published for a while now, and at least for me, it's the goal that I'm looking towards every day. (heck... we're still deciding what "supported" means...) 2) We're not stable enough to do something we want to shout out to the world as a "developer release" or similar. We will be ready soon, but not now. (This is just my personal opinion - others may certainly differ...) Anyway, that's what I feel about it. There are Incubator PMC members that have decided that there is ample information (Dims, Stefano and Leo really hit it out of the park with their assessments... thanks guys!) and have changed their minds, and I'm hoping to reach consensus with the rest that there *is* enough information. However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) Any other ideas, and any other thoughts? Another option: We have three security providers that are independent pluggable modules by definition. We can release all or some of them Good idea. Thanks, Mikhail geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
Mark Hindess wrote: On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote: FWIW: Below are the results of running RAT on a windows snapshot. For some reason it complained about lack of ASF block comments in DLLs, and proceeded to dump them to the console, so I chopped them out of the report. Looks like mainly missing block comments in emconf files. I suspect that it will be helpful to do this on an HDK snapshot, plus on a source drop (that we don't produce at present, but should IMO). I'm looking at modifying the federation build to have a source drop target. It looks like doing: svn export . target/src and modifying the build.xml to cope with the lack of svn files might be a good start. I'll probably take a little more work but I'll get something checked in so we have something to work with. Wait. Why not just do a tar/zip on the working_classlib and working_vm with a filter to keep out the generated stuff? geir -Mark. P.S. Geir, can we move https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/sandbox out of the federation trunk so the svn export above doesn't copy it? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
Alex Blewitt wrote: However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) :-) So, you're saying I've got less than a month to finish it ... Nope! This was my worry - that this "testing" would disrupt normal life. Keep going at whatever course and speed you want. The point of a release would be to do the release, not show working perfect code. I'll probably be able to get *something* ready for a release, but I doubt it will be fully compliant by then. The problem is that decompressed Jars are supposed to be exactly the same for any decompressor, so that MD5 signatures remain valid afterwards. What I can probably get is an unpacked Jar that will execute, but might be in a different ordering or have different MD5 signatures for components. The problem is that there's a lot of possible combinations of input files ... Don't worry :) I've also tended to do fairly large code drops in patches, because it normally means a few days between submission and when it can be applied (thanks for the last one Paulex :-) I'd prefer to submit smaller patches as and when new functionality is added, but it would take longer that way. Small patches would be better ;) PS When's the code going to be moved to a jdktools subproject? That's actually a subject for a separate thread - given that the core code is in the classlib, we can't... geir Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
The same situation with DNS provider for JNDI. The only dependence is the internationalization stuff added recently. Regards, 2006/10/20, Mikhail Loenko <[EMAIL PROTECTED]>: 2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > For those that haven't been following along > > Graduating from the Incubator is a "dynamic" process, as there's no > really hard and fast rules to satisfy. On one hand, this is a good > thing, because determining the health and prospect of future success of > an Apache community is a difficult job, and it therefore relies on the > experience and judgment of the Incubator PMC members. (It also allows > the process to be adapted for different kinds of podlings - we're a > weird one...) On the other hand, it can result it individual Incubator > PMC members using different "filter" criterion. > > Now, I'm really proud to be a part of this community - I think we work > very well together, collaboratively, in a positive and friendly > atmosphere, and have demonstrated time and again the ability to vote, > deal with issues that arise in voting, deal with differences of opinion, > amass great hunks of software into an orderly project, etc. > > That said, I'm not very optimistic that we'll be able to bring this to a > close in time for this month's board meeting. It's a shame, but that's > ok - we're really in no rush, and if not this month, then next month. > There are no major problems - it's partially because of the rather short > timelines we tried, and partially because there are a few issues under > discussion on the general@incubator.apache.org list, a list I encourage > all of you to subscribe to and participate in. > > First, there are minor 'nits' here and there related to license and > license headers. For example, we're missing the antlr license in our > NOTICE file. Patch anyone? Also, there are other minor things here and > there which can be found with this tool : > > http://code.google.com/p/arat/ > > Anyone interested in running it ASAP and giving us a set of patches to > get a clean bill of health? > > Second, we're having a discussion on the general@ list (in which we all > can participate) regarding the necessity of a project going through a > release. This isn't actually an Incubator requirement, but the case > where information on community health and dynamics is absent or scarce, > it's a reasonable exercise. > > However... for Harmony, that isn't the case. I've been arguing that > there's plenty of information on us. All four of us mentors (Stefano, > Leo, Dims and myself) reported very positive independent assessments of > the community (go read on general@) and we have 18 months of consistent, > positive interaction with each other. My thinking was that > > 1) A release is something that we haven't wanted to do yet as a project, > as our interest is in producing a more complete and stable > implementation first. We have a roadmap, it's been published for a > while now, and at least for me, it's the goal that I'm looking towards > every day. (heck... we're still deciding what "supported" means...) > > 2) We're not stable enough to do something we want to shout out to the > world as a "developer release" or similar. We will be ready soon, but > not now. (This is just my personal opinion - others may certainly > differ...) > > Anyway, that's what I feel about it. There are Incubator PMC members > that have decided that there is ample information (Dims, Stefano and Leo > really hit it out of the park with their assessments... thanks guys!) > and have changed their minds, and I'm hoping to reach consensus with the > rest that there *is* enough information. > > However, if not, and some IPMC memebers still really want to see a > demonstration of a release process, we can certainly do that. I've > thought about what we might release. One thing that came to mind is a > Pack200 jar :) > > Any other ideas, and any other thoughts? Another option: We have three security providers that are independent pluggable modules by definition. We can release all or some of them -- Alexei Zakharov, Intel Enterprise Solutions Software Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
On 10/20/06, Geir Magnusson Jr. wrote: For those that haven't been following along Graduating from the Incubator is a "dynamic" process, as there's no really hard and fast rules to satisfy. On one hand, this is a good thing, because determining the health and prospect of future success of an Apache community is a difficult job, and it therefore relies on the experience and judgment of the Incubator PMC members. (It also allows the process to be adapted for different kinds of podlings - we're a weird one...) On the other hand, it can result it individual Incubator PMC members using different "filter" criterion. Now, I'm really proud to be a part of this community - I think we work very well together, collaboratively, in a positive and friendly atmosphere, and have demonstrated time and again the ability to vote, deal with issues that arise in voting, deal with differences of opinion, amass great hunks of software into an orderly project, etc. That said, I'm not very optimistic that we'll be able to bring this to a close in time for this month's board meeting. It's a shame, but that's ok - we're really in no rush, and if not this month, then next month. There are no major problems - it's partially because of the rather short timelines we tried, and partially because there are a few issues under discussion on the general@incubator.apache.org list, a list I encourage all of you to subscribe to and participate in. First, there are minor 'nits' here and there related to license and license headers. For example, we're missing the antlr license in our NOTICE file. Patch anyone? Also, there are other minor things here and there which can be found with this tool : http://code.google.com/p/arat/ Anyone interested in running it ASAP and giving us a set of patches to get a clean bill of health? Second, we're having a discussion on the general@ list (in which we all can participate) regarding the necessity of a project going through a release. This isn't actually an Incubator requirement, but the case where information on community health and dynamics is absent or scarce, it's a reasonable exercise. However... for Harmony, that isn't the case. I've been arguing that there's plenty of information on us. All four of us mentors (Stefano, Leo, Dims and myself) reported very positive independent assessments of the community (go read on general@) and we have 18 months of consistent, positive interaction with each other. My thinking was that 1) A release is something that we haven't wanted to do yet as a project, as our interest is in producing a more complete and stable implementation first. We have a roadmap, it's been published for a while now, and at least for me, it's the goal that I'm looking towards every day. (heck... we're still deciding what "supported" means...) 2) We're not stable enough to do something we want to shout out to the world as a "developer release" or similar. We will be ready soon, but not now. (This is just my personal opinion - others may certainly differ...) Anyway, that's what I feel about it. There are Incubator PMC members that have decided that there is ample information (Dims, Stefano and Leo really hit it out of the park with their assessments... thanks guys!) and have changed their minds, and I'm hoping to reach consensus with the rest that there *is* enough information. However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) I was under impression that you are against releasing "a piece of Harmony" [1]. Particularly, you wrote: "There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile." IIUC now it is OK to release harmony-ketool-v1.0.tar.gz. Right? Thanks, Stepan. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Any other ideas, and any other thoughts? geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
Alex Blewitt wrote: However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) :-) So, you're saying I've got less than a month to finish it ... I'll probably be able to get *something* ready for a release, but I doubt it will be fully compliant by then. The problem is that decompressed Jars are supposed to be exactly the same for any decompressor, so that MD5 signatures remain valid afterwards. What I can probably get is an unpacked Jar that will execute, but might be in a different ordering or have different MD5 signatures for components. The problem is that there's a lot of possible combinations of input files ... I've also tended to do fairly large code drops in patches, because it normally means a few days between submission and when it can be applied (thanks for the last one Paulex :-) I'd prefer to submit smaller patches as and when new functionality is added, but it would take longer that way. You are welcome:). About the size of patches, IMO it's a dilemma, if the patch is large and contains too many information for committers to understand in a glance, it generally needs more time to get it applied; while a relative smaller patch with clear objective and reasonable tests probably has more chance to go in the SVN very soon. PS When's the code going to be moved to a jdktools subproject? I can do that if no one objects(I personally +1 for that, but I'm waiting for more committers' opinion on this issue), and if you can provide a script to do that(svn move or so), it would be nice. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>: For those that haven't been following along Graduating from the Incubator is a "dynamic" process, as there's no really hard and fast rules to satisfy. On one hand, this is a good thing, because determining the health and prospect of future success of an Apache community is a difficult job, and it therefore relies on the experience and judgment of the Incubator PMC members. (It also allows the process to be adapted for different kinds of podlings - we're a weird one...) On the other hand, it can result it individual Incubator PMC members using different "filter" criterion. Now, I'm really proud to be a part of this community - I think we work very well together, collaboratively, in a positive and friendly atmosphere, and have demonstrated time and again the ability to vote, deal with issues that arise in voting, deal with differences of opinion, amass great hunks of software into an orderly project, etc. That said, I'm not very optimistic that we'll be able to bring this to a close in time for this month's board meeting. It's a shame, but that's ok - we're really in no rush, and if not this month, then next month. There are no major problems - it's partially because of the rather short timelines we tried, and partially because there are a few issues under discussion on the general@incubator.apache.org list, a list I encourage all of you to subscribe to and participate in. First, there are minor 'nits' here and there related to license and license headers. For example, we're missing the antlr license in our NOTICE file. Patch anyone? Also, there are other minor things here and there which can be found with this tool : http://code.google.com/p/arat/ Anyone interested in running it ASAP and giving us a set of patches to get a clean bill of health? Second, we're having a discussion on the general@ list (in which we all can participate) regarding the necessity of a project going through a release. This isn't actually an Incubator requirement, but the case where information on community health and dynamics is absent or scarce, it's a reasonable exercise. However... for Harmony, that isn't the case. I've been arguing that there's plenty of information on us. All four of us mentors (Stefano, Leo, Dims and myself) reported very positive independent assessments of the community (go read on general@) and we have 18 months of consistent, positive interaction with each other. My thinking was that 1) A release is something that we haven't wanted to do yet as a project, as our interest is in producing a more complete and stable implementation first. We have a roadmap, it's been published for a while now, and at least for me, it's the goal that I'm looking towards every day. (heck... we're still deciding what "supported" means...) 2) We're not stable enough to do something we want to shout out to the world as a "developer release" or similar. We will be ready soon, but not now. (This is just my personal opinion - others may certainly differ...) Anyway, that's what I feel about it. There are Incubator PMC members that have decided that there is ample information (Dims, Stefano and Leo really hit it out of the park with their assessments... thanks guys!) and have changed their minds, and I'm hoping to reach consensus with the rest that there *is* enough information. However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) Any other ideas, and any other thoughts? Another option: We have three security providers that are independent pluggable modules by definition. We can release all or some of them Thanks, Mikhail geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
On the 0x208 day of Apache Harmony Tim Ellison wrote: > FWIW: Below are the results of running RAT on a windows snapshot. For > some reason it complained about lack of ASF block comments in DLLs, and > proceeded to dump them to the console, so I chopped them out of the > report. Looks like mainly missing block comments in emconf files. I fixed *.emconf block comments in HARMONY-1928. OK? > I suspect that it will be helpful to do this on an HDK snapshot, plus on > a source drop (that we don't produce at present, but should IMO). > > Regards, > Tim > > --- > Notes:3 > Binaries: 39 > Archives: 44 > Standards: 72 > 27 Apache Licensed > 45 Unknown Licenses > > > Analysing Documents... > Files with ASL headers will be marked L > Binary files (which do not require ASL headers) will be marked B > Compressed archives will be marked A > Notices, licenses etc will be marked N > D \harmony-jre-r450941 > !? COPYRIGHT > N INCUBATOR_NOTICE.txt > N LICENSE > N NOTICE > !? THIRD_PARTY_NOTICES.txt > !? readme.txt > D \harmony-jre-r450941\bin > !? ICUInterface34.dll > !? Win32Wrapper.dll > !? accessors.dll > !? fontlib.dll > !? gl.dll > ASL harmony.properties > ASL harmony_ca.properties > ASL harmony_cs.properties > ASL harmony_de.properties > ASL harmony_es.properties > ASL harmony_fr.properties > ASL harmony_hu.properties > ASL harmony_it.properties > ASL harmony_ja.properties > ASL harmony_ko.properties > ASL harmony_pl.properties > ASL harmony_pt_BR.properties > ASL harmony_ru.properties > ASL harmony_sk.properties > ASL harmony_sl.properties > ASL harmony_tr.properties > ASL harmony_zh.properties > ASL harmony_zh_TW.properties > !? hyarchive.dll > !? hyauth.dll > !? hyinstrument.dll > !? hyluni.dll > !? hynio.dll > !? hyprefs.dll > !? hyprt.dll > !? hysecurity.dll > !? hysig.dll > !? hytext.dll > !? hythr.dll > !? hyzlib.dll > !? icudt34.dll > !? icuin34.dll > !? icuuc34.dll > B java.exe > B javaw.exe > !? jpegdecoder.dll > !? lcmm.dll > !? msvcr71.dll > D \harmony-jre-r450941\bin\default > !? client.emconf > !? eclipse.bat > !? em.dll > !? encoder.lib > !? gc.dll > !? harmonyvm.dll > !? harmonyvm.lib > !? harmonyvm.properties > !? hythr.dll > !? interpreter.dll > !? jet.emconf > !? jitrino.dll > !? opt.emconf > !? server.emconf > !? server_static.emconf > !? ti.emconf > !? vmi.dll > !? zlib1.dll > D \harmony-jre-r450941\doc > ASL GettingStarted.htm > !? drl.css > D \harmony-jre-r450941\doc\images > B DRL_structure.gif > B EM_interfaces.gif > B Stack.gif > B Stack_managed.gif > B Stack_native.gif > B VM_core.gif > B bytecode_to_native.gif > B code_selector.gif > B compilation_process.gif > B debug_java_application.gif > B debug_result.gif > B debugging_code.gif > B final_alloc_all.gif > B final_final_queue.gif > B final_graph.gif > B final_queques.gif > B final_threads.gif > B final_unmarked_queue.gif > B log_categories.gif > B monitor_structure.gif > B new_java_class.gif > B new_project.gif > B operand_depth.gif > B operand_to_memory.gif > B package_explorer.gif > B print_hello_world.gif > B reference_count.gif > B run_java_application.gif > B selecting_code.gif > B toggle_breakpoint.gif > B vCRC.gif > B workspace1.gif > B workspace_launcher.gif > D \harmony-jre-r450941\include > ASL jni.h > ASL jni_types.h > ASL jvmti.h > ASL jvmti_types.h > D \harmony-jre-r450941\lib > ASL logging.properties > D \harmony-jre-r450941\lib\boot > A accessibility.jar > A annotation.jar > A antlr-2.7.5.jar > A applet.jar > A archive.jar > A auth.jar > A awt.jar > A beans.jar > ASL bootclasspath.properties > A concurrent.jar > A crypto.jar > A icu4jni-3.4.jar > A instrument.jar > A jndi.jar > A kernel.jar > A lang-management.jar > A logging.jar > A luni-kernel-stubs.jar > A luni.jar > A math.jar > A misc.jar > A nio.jar > A nio_char.jar > A prefs.jar > A regex.jar > A rmi.jar > A security-kernel-stubs.jar > A security.jar > A sound.jar > A sql.jar > A suncompat.jar > A swing.jar > A text.jar > A x-net.jar > D \harmony-jre-r450941\lib\boot\bcel-5.2 > A bcel-5.2.jar > D \harmony-jre-r450941\lib\boot\icu4j_3.4.4 >
Re: [general] Incubator graduation update
On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote: > FWIW: Below are the results of running RAT on a windows snapshot. > For some reason it complained about lack of ASF block comments in > DLLs, and proceeded to dump them to the console, so I chopped them out > of the report. Looks like mainly missing block comments in emconf > files. > > I suspect that it will be helpful to do this on an HDK snapshot, plus > on a source drop (that we don't produce at present, but should IMO). I'm looking at modifying the federation build to have a source drop target. It looks like doing: svn export . target/src and modifying the build.xml to cope with the lack of svn files might be a good start. I'll probably take a little more work but I'll get something checked in so we have something to work with. -Mark. P.S. Geir, can we move https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/sandbox out of the federation trunk so the svn export above doesn't copy it? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
FWIW: Below are the results of running RAT on a windows snapshot. For some reason it complained about lack of ASF block comments in DLLs, and proceeded to dump them to the console, so I chopped them out of the report. Looks like mainly missing block comments in emconf files. I suspect that it will be helpful to do this on an HDK snapshot, plus on a source drop (that we don't produce at present, but should IMO). Regards, Tim --- Notes:3 Binaries: 39 Archives: 44 Standards: 72 27 Apache Licensed 45 Unknown Licenses Analysing Documents... Files with ASL headers will be marked L Binary files (which do not require ASL headers) will be marked B Compressed archives will be marked A Notices, licenses etc will be marked N D \harmony-jre-r450941 !? COPYRIGHT N INCUBATOR_NOTICE.txt N LICENSE N NOTICE !? THIRD_PARTY_NOTICES.txt !? readme.txt D \harmony-jre-r450941\bin !? ICUInterface34.dll !? Win32Wrapper.dll !? accessors.dll !? fontlib.dll !? gl.dll ASL harmony.properties ASL harmony_ca.properties ASL harmony_cs.properties ASL harmony_de.properties ASL harmony_es.properties ASL harmony_fr.properties ASL harmony_hu.properties ASL harmony_it.properties ASL harmony_ja.properties ASL harmony_ko.properties ASL harmony_pl.properties ASL harmony_pt_BR.properties ASL harmony_ru.properties ASL harmony_sk.properties ASL harmony_sl.properties ASL harmony_tr.properties ASL harmony_zh.properties ASL harmony_zh_TW.properties !? hyarchive.dll !? hyauth.dll !? hyinstrument.dll !? hyluni.dll !? hynio.dll !? hyprefs.dll !? hyprt.dll !? hysecurity.dll !? hysig.dll !? hytext.dll !? hythr.dll !? hyzlib.dll !? icudt34.dll !? icuin34.dll !? icuuc34.dll B java.exe B javaw.exe !? jpegdecoder.dll !? lcmm.dll !? msvcr71.dll D \harmony-jre-r450941\bin\default !? client.emconf !? eclipse.bat !? em.dll !? encoder.lib !? gc.dll !? harmonyvm.dll !? harmonyvm.lib !? harmonyvm.properties !? hythr.dll !? interpreter.dll !? jet.emconf !? jitrino.dll !? opt.emconf !? server.emconf !? server_static.emconf !? ti.emconf !? vmi.dll !? zlib1.dll D \harmony-jre-r450941\doc ASL GettingStarted.htm !? drl.css D \harmony-jre-r450941\doc\images B DRL_structure.gif B EM_interfaces.gif B Stack.gif B Stack_managed.gif B Stack_native.gif B VM_core.gif B bytecode_to_native.gif B code_selector.gif B compilation_process.gif B debug_java_application.gif B debug_result.gif B debugging_code.gif B final_alloc_all.gif B final_final_queue.gif B final_graph.gif B final_queques.gif B final_threads.gif B final_unmarked_queue.gif B log_categories.gif B monitor_structure.gif B new_java_class.gif B new_project.gif B operand_depth.gif B operand_to_memory.gif B package_explorer.gif B print_hello_world.gif B reference_count.gif B run_java_application.gif B selecting_code.gif B toggle_breakpoint.gif B vCRC.gif B workspace1.gif B workspace_launcher.gif D \harmony-jre-r450941\include ASL jni.h ASL jni_types.h ASL jvmti.h ASL jvmti_types.h D \harmony-jre-r450941\lib ASL logging.properties D \harmony-jre-r450941\lib\boot A accessibility.jar A annotation.jar A antlr-2.7.5.jar A applet.jar A archive.jar A auth.jar A awt.jar A beans.jar ASL bootclasspath.properties A concurrent.jar A crypto.jar A icu4jni-3.4.jar A instrument.jar A jndi.jar A kernel.jar A lang-management.jar A logging.jar A luni-kernel-stubs.jar A luni.jar A math.jar A misc.jar A nio.jar A nio_char.jar A prefs.jar A regex.jar A rmi.jar A security-kernel-stubs.jar A security.jar A sound.jar A sql.jar A suncompat.jar A swing.jar A text.jar A x-net.jar D \harmony-jre-r450941\lib\boot\bcel-5.2 A bcel-5.2.jar D \harmony-jre-r450941\lib\boot\icu4j_3.4.4 A icu4j_3_4_4.jar D \harmony-jre-r450941\lib\boot\icu4j_3.4.4\META-INF B MANIFEST.MF D \harmony-jre-r450941\lib\boot\mx4j_3.0.1 A mx4j-remote.jar A mx4j.jar D \harmony-jre-r450941\lib\boot\mx4j_3.0.1\META-INF B MANIFEST.MF D \harmony-jre-r450941\lib\boot\xalan-j_2.7.0 A xalan.jar D \harmony-jre-r450941\lib\boot\xalan-j_2.7.0\META-INF B MANIFEST.MF D \harmony-jre-r450941\lib\boot\
Re: [general] Incubator graduation update
However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) :-) So, you're saying I've got less than a month to finish it ... I'll probably be able to get *something* ready for a release, but I doubt it will be fully compliant by then. The problem is that decompressed Jars are supposed to be exactly the same for any decompressor, so that MD5 signatures remain valid afterwards. What I can probably get is an unpacked Jar that will execute, but might be in a different ordering or have different MD5 signatures for components. The problem is that there's a lot of possible combinations of input files ... I've also tended to do fairly large code drops in patches, because it normally means a few days between submission and when it can be applied (thanks for the last one Paulex :-) I'd prefer to submit smaller patches as and when new functionality is added, but it would take longer that way. PS When's the code going to be moved to a jdktools subproject? Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] Incubator graduation update
For those that haven't been following along Graduating from the Incubator is a "dynamic" process, as there's no really hard and fast rules to satisfy. On one hand, this is a good thing, because determining the health and prospect of future success of an Apache community is a difficult job, and it therefore relies on the experience and judgment of the Incubator PMC members. (It also allows the process to be adapted for different kinds of podlings - we're a weird one...) On the other hand, it can result it individual Incubator PMC members using different "filter" criterion. Now, I'm really proud to be a part of this community - I think we work very well together, collaboratively, in a positive and friendly atmosphere, and have demonstrated time and again the ability to vote, deal with issues that arise in voting, deal with differences of opinion, amass great hunks of software into an orderly project, etc. That said, I'm not very optimistic that we'll be able to bring this to a close in time for this month's board meeting. It's a shame, but that's ok - we're really in no rush, and if not this month, then next month. There are no major problems - it's partially because of the rather short timelines we tried, and partially because there are a few issues under discussion on the general@incubator.apache.org list, a list I encourage all of you to subscribe to and participate in. First, there are minor 'nits' here and there related to license and license headers. For example, we're missing the antlr license in our NOTICE file. Patch anyone? Also, there are other minor things here and there which can be found with this tool : http://code.google.com/p/arat/ Anyone interested in running it ASAP and giving us a set of patches to get a clean bill of health? Second, we're having a discussion on the general@ list (in which we all can participate) regarding the necessity of a project going through a release. This isn't actually an Incubator requirement, but the case where information on community health and dynamics is absent or scarce, it's a reasonable exercise. However... for Harmony, that isn't the case. I've been arguing that there's plenty of information on us. All four of us mentors (Stefano, Leo, Dims and myself) reported very positive independent assessments of the community (go read on general@) and we have 18 months of consistent, positive interaction with each other. My thinking was that 1) A release is something that we haven't wanted to do yet as a project, as our interest is in producing a more complete and stable implementation first. We have a roadmap, it's been published for a while now, and at least for me, it's the goal that I'm looking towards every day. (heck... we're still deciding what "supported" means...) 2) We're not stable enough to do something we want to shout out to the world as a "developer release" or similar. We will be ready soon, but not now. (This is just my personal opinion - others may certainly differ...) Anyway, that's what I feel about it. There are Incubator PMC members that have decided that there is ample information (Dims, Stefano and Leo really hit it out of the park with their assessments... thanks guys!) and have changed their minds, and I'm hoping to reach consensus with the rest that there *is* enough information. However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) Any other ideas, and any other thoughts? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
