Obviously we should encourage submission of patches but the committers should remember that tthere are non-committers around who are happy to help get worthwhile contributions in shape!
Perhaps just adding a comment to the JIRI suggesting the submitter provide a patch or ask for help on the list? I've been spending a little time fixing up contributions that I think are worthwhile - mostly patches that have been broken by the recent shared native code moves that Tim committed. I'm willing to do this because I broke them ;-) but mostly because I know it helps reduce the load on committers and because having your patch broken/delayed can be discouraging for new contributors. For me this is a good way to become more familiar with the code base. I'm sure that will be true for others joining the project. I don't think there is any harm in having plenty of obvious tasks for potential new contributors. Our committers shouldn't be slow to ask for help either. For instance, a number of the recent large contributions aren't going to be trivial to integrate in to subversion, but I'm sure there are many people - at least one anyway! - looking forward to seeing them in subversion who would be willing to help create patches [0] from contributions if it helped move them forward. Regards, Mark. [0] More likely a tar with the new files and a patch to existing build.xml files. On 02/03/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > maybe we should reject things not in patch format, as it puts > unnecessary load on the committers. > > Feel free to drop the code into comment or email so that we can discuss, > but patch is much easier for everyone involved.... > > > Tim Ellison wrote: > > p.s. I accept test cases in patch format too ;-) > > > > Regards, > > Tim > > > > Richard Liang (JIRA) wrote: > >> [ > >> http://issues.apache.org/jira/browse/HARMONY-141?page=comments#action_12368097 > >> ] > >> > >> Richard Liang commented on HARMONY-141: > >> --------------------------------------- > >> > >> Here are the test cases which will pass on RI but fail on Harmony. > >> > >> public void testConstructorIlegalAverageBytesPerChar() { > >> try { > >> Charset cs = Charset.forName("UTF-8"); //$NON-NLS-1$ > >> CharsetEncoder encoder = new > >> MockCharsetEncoderForHarmony141(cs, 1.1f, 1); > >> fail("Should throw IllegalArgumentException."); //$NON-NLS-1$ > >> } catch (IllegalArgumentException e) { > >> // expected > >> } > >> } > >> > >> public void testConstructorIlegalAverageBytesPerChar2() { > >> try { > >> Charset cs = Charset.forName("ISO8859-1"); //$NON-NLS-1$ > >> CharsetEncoder encoder = new > >> MockCharsetEncoderForHarmony141(cs, 1.1f, 1, > >> new byte[] { 0x1a}); > >> fail("Should throw IllegalArgumentException."); //$NON-NLS-1$ > >> } catch (IllegalArgumentException e) { > >> // expected > >> } > >> } > >> > >> public static class MockCharsetEncoderForHarmony141 extends > >> CharsetEncoder { > >> > >> protected MockCharsetEncoderForHarmony141(Charset cs, float > >> averageBytesPerChar, > >> float maxBytesPerChar) { > >> super(cs, averageBytesPerChar, maxBytesPerChar); > >> } > >> > >> public MockCharsetEncoderForHarmony141(Charset cs, float > >> averageBytesPerChar, > >> float maxBytesPerChar, byte[] replacement) { > >> super(cs, averageBytesPerChar, maxBytesPerChar, replacement); > >> } > >> > >> protected CoderResult encodeLoop(CharBuffer in, ByteBuffer out) { > >> return null; > >> } > >> > >> } > >> > >> > >>> Constructors of java.nio.charset.CharsetEncoder do not validate arguments > >>> ------------------------------------------------------------------------- > >>> > >>> Key: HARMONY-141 > >>> URL: http://issues.apache.org/jira/browse/HARMONY-141 > >>> Project: Harmony > >>> Type: Bug > >>> Reporter: Richard Liang > >>> Constructors of java.nio.charset.CharsetEncoder should throw > >>> IllegalArgumentException when averageBytesPerChar exceeds maxBytesPerChar. > > > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
