Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] About optional +1 (was Re: EPP 2020-09 RC2)



On Fri, Sep 11, 2020 at 2:25 PM Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:
The reasons this was changed is because everything was manual in the past and this caused additional manual work, confusion and delays often leading to missing packages on the download page.

Yes, and it changed from 1 mandatory check on every milestone to 0 check across several releases. It think it was a bit too much, as 0 check isn't enough to ensure a minimal quality.

The source of (most) packages is the simrel repo.

The EPP build itselfs has a lot of things that could go wrong and pass the build (preferences and other things), but that are not at all included in SimRel. Even if we had 100% coverage of SimRel combinations, it would mean that we'd have less than 100% coverage of EPP.
 
It's generally in good state. [...] a few issues requiring a re-spin. As far as I remember those have been detected by project teams but not package maintainers and reported via simrel.

Although SimRel builds all together, it doesn't mean that things integrate well together and there is about no-one systematically checking the consistency of SimRel at execution. What for example in SImRel guarantee that eg. Wild Web Developer and EGit do work well together? And even so, what guarantees that in an EPP package, with some possible different preferences, those would work well together?
We had cases some time ago of guava making LSP4E and Mylyn fail in some EPP packages and not others (depending on the load order, one was failing or the other). SimRel didn't detect it, typical contributors for Wild Web Developer who don't use Mylyn in their IDE would have detected it. Some manual testing of EPP would have at least allowed to spot the issue (not guarantee it would be spot, but at least making it possible to be spot).

Note that I'm not asking for a +1 for all milestones, but to me, shipping something so movable as an Eclipse distribution without someone to just give it a try and report satisfaction before the release is the poorest QA possible and can lead to terrible results.
I agree skipping checks has saved time to everyone, I agree it's very helpful for the milestones. But all serious products do require at least one person to feel confident about its quality before release, and the current EPP process doesn't mandate that. If some packages don't have the sufficient support to find someone to test them and send a +1 once every 3 months, maybe it's a sign that they should be retired.
--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers

Back to the top