[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [iot-pmc] Request assistance for Eclipse Cyclone DDS
|
Hi,
Yes, it's a single commit. But, there was a lot more work involved in
setting it all up.
1) Providing instructions to team-members on what accounts were need
where (Travis, AppVeyor, Bintray)
2) Writing Conan recipes and testing them:
2a) https://github.com/atolab/conan-criterion
2b) https://github.com/atolab/conan-libcsptr
2c) https://github.com/atolab/conan-dyncall
2d) https://github.com/atolab/conan-nanomsg
2e) https://github.com/atolab/conan-boxfort
2f) https://github.com/atolab/conan-cunit
2g) https://github.com/atolab/conan-wingetopt
Other than that I'm implementing new features and cleaning up some
things in my own repository: https://github.com/k0ekk0ek/cyclonedds.
Would that be enough to reconsider?
As for the signed-off-by footers, yes, that's on our radar. This seems
to be a direct commit, which certainly isn't the right way. We need to
address that. My intention is to add markdown documentation with the
proper project policies etc as soon as possible, so that committers and
contributors know what standards pull-requests need to adhere to. Maybe
even get all that integrated with GitHub somehow.
Best regards,
Jeroen
On 2018-09-19 11:39, Kai Kreuzer wrote:
Hi,
And I think you just provided this, by pointing to the project
activity: -> https://projects.eclipse.org/projects/iot.cyclonedds/who
... while all this activity seems to be attributed through a single PR
(https://github.com/eclipse/cyclonedds/pull/13) with ~300 lines of code
and no discussions.
So if you think that there is public information available that you can
point to, please feel free to do a new nomination and provide those
links in it.
My personal feeling as a project lead is that it would make more sense
though to wait for more contributions being done and merged. Note that
it is possible for every contributor to add reviews and comments to
PRs, which should be a good way to act as a peer review even without
having commit rights.
Btw, what I also notice is that (almost all of) the commits to the repo
are missing signed-off-by footers up to June this year (and even the
very latest commit lacks it). Is that something you have on the radar?
Best regards,
Kai
On 19. Sep 2018, at 08:40, Jens Reimann <jreimann@xxxxxxxxxx> wrote:
Hi Jeroen,
On Tue, Sep 18, 2018 at 5:21 PM, Jeroen Koekkoek <jeroen@xxxxxxxxxxx>
wrote:
Hi Guys,
I've been following the conversation a bit and let me start by saying
that I fully agree. This situation must be resolved, but in order to do
so I first need to have the privileges.
The commit history is gone from the project, but I've been working on
our private copy for quite some time (about 1.5 years, since
incubation). What's visible in the community, for now, is the entire
build system and all the conan recipes etc (different repositories).
Other than that I'm working on a FreeRTOS port and as part of ADLINK,
I'm working on adding ISOCPP support. To be fair, I'm 2nd in line when
it comes to activity:
https://projects.eclipse.org/projects/iot.cyclonedds/who.
What do I need to do to provide enough proof?
It is not so much important on what your are working, behind the
scenes, but what is on public record, for others to see.
And I think you just provided this, by pointing to the project
activity: -> https://projects.eclipse.org/projects/iot.cyclonedds/who
Best regards,
Jeroen Koekkoek
On 2018-09-18 16:53, Jens Reimann wrote:
I fully agree with Kai here. And I would like to add something.
The Eclipse project handbook says:
---
Each project is entitled to define how it evaluates "[people] who have
the trust of the Project's Committers ... [through] contributing and
showing discipline and good judgment". This definition needs to be a
transparent and public document on the project's website (the top-level
project charter may provide this). It is extremely important to publish
these criteria to avoid any issues around cliques or "the in-crowd"
preventing others from joining a project.
---
Having personal conversations with a committer, not sharing work,
doesn't really help as an argument in favor IMHO. The problem for me
would be, how would other contributors be nominated in a similar
fashion then? As Kai mentioned, there is no public record, which would
make the decision transparent to others.
I also think something sounds a little odd here, if 3 project leads and
4 committers are inactive on the project, but still vote. I would of
course understand if all (but one) committer are inactive and won't be
involved in the project in the future. Then we might think about
declaring the project dysfunctional (not in a technical sense of
course) and reset the committer base. Things like this happen and there
is a solution for that.
Otherwise I think it maybe helpful help us understand the current
situation of the project a bit better.
On Tue, Sep 18, 2018 at 4:39 PM, Kai Kreuzer <kai@xxxxxxxxxxx> wrote:
Dear Erik,
Thanks for this further information, it is much appreciated.
As I was the one that vetoed the election, let me respond to it:
First of all, it is very important to understand that this veto was not
at all about Jeroen in person, but rather about the way the nomination
was done. You are at any time free to do a new nomination of Jeroen.
The veto has been expressed because a nomination should show a track
record of work of the nominee, which proves that he understands the
project, its processes, that he did valuable contributions already and
that it is likely that he will continue that way. All of this was
missing in the description of the nomination.
has worked on what is now Eclipse Cyclone DDS internally before it was
contributed to Eclipse
This is an important argument for the nomination. It should be possible
to link to commits or code in the project that he has authored, so such
links would be helpful.
is currently undertaking relevant work, work that he simply hasn't yet
felt ready to share
This sounds as if it might simply be too early for a nomination. Let
him contribute all those great things as a regular contributor and once
it is accepted and merged, it should be a good time to make him a
committer as well.
that in itself does not eliminate the conflict of interest that is
inherent in a committer approving his own contributions, which is
basically what I have been forced to do, though it bothers me quite a
bit.
I think we all agree that no committer should be forced to approve his
own contributions, so having more than one committer in the project is
indeed essential. It leaves me quite puzzled though that
https://projects.eclipse.org/projects/iot.cyclonedds/who lists 3 (!)
project leads and 4 committers. So what exactly is wrong here that you
so strongly require another committer?
Hope this clarifies the reasons for the veto and what is expected of a
committer nomination.
Best regards,
Kai
On 18. Sep 2018, at 15:51, Erik Boasson <erik.boasson@xxxxxxxxxxxxxx>
wrote:
Discussion regarding Election for Jeroen Koekkoek as Committer on
Eclipse Cyclone DDS
https://projects.eclipse.org/projects/iot.cyclonedds/elections/election-jeroen-koekkoek-committer-eclipse-cyclone-dds
I believe there has been an unfortunate misunderstanding of the
position of Jeroen that caused his nomination as a committer to have
been rejected. If it is possible, I would like the decision to reject
to be reconsidered. If I am wrong in sending to this list on this
particular issue, then please forgive me and direct me to the
appropriate procedure instead.
Two points were raised essentially. The first is that it carried a
whiff of him having been hired for the express purpose of becoming a
committer. That, however, is definitely not the case.
He has been with ADLINK for several years, has worked on what is now
Eclipse Cyclone DDS internally before it was contributed to Eclipse,
and is the only one besides myself who has actually made substantive
contributions to the project: the work on continuous integration is
his, and I know from personal conversations that he is a strong
supporter of the project and is currently undertaking relevant work,
work that he simply hasn't yet felt ready to share. This includes:
* FreeRTOS support -- quite valuable for embedded systems, which is one
of the strong points of DDS
* various improvements to the testing, as we have some issues with
intermittent tests on Windows due to a problematic library we depend on
* the beginnings of proper C++ support
* assembling a list of issues that need to be addressed, so that others
in the community can actually see if there is anything they can do
without first digging into all the details.
On the second point, regarding the existence of proper procedures for
contributions from non-committers, I agree that these procedures are in
place. However, that in itself does not eliminate the conflict of
interest that is inherent in a committer approving his own
contributions, which is basically what I have been forced to do, though
it bothers me quite a bit. Having an _active_ co-committer would solve
that. In my personal opinion and having known Jeroen for years, he is
someone who will take on that role in a meaningful manner.
I am aware that there are a number of other committers, but they have
not taken that _active_ role, as the record shows. Still, they have
voted in favour. Finally, outside this group of people, the community
really is but nascent, with only a few people having asked questions so
far and only one truly external contribution.
Given all that, I feel my vote should carry some weight, and it is
fully behind Jeroen becoming a committer.
Best regards,
Erik Boasson _______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
--
Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen,
HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill _______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
_______________________________________________
iot-pmc mailing list
iot-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc