|Re: [cross-project-issues-dev] MPC not opening with space in install path - requesting respin|
On 30.06.2018 13:26, Mickael Istria wrote:
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.Hi Ed,
Thanks for those very valuable additions to the discussion.
On Sat, Jun 30, 2018 at 11:07 AM, Ed Merks <ed.merks@xxxxxxxxx> 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.
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...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.
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)...
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...
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.
Certainly the decision of whether we will do respins affects the decision of whether 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 ?
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.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?
In the end, I think there are other approaches than a respin that would help minimize (and in many case eliminate) the problem.
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?Is this a process issue, or a technical pain point?
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.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.
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:
Should I personally care that Rust has no pretty branding icon in the installer? Well, I do care actually, but what can I do...
_______________________________________________ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top