Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this exception,
get error code, and throw another exception.
If so, why not just return the error code directly instead? :)
2006/7/14, Mikhail Loenko [EMAIL PROTECTED]:
Hi Andrew
this seems reasonable
Thanks,
Mikhail
2006/7/14, Andrew Zhang [EMAIL PROTECTED]:
Hi folks,
I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids
message
comparison while keeps current luni native architecture.
Before I upload a new patch to JIRA, I want to hear more voices from
the community. Any better suggestions? Any comments?
Mikhail, what's your opnion? Do you think it makes sense?
Thanks in advance!
Best regards,
Andrew
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException,
looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't
want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony
socket
native
code
uses messages in SocketException to identify error type.
To avoid the confusion, two alternatives way I could image
are:
1. Native code returns platform-independent error code.
2. Native code throws different exceptions, which are all
extended from
SocketException.
Anyway, as current Harmony native design, the message in
SocketException
thrown by native code is a NON-NLS string, that is to say,
like
GET,POST
in http protocol. Unless we take a big change on native
code
design, I
don't think the code is dangerous.
What's your opnion?
I like option #2.
I also prefer option1 and 2 to current native solution.
I don't think exception messages are the same as GET and
POST, we
agreed
that the messages are to be internationalized. I see that
currently
not
all
the messages are internationalized but I think they will in
the
future.
NO. Currently, exception message thrown by native code are
used as
if error
code [1]. Please pay attention to netLookupErrorString
function.
Harmony-815 patch is based on current Harmony native
implemenation,
therefore, it should work well if design is not changed.
If we decide to adopt option 1, or 2, we have to re-design
native
and java
interface,
and there are lots of native and java code to be changed.
How to design native interface is out of scope to this patch,
therefore, I
think a seperate JIRA or thread for socket native interface
design
is more
suitable.
Of course, once decision is made, I'll volunteer to revise
native
and java
code.
Yep, I also find this strange style of return value, I doubt if
the
exception thrown in native may be an enhancement to code
efficiency?
However to refactor this may be a heavy work, as much code
follows
this
style, affects both luni and nio. I suggest apply this patch,
and
leave
this work until Harmony begins i18n.
Does it make sense?
Thanks!
[1] native-src (nethelp.c)
Re: [classlib] debug compilation as default
I have already implemented it using ant variables, look at the latest patch. You can use following notation with it: ant -Dhy.cfg=release I'm not sure the patch will apply cleanly, there was some changes in the makefiles since then. -- Ivan On 7/16/06, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 10-07-2006 14:18: What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant This only works well under Unix. To my knowledge this is not immediately possible under Windows. The and properties should work everywhere. -- Thorbjørn -- Ivan Intel Middleware Products 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: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Matt Benson wrote:
--- Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
[SNIP]
I guess the primary job of these scripts is to
setup the classpath
correctly.
We can get of them under assumption that everyone
has a cpptasks
(which is needed for native code compilation) and
antcontrib packages
installed with the Ant.
And as soon as we get rid of the need for
cpptasks ;)
I wonder if we can add them to the classpath in the
first ant-script we
run, and then have them avail for invoked scripts.
Seriously, if the native build is switched to a make
approach, it wouldn't be impossible to remove the ac
dependency from what I can see in the drlvm buildfile.
Personally I would probably prefer the cpptasks be
used but grudgingly admit that actual C hackers are
probably more accustomed to make. ;)
Beyond that, however, antcontrib is THE most often
mentioned/recommended 3rd-party package on Ant's user
lists;
Why don't you guys fold this into ant then?
more than one of its developers are also Ant
committers. I don't know that I see the harm in
simply requiring that the user install antcontrib (and
cpptasks, while it is used). The user can simply drop
the jars into $ANT_HOME/lib (actually I don't set
ANT_HOME but let the location of the invoker script
along my PATH pick it up, but that's a different
story).
Because it's annoying when you need to modify standard tools just for
one project...
On shared installations (with Ant = 1.6),
the user can install in ${user.home}/.ant/lib or
supply the -lib option at the commandline. If the
-lib option is chosen, that can be configured with
ANT_ARGS .
Oh, that's cool. Still, why don't you let me augment ant's lib at
runtime from w/in the ant script? I would assume it would be related to
initial parsing and recognition of elements in the script, but some kind
of late-binding would be nifty...
My cygwin Harmony classpath build
environment actually uses the -lib option to include
the ecj jar, for example.
So there's no way to do a fork-like thing - let a top ant script setup
the environment and then launch the script that does the work?
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: [classlib] debug compilation as default
Ivan Volosyuk wrote: I have already implemented it using ant variables, look at the latest patch. You can use following notation with it: ant -Dhy.cfg=release I'm not sure the patch will apply cleanly, there was some changes in the makefiles since then. Now we're getting somewhere. I assume then I can put this into the build.properties that we'll be adding Real Soon Now (as I can never remember command line args anyway...) geir -- Ivan On 7/16/06, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: Ivan Volosyuk skrev den 10-07-2006 14:18: What's wrong with the notation: 'BUILD_CFG=debug ant' or simply 'ant' BUILD_CFG=release ant This only works well under Unix. To my knowledge this is not immediately possible under Windows. The and properties should work everywhere. -- Thorbjørn - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[announce] New Apache Harmony Committer : Paulex Yang
Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Paulex Yang
congrats and keep up the good work! Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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: [classlib][concurrent] java.util.concurrent module proposal
Nathan Beyer wrote: Resulting actions: * Move code to the 'standard' folder? (I'll do this in the next few days if there aren't any complaints) Sure. It's just a proposal at this point anyway. Things to think about though will be if we choose this route (and I see no reason why not) then how do we integrate it into the build? Given it's really just an external dependency that we have a copy of the code for (and create a jar), then maybe it's at first simply go into /standard, do an 'ant jar', and then copy the dep jar over. Later we can integrate in to the top-level dependency area. Assuming we do this, the com.misc.Unsafe code *will* be in /enhanced somewhere as that is our code and in theory clean. * Continue with proposal code, create a prototype and try to work with the concurrency group. The only thing I could see us doing w/ the 166 EG right now is to offer them back a clean-room copy of CopyOnWriteArrayList since we have to implement it (in /enhanced), to replace the proprietary Sun version that's there. Any other major items? Well, implement com.misc.Unsafe. :) Also, I'm getting a note from Doug to see if that satisfies the various constituencies. I'll post that once that's done. geir -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 12:03 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][concurrent] java.util.concurrent module proposal Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Nathan Beyer wrote: I've checked in my proposal for the java.util.concurrent module at https://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk /s andbox/juc-proposal. You didn't just check in a proposal, you also checked in Doug Lea et al's code. Nobody should commit other people's code into svn this way. The code is under public domain license, so there should be no problem doing it since Doug et al produce no builds, and they suggested we do this. (not trying to be provocative, just trying to understand) they = the concurrency authors? do this = produce builds or check the code into our repository? Did I get this right? Sorry - I missed this - they really was Doug, and do this is take the code. Checking it in simply is good practice for peace of mind. it's also in our sandbox, and we're not redistributing it yet. Was there a reason to create .../classlib/trunk/sandbox? wouldn't .../classlib/sandbox make more sense? We already had the sandbox under /trunk No we didn't. http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/san dbox/?view=logpathrev=42 Perhaps it was created in the trunk by mistake. Oh, right. Sorry - there was a sandbox in enhanced/trunk which is what I thought it was checked into... So does anyone object to the proposed code being moved out of the enhanced subtree while we stare at it, thereby preserving our definition of 'enhanced'. I sort of do because we are utterly inconsistent about this, but if you look at my other message, if we just shove this into /standard/ the whole problem seems to magically go away anyway, so go ahead. I see copying the code as a one-way operation. We can hope to track updates to the original code thoroughly, but I don't see any fixes made in Harmony making it back directly into Doug's repository. Why not? We just offer them to Doug, and he can accept or reject. It strikes me as a strange model. If there is a well-run, active project with compatible license elsewhere I'm struggling to see why we would not just join in there, and all enjoy the fruits of the combined work g. Maybe this was discussed as part of the suggestion from Doug? Doug just suggested that we'd be well served using his code since it's public domain and the definitive implementation. If there is a well-run, active project with compatible license elsewhere, please point it out. As far as I know, this is the only implementation out there, and is why it's taken and used by IBM, BEA, Apple and Sun in the same way we're proposing. (IBM does not source the code directly from there, but that is a different matter) Why not just enjoy the fruits of what's being offered as public domain by arguably the world's top expert on the subject? While we have lots of talent around here, I'd be very surprised if we could do better. No arguments from me, that was the point that I was making too. Let's work with that project where we need to do so, and take their code as a dependency for Harmony. That's what we're doing. Is there a reason why we want to fork this code? I'd rather we worked with Doug (contributing directly to his project to make it more widely usable etc). Tim, isn't this what we discussed? This isn't a fork in the community sense, it's what amounts to a read only copy of the code for purposes of
Re: [classlib][concurrent] java.util.concurrent module proposal
Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] snip/ First problem is that you included CopyOnWriteArrayList.java, which is *not* a file we can take, as it's (c) Sun and under some unknown license. I've deleted it from SVN. Sorry, I completely overlooked that. Please be careful - I know it's difficult, but that's why we're so careful about bringing in foreign code. Design - Most of the code is straight from Doug Lea and the JSR group. The only piece I've added are the service interfaces that the VM must implement and I've uplifted the original code, where necessary to utilize these VM service interfaces. I don't know what you mean by uplift - I'm guessing you mean how you modified to not use sun.com.Unsafe? I'd like to avoid modifying any of this code, and just using as is, meaning for now we implement sun.com.Unsafe and whatever else, and then lobby Doug to change to something neutral. We might be able to get away with using the jar that is found on his website (assuming we can get him to produce one w/o Sun code, which isn't the case now), which would further drive the requirement that we use the code unmodified. I'm fine with doing this, but I thought there might be a copyright issue with using the 'sun.misc.Unsafe' class name. Additionally, the interface would have to be reverse engineered from the source that uses it. There isn't a stub of it in the ViewCVS repository that can be seen. Also, the .class file is NOT included in any of the JARs on the site. Are we cool with doing this? Note, just implementing 'sun.misc.Unsafe' may not be enough, as it seems that some pieces of the code make assumptions about internals of other classes. For example, LockSupport [1] retrieves the Field 'parkBlocker' from java.lang.Thread, which is not part of the public contract. Well, we just modify Thread then? If we just want to stick to a pure compilation route, then I think we would likely have to get Doug, et al to adopt some VM agnostic APIs before we take this code. I don't understand why. If we implement sun.misc.Unsafe and make the mod to Thread, what do we need to do to the code? [SNIP] * There are a LOT of changes, fixes and enhancements to the code at Doug Lea's site; consider what code we should additional take. Doug suggested we take HEAD, which would include changes for Mustang, but should be 100% compatible w/ Java 5. (And it doesn't really matter if we try and it's not true, as we aren't modifying any of his code, presumably.) I'd prefer to take HEAD myself and the code only uses JLS3, but there are dependencies on Java 6 APIs. For example, the ConcurrentHashMap uses the new AbstractMap.SimpleEntry class [1]. Also, there are a number of references to the new Arrays.copyXXX methods as well. Additionally, we talked about this a few times and I came away with that we should try to use the latest Java 5 tag [2][3][4]. Just as a reminder: there hasn't been a new tag since the JSR166_PFD tag (over 2 years old), so it's either that or HEAD + Harmony building some Java 6 APIs. Note, I'm perfectly fine with doing that as we'll need to do it eventually. either one - seems like the simple route for now is the 166 tag used in Tiger, and then we circle back once this is in. Goal is to get Java 5 j.u.c... Again, thanks for doing this. Don't let this minor process debate over provenance distract you from this mighty feat! 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: [legal] taking concurrency utils code into the project (Re: svn commit: r421111 [1/11] - in /incubator/harmony/enhanced/classlib/trunk/sandbox: ./ juc-proposal/ juc-proposal/concurrent/ juc-propos
Geir Magnusson Jr wrote: Tim Ellison wrote: Magnusson, Geir wrote: [SNIP] Second, we can certainly make exceptions to the project guidelines for cases where we believe there are no risks to the project. In fact, we've done it before when we accepted the core classes from ibm, iirc. How so? The IBM core classes contribution came with a completed bulk contribution questionnaire from the code owner detailing the authorship and a software grant. If we can get those for the concurrent code then I'm happy. And not every author of that has an ACQ. The point is that we've made the decision that not all code in our repository must have an ACQ. We don't have any provenance information on the binaries that we have, for example. And remember, Doug isn't making a contribution, we're discussing electing to use his code. it just has the odd property that there isn't a jar. To that end, are you aware of any risks for taking this code, given its uniqueness and statements by its author? It is authors plural, right? That is my suggestion, that we get statements from the authors as we agreed in the project guidelines. We spent some time refining exactly what we needed to know in such a statement. It's a guideline. We can also decide, as we've done in the past, to accept code w/o statements from each author. Do you really want to reconsider that? As I wrote earlier, I have no reason to doubt that the authors' employers (who may have a claim on that work) knew what they were doing and were happy for that work to be out in public domain. So we should go and get the doc to show that is the case. How consistent do you need to be here? If letter-of-the-law, IBM owes us a bit of paperwork, and I don't know what to do about the binaries we have lying around. I don't really want to be consistent for consistent sake, simply because we can and have made rational, calculated decisions based on our understanding of risk factors so we can move the project forward. I want to make something explicitly clear to everyone (IOW, this isn't asking for a response from Tim...) : In no way do I believe that anything* this project has accepted from IBM or any other contributor has been created under conditions that are not clean room, fully acceptable to the project, or in any way put this project or it's users in any risk whatsoever. My point is - which I appear to have stated in a way that is unfortunately both unclear and too strong, thus further confusing the message - that the process that we have created is a set of guidelines for both contributors as well as us, and we always have the freedom to adapt to exceptional or unusual circumstances, and I support doing that as long as we always keep with the intent of the project cleanroom goals, and understand and make intelligent decisions about risk along the way. geir * Ok, there was that issue with the two files in JCHEVM, but that's been resolved to everyone satisfaction - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Paulex Yang
GREAT! Congratulation, Paulex! :) 2006/7/17, Geir Magnusson Jr [EMAIL PROTECTED]: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [announce] New Apache Harmony Committer : Paulex Yang
Congrats, Paulex Yang! On 7/17/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
RE: [announce] New Apache Harmony Committer : Paulex Yang
Good job, Paulex! Congradulations. Dan Lydick [Original Message] From: Geir Magnusson Jr [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 7/16/06 6:36:24 PM Subject: [announce] New Apache Harmony Committer : Paulex Yang Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - 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]
