Hi Mickael and all the other people who worked hard to get to this point, This is great, well done! I had a look at the gerrit and it is quite nice. It certainly looks familiar. And despite my concerns listed below, moving to Tycho seems fairly obviously the way forward.
There are a few questions I have: - B3 is split into multiple files, this Tycho solution has everything in a single file (two actually, pom.xml and category.xml). This has two disadvantages: 1. Merge conflicts - this is probably not such a big deal as the tycho validation seems very fast (2 minutes!). 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? - 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? - 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. BTW I don't know what other features of b3 may be important - but I don't know what this was: "sending emails for example wouldn't be available anymore." That is something I have not heard of. Thanks, Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Tue, 10 Nov 2020 at 10:43, Mickael Istria <mist...@redhat.com> wrote: > Hi all, > > With a recent patch, Tycho has achieved a major milestone that allows it > to be a viable replacement to build SimRel repo in place of the very > specific CBI aggregator. Specifically, Tycho now can validate a build plan > without downloading all artifacts, so it can allow the Gerrit patch/CI > feedback short feedback loop. > > The principle and benefits of this change consists in getting rid of CBI > aggregator specific files, models, builders... which no-one beyond a few > privileged (?) ones know how to deal with. By moving it to more mainstream > and better known Maven+Tycho+category.xml stack, we allow more people to > participate in the maintenance of the SimRel aggregation; and we also get > rid of one brick to maintain (CBI aggregator) in favor of a well maintained > and active one (Tycho). This will overall result in some resources saving > and SimRel entry-barrier being much lowered. > Of course, there are some features of CBI aggregator that don't have > equivalent in Tycho, and the other way round; sending emails for example > wouldn't be available anymore. But times have changed since the > introduction of CBI aggregator (called b3 back then): CI rose, Code Review > rose, all this DevOps things basically matured and has brought solutions > for the use-case that were directly supported by b3. Not so objectively, I > don't know of any feature of CBI aggregator for SimRel build that we would > really miss when moving to Tycho. I don't the replacement this will either > increase difficulty of contributing to SimRel or to maintain it. > > This Gerrit patch shows it in action > https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170553 . > You see it adds 1 category.xml file with the content of SimRel, and the > list of p2 repositories in the pom.xml. > > I think all that stack is mature enough, and the value/savings in changing > to Tycho is compelling enough to consider this migration for 2021-03. > > Cheers, > -- > Mickael Istria > Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> > developer, for Red Hat Developers <https://developers.redhat.com/> > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
