Do we have a bug to make MPC a root level feature for the EPPs? Seems like a good idea.
Ed Merks <[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]> 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 [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://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
_______________________________________________ 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
