Re: Merge policy for the 1.6 branch

[Michael Dürig]

On 10.04.17 17:59, Michael Dürig wrote:


Hi,

I think we can get a consensus on the following statement:

"Back ports bear a certain risk of introducing regressions to otherwise 
stable branches. Each back ported change should be carefully evaluated 
for its potential impact, risk and possible mitigations. It is the 
responsibility of each committer to asses these and ask for advise or 
reviewing on oak-dev@ if uncertain. Whether using RTC or CTR is up to 
the committer."


I will add a statement along these lines to the "Participating" section 
of the Oak documentation unless there are further objections.


Done http://svn.apache.org/viewvc?rev=1792601=rev

Michael


Michael


On 14.03.17 11:59, Michael Dürig wrote:


Hi,

Following up on Davide's release plan for Oak 1.6 [1] we should define a
merge policy for the 1.6 branch. I would suggest to be a bit more
conservative here than we have been in the past and ask for reviews of
backports. That is, announce candidates on @oak-dev mentioning the issue
reference, potential risks, mitigations, etc. I don't think we need to
block the actual backport being performed on the outcome of the review
as in the worst case changes can always be reverted. The main aim of the
announcement should be to increase visibility of the backports and
ensure they are eventually reviewed.

In short, announce your backport on @oak-dev and ask for review. If
confident enough that the review will pass anyway, go ahead but be
prepared to revert.

I think this is what we informally did so far already but wanted to
state this a bit more explicitly.

WDYT?

Michael



[1]
https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E 

Re: ObservationTest with Thread.sleep()

[Stefan Egli]

Hi Marcel,

IIUC then the sleeps are used to check for expected *and* unexpected
events. The expected part could be easily replaced with a busy-check loop.
The unexpected part is a bit more tricky though, but the test could be
rewritten to be more of a white-box test where not only both ends are
tested but also the middle (observation queue) part, that would work.

So I guess yes, the sleeps could be avoided - with a bit of effort though.

Cheers,
Stefan

On 25/04/17 10:56, "Marcel Reutegger"  wrote:

>Hi,
>
>there is a test in oak-jcr
>(org.apache.jackrabbit.oak.jcr.observation.ObservationTest) with many
>Thread.sleep() calls. This means, the test mostly sleeps and slows down
>the build. What's the reason for those sleeps and can we somehow remove
>them?
>
>Regards
>  Marcel

ObservationTest with Thread.sleep()

[Marcel Reutegger]

Hi,

there is a test in oak-jcr 
(org.apache.jackrabbit.oak.jcr.observation.ObservationTest) with many 
Thread.sleep() calls. This means, the test mostly sleeps and slows down 
the build. What's the reason for those sleeps and can we somehow remove 
them?


Regards
 Marcel

Re: Dangling Java 8 Maven profile!?

[Francesco Mari]

+1

2017-04-25 9:08 GMT+02:00 Michael Dürig :

>
> Hi,
>
> After OAK-5664 moved us to Java 8 I believe we can remove the java8 Maven
> profile as well [1].
>
> Michael
>
> [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-pare
> nt/pom.xml#L960
>

Dangling Java 8 Maven profile!?

[Michael Dürig]

Hi,

After OAK-5664 moved us to Java 8 I believe we can remove the java8 
Maven profile as well [1].


Michael

[1] 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-parent/pom.xml#L960