Mickael,
Comments below.
On 02.09.2019 10:30, Mickael Istria wrote:
Hi Ed,
Some similar (yet different) reports already exist in
https://download.eclipse.org/releases/2019-09/201907191000/buildInfo/reporeports
and some of the issues you mention have already been reported for ages.
Indeed, I am aware of those reports. The presentation just makes it
difficult to get a real overview and it is not highly navigable.
The report details for installable units are particularly useful for
figure what depends on what and how it depends on those things. So, for
example, when there are duplicates, one can determine which things rely
on which versions and how specific the range of that dependency is...
The report is also intended to do a deeper analysis of the actual
artifacts as well, i.e., the process already does actually mirrors the
artifacts and ensures they can be unzipped, for example. Ideally I'd be
able to test that native artifacts are properly signed, but I don't know
how to do that yet...
Those reports are generated at build-time for every build, in pom.xml:
https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/pom.xml#n84
Overall, I'm unsure reports have been a successful way to provide
feedback in our community, and think we need something more
"aggressive" to drive us towards higher quality.
Yes, at some point we have to enforce rules. I'm incline, for example
to ask to PMF be removed from the train because I doubt they will be
responsive and are a source of too many problems.
Basically, we need failing builds for erroneous content, and a policy to
But whose builds will fail?
So I'm wondering:
1. Can the Oomph reports be automated in the build just like CBI
report are? If yes, can you please just point to interesting technical
facts like application name and arguments to use?
Certainly the job is super easy to configure:
https://ci.eclipse.org/oomph/job/repository-analyzer/
I tried to minimize the amount of shell script involved...
2. Can the Oomph report application *fail the build*? Ie if someone
submit bad content, can they see a -1 on Gerrit and see their patch
rejected, and see Planning Council warning of a risk of exclusion if
issue is not fixed? The CBI one doesn't AFAIK (and it's a pity)
Not at this point, but someone has already asked for such a thing in the
Bugzilla.
To me, the target is really to have the process 2. implemented, and
all efforts in gathering more data do not deliver the most of their
value, until we have processes to really leverage that data.
I can lead a horse to water, and I can even be the horse and do some of
the drinking myself, but no matter what, the horses in general will have
to do their own drinking
Cheers,
_______________________________________________
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://www.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://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
