Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] v0.8 release
Hi,

The most important difference between the official build (which are used in the Papyrus-RT installer, if I understood you correctly) and the custom build is that the official build does not include model fragments in the "logical model comparison" if they are available only on the "remote side" in the comparison, e.g. when a user extracted a sub-model in a "remote branch" (i.e., not checked-out branch). In this case, we won't see it in a comparison if using the official EMF Compare & EGit build. In certain scenarios, this may also have a bad impact on the merge (e.g., if the content that has been extracted also has been changed on the local branch). Besides there are a few less critical usability improvements, which would be missing in the official builds.

The good news is that I just completed the integration build and it is now available at the update-sites listed below:
I'll just give them another test within Papyrus-RT until tomorrow and if everything looks as expected, we could switch to these update sites for the Papyrus-RT release stream in the Oomph.

Thanks and best wishes,

Philip

On Thu, Oct 27, 2016 at 3:03 PM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Comments inline below.

/Peter Cigéhn

On 27 October 2016 at 14:53, Philip Langer <planger@xxxxxxxxxxxxxxxxx> wrote:
Hi Peter, hi Charles,

2) We need to get an updated integration build fo the custom builds of EGit and EMF Compare in place. The 0.8 RCP build used the nightly build, and the Oomph end-user setup uses the (too old) integration build (which in its turn casues the Oomph based installation to bring in the non-custom builds of EGit and EMF Compare part of the Neon.1 release). This needs to be aligned, based on updated integration builds. As I understood it from Philip, work is ongoing with providing updated integration builds of the custom builds of EGit and EMF Compare. When that has been provided, we need to update the .tpd-files to use the integration build repos instead.

I'm actually working on the custom EGit/EMFCompare integration build right now. We should be able to publish it next week. Once this is published, the plan is to use the nightly custom build only in the Papyrus-RT nightly builds and everywhere else (integration & release), the integration EGit/EMFCompare build.
 
I haven’t tried the compare/merge feature yet. What is the impact on the user on leaving as is?
Based on this, we can decide to either document the impact (as above, taking advantage of incubation leeway), provide new v0.8.1 installers, or defer to 0.9.

The short-term impact of using the nightly builds is de-facto zero, as the current nightly build is actually the release candidate for the next EMF Compare version and, hence, the release candidate for the custom EGit/EMFCompare integration build. This is also why we suggested to use the EGit/EMFCompare nightliy build until the integration build is available.

Mid-term we want to switch back to the integration build for all integration/stable releases of Papyrus-RT, because the EGit/EMFCompare nightly may get unstable again in near future (as is the nature of nightly builds). The release of the custom EGit/EMFCompare integration build is done manually, so we have full control when to publish it and may do some manual validation before.

I hope this helps. Please let me know if there are any questions!

​I assume the question was not what the difference is between using the nightly custom builds vs the integration custom builds, but the fact that the current end-user setup in the Papyrus-RT Installer produces and installation which brings in the *non-custom* builds of EGit and EMF Compare as part of the official Neon.1 release. This as we know is due to the current integration repo for the custom build are containing too old versions of ​EGit and EMF Compare, which causes the p2 installer to bring the newer versions in the official Neon.1 release (which thus does not contain any of the custom functionality). That as I see it, is what we need to understand in the short term.  

Does it matter for users installing Papyrus-RT 0.8 (using the Papyrus-RT Installer) that they will get the wrong builds (non custom builds) of EGit and EMF Compare? Or can they live with this in the short-term, and simply update their installation once the integration repo for the custom bulids are in place? 

I mean, there must have been a reason why we temporarily switched to using the nightly builds of the custom builds of EGit and EMF Compare when building the 0.8 RCP package/zip-file. I myself have not gotten the faintest idea about this impact, all I can see is that what happens when using the Papyrus-RT Installer at the moment due to the "anomaly" with the current contents of the integration repo.

/Peter Cigéhn
 

Best wishes,

Philip



On Wed, Oct 26, 2016 at 4:33 PM, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
Comments inline below.

/Charles

On 2016.10.26, at 09:54 , Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

​​
Hi,

Comments inline below.

/Peter Cigéhn

On 26 October 2016 at 15:14, charles+zeligsoft.com <charles@zeligsoft.com> wrote:
Regarding bug 505416, I would propose the following (see inline below).


On 2016.10.26, at 03:45 , Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

Regarding 505416 I am not sure how much to keep within the scope of that Bugzilla, and what we shall break out into separate new Bugzillas. Here are a few remaining issues identified during the work with this Bugzilla (and the related one regarding the Papyurs-RT Installer):

1) The version used for Designer needs to be updated (and aligned with the Oomph end-user setup). Rémi provided a Gerrit change, but it was decided to post-pone the merging of that one to post-0.8. See https://git.eclipse.org/r/#/c/83452/
<cr>
Are you sure about bug 83452 (org.eclipse.launchers feature missing linux/motif files) which is from 2005?

​The link is for a Gerrit change, not a Bugzilla. Please follow the link and you will see the Gerrit change the Rémi have proposed related to the update to version 1.0.3 of Designer.
​
 

My proposal:
  • Document the current state of RCP vs. Papyrus-RT installers (i.e., the differences) in the release notes. Could someone write up what these are and their consequences (if known)?
