Csm merge from main

[rogierc]

Merge head of main into csm branch. Conflicts resolved.

[boaks]

Thanks for your contribution.

From the discussion in issue #2092 I'm not sure, what the right strategy should be.
There was no agreement to maintain this work in an feature branch or separate module.
And with the number of changes I don't think it could be merged into main soon.

As I already wrote, if we agree to put it on a feature branch, we need a shepherd for that branch.
I will not be able to spend that time.

[rogierc]

It's an update to actual state of main. Either way it's a no regret IMHO.

[rogierc]

There was no agreement to maintain this work in an feature branch or separate module.

I don´t understand. The merge request concerns an update of csm branch itself. It does not touch main. This has no relation to the discussion whether csm branch gets merged into main.

[boaks]

I don´t understand. The merge request concerns an update of csm branch itself.

If the csm branch is considered to be developed for a certain time on it's own, then in my opinion the "shepherd" will be responsible for that merge. As you may have noticed, the author of that branch didn't agree on maintaining the work as branch. Without that "shepherd", I don't know, which committer is going to merge it.

Sorry, I know in an other case you asked first about contribution (at that time to main), and I answered it's easier for me to have a PR. This time the point is, you don't ask me, you need to ask someone else.

[rogierc]

As you may have noticed, the author of that branch didn't agree on maintaining the work as branch

I didn't read that. Many is said in #2092 and it seems the discussion got derailed somehow. But, what I read is a lot of agreement and:

With this, I will never be able to integrate it in Leshan. So this doesn't really fit my needs.

So the problem seems not to work in a branch, but to get the tcp feature usable in Leshan.

A solution might be to "release" a californium version built from the branch to Maven Central, e.g. as "3.8.0-TCP-M1". This way Leshan (and Mule CoAP Connector) could benefit from a rfc8323 complient version and the tcp feature can be (alfa/beta) tested without risk to others. In the meantime main can be kept stable and merges of (parts of) changes can be done when considered stable enough. With the intention to get all merged, but paced by the time available to contributors.

This PR concerned - I can't imagine any future "shepard" would object to a branch that´s not too diverged from main. Also, if the branch isn 't expected to get released soon there is little risk in merging, IMHO. That I should ask a non-existent "shepard" to merge, feels a bit Kafkaesque.

The author seems not to object:

feel free to reuse my work if you think it's useful.

I ´m only able to make small contributions. But the idea of open-source is to combine (small) contributions to get the project, forward, isn't?

[boaks]

Kafkaesque

Sure. It's also Kafkaesque to be blamed to run this project as a "one man show". But if it comes to work, only one man is left. As you may have noticed, I changed the job last year. Not that staying at that job would have preserved my time for working in Californium, the opposite is the case. Anyway, I still need to ramp down my efforts.

The branch csm fails to build on my machine. It comes without documentation. the API breaks need to be escaped for the revapi checks. E.g. the csm branch breaks the TLS support. TLS was not considered for the first work, but I'm not sure, if that is considered to be acceptable or will be fixed or whatever is the intention.

But again also here: I need to ramp down my efforts. If others want to jump in, welcome, if not, I don't see, that I can spend my time to shape the csm branch in order to fit common quality standard. We may also lower these standards, but in difference to the past years, I'm not the one who jumps then in to fix it.

Overall:
My strategy is to build products on CoAP/DTLS 1.2 CID in order to finance the work on Californium again.
Therefore my engagement in Eclipse/tinydtls, therefore I started zephyr-coaps-client, and therefore I gave a session yesterday about using cellular devices with Californium.

The last question from my side would then just be:
If you like to became a committer in order to evolve coap+tcp, welcome.
Then I ask the other committers for their agreement, I guess, they will do.

[sbernard31]

It's also Kafkaesque to be blamed to run this project as a "one man show". But if it comes to work, only one man is left

A humble way of looking at this situation would be to ask yourself why you are the only one man left instead of denied the work of others.

[boaks]

There may be many different views on that, I don't share yours.

[boaks]

@rogierc

Sorry again, that you spend your time before asking.
It was Simon, who wrote "feel free to reuse my work" and you need to ask him how to do that. It's also just a few seconds for Simon to merge this PR against his branch. Not sure, if in the end it requires a CQ (more than one contributor, but that's currently in discussion and may be relaxed anyway) and usually we rebase and refactor branches towards main. That provides a clear history, when it finally gets merged.

[sbernard31]

@boaks, really ...
I was pretty clear in #2092, I stop working on this for clear reasons explained at :

• [coap+tcp] Adding Capabilities and Settings Messages (CSM) support  #2092 (comment)
• [coap+tcp] Adding Capabilities and Settings Messages (CSM) support  #2092 (comment)

It was Simon, who wrote "feel free to reuse my work" and you need to ask him how to do that.

It just means, "you can take my code as base if you want to move forward on this"...
That did not mean that I will handle new contribution. I think (I hope) that was clear enough.

It's also just a few seconds for Simon to merge this PR against his branch.

Am I the only one who doesn't understand this ?
Why do you ask to an inactive committer who clearly say he doesn't want to work on this anymore to manage this kind of thing ?
What is the idea behind this ? this doesn't make any sense to me. Even not working with you is complicated 😅

So you are the project lead and the only one active committer.
A contributor ask you to handle a PR about a feature that it seems you consider to be in scope of the project. (At least you didn't say clearly it is out of scope), just handle the situation without involving me.

I just answer to this topic because you triggered me with : " It's also Kafkaesque to be blamed to run this project as a "one man show". But if it comes to work, only one man is left." which clearly target me and totally denies my works....

Not sure, if in the end it requires a CQ

A CQ for a merge request between 2 branch already in Californium repository ? What would be the purpose of this ?

@rogierc good luck for your collaboration on this with @boaks.
(If at the end of this discussion @boaks still considers that I MUST merge your PR and if you want me to do that I can do a blind merge, just let me know)

[boaks]

A contributor ask you to handle a PR about a feature that it seems you consider to be in scope of the project.

As I wrote already last year, December:

"at least I don't plan to spend my time in maintaining that."

And though I'm not aware, that any committer will take care of it, I informed the contributor about that.
If he wants to become that committer, great. If an other committer jumps in, great. If not, sorry.

[jvermillard]

Now that Californium has no corporate sponsors to improve and maintain such a complicated project and communication issues between committers, maybe it's time to move to maintenance mode:

• no new feature
• bug fix release based on the community involvement

I started to work with Californium 3.7 recently, debugging minor issues, and my feeling is that the code is too old, too complex, with an enormous scope (from base CoAP/DTLS lib to k8s clustering), and it's going to be challenging to keep running the project as-it-is without a clear full-time corporate workforce.

[boaks]

@jvermillard

Would it be OK to copy your comment to an new issue?

[jvermillard]

Here you go: #2131

[boaks]

After all, it seems that none is interested in spending the time in being a shepherd for this work.
From my side, after a year, I'm not sure, if someone did a review and could give us a feedback, how much work is open.
If this is changing, feel free to comment to open this PR again.