Hi
Contrariwise, surely this is a classic example of why precise
feature bounds are bad?
- <features
name="org.eclipse.mylyn.github.feature.feature.group"
versionRange="[4.4.0.201605250940-rc1]">
+ <features
name="org.eclipse.mylyn.github.feature.feature.group"
versionRange="[4.4.0.201605252217]">
If the consumption range was perhaps
versionRange="[4.4.0,4.5.0)" or versionRange="[4.4.0,4.4.1)"
the build wouldn't fail every time another project is excessively
tidy. Whether Gerrit traps this problem is pot luck; AFAIAA Gerrit
does not control/observe deletion of P2 repositories.
One of my contributions failed
(https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/491/changes)
because BIRT had deleted its RC1 repository. The subsequent build
succeeded once BIRT's RC2 repository appeared.
Ensuring that contributions are reasonably stable (last two
milestones / release candidates) seems a minor requirement, not
suggestion, for SimRel participation.
Regards
Ed Willink
On 26/05/2016 01:12, David M Williams
wrote:
> ... Does anyone know why, or how to fix it?
My EGit contacts have not responded to my mail.
Or
a classic case of "committing, then going home" :) Or at least
a classic case where a Gerrit submission would have helped! It
would have
caught the problem easily and prevented it from getting in the
way of others.
[I have seen that several times today, folks -- for all you
who don't routinely
use Gerrit -- please do!]
I've taken my "best guess" as to what they
intended. If my guess was wrong, they'll have to tell us that
later, I
guess.
Thanks,
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev