| Re: [epp-dev] 2020-12 - Retrospective |
On Wed, Dec 16, 2020 at 5:29 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:Yes - we can launch each EPP package and error the package if there are any errors in the output. We can also install the previous R build and do a check for updates and install updates. I don't know how hard it is to automate any of that, but it seems feasible enough.How much time do you estimate such a check would have saved during 2020-12 ?
However that wouldn't have detected the problem in 2020-06 as that was done to a bad MANIFEST.MF allowing for illegal OSGi wiring which eventually leads to a ClassCastException or NoClassDefFoundError because of the wiring, but those don't show up until that particular piece of code is exercised, which is not feasible to automate checks for. (In this specific case it only happened once a user tried to connect to a Jenkins server with the Mylyn Builds view.)OK, so there is such a class of issues we cannot do much about and that are expensive to identify and fix...I think that is reasonable for cases that I can't track down quickly enough. So far the cases have been either easy (like recurring EMF Parsley problem) or affect all packages anyway.OK. It's more up to you then: the strategy depends on how you want to distribute smaller work items while taking care of the "big picture".
- Updating the N&N links in the epp.website.xml files. This activity ends up serving two functions, first is I collect all the relevant N&N links into epp.website.xml, but secondly I end up reviewing the state of simrel. There are currently 18 unique N&N links, but I had to send emails out to 4 of the projects because their N&N links were somehow broken (e.g. simply 404, or fully missing PMI entry). This is improved in one of two ways - 1. all projects have a generic N&N entry, like wwd[1] or 2. use the Eclipse web API to automate this step[2], but that would require projects to still have up to date N&N links.Do you think we should keep those N&N info for individual packages? There is a N&N aggregated for all SimRel projects, isn't it enough? Do you need this "intermediary" grain between SimRel and projects? Would it hurt of we get rid of package specific N&N links?
The N&N entries are the ones from the simrel that are relevant, but I am skeptical of how useful they are. If we replaced the link to the global simrel one that may be more than enough. For reference I am referring to the links in the red box in this screenshot. This page is linked to from the "details" link in the Eclipse Installer tooShould we open a bug for this specific proposal and suggest on this mailing-list that other EPP committers join the discussion?
If we published snapshots to download.eclipse.org directly it would save 30+ minutes. The build already has to archive the artifacts which takes time and that time could be removed and the promotion would be simply a "mv" instead. I have had looking into this on my todo list for a while. Until quite recently (2020-12 M1) the mac notarization was the biggest bottleneck, for 2020-12 M2 I fixed that so it runs in ~20 minutes instead of the nearly 2 hours it used to take. I fear once we get moved to JIRO that all these times will get worse due to the containerized structure, so if I haven't fixed it by then I will be fixing it once we are on JIRO.OK, good to know; and I agree it's them better to wait for the move to JIRO?Do we already have some estimate date of when that should be taken care of? Should we eagerly ask for the migration to start on early January so we have more chances of being done for 2021-03 M3?
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epp-dev