0.2 release is nigh! Last action items coordination

[jpfr]

Hey there!

0.2 is feature complete. The last CTT tests of the implemented features are green. Can we have a list of open points and who is working on them?

The following issues need a fix / wontfix / wontfix now decision

• [x] #666 Multiple subscriptions broken?
• [x] #660 Retransmission queue keeps growing when no acknowledgement is received 0.2
• [x] #655 stress test causes loop (in client or server)
• [x] #632 The first session GUID is always the same
• [x] #509 Verify tutorials

Verify / Update release packaging

• Do we want to distribute the PDF documentation in every zip?
• Should we have a single-file release zip with the header + source + pdf docs?

Update copyright header year

• And update the AUTHORS file

Write the release statement

Please add your open points to the list. And add yourself to assignments. :+1:

[ichrispa]

Don't quite agree with you here @jpfr. There are a lot more points on the todo list and I want to stress that Assignees are the ones who broke features, then made them experimental instead of fixing them.

You'll get a full list tomorrow.

[jpfr]

Ok. Now is the time.

As said before, the best way to protect against regressions are unit tests. CTT and unit tests are all green. Let's take the opportunity and add some more tests where you experienced breakage.

[ichrispa]

OK, mostly done.

Sry for being a bit pissed off @jpfr; the stricter typeDef handling managed to break a backend generator (in addition to the namespace compiler) that tied into several projects. That caused quite a bit of havoc and a lot of work.

We have the namespace compiler back. Before 0.2, I would like to get that one out of the experimental category. Generating complex object models based on NS0 and Di/FSI is quite a common use-case for me.

• [ ] Make namespace-compiler none-experimental
• [x] Re-Add Travis builds against full generated NS0 (check duplicate nodes in server, propper dataType tree)

I also expanded/fixed instantiation as current projects are heavily based on complex information models. Here's what is covered at the moment:

• We can instatiate object nodes from typedefs (obviously)
• We can instatiate superTypes (inheritance) along with objects:

Type:
+ MamalType
   v- Class = "mamalia"
   v- Species
   + DogType
      v Name

Instance of Dog:
+ Dog
  v- Class = "mamalia"
  v- Genus
  v= Name

• We can mask superType attributes

Type:
+ MamalType
   v- Class  = "mamalia"
   v- Species
   + DogType
      v- Species = "Canis"
      v- Name

Instance of Dog:
+ Dog
  v- Class  = "mamalia"
  v- Species  = "Canis"
  v= Name

• We can do both of these things in nested variable and object definitions, which are merged in the instance

Type:
+ MamalType
   v- Class  = "mamalia"
   v- Species
   o- Abilities
       v- MakeSound
       v- Breathe = True
   + DogType
      v- Species = "Canis"
      v- Name
      o- Abilities
         v- MakeSound = "Wuff"  
         v- FetchNewPaper           

Instance of Dog:
+ Dog
  v- Class  = "mamalia"
  v- Species  = "Canis"
  v- Name
  o- Abilities // Merged nested definition
      v- Breathe = True // Inherited in nested object from SuperType
      v- MakeSound = "Wuff" // Overwrite/Mask SuperType
      v- FetchNewPaper // Add to superType

• [x] Add tests for instantiation scenarios
• [ ] Expand on documentation to cover these mechanisms in more detail

I did actually violate the API freeze... The API did not offer any way to add typeDefs to variableTypeNodes. Since the instantiation heavily relies on them now, I thought it would be propper to match up the API to addObjectNode and addVariableNode by adding a typeDef nodeid to the addVariableType call. If that is a gamestopper to anyone, I am sure I can find a workaround.

As a closing remark, I would like to propose drafting up a development guideline that allows us to actually agree on a strategy on when tests or features may be modified. That way we can guarantee that critical features are not accidentally broken or testcases adapted to work with changes.

We should also regulate our commit/merge strategies as we appear to be handling them quite differently. For example, at the moment we mostly commit straight to the 0.2 branch - intuitively I would suggest development to focus on master with regular merges to 0.2 (or other tags) up to a release. We should agree upon whether we want to work with pull requests on a global scale (allowing all devs to inspect/approve changes prior to commit) or push straight to the master branches.

What's your take on regulating commit strategies and sticking to a testcase scheme that guarantees features not being accidentally modified into oblivion?

[Pro]

Just a sidenote to the workflow/merging strategies: I would suggest agreeing on one of the default Git Workflows. There are some described here: https://www.atlassian.com/git/tutorials/comparing-workflows

I personally prefer Gitflow (http://nvie.com/posts/a-successful-git-branching-model/) and naming convention using slashes (e.g. hotfix/some_bug, feature/my_new_feature) but there are of course other ways to organize the branches.

An additional non-critical TODO for the release:

• [x] It would be useful if the main webpage includes a table with all the OPC UA features supported and not supported by open62541. Maybe also a comparison to other SDKs?

[jpfr]

@Pro We had a lengthy discussion some time ago and settled on the following:

• we make the current stable-release branch the git default branch so users see it first (currently 0.2)
• everything that happens on 0.2 until the release is merged into master as well
• after 0.2, new development happens only on master and bugfixes are cherry-picked on 0.2

I like the idea of havon hotfix/feature/... prefixes. Old issues get buried after some time. Can you make a sensible list of them and add suggestions to the wiki?

[Pro]

@jpfr I added the git workflow to https://github.com/open62541/open62541/wiki/Git-Commit-Hygiene Please edit if required.

[ichrispa]

Hey @jpfr, Hi @markusgraube,

as discussed using old-fashioned telephony methods, I have added the Collective Code Construction Contract to our wiki. It's contents are of course up for discussion.

The goal here is to regulate our development ecosystem a bit more formally than we have so far. We have reached a stage in our projects evolution where we are no longer developing a small, academic project for the benefit of a hand full of researchers. Not only has open62541 been a driving element behind numerous projects and cooperations, it is also beginning to find its way into more commercial applications and production use.

It is vital for the continued collaboration on this projekt that all stakeholders be assured that their interests are served. A contract should serve as a basis for stakeholders to steer the development and evolution of this project.

I would very much encourage the creation of a more organizational hierarchy to seperate the roles of "Developers", "Maintainers" and "Administrators"; with active members of the project falling into those categories. I don't feel the current contract does a good job at it yet. For example, if we end up having a developing maintainer being an administrator, we have basically let someone hijack the project...

I would propose @Stasik0 and @uleon taking up the role of project administrators, as they were involved in founding the project. This appointment doesn't imply developing, merging or otherwise maintaining code.

Looking forward to your comments,

Best regards,

ichrispa

[jpfr]

Hey @ichrispa,

nice one. Giving formal roles to trusted persons with long-term involvement is a good idea for transitioning from a founder-run to community-run project. So far, the bulk of work was done by a handful of committers. A quick look in the Graphs tab reveals clearly who they are. Now, many of the founders / core developers will have obtained their PhDs in the foreseeable future. Some, e.g. @Stasik0, have already transitioned to a position where they cannot easily contribute from within their new organization. So +1 for the community contract. The C4 is a good starting point.

To me, the purpose of a community contract for open62541 can be expressed in a single sentence:

Ensure that the project converges to an infrastructure technology

Convergence OPC UA now is a complete and stable (modulo pub/sub and some details) standard. As an open source project we implement the stable standard and don't have pressure to add shiny new features every year for our sales prospectus. That means, at some point open62541 will be effectively done.

The old masters show us how effectively done can be achieved. Just have a look at the version history of [1]. However, many projects that could at one point be effectively done never are. They instead become a big-ball-of-mud [2] where you can only add more mud to the outside as the internal workings are so complex and unstructured that nobody dares to touch it. Then, some years and technology-cycles later, these projects are lost in time.

But we should not confound convergence with frozen API. As long as we add features (that are not 100% orthogonal to the existing ones), we need to be able to adjust to keep a sensible architecture. Otherwise, the same "add more mud to the outside" effect kicks in. Still, API changes between major versions should be kept to a minimum.

Infrastructure Technology The projects I am doing in my organization today achieve in their first week what projects 3 years ago defined as their final project goal: flexible connectivity. That means we have freed ourselves from a big bottleneck that was the same for every project and we can now focus on the "actual work". However, industrial users don't do researchy throw-away implementations that need to run just until the final project demo. So we also use commercial SDKs where appropriate.

In order for open62541 to become an infrastructure technology (that always works and that you don't have to think about), we need to be absolutely reliable. Currently, users need a lot of time just to figure out which features are usable for them, let alone reliable. Some parts of the library are still kinda half-assed. For example the client is not on par with the server and has no async service calls. It should be absolutely clear what the state of which component is. And there is a big difference between "works" and "works absolutely and always". The currently open issues don't exactly shed a very good light. That said, the core of open62541 is already a delight to work with. And we are getting better and better overall in terms of quality and reliability.

Closing thoughts +1 for the suggestion of @Stasik0 and @uleon as patrons aka Administrators. But I'm not sure whether @Stasik0 is allowed to take on such an "official" role due to obligations towards his employer.

Just enumerating the stuff that is already developed but has not landed:

• 0.2 Release (just a few more issues to close)
• Nodestore plugin (done by @JGrothoff including things like a SQL node backend)
• Encryption (basically finished at IOSB (but not from me), demos run clean, ETA for PR in spring)
• Fine-grained user access control (plugin API already landed on master)
• mDNS for discovery by @Pro

Once we have those features landed and a community contract, we are in a really good position to less rely on the project founders (that might not be there forever, including me) for developer work. But keep in mind that we should try to achieve convergence, hence not have to rely on any developers in the long term. 😄

[1] http://tug.ctan.org/systems/knuth/dist/tex/tex.web [2] https://blog.codinghorror.com/the-big-ball-of-mud-and-other-architectural-disasters/

[jpfr]

Addendum: Also the mDNS discovery work of @Pro needs to be mentioned!

[HolgerJeromin]

Will be the licence change part of release of 0.2?

[FlorianPalm]

Yes!

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.