|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.
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...
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)...
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.
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.
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?
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:
Should I personally care that Rust has no pretty branding icon in the installer? Well, I do care actually, but what can I do...
Back to the top