Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] [cross-project-issues-dev] Building SimRel with Tycho for 2021-03

Hello Jonah,

Thanks for having a look, answer inline


On Tue, Nov 10, 2020 at 5:21 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
  1. Merge conflicts - this is probably not such a big deal as the tycho validation seems very fast (2 minutes!).

I think the case of merge conflicts are almost non-existent for SimRel: projects typically modify a few lines, or add a few lines, which are independent from others. Git or even plain diff would be able to merge the various change without pain.
 
  2. Tracking who is paying attention. Until now the rule was touch the .aggrcon file, which then was easy to identify with git log. Is this rule important going forward? I believe so, and if so can we agree on a simple standard for what this looks like? e.g. The <id> of the repository in the pom.xml should have the simrel version that it was contributed for in the id?

We can indeed set up some new convention in the pom.xml file, either with id, or with some comment convention such as <!-- Sign-Off 2021-03: Not there yet --> to be replaced by <!-- Sign-Off 2021-03: mistria@xxxxxxxxxx on 20210112 --> and make the inactive contribution tool report the url of repo for which is just after a "Not there yet" line.
 
- Updating version number ranges. The b3 aggregator has a very useful "fix versions" action that can set all the version ranges quickly and accurately. Is there some way to make this easier with Tycho?

There is no such tool for Tycho/category.xml at the moment; and I think it's mostly a use-case that is related by some existing PDE and m2e (requiring a lot of work though). One alternative would be to implement a SimRel/Tycho specific tool; that would be more affordable. I'll investigate about it.
 
- The gerrit today only has a subset of the parts of CDT that are in simrel.aggr/cdt.aggrcom (the only contribution I looked at closely). AFAICT only the items that are categorized are present in category.xml. Where do uncategorized features end up? Similar question about uncategorized bundles. I could add them all to a new category if needed.

That seems like a bug in the routine that turns the .aggr model to a category.xml/pom.xml pair. I'll fix it.

Back to the top