We do now: https://bugs.eclipse.org/bugs/show_bug.cgi?id=536583
I had this on my todo list for post-Photon regardless of this issue, but was holding off until this is sorted, as not to create the impression that I was asking for this change as part of the respin. Best, Carsten -- +49 (0)69 2475666-33 | [email protected]<mailto:carsten%20reckord%20%[email protected]%3e> | www.yatta.de<http://www.yatta.de/> Lead Software Architect & co-founder Yatta Solutions GmbH c/o WeWork · Neue Rothofstraße 13-19 · 60313 Frankfurt a.M. (Germany) Registered Seat: AG Kassel, HRB 14720 · VAT-ID DE263191529 · Managing Director Johannes Jacop ________________________________ From: [email protected] <[email protected]> on behalf of Lars Vogel <[email protected]> Sent: Monday, July 2, 2018 10:58:11 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] MPC not opening with space in install path - requesting respin Do we have a bug to make MPC a root level feature for the EPPs? Seems like a good idea. Ed Merks <[email protected]<mailto:[email protected]>> schrieb am Sa., 30. Juni 2018, 14:18: 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 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]<mailto:[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]<mailto:[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
