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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev