Ah. I was unaware of that bug (and the gerrit) or the fact that the structure was introduced to solve it.
But reading through the bug comments, it is still unclear why are there any features "outside", in particular the Papyrus-RT Compare and Migration features.
Furthermore, I do not understand the solution. The "top-level" feature adds the requirement of the Papyrus perspective, and as per Camille's comments, it's installable to all users. Then the "Papyrus-RT All" feature (I still think that's a terrible name, if it doesn't include *all*), includes the profile, core, common and tooling features, and apparently it's "[...] separately installable for tool providers". Why tool providers? This contains *the* stuff that end-users install.
In any case, if I (as a user) go to "Install New Software..." and point to the update site and I select "group items by category", I see two: "Papyrus-RT Codegen" and "Papyrus-RT". The first contains codegen, runtime and textual. Here's the first confusing issue: why is "codegen" not included in the other feature? Is codegen not part of Papyrus-RT? The second feature (i.e. "Papyrus-RT") contains everything else, including a nested "Papyrus-RT Feature" which is *very* confusing. The user might wonder "what's in this one? which should I choose?". If I unselect "group items by category", I see "Papyrus-RT All Feature", which will not include all. As an end-user, I would say that is a terribly confusing experience.
I think the most important stakeholder is the end-user.
So the top-level feature seems to resolve the perspective issue. But it doesn't explain why other features lie outside. If the structure is to remain in place, couldn't we at least change the name of the "All" feature? That is *really* confusing.
(Unfortunately Christian is on vacations, so he cannot comment as to why he proposed to call it "all".)
--
Ernesto Posse
Zeligsoft
Hi,
As Camille indicates, this new feature structure was introduced to solve
bug 494931. Regarding the naming of the new nested feature it was discussed in the related
Gerrit change. As can be seen fromt the patch sets this new feature was actually named "base" initially (in patch set 1), but Christian opposed and Camille changed it to "all" (in patch set 2) based on Christian's input. On the other hand, Christian did oppose to the new nested feature itself.
Personally I think it is a little bit too late in the release cycle of 1.0 to start discussing the feature structure. We have had these discussion on and off numerous times on this mailing list, including a discussion if/how we are going to support advanced users to install using the ordinary "Install New Software..." menu in Eclipse which we so far never really have provided a good support for.
I would also like to understand who are the main stakeholders and what are the driving forces behind the different proposed feature structures? The driving force behind this change was a tool smith that was authoring an Oomph setup file. Which stakeholder in mind do we have for the different proposals? Tool smiths authoring Oomph setup files? Advanced end-users using "Install New Software..." (which we don't really support in a good way anyway)?
If we are considering the latter, we also have the aspect of how we categorize the features (so far we seem to only have focused on the feature structure and how it looks like *after* you actually have made the installation). To my understanding this new "all" feature is not even categorized, and thus does not even show up when using "Install New Software..." when you have the "Group Items by Category" enabled. And we other aspects when it comes to categories, e.g. why do we have a separate "Codegen" category where codegen, run-time and textual are placed? And only one "top level" for category for everything else (expect this new "all" feature then).
So at this stage of the release cycle, I would go for option 5, i.e. status quo. Regarding whether it shall be named "base" or "all" I really don't have any strong opinion. Maybe Christian who objected to the initial name of "base" on the Gerrit change should give his view regarding this.
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev