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 <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
