Re: [cross-project-issues-dev] SimRel 2019-09 Repository Quality

[Ed Merks <ed.merks@xxxxxxxxx>]

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