Mickael,
Comments below.
On 30.06.2018 13:26, Mickael Istria wrote:
Hi Ed,
Thanks for those very valuable additions to the discussion.
On Sat, Jun 30, 2018 at 11:07 AM, Ed Merks <[email protected]
<mailto:[email protected]>> wrote:
Probably the worst case would be if the user's home folder name
has spaces "C:\Users\john doe", but I suppose that in (almost?)
all cases the user could choose to install to a location without
spaces and in all cases the user can update MPC from a specific URL.}
In any case, the combination of "I install to a disk location with
spaces" (which is generally always a bad idea because something
is bound not to work properly because it's not been tested) with
"I actually use MPC" is probably relatively small, but who knows.
Several users were hit by this on the hours after the release and
reported the bug. Although it does affect only a minority of users,
it's still a critical issue IMO and we shouldn't try to minimize it in
this discussion.
I'm certainly not trying to minimize or trivialize the problem. After
all, we don't have any actual statistics on which to base a truly
informed opinion. I know Oomph had problems in the past with
installations with spaces in them, so I sympathize fully that such an
issue is easily overlooked.
Maybe the conclusion will just be "we acknowledge that it's critical
but didn't want to release the fix off-process" or maybe it'll be
"let's do a respin", but the issue remains critical in both cases.
There's certainly a lesson to be learned when respins are generally
refused though. But in this case the user will need to explicitly
install the update, as Carsten pointed out, because MPC is not a root
feature amenable to updates. I tested to confirm that, and that does
seem a far-less-than-ideal workaround. So from such a user's point of
view its certainly a major problem, and perhaps major problems for many
users becomes a critical problem for us...
Given we are no longer in the business of providing update
releases, to me it's a slippery slope to me if we start respinning
releases to publish multiple releases. My knee jerk reaction is
to vote -1 on a respin.
That's a very valid point. And I agree we shouldn't have a "respin" but...
Yes, that's why I said "knee jerk" because I realize there's always room
to consider exceptions to the rules (which of course lead on a downward
slope)...
Certainly the decision of whether we will do respins affects the
decision of whether http://download.eclipse.org/releases/2018-09
<http://download.eclipse.org/releases/2018-09> for the September
release can be a simple repository because there can/will never be
updates versus whether it should be a composite to accommodate
arbitrary/possible respins.
... what about publishing a respin labelled as 2018-07 ?
Indeed that's a possibility. Though in this case, we'd probably better
just stick to a composite with generally a single child. The Oomph
Product Catalog has to point at something, and it would seem strange
that the 2018-09 product version actually points at a 2018-10 p2 repo.
In the end, I think there are other approaches than a respin that
would help minimize (and in many case eliminate) the problem.
What do you think is the main point that would make a re-build of
SimRel with newer MPC worse than adding a composite or similar things?
Given Cartsen pointed out that MCP is not a root feature, adding to the
composite will not make Check for Updates work, so it's a moot point.
Of course the main point is that adding a repo to the composite would
take 5 minutes, but if you factor in all the overhead for all the people
involved in producing the packages, testing them, and making them
available to the public, it's hard to calculate the number of person
hours involved.
Is this a process issue, or a technical pain point?
Well both. One process issue is the exception process and the other
technical issue is how many people suffer how much technical pain each
time there is an exception?
It would be interesting to make SimRel build/respin/release so trivial
that we shouldn't even have to think about alternatives for such cases.
Indeed, if we could push a button, and all the repos and packages would
created, and of course installed and fully tested, the technical pain
points would be minimized.
Of course the only/main pain point for me personally is if/when the
Oomph Project Catalog needs to be updated (regenerated). Everyone just
forgets about that aspect of the release process because I quietly do
that in the background. When I do encounter problems, the response can
be somewhat underwhelming:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536248
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536249
Should I personally care that Rust has no pretty branding icon in the
installer? Well, I do care actually, but what can I do...
Cheers,
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
