Re: [cross-project-issues-dev] Fwd: Change 73676 insimrel/org.eclipse.si

[Ed Willink <ed@xxxxxxxxxxxxx>]

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