​I think that we first need to decide what to do regarding these three issues I have listed here, before documenting their consequences.
<cr>
If you mean that it is irrelevant in determining whether the bug must be split, then I agree and, as I mentioned in my previous response, I would personally prefer the bugs to be split to provide more flexibility. In general, I find that many of the bugs we have sometimes evolved to include more (sometimes tenuously related) issues than the one for which they were initially created, and it is my opinion that we need to be careful about this in the future.

However, there are deeper needs that need to be addressed now and then, and with all due respect, I disagree that we can look into this later.
Please correct me if my thinking is incorrect, but it is my understanding that since this bug is not closed, there are issues that currently exist in the installers that, even if unannounced, have been provided on the download site. This means that it is possible for people to have access to them and, therefore, potentially run into issues with the tool.
As such, we need to understand the potential issues and these differences and their impact (consequences) based on the various installation methods selected. We need this both to properly guide our users in making the correct choice of the installation process and, more importantly, to manage their expectations once the tool is installed.
Without knowing the consequences of the differences in installation, we cannot properly manage user expectations, which often leads to dissatifaction - even in an incubation setting. We need to, nay must, be proactive in these matters.
This would only become moot if there are no differences in the installations and there are no issues to tell the users. Is that the case?
Knowing the consequences will also help in determining the severe and urgency of required fixes, e.g., do they need to be fixed in a 0.8.1 release? Can they wait until 0.9?


</cr>
  • Consider the creation of a 0.8.1 version with the updated installations that provide installation parity.
We are still in incubation, so I think we can get away with describing the differences between the installer iff we have bugs to which we can point to show they will be fixed. There is already information on the download site and on the Early Adopter wiki page describing the differences in the installation capability, so we can just add to that.
</cr>

2) We need to get an updated integration build fo the custom builds of EGit and EMF Compare in place. The 0.8 RCP build used the nightly build, and the Oomph end-user setup uses the (too old) integration build (which in its turn casues the Oomph based installation to bring in the non-custom builds of EGit and EMF Compare part of the Neon.1 release). This needs to be aligned, based on updated integration builds. As I understood it from Philip, work is ongoing with providing updated integration builds of the custom builds of EGit and EMF Compare. When that has been provided, we need to update the .tpd-files to use the integration build repos instead.
<cr>
I haven’t tried the compare/merge feature yet. What is the impact on the user on leaving as is?
Based on this, we can decide to either document the impact (as above, taking advantage of incubation leeway), provide new v0.8.1 installers, or defer to 0.9.

</cr>

​Regarding the impact of having the older, non-custom builds of EGit and EMF Compare in the Ooomph based setup, I think that Philip and/or Alexandra need to answer. I myself have not tested the compare/merge feature enough either, and especially not trying to compare the behavior with the non-custom builds of EGit and EMF Compare with the latest (nightly) custom builds included in the RCP.

But the "only" thing that is needed, is to ensure that the integration p2 repos gets updated. No need to neither provide a new installer nor provide an updated setup file. Then users can update their installations (I even guess that Oomph might to this automatically if the user does not do a manual update). 
<cr>
OK, this one looks easy. 
What is the impact of this delay on the user? Will the user experience any visible issue before this is fixed?
If so, then there is nothing to do. If there is the potential for the user to be inconveniences, then we just need to have a mention in the release notes that will be “cleared” once the integration repository is updated.
</cr>


And the integration p2 repos is planned to be updated anyway (Philip indicated earlier "within 2 weeks"). We just need to track the work with getting the integration p2 repos updated.

3) The RCP still lacks the org.eclipse.platform.ide, which is part of the Oomph end-user setup, which suspectedly causes the welcome page to go missing in the RCP build. In general we need to provide some contents on the Welcome page as well, which I guess is best to be tracked with a completely separate Bugzilla. 

I guess we at least could include 1) in the scope of 505416 before we consider it to be resolved. 2) and 3) I guess it best tracked by separate Bugzillas.
<cr>
I would prefer splitting the bugs. This gives us more flexibility in determining the individual impacts of these to the current and future releases.
</cr>


/Peter Cigéhn

On 25 October 2016 at 17:05, charles+zeligsoft.com <charles@zeligsoft.com> wrote:
There are still three bugs that need to be closed for Papyrus-RT 0.8 - let’s get these closed!



Status = Assigned:

505416  [RCP and Product] List of missing requirement for the RCP...  Celine.janssens@xxxxxxxxxxx  peter.cigehn@xxxxxxxxx  Celine.janssens@xxxxxxxxxxx  ASSI

Céline: Do you need any help in moving 505416 forward? What is still needed?
The last comment was on 10-21 and was a commit - who can review/test that?

Status = Resolved:

500287 [Releng] Build Process - Unify Codegen structure to be al...  Celine.janssens@xxxxxxxxxxx  Celine.janssens@xxxxxxxxxxx  RESO  2016-09-30

Who can verify this fix?

503065 [RCPTT] Extract Rcptt test from the Product build  Celine.janssens@xxxxxxxxxxx  Celine.janssens@xxxxxxxxxxx  RESO  2016-10-07

Who can verify this fix?


Regards,

Charles Rivet
Senior Product Manager, Papyrus-RT product lead


_______________________________________________
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


_______________________________________________
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


_______________________________________________
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


_______________________________________________
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


_______________________________________________
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

_______________________________________________
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



_______________________________________________
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


Back to the top