We are not talking about weakening them on Jenkins though. It won't wait till
release time, it will be caught 10 min later by Jenkins.
But if we can make it faster and keep all the checks, then by all means!
Mark
Sent from my iPhone
On Dec 4, 2012, at 12:23 PM, Robert Muir <rcm...@gmail.com> wrote:
> I think the slowness problem can be fixed way easier than that.
>
> Actually in my opinion the main bug is the speed of building javadocs
> themselves. Today this requires lots of building of useless jars and some
> other things that are unnecessary.
> I also think javadocs for a module get "rebuilt" across the whole thing
> because they are depended on by some other module's javadocs, and so on.
>
> I really don't think the checks should be weakened in any way. These checks
> are necessary (people will complain about them at release vote time, so we
> have to keep the codebase in good order and not just all make a mess for
> months, waiting for some RM to clean it up).
>
>
> On Tue, Dec 4, 2012 at 3:16 PM, Steve Rowe <sar...@gmail.com> wrote:
>> I think one useful middle point might be to only run checks on modules that
>> have pending changes. Yes, as Hoss points out, an unchanged module's
>> javadocs might no longer work (etc.), but I don't think that's the common
>> case.
>>
>> On Dec 4, 2012, at 3:00 PM, Mark Miller <markrmil...@gmail.com> wrote:
>>
>> > Well perhaps there is a middle ground - 'quasi-precommit' that just checks
>> > fast stuff per module… (eg doesn't build all the javadocs)
>> >
>> > Then we would catch more, but perhaps not everything.
>> >
>> > Precommit is scary slow and if it's so slow no one will use it, it's
>> > almost not so helpful.
>> >
>> > - Mark
>> >
>> > On Dec 4, 2012, at 11:53 AM, Chris Hostetter <hossman_luc...@fucit.org>
>> > wrote:
>> >
>> >>
>> >> : I'd really love to have a per-module "ant precommit".
>> >>
>> >> That's not really viable is it?
>> >>
>> >> small tweaks in one class might leave everything fine and dandy in that
>> >> module, but another module that depends on it could break as a result (eg:
>> >> removing a method/variable that is {@link}ed to, etc...)
>> >>
>> >>
>> >> -Hoss
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>
