Re: [platform-dev] API changes in SDK

[Andrey Loskutov <loskutov@xxxxxx>]

Ed, see my answers below.

On 09.05.2019 10:28, Ed Merks wrote:
> Andrey,
>
> Comments below.
>
> On 09.05.2019 10:10, Andrey Loskutov wrote:
>> Ed,
>>
>> While we use Oomph in the lab (thanks for the tool!), I can't use
Oomph for SDK development,
> Why not?    I've certainly used to to make contributions to the
Platform UI.

Yes. I believe SDK provisioning with Oompf is a great thing and lowers
the entry barrier for the new contributions significantly, and I really
appreciate all the effort spent for automating things with Oomph. As
I've already said, I'm not against Oomph in general - I've introduced
this internally in our lab and maintain our custom Oomph installation,
I've also contributed some bug fixes to Oomph.

So Oomph is great ... for some use cases!

I had few problems with Oomph in the past, and still have it. My biggest
concern and problem is that I want to use new nightly SDK builds *every
day*, but I don't want to have *some* random p2 updated "mix and match"
platform state. p2 never deletes old bundles from the install, only some
non human maintainable config files are updated, and so the updated
installation is a nightmare mix of new and old bundles, where nothing is
as it is supposed to be with a clean installation. Like with every
incremental compile, resulting artifacts state is not reproducible and
depends on the history of previous actions.

We all know how complicated and unpredictable p2 is, and we know that
Oomph adds another extra complexity layer on top of that. I need an SDK
installation that I can trust, because I need to know if that state I
observe is an SDK issue and not some p2/Oomph update issue. I have no
time to run daily investigation what broke the update or why the
installation doesn't behave as expected, clean all the obscure p2/oomph
caches, bundle pools, config files etc. It will simply ruin my daily
work. If I would be Oomph developer, I would for sure do this, but I'm
SDK developer and just want to consume Oomph, not debug it every day.

I write this because of my personal experience. I'm updating our
internal Oomph based installation for our lab every 1-2 months. Almost
every time I deploy an updated update site and test drive the update
with Oomph I observe some oddities, which may or may not be caused by
Oomph or p2 or network or new platform patches - I have no idea because
it is extremely time consuming to debug p2/update troubles, especially
with Oomph extra layer on top. So I can't afford such investigation
*every day*, not even monthly.

>>   and also Oomph leads to problems where occasional change of some
preference leads to the "automatically" wrong setup.
> This is very non-concrete.  I know for example that JDT occasionally
has null pointer exceptions while importing a new project (I see this on
the forum daily), but that's hardly an argument to say JDT leads to
problems so can't be used.

It is not because of bugs alone, I believe Oomph current state is mostly
acceptable (I haven't reported Oomph bugs for a year or so). My biggest
issue with Oomph is that thanks Oomph people don't even know what they
*need* to know, and if they change occasionally some important setting,
Oomph happily remembers that. After all, people have troubles, delete
the workspace (because they know that deleting workspace "fixes"
issues), create new one and Oomph happily applies saved wrong user
settings. After that people blindly do wrong things with the assumption
that everything is properly setup, and if you ask why do they do this,
they answer: "I haven't changed anything"!

Oomph (like any other advanced technology that simplifies our life)
changes developers to consumers. This is OK for a *usual* application
developers or for an *occasional* SDK contributors that don't need/want
to know how they tools are working, but as SDK maintainers we must know
our tools and must know how they work, because if we fail, all the
downstream projects will be affected, including Oomph which will fail to
update your install because the bundle versions aren't properly updated
etc. So I believe it is required for all SDK developers to understand
what API and bundle versions are and how to maintain them. Understanding
it also means to know where to look for and what to do if something is
not working as expected.

>>   Oomph can't fully resolve the "human" factor.
> So I simply don't see the point of a long list of detailed manual
instructions that are only in an email.

I've sent email first because we had some API troubles recently, and
I've updated now wiki to include the notes I've sent. It was just a
matter of free time. See
https://wiki.eclipse.org/Platform/How_to_Contribute#.5B4.5D_Prepare_API_tooling.

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------