[
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
|
Hi
Good: The fewer files should avoid the bidirectional references
that break for non-trivial edits with 'Notepad'. No more newline
anomalies.
The default id's for repositories seem unnecessarily verbose
involving a version that is guaranteed to go stale very quickly. I
suggest that something more like org.eclipse.project.simrel-2021-03
would make a better default that is changed to satisfy the touch
rule.
Regards
Ed Willink
On 10/11/2020 16:20, Jonah Graham
wrote:
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
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.
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,
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cbi-dev