Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[Mickael Istria <mistria@xxxxxxxxxx>]

On 01/14/2016 07:46 AM, Eike Stepper wrote:

That looks nice!

Thanks. Would you use such features and start specifying fully-qualified versions in your contributions thanks to them?

I'm a bit concerned, though, that we start to rely on tooling that's no longer actively maintained. For example, for me the editor doesn't work at all anymore (see my post "Simrel: Is the b3 Aggregator Editor broken?") and there seems to be nobody who can help me fix that.

I agree that B3 is probably not the best way forward. However, because of the inertia there is when trying to change the Simultaneous Release process, I believe that we should just all get used to the idea that despite B3 is not optimal, it will remain for a while, and adapt to this idea.
Even if SimRel moves to another technology like Tycho, the issue about fully-qualified versions would be that same, except that it would occur in a category.xml file instead of a b3aggrcon file...

IMHO the main reason to use that editor over a plain XML editor was the poor model/serialization design, in particular:
a) that path-based cross-references (which break easily when features or categories were added and removed) were used over ID-based references, and
b) that bidirectional references were used for Categories <-> Features instead of simple uni-directional references, and
c) that Contact persons are shared across contributions (again with bidi-refs, IIRC).
If the underlying model/serialization was fixed w.r.t. the above issues it would be way simpler to edit the XML directly without breaking the overall model so easily.
I know this is a little bit off-topic, but it demonstrates that this model+editor is not very well maintained. And that becomes a concern if we start to rely upon it.

Have you considered contributing to the B3 editor? Your experience about Modeling would be highly welcome there. (let's assume that the current inactivity in B3 is "transitional" and that B3 will be again an active projects within a few weeks).

Personally I like Matthias' proposal to automate the "version narrowing/fixing" as part of the aggregation.

I dislike automating additional edition out of the user sight. Some reasons: there's a diff between what's tested locally and what's built; users don't see how things are best and are not encouraged to learn the best way to do things, it makes users rely so much on the tool (or build in that case) that it becomes almost impossible for them to make a correct edition without this exact tool... SimRel contributors must see and know what is a perfect contribution. Putting a magic piece of code that turns a crappy contribution to a good one without informing the author isn't going to make contributors understand the purpose of the contribution.
It would be like having FindBugs automatically changing pieces in your Java code at build time. Even many of those who were simply automating code-style as commit hook have stopped doing that because it was causing more pain than fixing issue; imagine if the change is not only style but an actual "payload" change (like it's suggested here)...

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets