next steps for Vert.x @ Eclipse
958 views
Skip to first unread message
Max Rydahl Andersen
Nov 25, 2015, 5:00:07 AM11/25/15
to vert.x
Hey!
Hi,
As some of you might be aware Vert.x moved to Eclipse a while back and while parts of Vert.x is fully at eclipse (vert.x core) other (most) parts are not.
This has always been known and we (Tim, Julien, and various people at Red Hat and Eclipse Foundation) have been working on figuring out how to best handle this.
Below is a mail from Mike outlining some of the things Eclipse Foundation have changed recently that should benefit vert.x situation and a set of recommendations to how to make vert.x compliant with what being an Eclipse project means (mainly to have clearly identified opensource dependencies and an open documented release process).
Let us know what you think.
From Mike:
Tim and the Vert.x community,
As you know, when Vert.x first moved to the Eclipse Foundation, the expectation was that the project would become part of the Eclipse community. Becoming part of a community entails engaging with it, and adopting the policies, practices, and social norms of that community. To a very large degree, we're still waiting for that to happen.
Since your request to look at how Vert.x can be more successful at Eclipse, a number of things have happened here which have a positive impact on the way things work. Examples include:
The Eclipse Board has decided that Eclipse projects will be able to use GitHub Issues rather than Bugzilla for their issue tracking.
We have significantly reduced the amount of IP review that has to happen when you want to use a new version of a previously improved library. For example, if you're using Foo 2.1.3 and the Foo project ships Foo 2.1.4, no review at all needs to happen. You can stay on the latest patch releases of your dependencies without any IP-process latency.
We've made it possible to get libraries approved that were previously not allowed. For example, we can now distribute Groovy if a project needs to.
The Board has decided that all Eclipse projects need to be more consistent in their trademark usage, and we'll be rolling that out to all of our projects soon.
Based on where we are today, we have a number of recommendations on how Vert.x can improve its "Eclipse experience".
Recommendations:
We can enable GitHub issues for the Eclipse Vert.x Core project [1]. If you would like to do this (and we're sure you do), you'll need to get PMC approval and then contact webmaster to set things up. If so-desired by the project team, we can shut down the "Vert.x" Bugzilla product. We hope that this will make many of your development workflows simpler.
The Eclipse Vert.x project team must fully engage in the Eclipse Development Process by engaging in proper release reviews for all major and minor releases. The frequency of these releases, including the number of betas/milestones between releases, is left to the discretion of the project team (we can help where needed). There are other projects (e.g. Orion), that have a very rapid release cadence. We know how to support this.
Our understanding is that the Eclipse Vert.x Core binary distributions are not generally useful and that there are three meaningful binary distributions of Eclipse Vert.x as described in the vertx-stack repository [2]. The Eclipse Vert.x project team needs to provide the EMO with their plan to migrate the source code/repositories that contribute to the "min" binary distribution (including build scripts) to the Eclipse Vert.x project. As we recall, the main impediment to doing so was concern about getting Groovy and JRuby approved for distribution by an Eclipse project. We are now confident that we can do so. If there are any outstanding issues in this regard, let's get them on the table and deal with them.
The project team must establish the Eclipse trademarks on all web properties that bear the project name (including the vert-x, vert-x3 GitHub organizations and all related websites), README files, etc.. e.g. occurrences of the term "Vert.x" must be changed to "Eclipse Vert.x", particularly in headings and first use on a page.
The "Vert.x" organization landing page must clearly indicate that it is a trademark of the Eclipse Foundation and include a clear pointer to the eclipse.org site (e.g. http://www.eclipse.org/vertx)
Repositories and binary distributions that are not part of the Eclipse Vert.x project must be clearly labeled as such and must conform to the Guidelines for Eclipse Logos & Trademarks [3].
E.g. the "mod-mongo-persistor" module's repository must have "MongoDB Module for Eclipse Vert.x" in the description and README.
E.g. the Vert.x Core module's repository must have "Eclipse Vert.x" in the description and the README.
Summary:
We are committed to the overall success of the Vert.x project and its community. However, it does require some effort on both sides to make that happen. We look forward to helping Eclipse Vert.x become wildly successful in the industry.
[1] https://github.com/eclipse/vert.x
[2] https://github.com/vert-x3/vertx-stack
[3] https://eclipse.org/legal/logo_guidelines.php
Hi,
As some of you might be aware Vert.x moved to Eclipse a while back and while parts of Vert.x is fully at eclipse (vert.x core) other (most) parts are not.
This has always been known and we (Tim, Julien, and various people at Red Hat and Eclipse Foundation) have been working on figuring out how to best handle this.
Below is a mail from Mike outlining some of the things Eclipse Foundation have changed recently that should benefit vert.x situation and a set of recommendations to how to make vert.x compliant with what being an Eclipse project means (mainly to have clearly identified opensource dependencies and an open documented release process).
Let us know what you think.
From Mike:
Tim and the Vert.x community,
As you know, when Vert.x first moved to the Eclipse Foundation, the expectation was that the project would become part of the Eclipse community. Becoming part of a community entails engaging with it, and adopting the policies, practices, and social norms of that community. To a very large degree, we're still waiting for that to happen.
Since your request to look at how Vert.x can be more successful at Eclipse, a number of things have happened here which have a positive impact on the way things work. Examples include:
The Eclipse Board has decided that Eclipse projects will be able to use GitHub Issues rather than Bugzilla for their issue tracking.
We have significantly reduced the amount of IP review that has to happen when you want to use a new version of a previously improved library. For example, if you're using Foo 2.1.3 and the Foo project ships Foo 2.1.4, no review at all needs to happen. You can stay on the latest patch releases of your dependencies without any IP-process latency.
We've made it possible to get libraries approved that were previously not allowed. For example, we can now distribute Groovy if a project needs to.
The Board has decided that all Eclipse projects need to be more consistent in their trademark usage, and we'll be rolling that out to all of our projects soon.
Based on where we are today, we have a number of recommendations on how Vert.x can improve its "Eclipse experience".
Recommendations:
We can enable GitHub issues for the Eclipse Vert.x Core project [1]. If you would like to do this (and we're sure you do), you'll need to get PMC approval and then contact webmaster to set things up. If so-desired by the project team, we can shut down the "Vert.x" Bugzilla product. We hope that this will make many of your development workflows simpler.
The Eclipse Vert.x project team must fully engage in the Eclipse Development Process by engaging in proper release reviews for all major and minor releases. The frequency of these releases, including the number of betas/milestones between releases, is left to the discretion of the project team (we can help where needed). There are other projects (e.g. Orion), that have a very rapid release cadence. We know how to support this.
Our understanding is that the Eclipse Vert.x Core binary distributions are not generally useful and that there are three meaningful binary distributions of Eclipse Vert.x as described in the vertx-stack repository [2]. The Eclipse Vert.x project team needs to provide the EMO with their plan to migrate the source code/repositories that contribute to the "min" binary distribution (including build scripts) to the Eclipse Vert.x project. As we recall, the main impediment to doing so was concern about getting Groovy and JRuby approved for distribution by an Eclipse project. We are now confident that we can do so. If there are any outstanding issues in this regard, let's get them on the table and deal with them.
The project team must establish the Eclipse trademarks on all web properties that bear the project name (including the vert-x, vert-x3 GitHub organizations and all related websites), README files, etc.. e.g. occurrences of the term "Vert.x" must be changed to "Eclipse Vert.x", particularly in headings and first use on a page.
The "Vert.x" organization landing page must clearly indicate that it is a trademark of the Eclipse Foundation and include a clear pointer to the eclipse.org site (e.g. http://www.eclipse.org/vertx)
Repositories and binary distributions that are not part of the Eclipse Vert.x project must be clearly labeled as such and must conform to the Guidelines for Eclipse Logos & Trademarks [3].
E.g. the "mod-mongo-persistor" module's repository must have "MongoDB Module for Eclipse Vert.x" in the description and README.
E.g. the Vert.x Core module's repository must have "Eclipse Vert.x" in the description and the README.
Summary:
We are committed to the overall success of the Vert.x project and its community. However, it does require some effort on both sides to make that happen. We look forward to helping Eclipse Vert.x become wildly successful in the industry.
[1] https://github.com/eclipse/vert.x
[2] https://github.com/vert-x3/vertx-stack
[3] https://eclipse.org/legal/logo_guidelines.php
Arnaud Estève
Nov 25, 2015, 6:51:23 AM11/25/15
to vert.x
> The Eclipse Board has decided that Eclipse projects will be able to use GitHub Issues rather than Bugzilla for their issue tracking.
Yay ! Easier to follow in my mailbox. Easier to manage mail subscriptions, too. Thanks.
> We have significantly reduced the amount of IP review that has to happen when you want to use a new version of a previously improved library.
Nice !
> occurrences of the term "Vert.x" must be changed to "Eclipse Vert.x"
> Repositories and binary distributions that are not part of the Eclipse Vert.x project must be clearly labeled as such and must conform to the Guidelines for Eclipse Logos & Trademarks [3].
Well, mmh...
First, from a pragmatic PoV:
The MongoDB persistor example is a bit vague since it's an "official" module.
What about our (as a community) personal projects, not hosted by Vert.x (thus not part of the Eclipse Vert.x project ?), but intimately bound to Vert.x. ?
E.g. our services implementations (PostgreSQL, MySQL, Cassandra, Kafka, ...), our language implementations (typescript, scala, python, ...), our frameworks (QBit, Jersey, Nubes, ...).
All of these projects are mentionning Vert.x absolutely everywhere (in README files, websites if they have any) because they're building bricks on top of Vert.x. They all would not exist without Vert.x.
So what about our documentations ? Do we have to sed/Vert.x/Eclipse Vert.x/, too ?
If our own repos are affected, this would mean (for me) changing at least the description/README, (and also the documentation ?) of :
Almost every project I've been working on (on my free time) during the last 10 months.
It really doesn't sound fun to me...
And what about projects who depend on projects who depend on Vert.x ? https://github.com/aesteve/nubes-orm ? Is the trademarkink "transitive" ?
Second : from a sentimental PoV, I really don't want to sound ungrateful towards the Eclipse foundation, really. Thanks for being engaged, supporting Vert.x.
And I know you (as an organization) should reap the rewards of "hosting" Vert.x but honestly, I just hate the "trademarking" stuff.
The logo should be there, absolutely, Eclipse should be mentionned on Vert.x's official website, absolutely, and in big bold black. But on each of the modules ? Everywhere in the READMEs and descriptions ? Seriously ? Doesn't it sound like "plugging" to you ?
I love reading "Eclipse Vert.x", once. And I think it's well diserved.
I hate reading "Eclipse Vert.x" absolutely everywhere. It sounds like watching a bad commercial in the late 70's.
Thanks alot for sharing the announcement Max, sorry for being such a pragmatic ass*ole and not commenting the good parts of the email, but I'm a bit concerned...
Regards, have a nice day.
Jez P
Nov 25, 2015, 7:01:48 AM11/25/15
to vert.x
Same applies to vertx-pac4j presumably. I'm ok with referring to Eclipse Vert.x at the top of the readme, and presumably updating the logo, I'm not ok with wasting my hard-fought time doing this everywhere in the README. This is only one project of course, and won't take time but I'm really not interested in continuously reviewing any changes I make to the README to ensure that if I mention "Vert.x" it's only referred to as "Eclipse Vert.x".
In short, Arnaud, I agree with you. At present (hopefully this will change soon) I'm finding about 40 mins a week to work on my vert.x project, I don't want to lose even 2-3 mins of that to ensuring the Eclipse trademark features everywhere.
Max Rydahl Andersen
Nov 25, 2015, 8:44:32 AM11/25/15
to vert.x
Hey,
Just want to be clear I simply just forward the mail from Mike to start the discussion sooner.
My comments before the mail and now in this one is just me as interested party from Red Hat and knowledgable about Eclipse requirements in helping resolve any issues found.
Wayne and Mike should join the conversation later today as official Eclipse Foundation representatives.
Now onto the comments:
The Eclipse Board has decided that Eclipse projects will be able to use
GitHub Issues rather than Bugzilla for their issue tracking.
Yay ! Easier to follow in my mailbox. Easier to manage mail subscriptions,
too. Thanks.
Glad you like it :)
We have significantly reduced the amount of IP review that has to happen
when you want to use a new version of a previously improved library.
Nice !
It might not look at much but this is actually a big deal and will help a lot of Eclipse projects. Happy it came through.
occurrences of the term "Vert.x" must be changed to "Eclipse Vert.x"
Repositories and binary distributions that are *not part of the Eclipse
Vert.x project* must be clearly labeled as such and must conform to the
Guidelines for Eclipse Logos & Trademarks [3].
Well, mmh...
First, from a pragmatic PoV:
The MongoDB persistor example is a bit vague since it's an "official"
module.
Yes, the issue that is present right now is that Vert.x "official" modules has not gone through the Eclipse process thus the IP of especially the dependencies haven't received the same scrutiny as other Eclipse projects.
The suggestion here is just to make it clear which parts of Vert.x are released under the Eclipse umbrella and which are separate.
What about our (as a community) personal projects, not hosted by Vert.x
(thus not part of the Eclipse Vert.x project ?), but intimately bound to
Vert.x. ?
E.g. our services implementations (PostgreSQL, MySQL, Cassandra, Kafka,
...), our language implementations (typescript, scala, python, ...), our
frameworks (QBit, Jersey, Nubes, ...).All of these projects are mentionning Vert.x absolutely everywhere (in
README files, websites if they have any) because they're building bricks on
top of Vert.x. They all would not exist without Vert.x.
So what about our documentations ? Do we have to sed/Vert.x/Eclipse
Vert.x/, too ?
As I read it - it is just about the first mention of Vert.x you are requested to put the full name.
I don't know enough of the project repos you mention below in detail but the requirements are no different than if you made a plugin to Apache Maven or made a plugin for the Eclipse IDE.
If you read through the naming policies for Eclipse projects they are very close if not identical to how Apache project naming/trademark guidelines are.
I'll let Wayne or Mike do an official response, but my understanding of the proposal is that things coming as part of official Eclipse Vert.x project can call it self Eclipse Vert.x <subproject>.
Where as if you do some non-official vert.x module, you can call it <submodule> for Eclipse Vert.x.
If our own repos are affected, this would mean (for me) changing at least
the description/README, (and also the documentation ?) of :
- https://github.com/aesteve/vertx-feeds
- https://github.com/aesteve/nubes
- https://github.com/aesteve/vertx-markdown-service
- https://github.com/aesteve/vertx-git-service
- https://github.com/aesteve/vertx-gradle-service
- https://github.com/aesteve/gg-ciAlmost every project I've been working on (on my free time) during the last
10 months.
It really doesn't sound fun to me...
There is not an expectation that this will happen overnight - the post is an attempt from Eclipse foundation to clarify and make the community aware that there are these guidelines that exist and would like to find a best way to do it.
And what about projects who depend on projects who depend on Vert.x
? https://github.com/aesteve/nubes-orm ? Is the trademarkink "transitive" ?Second : from a sentimental PoV, I really don't want to sound ungrateful
towards the Eclipse foundation, really. Thanks for being engaged,
supporting Vert.x.And I know you (as an organization) should reap the rewards of "hosting"
Vert.x but honestly, I just hate the "trademarking" stuff.
The logo should be there, absolutely, Eclipse should be mentionned on
Vert.x's official website, absolutely, and in big bold black. But on each
of the modules ? Everywhere in the READMEs and descriptions ? Seriously ?
Doesn't it sound like "plugging" to you ?
I'll let Mike/Wayne respond to this - but afaik this is similar to Apache, Fedora and other organisations that uses their main name as the lead for their trademarks.
I love reading "Eclipse Vert.x", once. And I think it's well diserved.
I hate reading "Eclipse Vert.x" absolutely everywhere. It sounds like
watching a bad commercial in the late 70's.
The mail from Mike explicitly states:
"particularly in headings and first use on a page."
And if you read https://eclipse.org/legal/logo_guidelines.php (and similar Apache: http://www.apache.org/foundation/marks/pmcs.html) it has a line stating:
"Therefore, when referencing an Eclipse project, we ask that the first reference to the project is identified as Eclipse [project name]"
so it is really not asking to replace ALL mention of vert.x, just the first one.
Thanks alot for sharing the announcement Max, sorry for being such a
pragmatic ass*ole and not commenting the good parts of the email, but I'm a
bit concerned...
/max
--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/8c6902b4-2b43-4c38-98f0-85cfd359f0c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arnaud Estève
Nov 25, 2015, 9:29:21 AM11/25/15
to vert.x
Thanks alot for your answer.
I'm off the discussion for now, curious to read what other ppl have in mind :)
Tim Fox
Nov 25, 2015, 10:15:00 AM11/25/15
to ve...@googlegroups.com
Dear Vert.x community,
I believe the only thing that really matters here is what is best for the Vert.x project and the only people that really know that and can decide that are the Vert.x community. Not Eclipse, not me, not Red Hat and not any other single interested party.
These comments are my personal opinion, and I'm just a member of the Vert.x community, albeit one who has helped to grow Vert.x from nothing to the thriving ecosystem it is today. But fundamentally just a member of the community who is no more important than anyone else.
Whatever happens, and irrespective of what I personally believe, I will respect the wishes of the Vert.x community as to the future of the project. I hope and expect other parties will do this too rather than try and push their own agendas.
A little bit of history might be in order here: The only part of Vert.x that ever moved to Eclipse is the part of Vert.x that we now know as "Vert.x core". "Vert.x" has always been much more than that small part of Vert.x which was signed over to Eclipse.
What we should be asking ourselves here is "What is best for Vert.x?", not "Who owns the trademark?" or anything else. I consider Eclipse to be the legal custodians of the Vert.x trademark who hold it on behalf of the Vert.x community and their role is to respect the Vert.x community's wishes as to the use of that trademark, not seek to impose their own wishes on the Vert.x community.
I'm not going to address all the points below one by one, but my personal opinion is that moving most of Vert.x to Eclipse would be very painful for the Vert.x community and therefore fails the "What is best for Vert.x?" question. Currently we have just one GitHub project under the Eclipse process, and it seems that Eclipse is mandating at least 20 more to move over (and maybe many more). In my view that would be crippling to the project. The team are already massively overstretched trying to manage the official components, and one more straw could break the camel's back.
Moreover mandating that the "Vert.x" trademark can only be used for the small part of Vert.x that lives under Eclipse seems a harsh restriction that, again, doesn't seem to help the Vert.x community in any way, quite the opposite it imposes a real burden on us. It's also a hard one to swallow - as the people who have spent years building up the "Vert.x" brand are now being told how they can use that brand by an entity who, frankly, has done very little to build that brand, but by an accident of fate own a piece of paper which grants them the legal right to do this. But not the moral right. I will always continue you the community to be the true owners of "Vert.x".
Anyway... Eclipse does control the trademark and is quite within their (legal) rights to do this, so that's not much else we can do as a community other than fork the project and rename it something else. To be honest after several years of working on this project I'm tired and don't really have the strength or desire to do this or fight any more about it.
So that's all I really have to say on the subject. It's up to you, the community to decide where you want to go from here.
I believe the only thing that really matters here is what is best for the Vert.x project and the only people that really know that and can decide that are the Vert.x community. Not Eclipse, not me, not Red Hat and not any other single interested party.
These comments are my personal opinion, and I'm just a member of the Vert.x community, albeit one who has helped to grow Vert.x from nothing to the thriving ecosystem it is today. But fundamentally just a member of the community who is no more important than anyone else.
Whatever happens, and irrespective of what I personally believe, I will respect the wishes of the Vert.x community as to the future of the project. I hope and expect other parties will do this too rather than try and push their own agendas.
A little bit of history might be in order here: The only part of Vert.x that ever moved to Eclipse is the part of Vert.x that we now know as "Vert.x core". "Vert.x" has always been much more than that small part of Vert.x which was signed over to Eclipse.
What we should be asking ourselves here is "What is best for Vert.x?", not "Who owns the trademark?" or anything else. I consider Eclipse to be the legal custodians of the Vert.x trademark who hold it on behalf of the Vert.x community and their role is to respect the Vert.x community's wishes as to the use of that trademark, not seek to impose their own wishes on the Vert.x community.
I'm not going to address all the points below one by one, but my personal opinion is that moving most of Vert.x to Eclipse would be very painful for the Vert.x community and therefore fails the "What is best for Vert.x?" question. Currently we have just one GitHub project under the Eclipse process, and it seems that Eclipse is mandating at least 20 more to move over (and maybe many more). In my view that would be crippling to the project. The team are already massively overstretched trying to manage the official components, and one more straw could break the camel's back.
Moreover mandating that the "Vert.x" trademark can only be used for the small part of Vert.x that lives under Eclipse seems a harsh restriction that, again, doesn't seem to help the Vert.x community in any way, quite the opposite it imposes a real burden on us. It's also a hard one to swallow - as the people who have spent years building up the "Vert.x" brand are now being told how they can use that brand by an entity who, frankly, has done very little to build that brand, but by an accident of fate own a piece of paper which grants them the legal right to do this. But not the moral right. I will always continue you the community to be the true owners of "Vert.x".
Anyway... Eclipse does control the trademark and is quite within their (legal) rights to do this, so that's not much else we can do as a community other than fork the project and rename it something else. To be honest after several years of working on this project I'm tired and don't really have the strength or desire to do this or fight any more about it.
So that's all I really have to say on the subject. It's up to you, the community to decide where you want to go from here.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4a5141f4-f14b-4a14-b241-17e957cc40ac%40googlegroups.com.
Wayne Beaton
Nov 25, 2015, 10:27:47 AM11/25/15
to ve...@googlegroups.com
On 25/11/15 05:00 AM, Max Rydahl
Andersen wrote:
The Eclipse Board has decided that Eclipse projects will be able to use GitHub Issues rather than Bugzilla for their issue tracking.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
Wayne Beaton
@waynebeaton
The Eclipse Foundation
Julien Viet
Nov 25, 2015, 10:31:26 AM11/25/15
to ve...@googlegroups.com, Wayne Beaton
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655D369.4060604%40eclipse.org.
Jez P
Nov 25, 2015, 11:18:21 AM11/25/15
to vert.x
There is a valid question here which I'm not sure is totally answered in Tim's post. If 20 extra projects move under the Eclipse umbrella, what does that do to the admin overhead on the core team members? If this creates a big administrative overhead, I'm not sure I understand the benefits to the Vert.x community at large of that move. And what would happen if that proposal were rejected?
In short, the Eclipse foundation seems to believe that everything released as part of the Vert.x stack should be under the Eclipse umbrella. I'd say before anyone moves in that direction, I'd like to understand what the benefits are to the community of that happening. And, for that matter, the costs in terms of core developer time lost to managing that.
Notwithstanding this, I'm perfectly happy to label my READMEs with the Eclipse name on first mention of Vert.x as mentioned above, no problem whatsoever with that, as the overhead on me is tiny and effectively once per README.
Martijn Verburg
Nov 25, 2015, 11:25:12 AM11/25/15
to ve...@googlegroups.com
Hi Tim/All,
So I think it would help if there was a explanation of the overhead vs benefits of working on and releasing vertx official modules at Eclipse vs just at GitHub. If each official module project is being hosted on GitHub with GitHub issues then a simple redirect of the existing repos should mean that end users don't get lost, so there's that. Is it the PR model that's different? The CLA requirements that are onerous...? Or....?
Cheers,
Martijn
Martijn
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655D06F.5080900%40gmail.com.
Wayne Beaton
Nov 25, 2015, 12:43:00 PM11/25/15
to ve...@googlegroups.com
The release requirements imposed by the Eclipse Development Process
(EDP) are not particularly onerous. If it takes more than a couple
of minutes, then you may be trying too hard.
Having said that, I should prefix the rest of this description with an assumption that the project team will have something like a plan at the beginning of a release cycle. The plan could be something as simple as a list of features that are going to be implemented or a intention to just fix some outstanding bugs. While the requirements imposed by the EDP are not particularly onerous, the consensus building process involved in coming up with a decent plan at or near the beginning of a release cycle can be a pretty time-consuming process. This will become especially true as the project grows in adoption.
According to the EDP, any major or minor release requires a "Release Review". Service releases--releases containing bug fixes only--do not require a review. A project may also make distribute any number of milestone builds (release candidates, alphas, betas, whatever you want to call them) leading up to a release.
We define a minor release as one that includes new functionality. Major releases likely include API breakage; the project team may opt to do a major release for significant new functionality or to otherwise make the release a "bigger deal". The release process is the same for both.
In pragmatic terms, we require that a project do an intellectual property (IP) checkpoint and get approval for the release from their Project Management Committee (PMC).
The IP checkpoint requires that a member of the project team submit the project's IP Log for approval by the Eclipse IP Team. The IP Log is automatically generated from information extracted the project's Git repositories our our database of known third-party library use. Assuming that the project has been following the IP Due Diligence process, the IP Log approval process should require only a few minutes of the project team's time to quickly review the generated log and click the "Submit" button.
The PMC approval requires that the project team create a release record in our system [1] that describes the release. Ideally this record is created early in the release cycle and updated as targets change. For Vert.x's PMC, a brief description of the focus and features of the release are all that's required.
We ask that project teams make the binary distributions of their official releases available from the Eclipse Foundation-provided download server. We encourage distribution via other services as well. This is primarily a "freedom of action" consideration (which I'll try to address in a separate post).
How often you do this really depends on the project team and the community's priorities. Some our projects, for example, do annual releases with monthly-ish milestone builds leading up to the official release and some number of service/bug-fix releases afterwards. Some do official releases more frequently.
Consumers of the project code benefit from a well-defined predictable release schedule. Organizations basing products on the code, and organizations deploying the code can do reasonably planning if they know when your releases are going to be available and what they will include. While much of this information can be discovered from discussions in the mailing list, having it captured in a consistent manner makes it easier.
Further, by defining a release plan (i.e. creating your release record in advance), you level the playing field for developers who want to contribute. They can more easily understand your priorities for the release and know how they can contribute. Again, somebody who is paying close attention should be able to sort this out from the discussion, but making it explicit makes it easier and lowers the barriers for entry.
HTH,
Wayne
[1] https://projects.eclipse.org/projects/rt.vertx
Having said that, I should prefix the rest of this description with an assumption that the project team will have something like a plan at the beginning of a release cycle. The plan could be something as simple as a list of features that are going to be implemented or a intention to just fix some outstanding bugs. While the requirements imposed by the EDP are not particularly onerous, the consensus building process involved in coming up with a decent plan at or near the beginning of a release cycle can be a pretty time-consuming process. This will become especially true as the project grows in adoption.
According to the EDP, any major or minor release requires a "Release Review". Service releases--releases containing bug fixes only--do not require a review. A project may also make distribute any number of milestone builds (release candidates, alphas, betas, whatever you want to call them) leading up to a release.
We define a minor release as one that includes new functionality. Major releases likely include API breakage; the project team may opt to do a major release for significant new functionality or to otherwise make the release a "bigger deal". The release process is the same for both.
In pragmatic terms, we require that a project do an intellectual property (IP) checkpoint and get approval for the release from their Project Management Committee (PMC).
The IP checkpoint requires that a member of the project team submit the project's IP Log for approval by the Eclipse IP Team. The IP Log is automatically generated from information extracted the project's Git repositories our our database of known third-party library use. Assuming that the project has been following the IP Due Diligence process, the IP Log approval process should require only a few minutes of the project team's time to quickly review the generated log and click the "Submit" button.
The PMC approval requires that the project team create a release record in our system [1] that describes the release. Ideally this record is created early in the release cycle and updated as targets change. For Vert.x's PMC, a brief description of the focus and features of the release are all that's required.
We ask that project teams make the binary distributions of their official releases available from the Eclipse Foundation-provided download server. We encourage distribution via other services as well. This is primarily a "freedom of action" consideration (which I'll try to address in a separate post).
How often you do this really depends on the project team and the community's priorities. Some our projects, for example, do annual releases with monthly-ish milestone builds leading up to the official release and some number of service/bug-fix releases afterwards. Some do official releases more frequently.
Consumers of the project code benefit from a well-defined predictable release schedule. Organizations basing products on the code, and organizations deploying the code can do reasonably planning if they know when your releases are going to be available and what they will include. While much of this information can be discovered from discussions in the mailing list, having it captured in a consistent manner makes it easier.
Further, by defining a release plan (i.e. creating your release record in advance), you level the playing field for developers who want to contribute. They can more easily understand your priorities for the release and know how they can contribute. Again, somebody who is paying close attention should be able to sort this out from the discussion, but making it explicit makes it easier and lowers the barriers for entry.
HTH,
Wayne
[1] https://projects.eclipse.org/projects/rt.vertx
On 25/11/15 11:24 AM, Martijn Verburg
wrote:
So I think it would help if there was a explanation of the overhead vs benefits of working on and releasing vertx official modules at Eclipse vs just at GitHub. If each official module project is being hosted on GitHub with GitHub issues then a simple redirect of the existing repos should mean that end users don't get lost, so there's that. Is it the PR model that's different? The CLA requirements that are onerous...? Or....?
Max Rydahl Andersen
Nov 25, 2015, 12:56:51 PM11/25/15
to vert.x
Thanks for the details Wayne - im
In a car right now but want to say to vertx community that there is a simple mapping between most of what Wayne outlines here and what you already do.
In a car right now but want to say to vertx community that there is a simple mapping between most of what Wayne outlines here and what you already do.
I'll try outline that asap once I'm at a more decent keyboard :)
Tim Fox
Nov 25, 2015, 12:59:07 PM11/25/15
to ve...@googlegroups.com
On 25/11/15 16:24, Martijn Verburg
wrote:
Hi Tim/All,
So I think it would help if there was a explanation of the overhead vs benefits of working on and releasing vertx official modules at Eclipse vs just at GitHub. If each official module project is being hosted on GitHub with GitHub issues then a simple redirect of the existing repos should mean that end users don't get lost, so there's that. Is it the PR model that's different? The CLA requirements that are onerous...? Or....?
The issue is with the Eclipse process. We currently have a single
project (Vertx-core) at Eclipse and have to jump through the Eclipse
hoops every time we do a release. The last time I had the misfortune
to have to partake in that process it was horrible - it sucked every
last bit of enjoyment out of the development process.
We have around 80+ projects that make up Vert.x "official" components (if you include Vert.x 2). Now imagine that horrible process multiplied by 80 (this https://eclipse.org/projects/dev_process/development_process.php times 80) every time we need to do a release of one of those projects. It doesn't bear thinking about, and personally, I would have to rule myself out of being part of a solution like that.
And none of this bureaucracy has any obvious to benefit to Vert.x (quite the opposite). And all of this despite the fact that we already have a nice development process that seems to work great as far as I can tell https://github.com/vert-x3/wiki/wiki
All of this seems to be bureaucracy for bureaucracy's sake.
We have around 80+ projects that make up Vert.x "official" components (if you include Vert.x 2). Now imagine that horrible process multiplied by 80 (this https://eclipse.org/projects/dev_process/development_process.php times 80) every time we need to do a release of one of those projects. It doesn't bear thinking about, and personally, I would have to rule myself out of being part of a solution like that.
And none of this bureaucracy has any obvious to benefit to Vert.x (quite the opposite). And all of this despite the fact that we already have a nice development process that seems to work great as far as I can tell https://github.com/vert-x3/wiki/wiki
All of this seems to be bureaucracy for bureaucracy's sake.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAP7YuASDE2%3D2atmfZiDUDx%2B8LBedVjLB2O5f5tJ_1cHw%3Dg82Xg%40mail.gmail.com.
Tim Fox
Nov 25, 2015, 1:02:35 PM11/25/15
to ve...@googlegroups.com
On 25/11/15 17:42, Wayne Beaton wrote:
The release requirements imposed by the Eclipse Development Process (EDP) are not particularly onerous. If it takes more than a couple of minutes, then you may be trying too hard.
Now, back in the real world. It took me around 2 weeks of pain last
time I tried it. And that was for a single project, not 80.
Having said that, I should prefix the rest of this description with an assumption that the project team will have something like a plan at the beginning of a release cycle. The plan could be something as simple as a list of features that are going to be implemented or a intention to just fix some outstanding bugs. While the requirements imposed by the EDP are not particularly onerous, the consensus building process involved in coming up with a decent plan at or near the beginning of a release cycle can be a pretty time-consuming process. This will become especially true as the project grows in adoption.
According to the EDP, any major or minor release requires a "Release Review". Service releases--releases containing bug fixes only--do not require a review. A project may also make distribute any number of milestone builds (release candidates, alphas, betas, whatever you want to call them) leading up to a release.
We define a minor release as one that includes new functionality. Major releases likely include API breakage; the project team may opt to do a major release for significant new functionality or to otherwise make the release a "bigger deal". The release process is the same for both.
In pragmatic terms, we require that a project do an intellectual property (IP) checkpoint and get approval for the release from their Project Management Committee (PMC).
The IP checkpoint requires that a member of the project team submit the project's IP Log for approval by the Eclipse IP Team. The IP Log is automatically generated from information extracted the project's Git repositories our our database of known third-party library use. Assuming that the project has been following the IP Due Diligence process, the IP Log approval process should require only a few minutes of the project team's time to quickly review the generated log and click the "Submit" button.
The PMC approval requires that the project team create a release record in our system [1] that describes the release. Ideally this record is created early in the release cycle and updated as targets change. For Vert.x's PMC, a brief description of the focus and features of the release are all that's required.
We ask that project teams make the binary distributions of their official releases available from the Eclipse Foundation-provided download server. We encourage distribution via other services as well. This is primarily a "freedom of action" consideration (which I'll try to address in a separate post).
How often you do this really depends on the project team and the community's priorities. Some our projects, for example, do annual releases with monthly-ish milestone builds leading up to the official release and some number of service/bug-fix releases afterwards. Some do official releases more frequently.
Consumers of the project code benefit from a well-defined predictable release schedule. Organizations basing products on the code, and organizations deploying the code can do reasonably planning if they know when your releases are going to be available and what they will include. While much of this information can be discovered from discussions in the mailing list, having it captured in a consistent manner makes it easier.
We already have this captured in a easy to find consistent manner:
https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap
https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap
Further, by defining a release plan (i.e. creating your release record in advance), you level the playing field for developers who want to contribute. They can more easily understand your priorities for the release and know how they can contribute. Again, somebody who is paying close attention should be able to sort this out from the discussion, but making it explicit makes it easier and lowers the barriers for entry.
Strawman.
HTH,
Wayne
[1] https://projects.eclipse.org/projects/rt.vertx
On 25/11/15 11:24 AM, Martijn Verburg wrote:
So I think it would help if there was a explanation of the overhead vs benefits of working on and releasing vertx official modules at Eclipse vs just at GitHub. If each official module project is being hosted on GitHub with GitHub issues then a simple redirect of the existing repos should mean that end users don't get lost, so there's that. Is it the PR model that's different? The CLA requirements that are onerous...? Or....?
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
![EclipseCon Europe 2015]()
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655F31B.9080708%40eclipse.org.
Tim Fox
Nov 25, 2015, 1:05:01 PM11/25/15
to ve...@googlegroups.com
Wayne,
I think the question you need to answer is how does it help Vert.x to force a new and much more complex development process on the Vert.x community when it already has one which seems to work pretty well, with the minimum of pain.
I think the question you need to answer is how does it help Vert.x to force a new and much more complex development process on the Vert.x community when it already has one which seems to work pretty well, with the minimum of pain.
On 25/11/15 17:42, Wayne Beaton wrote:
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655F31B.9080708%40eclipse.org.
Max Rydahl Andersen
Nov 25, 2015, 1:38:14 PM11/25/15
to ve...@googlegroups.com
Could we please talk about *mapping* the release process and filling in whatever gaps are on either vertx or eclipse edp instead of about forcing a new one :)
That's what being proposed. To find a way to map.
That's what being proposed. To find a way to map.
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655F84A.9060506%40gmail.com.
Max Rydahl Andersen
Nov 25, 2015, 1:40:12 PM11/25/15
to ve...@googlegroups.com
Btw. I do agree Wayne should comment on what the expected value is from this.
Just saying that I don't believe the current vertx process is *that* far from what EDP outlines. Main diff is that dependencies are checked for possible IP issues.
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655F84A.9060506%40gmail.com.
Wayne Beaton
Nov 25, 2015, 2:45:20 PM11/25/15
to ve...@googlegroups.com
Your first experience was atypical. At some point, I'll need to
review my records from the event to sort out where the breakdowns
occurred and sort out how we can fix them. In the meantime, I
believe that we have refined the experience.
Moving Vert.x min functionality into the Eclipse Vert.x project will just add repositories to the existing project. The actual release process won't be affected by this other that to add a few words about the addition to the description on the release record.
Wayne
Moving Vert.x min functionality into the Eclipse Vert.x project will just add repositories to the existing project. The actual release process won't be affected by this other that to add a few words about the addition to the description on the release record.
Wayne
On 25/11/15 01:02 PM, Tim Fox wrote:
On 25/11/15 17:42, Wayne Beaton wrote:
The release requirements imposed by the Eclipse Development Process (EDP) are not particularly onerous. If it takes more than a couple of minutes, then you may be trying too hard.
Now, back in the real world. It took me around 2 weeks of pain last time I tried it. And that was for a single project, not 80.
Max Rydahl Andersen
Nov 25, 2015, 2:57:11 PM11/25/15
to ve...@googlegroups.com
Wayne, will that be true if some of these projects release updates at different times ?
I hope it can be - just want to be sure we don't miss some detail that currently would prevent that.
/max
/max
--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56560FC6.2020304%40eclipse.org.
Wayne Beaton
Nov 25, 2015, 3:12:36 PM11/25/15
to ve...@googlegroups.com
If releasing different components on different schedules makes
sense, a project team can do that.
I would suggest that attempting to release different aspects of the same project on different schedules would be confusing for adopters, but I defer to the project team's better understanding of the requirements of their community and adopters.
HTH,
Wayne
I would suggest that attempting to release different aspects of the same project on different schedules would be confusing for adopters, but I defer to the project team's better understanding of the requirements of their community and adopters.
HTH,
Wayne
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/60A1E3A2-1245-452E-87B5-7019B0A84704%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Tim Fox
Nov 25, 2015, 3:20:06 PM11/25/15
to ve...@googlegroups.com
I am still waiting for you to make a
case for why the 99% of Vert.x which is not an Eclipse project
should move to Eclipse.
For the community to even consider moving, there needs to be a very strong value-add. So far I am not aware what that value-add is.
Please advise.
For the community to even consider moving, there needs to be a very strong value-add. So far I am not aware what that value-add is.
Please advise.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5656162D.9%40eclipse.org.
Jez P
Nov 25, 2015, 3:24:17 PM11/25/15
to vert.x
Before I say more, I should point out that I don't know what happened with Tim's experience of the release, I'm neither part of the Vert.x core team nor Eclipse foundation and I don't particularly have a preference for direction beyond wanting to keep the core team reasonably happy so they stick with the project, as they've done fantastically so far. From past personal (commercial, not open source) experience an excessively onerous development or release process doesn't encourage good people to want to stick around as in the end they come to the conclusion it's not worth it. That said, I don't know whether Tim's experience was either typical or atypical, or where the pain points were, so I'm not going to accuse the process of being cumbersome and I hope this post won't be seen as such.
On that basis, I would suggest that it would be good for you to work with Tim and your records to find out where the pain points were for him, sooner rather than later; while his experience was atypical, it still happened and spending some time helping him know how to avoid that pain in future might change his mind about adopting the Eclipse release process. Right now you have a very smart, professional guy whose only experience of this was, frankly, bloody awful, to the extent he's talking about moving on if we adopt that process for more modules. That says that either the process was more onerous than you think it should be, or that the information Tim was given about how to do it was at best misleading. Given that, it's not going to be too easy to persuade anyone who hasn't had direct experience of doing such a release that all is rosy in Eclipse-release-land. We don't want to see the core devs tied up for 2 weeks at a time per module with a release process, and realistically the best way to persuade us that it was atypical is to persuade those core devs that it was atypical.
Max Rydahl Andersen
Nov 25, 2015, 3:33:37 PM11/25/15
to vert.x
On Wednesday, November 25, 2015 at 7:02:35 PM UTC+1, Tim Fox wrote:
On 25/11/15 17:42, Wayne Beaton wrote:
The release requirements imposed by the Eclipse Development Process (EDP) are not particularly onerous. If it takes more than a couple of minutes, then you may be trying too hard.
Now, back in the real world. It took me around 2 weeks of pain last time I tried it. And that was for a single project, not 80.
It would be great if Julien could give his experience since he have been doing these multiple times now and afaik besides having to deal with a potential IP issue in a library update it have not taken 2 weeks of pain each time.
And i'm sure it can be made it even smoother if we actually listed the issues in weed out problems.
Tim Fox
Nov 25, 2015, 3:37:50 PM11/25/15
to ve...@googlegroups.com
On 25/11/15 20:33, Max Rydahl Andersen
wrote:
On Wednesday, November 25, 2015 at 7:02:35 PM UTC+1, Tim Fox wrote:On 25/11/15 17:42, Wayne Beaton wrote:
The release requirements imposed by the Eclipse Development Process (EDP) are not particularly onerous. If it takes more than a couple of minutes, then you may be trying too hard.
Now, back in the real world. It took me around 2 weeks of pain last time I tried it. And that was for a single project, not 80.
It would be great if Julien could give his experience since he have been doing these multiple times now and afaik besides having to deal with a potential IP issue in a library update it have not taken 2 weeks of pain each time.
Julien did it for one project, not 80.
And i'm sure it can be made it even smoother if we actually listed the issues in weed out problems.
Please stop working from the assumption that the only option is to
adopt the Eclipse process.
Before we even get to that point, you need to make a very good case to the Vert.x community that moving the 99% of Vert.x which is not Eclipse, to Eclipse.
If you can make such a case, and the community agrees that it the way forward then we can start talking about details of project process.
So... over to you guys: Make your case and sell it to us :)
Before we even get to that point, you need to make a very good case to the Vert.x community that moving the 99% of Vert.x which is not Eclipse, to Eclipse.
If you can make such a case, and the community agrees that it the way forward then we can start talking about details of project process.
So... over to you guys: Make your case and sell it to us :)
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/248f535c-2be0-4d90-ab02-6078c33f9634%40googlegroups.com.
Wayne Beaton
Nov 25, 2015, 3:57:55 PM11/25/15
to ve...@googlegroups.com
I'll address the "how is this valuable" question shortly. First, I'd
like to address the "how is this different" question.
We actually forced a couple of things on other Eclipse projects because of the way that Vert.x does things. For example, all Eclipse projects are now required to have a CONTRIBUTING guide in every Git repository. Vert.x was also one of the driving factors behind our "social coding" efforts to enable Eclipse projects to host directly on GitHub (the mirroring idea that we'd originally discussed had some significant flaws).
As Max says, I don't think that we're all that far apart in terms of the process.
The roadmap document [1] is basically what we look for in a project plan. I assume, though, that "Vert.x Core" is only a subset of this and am pretty sure that corresponding bits have just been copied out of this for the Eclipse project's release records.
FWIW, we have a handy feature that connects a release document with corresponding issue records (e.g. [2]). We're going to extend this to support GitHub Issues (it'll match release numbers to milestone tags). The idea is that you can make a pretty complete (and dynamic) release record without having to do very much.
The Eclipse Development Process doesn't generally impose anything on the day-to-day operations of the project. The Development Process document [3] is consistent with what other project teams do. How you use Git branches and such is really up to you. Whether not to impose coding styles is up to you. The thing that I'd add is "signed-off-by" requirement for Git commit records; but only for repositories that might eventually be moved into the Eclipse Vert.x project (apparently this makes the lawyers feel a lot better about contributions).
For repositories that are part of the Eclipse Vert.x project, the IP Due Diligence process [4] would have to be followed, but based on what I see in the project repositories, I'm pretty sure that most contributions require no engagement with the Eclipse IP Team.
Engagement with the IP Team will, however, be required as components are moved into the Eclipse Vert.x project. As part of their due diligence process, they'll have to look at the entire code base in the Git repository, along with all third-party libraries. We took a quick look at the third-party libraries used by Vert.x min and are pretty sure that most of them are already approved. Having said that, there may be surprises and some effort may be required from the project team to sort out those issues.
The Release Process document [5] seems to primarily describe the build process. How you build is your call. Having said that, it's important to make sure that builds aren't tied to any single individual or organization. We had a project just recently break an aggregation build because only one individual had access to the project's broken build and they weren't reachable. More than one person needs to be able to build and release your code.
The "Eclipse release" sections in that document are blank. I think that I've already summarized the process in a previous note, so I'll just use some bullets here:
* Create a release record at or near the beginning of the release cycle (or further in advance if you're planning that far ahead).
* At least two weeks ahead of your release date:
** submit the IP Log for review
** send a link to the release document to rt-...@eclipse.org requesting approval of the documentation and release
* With approvals in hand, we post a review of the release for the community see; we blog, we tweet, etc. to drive some attention to the release.
The IP Log review may require some remediation if we discover any violations of the IP process. This often happens when a project team inadvertently uses a different version of a library than what's approved. But some recent changes to our IP policy should make that less of an issue.
Asking the PMC for approval suggests that there is some possibility that the answer will be no. Theoretically, the PMC may not approve the release, but this should only happen if it is determined that a project isn't operating in a sufficiently open and transparent manner (this certainly doesn't apply to Vert.x). Sometimes the PMC may ask for clarifications of the release record content.
AFAICT, the documentation doesn't describe how somebody gains commit rights. We do this via a committer election. Theoretically, this could be done in a mailing list, but we so have some infrastructure in place to make it theoretically easier on all parties.
The general way that elections are run (this is true for Project Lead elections as well) is that after nomination is posted, the election runs for five business days (effectively a week) or until all committers have voted in favour. After the week, if there are at least three positive votes and no negative votes, the election is deemed successful. In the rare event that somebody votes negative, the rest of the project team has until the end of the voting period to convince them to change their mind. If a project has fewer than three committers, then everybody has to vote yes.
HTH,
Wayne
[1] https://github.com/vert-x3/issues-and-wiki/wiki/Vert.x-Roadmap
[2] https://projects.eclipse.org/projects/technology.egit/releases/4.0.0/bugs
[3] https://github.com/vert-x3/wiki/wiki/Development-Process
[4] https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
[5] https://github.com/vert-x3/wiki/wiki/Release-Process
We actually forced a couple of things on other Eclipse projects because of the way that Vert.x does things. For example, all Eclipse projects are now required to have a CONTRIBUTING guide in every Git repository. Vert.x was also one of the driving factors behind our "social coding" efforts to enable Eclipse projects to host directly on GitHub (the mirroring idea that we'd originally discussed had some significant flaws).
As Max says, I don't think that we're all that far apart in terms of the process.
The roadmap document [1] is basically what we look for in a project plan. I assume, though, that "Vert.x Core" is only a subset of this and am pretty sure that corresponding bits have just been copied out of this for the Eclipse project's release records.
FWIW, we have a handy feature that connects a release document with corresponding issue records (e.g. [2]). We're going to extend this to support GitHub Issues (it'll match release numbers to milestone tags). The idea is that you can make a pretty complete (and dynamic) release record without having to do very much.
The Eclipse Development Process doesn't generally impose anything on the day-to-day operations of the project. The Development Process document [3] is consistent with what other project teams do. How you use Git branches and such is really up to you. Whether not to impose coding styles is up to you. The thing that I'd add is "signed-off-by" requirement for Git commit records; but only for repositories that might eventually be moved into the Eclipse Vert.x project (apparently this makes the lawyers feel a lot better about contributions).
For repositories that are part of the Eclipse Vert.x project, the IP Due Diligence process [4] would have to be followed, but based on what I see in the project repositories, I'm pretty sure that most contributions require no engagement with the Eclipse IP Team.
Engagement with the IP Team will, however, be required as components are moved into the Eclipse Vert.x project. As part of their due diligence process, they'll have to look at the entire code base in the Git repository, along with all third-party libraries. We took a quick look at the third-party libraries used by Vert.x min and are pretty sure that most of them are already approved. Having said that, there may be surprises and some effort may be required from the project team to sort out those issues.
The Release Process document [5] seems to primarily describe the build process. How you build is your call. Having said that, it's important to make sure that builds aren't tied to any single individual or organization. We had a project just recently break an aggregation build because only one individual had access to the project's broken build and they weren't reachable. More than one person needs to be able to build and release your code.
The "Eclipse release" sections in that document are blank. I think that I've already summarized the process in a previous note, so I'll just use some bullets here:
* Create a release record at or near the beginning of the release cycle (or further in advance if you're planning that far ahead).
* At least two weeks ahead of your release date:
** submit the IP Log for review
** send a link to the release document to rt-...@eclipse.org requesting approval of the documentation and release
* With approvals in hand, we post a review of the release for the community see; we blog, we tweet, etc. to drive some attention to the release.
The IP Log review may require some remediation if we discover any violations of the IP process. This often happens when a project team inadvertently uses a different version of a library than what's approved. But some recent changes to our IP policy should make that less of an issue.
Asking the PMC for approval suggests that there is some possibility that the answer will be no. Theoretically, the PMC may not approve the release, but this should only happen if it is determined that a project isn't operating in a sufficiently open and transparent manner (this certainly doesn't apply to Vert.x). Sometimes the PMC may ask for clarifications of the release record content.
AFAICT, the documentation doesn't describe how somebody gains commit rights. We do this via a committer election. Theoretically, this could be done in a mailing list, but we so have some infrastructure in place to make it theoretically easier on all parties.
The general way that elections are run (this is true for Project Lead elections as well) is that after nomination is posted, the election runs for five business days (effectively a week) or until all committers have voted in favour. After the week, if there are at least three positive votes and no negative votes, the election is deemed successful. In the rare event that somebody votes negative, the rest of the project team has until the end of the voting period to convince them to change their mind. If a project has fewer than three committers, then everybody has to vote yes.
HTH,
Wayne
[1] https://github.com/vert-x3/issues-and-wiki/wiki/Vert.x-Roadmap
[2] https://projects.eclipse.org/projects/technology.egit/releases/4.0.0/bugs
[3] https://github.com/vert-x3/wiki/wiki/Development-Process
[4] https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
[5] https://github.com/vert-x3/wiki/wiki/Release-Process
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5860EE43-1535-4E0F-89E1-243DA7969425%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Max Andersen
Nov 25, 2015, 4:01:02 PM11/25/15
to ve...@googlegroups.com
okey, now behind real keyboard so I can summarize this.
> the project team will have something like a plan
at the beginning of a release cycle.
aka. a link to a roadmap - i.e. issue tracker query about what is coming up in the next release.
I believe vert.x already has this.
I believe vert.x already has this.
> According to the EDP, any major or minor release requires a "Release Review".
Release review is nothing but generate IP log for the project (a push of a button) and send as review to Tools PMC to get a +1.
That is it and it only have to be done for releases that include new functionality.
>The PMC approval requires that the project team create a release record in our system [1] that >describes the release.
See above about link to issue tracker + a one liner or whatever detail wanted about release.
>We ask that project teams make the binary distributions of their official releases available from the >Eclipse Foundation-provided download server.
In short: in the automatic release process add a scp to eclipse download server or publish to eclipse maven repo.
Afaik your build should be able to do this automatically. If not - then lets fix that.
Afaik your build should be able to do this automatically. If not - then lets fix that.
Thus in summary:
Have a roadmap/issue tracker with targeted bugs (already done)
Document that your dependencies and contributions are IP clean
Record it in eclipse foundation system.
That is it.
Wayne Beaton
Nov 25, 2015, 4:04:26 PM11/25/15
to ve...@googlegroups.com
Unless I'm missing something important, we're not talking about
moving all Vert.x repositories to the Eclipse Vert.x project.
The Eclipse Foundation specifically asked that the components included in the "Vert.x min" distribution be moved. I'm hopeful that this represents far fewer than 80 repositories.
Regardless of how many repositories, release reviews are concerned with the project. Even with 80 repositories, it will still just be one project.
Wayne
The Eclipse Foundation specifically asked that the components included in the "Vert.x min" distribution be moved. I'm hopeful that this represents far fewer than 80 repositories.
Regardless of how many repositories, release reviews are concerned with the project. Even with 80 repositories, it will still just be one project.
Wayne
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56561C1C.50202%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Max Andersen
Nov 25, 2015, 4:12:31 PM11/25/15
to ve...@googlegroups.com
Now, back in the real world. It took me around 2 weeks of pain last time I tried it. And that was for a single project, not 80.
It would be great if Julien could give his experience since he have been doing these multiple times now and afaik besides having to deal with a potential IP issue in a library update it have not taken 2 weeks of pain each time.
Julien did it for one project, not 80.
You then assume one github project = one eclipse release review.
I assume (since we never made it into the details yet) that not all 80 make sense to treat as individual eclipse project releases.
Where I think there could be an issue is with the amount of dependencies that needs checking - but I would suggest we actually try *look* at what could be an issue before giving all up ;)
With respect to checking for IP issues in dependencies the question that would be interesting to get an answer to from vert.x users is if they care about knowing dependencies used in Vert.x official distribution are expected to be IP clean or not at release time.
And i'm sure it can be made it even smoother if we actually listed the issues in weed out problem
Please stop working from the assumption that the only option is to adopt the Eclipse process.
Before we even get to that point, you need to make a very good case to the Vert.x community that moving the 99% of Vert.x which is not Eclipse, to Eclipse.
If you can make such a case, and the community agrees that it the way forward then we can start talking about details of project process.
So... over to you guys: Make your case and sell it to us :)
I'm not trying to sell Eclipse to you - I'm simply just trying to point how small a difference there at least seem to be when I try look into it.
Martijn Verburg
Nov 25, 2015, 4:42:08 PM11/25/15
to ve...@googlegroups.com
So I see the IP checking as a value add for Vertx (yeah a lot of developers hate all of that sort of thing, but boy is it needed). If the vert.x community at large were to go with Eclipse I'd recommend a 'trial' so move one or two projects, go through a release and see if it's been improved and whether the IP check (and other? Eclipse benefits) are worth the move.
Cheers,
Martijn
Martijn
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAPN8UD4H6oaBh5oDny9f6E4z6ra3dt3cuA60Czsqib7RE25TcQ%40mail.gmail.com.
Mark Little
Nov 25, 2015, 5:12:19 PM11/25/15
to ve...@googlegroups.com
I want to give a response on behalf of Red Hat. Max has done a great job with his responses but given that he's a Red Hat employee as well as our representative on the Eclipse Foundation Board I understand if at times he might feel a conflict. I have no such conflict to worry about.
Let me start by saying that I believe in Vert.x/Eclipse Vert.x. I worked with Tim and others to bring Vert.x to Eclipse back in 2013 and Tim worked with the Eclipse team as well as the community to identify Eclipse as the right home for the project once it was donated by Pivotal. I think Vert.x has a great future, otherwise I wouldn't have found the money to increase the Red Hat representation in the development effort from 1 to 4 dedicated people and several others who contribute time when they can. I also believe that the Vert.x brand has important value for the community: Tim, Julien and many other non-Red Hat people have evangelised the project so much over the last few years at numerous conferences (including EclipseCon) that it's a well known project and well thought of too. Obvious examples of this benefit are the companies putting Vert.x into production, some of whom are represented on this list. Non-obvious examples include EU research projects such as SERECA (http://www.serecaproject.eu/) which are using Vert.x in their long term research efforts.
I also continue to believe that Eclipse is a good home for the project. Why? Because although the process is more than what you have when just using a vanilla repository, whether git, svn or cvs, for instance, it's there to bring value to users and developers. It may not seem so obvious at first glance, but one of the key values that the process brings is the ability for contributors to know that (versions of) 3rd party components they're contributing to the codebase are free from IP or security issues; there's obviously similar value to users who know that what they've downloaded and deployed into production isn't likely to get them into legal hot water or open up vulnerabilities in their environment. Unless you're just toying with an open source project, hopefully many of you will understand why it's important to have a clear and clean audit of those components you're using or encouraging other groups in your company to use.
Now as I said before, I acknowledge that this process is imposing some overhead. Spending time on releasing a project, checking all the i's and t's etc. is time that isn't being spent cutting code and it's not something everyone wants or likes to do. To a degree I understand why Tim has concerns, but I also understand why we need to do it and why I think it's better to comply than fork the project. However, obviously I want to ensure that Tim isn't overburdened by every release and this is why I found additional funds to hire someone into the Red Hat Vert.x team to take over some or all of this load from Tim and shepherd us all through the process. I hope the community can agree that this is a better way forward if it results in us keeping that community together and happy.
Finally, I know there's been discussion about whether or not Tim's experience was atypical and if so, why? All I can say is that Red Hat has been involved with various other Eclipse Foundation projects including JBoss Tools and the Eclipse BPEL Designer for many years. Experience on those other efforts has not been problematical and we've got a lot of opinionated, skilled people working on them who would definitely say something if they thought the process was too heavyweight and didn't bring value to our communities.
Mark.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4a5141f4-f14b-4a14-b241-17e957cc40ac%40googlegroups.com.
Tim Fox
Nov 25, 2015, 7:55:09 PM11/25/15
to ve...@googlegroups.com
Each repository is a different project.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56562256.1000505%40eclipse.org.
Tim Fox
Nov 25, 2015, 7:56:03 PM11/25/15
to ve...@googlegroups.com
On 25/11/15 20:57, Wayne Beaton wrote:
I'll address the "how is this valuable" question shortly.
Please answer that first.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565620C7.6050602%40eclipse.org.
Tim Fox
Nov 25, 2015, 8:05:03 PM11/25/15
to ve...@googlegroups.com
On 25/11/15 21:41, Martijn Verburg
wrote:
So I see the IP checking as a value add for Vertx (yeah a lot of developers hate all of that sort of thing, but boy is it needed).
Bear in mind, that even without the extra level of IP checking that
you get from Eclipse (and you don't get anywhere else) we are
already very clean with respect to IP and license compatibility,
probably better than 90% of open source projects and to the level of
anything you get from Apache.
I have yet to find a single user who requires the level of IP cleanliness that Eclipse guarantees. If that user existed they wouldn't be using anything other than Eclipse software, because it's only Eclipse that provides that.
I have yet to find a single user who requires the level of IP cleanliness that Eclipse guarantees. If that user existed they wouldn't be using anything other than Eclipse software, because it's only Eclipse that provides that.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAP7YuAReOTQmkWRGV2M9SwCqBs9J%2BrV5S6mGO-WucUzgSkkpEQ%40mail.gmail.com.
jordan.h...@gmail.com
Nov 25, 2015, 9:39:44 PM11/25/15
to ve...@googlegroups.com
I, too, am waiting for clarity on the value provided given the apparently significant overhead such regulations imply. I agree that there's some value added in IP protection, but that alone is certainly not enough to justify the potential cost to community morale and future development. I worry the process will only turn us into a bureaucracy, and I'm not sure what existing problem we solve by putting up red tape.
Things are going well. What problem are we trying to solve?
Over the years, I've contributed a lot of time, code, and projects to Vert.x, including developing and maintaining code that would likely be included in this review and release process. I don't work at Red Hat or a company that currently supports full-time Vert.x development, and I work on a variety of open source projects both within and without the Vert.x community. So I have to ask myself: how does this change my thought process around contributing code to parts of the Vert.x project that fall under the Eclipse umbrella? I'd like to be able to share my expertise in some of the Vert.x projects that have historically been neglected but for me (and thankfully now a few others) spending a few extra hours here and there to develop and maintain them. I do that because I like Vert.x and the community, I want to see it succeed, and I want to influence its direction and make it accessible to more users. But I'm not sure it's worth a few more hours to deal with the added bureaucracy when a few hours is all I have.
From the perspective of planning, review, and release, it may seem like managing Vert.x core and all the smaller projects as a single monolithic Eclipse project would streamline the process, but I tend to think the opposite. The independence of each of the projects and their maintainers is what allows development to progress asynchronously and efficiently. That development model allows people like me to contribute when possible without too much concern for negatively impacting the development of Vert.x core. I'm worried that the added bureaucracy implies a need for a lot more spare time than I currently have.
So, if this plan were implemented and I were to want to develop, say, another language module or a cluster manager for Vert.x, would I do it? Sure I would. Would I contribute it to the Vert.x community? Yep. Would I offer it to the Vert.x GitHub organization and volunteer to maintain it under Eclipse's guidelines? Considering the added overhead that implies compared to maintaining it under my own account or organization and the lack of clear and significant added value (which could change), probably not. I think I have enough credibility for my language implementation or cluster manager to do just fine without having to go through the hassle of contributing it to Eclipse.
Vert.x has proven that it can stand on its own to this point without the help of Eclipse. To be honest, I'd like to see Vert.x finally free itself from the shackles of burdensome organizations and their overzealous lawyers. The code and the people that build and use it are what matters most, and so the solution should be about promoting code and its authors and users. It's clear how this helps the Eclipse Foundation. But in the age of social coding, how does this help Vert.x, its developers, and it's users?
Again, what problem are we trying to solve?
Jordan Halterman
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565658A1.8050800%40gmail.com.
Wayne Beaton
Nov 25, 2015, 10:01:42 PM11/25/15
to ve...@googlegroups.com
Why is that?
AFAICT, the only thing that might motivate this is that the different
repositories involved have different teams.
An Eclipse project has only one team and access to the different
functional areas (components) within a project is managed via social
convention.
If you are concerned that developers can't be trusted to stay within
their designated functional areas, we can set up subprojects managed via
the central project with no additional ongoing overhead.
Wayne
On 25/11/15 07:55 PM, Tim Fox wrote:
> Each repository is a different project.
AFAICT, the only thing that might motivate this is that the different
repositories involved have different teams.
An Eclipse project has only one team and access to the different
functional areas (components) within a project is managed via social
convention.
If you are concerned that developers can't be trusted to stay within
their designated functional areas, we can set up subprojects managed via
the central project with no additional ongoing overhead.
Wayne
On 25/11/15 07:55 PM, Tim Fox wrote:
> Each repository is a different project.
Wayne Beaton
Nov 25, 2015, 11:04:41 PM11/25/15
to ve...@googlegroups.com
On 25/11/15 07:56 PM, Tim Fox wrote:
On 25/11/15 20:57, Wayne Beaton wrote:
I'll address the "how is this valuable" question shortly.
Please answer that first.
Ok...
I put this off because I wanted to read through the thread that resulted in the decision to move the project to the Eclipse Foundation [1].
I believe that Eclipse was selected for two reasons: a vendor neutral foundation prevents any single entity from dominating the project; and
That Eclipse has a well-defined governance model was cited in the discussion as a valuable part of introducing Vert.x into large enterprises and a means of protecting the project from domination by any single entity. The IP Due Diligence process was also cited as a valuable service provided by the Eclipse Foundation.
The Eclipse Development Process (EDP) describes the governance model that ensures that the project continues to operate in an open, transparent, and vendor-neutral manner. It describes, for example, project lifecycle, how the meritocracy/election process works, the nature of releases, and the various sorts of reviews that we engage in. The IP Due Diligence and record keeping process ensure that IP is properly tracked and used.
The Eclipse processes provide the sort of governance that the sort of large enterprises that you want to have a foothold in look for.
HTH,
Wayne
[1] https://groups.google.com/forum/#!topic/vertx/WIuY5M6RluM
[2] https://groups.google.com/d/msg/vertx/WIuY5M6RluM/AW4_p7ckRRkJ
I put this off because I wanted to read through the thread that resulted in the decision to move the project to the Eclipse Foundation [1].
I believe that Eclipse was selected for two reasons: a vendor neutral foundation prevents any single entity from dominating the project; and
Eclipse is perhaps a little more "business friendly" and that's going to be an important thing for Vert.x as we progress if we want to get a foothold in large enterprises. [2]That choice was made after a lengthy discussion of the nature of the processes and services provided by the Eclipse Foundation and the obligations of a project hosted here.
That Eclipse has a well-defined governance model was cited in the discussion as a valuable part of introducing Vert.x into large enterprises and a means of protecting the project from domination by any single entity. The IP Due Diligence process was also cited as a valuable service provided by the Eclipse Foundation.
The Eclipse Development Process (EDP) describes the governance model that ensures that the project continues to operate in an open, transparent, and vendor-neutral manner. It describes, for example, project lifecycle, how the meritocracy/election process works, the nature of releases, and the various sorts of reviews that we engage in. The IP Due Diligence and record keeping process ensure that IP is properly tracked and used.
The Eclipse processes provide the sort of governance that the sort of large enterprises that you want to have a foothold in look for.
HTH,
Wayne
[1] https://groups.google.com/forum/#!topic/vertx/WIuY5M6RluM
[2] https://groups.google.com/d/msg/vertx/WIuY5M6RluM/AW4_p7ckRRkJ
Jordan Halterman
Nov 26, 2015, 12:34:01 AM11/26/15
to ve...@googlegroups.com
Thanks Wayne,
I think what is in the Vert.x min distribution is probably manageable even if we assume a poor process (for argument's sake, not because it's true). But how does Eclipse decide what projects must be included in this process, and why must they be included? In other words, how can we be sure that Eclipse won't assert its authority over the other distributions which are potentially much larger, consist of many more repositories and their authors, maintainers, and contributors, and are growing at a much faster rate? What does Eclipse typically require of other projects with multiple distributions and multiple repositories? Can we ultimately expect the same demands for Vert.x?
I don't think the naming changes are unreasonable as it is an Eclipse project. There has never seemed to exist much resistance to Vert.x core (http://github.com/eclipse/vert.x) going through the necessary planning, review, and release processes. Similarly, I doubt there would be much resistance to improving the collaboration there. But I have to wonder what this ultimately could mean for all Vert.x projects in the future.
Jordan Halterman
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565684D3.7030708%40eclipse.org.
Michael Scholz
Nov 26, 2015, 1:34:55 AM11/26/15
to vert.x
This is a fun thread. I am not a contributor and barely a member of the community, but I follow this group in case something interesting happens. Like today!
The Eclipse OP is about the changes they need to occur to resolve the differences between Eclipse’s expectations and the current reality. I especially like the implication that vert.x’s “Eclipse experience” is lacking. Someone without knowledge of open source software foundations might think of *that* IDE as the strongest association with that brand name, and not necessarily favorably.
The requested changes seem fourfold:
1. move more repos under the eclipse umbrella with associated benefits/friction
2. Participate better in three letter acronym processes with respect to reviewing releases; with the stated goals of transparency and IP legitimacy
3. “Fix” the branding such that it’s Eclipse Vert.x everywhere, and call out the exceptions
4. Link to Eclipse pages and show trademarks
I initially thought Tim’s negativity was an overreaction, but I can see it’s justified. My opinion, which I expect is in the majority, is that everything has been proceeding well to date, the stewardship of vert.x is the best it has ever been; so please do not change anything. And especially do not lose Tim’s (or Red Hat’s) support, without whom we would be discussing a far lesser technology.
The requested changes seem fourfold:
1. move more repos under the eclipse umbrella with associated benefits/friction
2. Participate better in three letter acronym processes with respect to reviewing releases; with the stated goals of transparency and IP legitimacy
3. “Fix” the branding such that it’s Eclipse Vert.x everywhere, and call out the exceptions
4. Link to Eclipse pages and show trademarks
I initially thought Tim’s negativity was an overreaction, but I can see it’s justified. My opinion, which I expect is in the majority, is that everything has been proceeding well to date, the stewardship of vert.x is the best it has ever been; so please do not change anything. And especially do not lose Tim’s (or Red Hat’s) support, without whom we would be discussing a far lesser technology.
So I would somewhat discourage Eclipse’s requested changes. Maybe it makes sense to consolidate Vertx-min into Eclipse GitHub - but draw the line there. If there’s boilerplate release review participation that needs to be stepped up, I am happy RedHat’s willing to put a body on it instead of Tim. (I think IP cleanness would be audited independently by the type of companies with those concerns. I don’t think of it as a benefit worthy of the cost)
The branding thing smells bad. Maybe it is a common requirement to crap out Apache or Eclipse all over marketing and press; but that’s not building up the vert.x brand, it’s diminishing it by associating it as an owned thing. I think Akka has more ‘mindshare’ than vert.x; and we can’t compete if we trying to sell the brand ‘eclipse vert.x’ versus the simpler ‘akka’. I don't think pre-pending Eclipse makes vert.x branding more marketable.
If Eclipse was supporting vert.x with a nontrivial marketing budget, then yeah, I’d get behind it. But it’s Red Hat that spends the money. Eclipse is just hosting and holding the legal reins and providing the IP assurance to hypothetical customers. The worst thing they could do is take away the hosting and the name. But that’s a lever they cannot pull, because they need the vert.x community’s support, without which they have nothing.
If Red Hat maintains faith in the Eclipse umbrella, then might as well stay put; especially as they're willing to put resources against the process items. But I don’t like the branding push without added marketing value. And most repos need to stay github, just for sanity’s sake.
M
M
Julien Ponge
Nov 26, 2015, 3:04:16 AM11/26/15
to ve...@googlegroups.com
Hi,
I am among those who don’t see much value in a “vert.x min” distribution. This is mostly because I like to see vert.x as a minimal core surrounded with focused modules, and that just does the work wonderfully if you ask me. In practice this means that vert.x and modules come as project dependencies, and there is not interest for me in downloading some kind of distribution.
It’s quite like Aether: the Eclipse Foundation does not require Maven and the whole plugin ecosystem to be Eclipse projects. (ok that’s a funny case if you dig a bit)
I believe that vert.x strives in having that rich modules ecosystem run as independent projects. Many of this projects cannot be Eclipse projects for obvious governance, maturity and licensing reasons, and that is very very fine.
That being said I also believe that a set of modules could easily join the rt/vert.x umbrella as separate Git repositories. I am especially thinking about those being prominent in the http://vertx.io documentation (vertx-web, vertx-unit, etc) especially as they match the release cycle of vert.x anyway.
Having a set of essential modules at Eclipse would also reinforce the commitment to vert.x being an Eclipse project. And that would not prevent a vibrant ecosystem to gravitate around it.
Now back to the requirement of having distributions then although I am not the target of this, perhaps vert.x could have a vertx shell subcommand for downloading modules from a repository. That would fit a vert.x platform / app server vision nicely.
Of course in terms of engineering history has shown that modular generic platforms do not come for free, but something simple like “just” a repository service that points to Maven artefacts could do the job (if anyone can bear with Aether, its peculiar API and dependencies set, but again I digress).
In that case you could ship vertx-core and the essential modules under the rt/vert.x umbrella, and the rest would be available from the distribution through some registry. Just like, say, Gradle does with a public index to independent project artefacts.
I nearly forgot the discussion around the Eclipse development process. Yes it comes with added bureaucracy, but that was clear from the start, right?
From what I can observe as an incubating project lead Eclipse *is* listening and making progress (e.g., we can avoid Bugzilla if it doesn’t fit us). CQs processing remains the biggest pain point, though. Resolution timeframe remains unpredictable, and having to upload public projects code as Bugzilla attachments, is, well… yes bureaucratic.
Hope this helps :-)
- Julien
I am among those who don’t see much value in a “vert.x min” distribution. This is mostly because I like to see vert.x as a minimal core surrounded with focused modules, and that just does the work wonderfully if you ask me. In practice this means that vert.x and modules come as project dependencies, and there is not interest for me in downloading some kind of distribution.
It’s quite like Aether: the Eclipse Foundation does not require Maven and the whole plugin ecosystem to be Eclipse projects. (ok that’s a funny case if you dig a bit)
I believe that vert.x strives in having that rich modules ecosystem run as independent projects. Many of this projects cannot be Eclipse projects for obvious governance, maturity and licensing reasons, and that is very very fine.
That being said I also believe that a set of modules could easily join the rt/vert.x umbrella as separate Git repositories. I am especially thinking about those being prominent in the http://vertx.io documentation (vertx-web, vertx-unit, etc) especially as they match the release cycle of vert.x anyway.
Having a set of essential modules at Eclipse would also reinforce the commitment to vert.x being an Eclipse project. And that would not prevent a vibrant ecosystem to gravitate around it.
Now back to the requirement of having distributions then although I am not the target of this, perhaps vert.x could have a vertx shell subcommand for downloading modules from a repository. That would fit a vert.x platform / app server vision nicely.
Of course in terms of engineering history has shown that modular generic platforms do not come for free, but something simple like “just” a repository service that points to Maven artefacts could do the job (if anyone can bear with Aether, its peculiar API and dependencies set, but again I digress).
In that case you could ship vertx-core and the essential modules under the rt/vert.x umbrella, and the rest would be available from the distribution through some registry. Just like, say, Gradle does with a public index to independent project artefacts.
I nearly forgot the discussion around the Eclipse development process. Yes it comes with added bureaucracy, but that was clear from the start, right?
From what I can observe as an incubating project lead Eclipse *is* listening and making progress (e.g., we can avoid Bugzilla if it doesn’t fit us). CQs processing remains the biggest pain point, though. Resolution timeframe remains unpredictable, and having to upload public projects code as Bugzilla attachments, is, well… yes bureaucratic.
Hope this helps :-)
- Julien
Mark Little
Nov 26, 2015, 3:06:51 AM11/26/15
to ve...@googlegroups.com
If you check through this group’s archives for around February/March 2013 you’ll get more context on why Vert.x ended up at Eclipse on the recommendations of Tim, the community at the time, Pivotal and Red Hat. We (Red Hat) continue to stand by that decision. When creating new open source projects or moving an existing project, we have a set of rules for where the project can reside; these rules have been defined over the years based on legal, community and developer feedback as well as mistakes we and others have made in the past with a few other projects. I won’t go into the specifics of the rules, but in short we prefer foundations such as Eclipse or Apache if the project is not being maintained under Red Hat governance. They provide value add to our communities and customers, including IP clearance (Apache has similar http://incubator.apache.org/ip-clearance/), vendor neutrality and PR (ever been to an EclipseCon?) Red Hat governance of a project imposes very similar requirements and benefits.
Unfortunately I’m unable to participate in these discussions as much or as frequently as others can due to travel and the fact we’re in the midst of financial planning for next year (and further Vert.x investment features in those plans). I’ve seen people push back on the Eclipse process and ask why additional overhead or bureaucracy is required, which is a good question to ask. I’ve seen Max suggest we try to map the existing processes to what the Eclipse Foundation have requested. We should do that because one thing I’ve not see called out clearly and explicitly here is precisely what it is in those requirements that represents this additional overhead or bureaucracy. Let’s itemise these things and go through them one at a time.
Mark.
Tim Fox
Nov 26, 2015, 3:53:39 AM11/26/15
to ve...@googlegroups.com
On 26/11/15 08:06, Mark Little wrote:
If you check through this group’s archives for around February/March 2013 you’ll get more context on why Vert.x ended up at Eclipse on the recommendations of Tim, the community at the time, Pivotal and Red Hat.
At the time I didn't have much choice. VMware (Pivotal didn't exist
then) would have accepted Apache or Eclipse. Red Hat preferred
Eclipse.
I really regret recommending Eclipse. If I could turn back the clock I certainly wouldn't recommend Eclipse again.
I really regret recommending Eclipse. If I could turn back the clock I certainly wouldn't recommend Eclipse again.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/35EAF37F-DE07-4494-B95E-DE3347360D19%40gmail.com.
Tim Fox
Nov 26, 2015, 4:08:07 AM11/26/15
to ve...@googlegroups.com
Thank you Jordan for putting it more
eloquently than I could.
"Again, what problem are we trying to solve?"
Vert.x is doing better than it ever has - we have a thriving
community and more hits to the web-site than ever before. We have
a growing list of production customers. All of this done without
the help of Eclipse. Things are looking good for Vert.x!
As far as I can tell *we're doing pretty well*. So why is an intervention by Eclipse necessary? What is it we're doing so wrong that needs fixing so badly? Please educate me.
I really can't see what Eclipse brings to the table here, but I can see what it hopes to gain by selfishly riding on the coat-tails of Vert.x.
I think Eclipse needs to back off and respect the Vert.x community a bit. Ownership of trademark doesn't mean ownership of community. Maybe in the process it can learn a bit about how to grow communities effectively.
As far as I can tell *we're doing pretty well*. So why is an intervention by Eclipse necessary? What is it we're doing so wrong that needs fixing so badly? Please educate me.
I really can't see what Eclipse brings to the table here, but I can see what it hopes to gain by selfishly riding on the coat-tails of Vert.x.
I think Eclipse needs to back off and respect the Vert.x community a bit. Ownership of trademark doesn't mean ownership of community. Maybe in the process it can learn a bit about how to grow communities effectively.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/B381B356-68F0-420D-BBBF-31D261FB09A6%40gmail.com.
Tim Fox
Nov 26, 2015, 4:14:02 AM11/26/15
to ve...@googlegroups.com
On 25/11/15 18:40, Max Rydahl Andersen
wrote:
Btw. I do agree Wayne should comment on what the expected value is from this.
Just saying that I don't believe the current vertx process is *that* far from what EDP outlines. Main diff is that dependencies are checked for possible IP issues.
The only possible value add of Eclipse is the extra IP checks.
But I find this argument rather bogus. No other organisation does IP checks like Eclipse - certainly not Apache or Red Hat/JBoss. The non Eclipse parts of Vert.x have IP cleanliness at least to the level of any Apache or Red Hat project which is probably better than 99% of the stuff you find on GitHub. I don't see people rejecting Apache or Red Hat projects because the IP isn't clean enough and I've yet to find a single user who has rejected the non Eclipse parts of Vert.x because it hasn't gone through the Eclipse IP checks.
The Eclipse IP checks seem to be a solution looking for a problem.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/AD374CF2-7450-47BC-88FF-89F084CD2C95%40gmail.com.
Max Rydahl Andersen
Nov 26, 2015, 4:44:00 AM11/26/15
to vert.x
Thanks Julien!
Your mail outlines the same/similar suggestions and ideas I have sent to Tim in past to suggest ways to handle the upfront known requirements of being an Eclipse project.
I would love to work with someone in the vert.x community on figuring out what is possible here to adjust/change.
Just like I have worked with Eclipse Foundation on changing and adjusting their approach to accommodate for the changing world of lets call it "ultra-social" software projects - very much based on feedback from Tim and others.
And I believe I (together with others) have already had a lot of headway on the Eclipse Foundation side - now I would just like to move the needle some more; but for that I need to go deeper *together* with someone in the Vert.x community that are willing to help explore what options are there.
Anyone interested ?
Your mail outlines the same/similar suggestions and ideas I have sent to Tim in past to suggest ways to handle the upfront known requirements of being an Eclipse project.
I would love to work with someone in the vert.x community on figuring out what is possible here to adjust/change.
Just like I have worked with Eclipse Foundation on changing and adjusting their approach to accommodate for the changing world of lets call it "ultra-social" software projects - very much based on feedback from Tim and others.
And I believe I (together with others) have already had a lot of headway on the Eclipse Foundation side - now I would just like to move the needle some more; but for that I need to go deeper *together* with someone in the Vert.x community that are willing to help explore what options are there.
Anyone interested ?
Max Rydahl Andersen
Nov 26, 2015, 4:53:50 AM11/26/15
to vert.x
On Thursday, November 26, 2015 at 10:44:00 AM UTC+1, Max Rydahl Andersen wrote:
Thanks Julien!
Your mail outlines the same/similar suggestions and ideas I have sent to Tim in past to suggest ways to handle the upfront known requirements of being an Eclipse project.
I would love to work with someone in the vert.x community on figuring out what is possible here to adjust/change.
Just like I have worked with Eclipse Foundation on changing and adjusting their approach to accommodate for the changing world of lets call it "ultra-social" software projects - very much based on feedback from Tim and others.
And I believe I (together with others) have already had a lot of headway on the Eclipse Foundation side - now I would just like to move the needle some more; but for that I need to go deeper *together* with someone in the Vert.x community that are willing to help explore what options are there.
Anyone interested ?
to be clear - the options I'm talking about is how to map vert.x existing process and distro to something that fits within Eclipse projects.
Eclipse Foundation said many times that if we can come with concrete issues they are happy to change/update guidelines/automation.
Julien Ponge
Nov 26, 2015, 5:00:55 AM11/26/15
to ve...@googlegroups.com
I’ve gotten to grips with the Eclipse development process so I can share thoughts if you ask me, but I don’t feel like I can speak for the Vert.x community. An independent regular contributor would be a nice fit.
- Julien
- Julien
> --
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/2a808a21-13b9-4c5b-9975-d49400b788c9%40googlegroups.com.
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
Mumuney Abdlquadri
Nov 26, 2015, 5:22:40 AM11/26/15
to ve...@googlegroups.com
Dear Max,
"Eclipse Foundation said many times that if we can come with concrete
issues they are happy to change/update guidelines/automation."
Can they allow us retain our name? "Eclipse Vert.x" is so horrible to pronounce.
Also why does everything in Vert.x-min be moved to Eclipse.
Vert.x-core is a useable software. I have built TCP-servers with it.
That should be enough. All other things are just modules. Some are
official because the core-team members have committed to supporting
them directly. Nothing more.
Lastly, I believe Tim is speaking for the community here because
RedHat can (and has) employed more people to offload his burden. So if
you are in the community and do not understand all these jargons.
Speak up now!
Thanks.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6CAFCC37-E569-4D73-A808-26F7D5A15A71%40ponge.org.
"Eclipse Foundation said many times that if we can come with concrete
issues they are happy to change/update guidelines/automation."
Also why does everything in Vert.x-min be moved to Eclipse.
Vert.x-core is a useable software. I have built TCP-servers with it.
That should be enough. All other things are just modules. Some are
official because the core-team members have committed to supporting
them directly. Nothing more.
Lastly, I believe Tim is speaking for the community here because
RedHat can (and has) employed more people to offload his burden. So if
you are in the community and do not understand all these jargons.
Speak up now!
Thanks.
Julien Ponge
Nov 26, 2015, 6:11:20 AM11/26/15
to ve...@googlegroups.com
> Can they allow us retain our name? "Eclipse Vert.x" is so horrible to pronounce.
I guess you say “Maven”, not “Apache Maven” :-)
If I recall right the foundation does not ask for a systematic usage of “Eclipse Vert.x”, only the first occurence in materials. And that does not preclude from the community to be the “Vert.x community”.
- Julien
Mark Little
Nov 26, 2015, 6:24:16 AM11/26/15
to ve...@googlegroups.com
Red Hat does very strict IP checks for all of our projects and products. It’s a core part of our business model and one our customers and communities rely upon. The only difference is you don’t see it because this is an Eclipse project not a Red Hat project/product. It’s part of the reason we are able to indemnify our users (https://www.redhat.com/en/about/open-source-assurance-agreement).
And Apache does IP checking too.
Mark.
And Apache does IP checking too.
Mark.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5656CD59.1010707%40gmail.com.
Tim Fox
Nov 26, 2015, 6:40:29 AM11/26/15
to ve...@googlegroups.com
On 26/11/15 11:24, Mark Little wrote:
Red Hat does very strict IP checks for all of our projects and products. It’s a core part of our business model and one our customers and communities rely upon. The only difference is you don’t see it because this is an Eclipse project not a Red Hat project/product. It’s part of the reason we are able to indemnify our users (https://www.redhat.com/en/about/open-source-assurance-agreement).
And Apache does IP checking too.
Apache doesn't do much more than check the license is compatible,
which is what we do anyway. So it's on the same level. As far as I
am concerned if it's good enough for Apache it's good enough for
Vert.x
AIUI the Red Hat open source assurance applies to Red Hat _products_ not projects. If Vert.x got into a Red Hat product it would go through a more detailed Red Hat IP check anyway, which kind of makes the Eclipse checks redundant.
AIUI the Red Hat open source assurance applies to Red Hat _products_ not projects. If Vert.x got into a Red Hat product it would go through a more detailed Red Hat IP check anyway, which kind of makes the Eclipse checks redundant.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/DB7880F0-CC13-4228-B75F-5C644AFF496B%40gmail.com.
Mark Little
Nov 26, 2015, 6:40:40 AM11/26/15
to ve...@googlegroups.com
Probably like you I’d prefer if this was someone who was not a Red Hat employee just so there’s no possible bias. However, if no one comes forward then I’m also sure that we could get one of the Red Hat Vert.x team to work with you on this and rely on them to remain objective.
Despite the fact that this group has only become aware of these issues in the last day or so, I know Tim, you, various folks from Eclipse and others in Red Hat have been trying to work through this for months and come to a resolution. And despite all of that I’m still no clearer on why there is the presumption of additional overhead, so selfishly I’d love to see the results of this effort. I agree with the underlying theme of Tim’s concern, that adding process for the sake of process doesn’t help a project to thrive, but I’m just not convinced that’s the case here. However, I am admitting that I may not understand all of the subtle nuances so would love to be educated.
Finally I’d also like to understand from where this number of 80 projects having to move under the Eclipse process comes. I realise this may be the total number of Vert.x related projects out there, but I didn’t think that was the actual number that was required to move. Again, maybe someone can shed some light on this number and/or define what is a minimal-viable Eclipse Vert.x distribution?
Mark.
Despite the fact that this group has only become aware of these issues in the last day or so, I know Tim, you, various folks from Eclipse and others in Red Hat have been trying to work through this for months and come to a resolution. And despite all of that I’m still no clearer on why there is the presumption of additional overhead, so selfishly I’d love to see the results of this effort. I agree with the underlying theme of Tim’s concern, that adding process for the sake of process doesn’t help a project to thrive, but I’m just not convinced that’s the case here. However, I am admitting that I may not understand all of the subtle nuances so would love to be educated.
Finally I’d also like to understand from where this number of 80 projects having to move under the Eclipse process comes. I realise this may be the total number of Vert.x related projects out there, but I didn’t think that was the actual number that was required to move. Again, maybe someone can shed some light on this number and/or define what is a minimal-viable Eclipse Vert.x distribution?
Mark.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0fe69646-6604-4650-a72e-d4e3a777ede7%40googlegroups.com.
Tim Fox
Nov 26, 2015, 6:48:19 AM11/26/15
to ve...@googlegroups.com
On 26/11/15 11:40, Mark Little wrote:
Probably like you I’d prefer if this was someone who was not a Red Hat employee just so there’s no possible bias. However, if no one comes forward then I’m also sure that we could get one of the Red Hat Vert.x team to work with you on this and rely on them to remain objective.
Despite the fact that this group has only become aware of these issues in the last day or so, I know Tim, you, various folks from Eclipse and others in Red Hat have been trying to work through this for months and come to a resolution. And despite all of that I’m still no clearer on why there is the presumption of additional overhead, so selfishly I’d love to see the results of this effort. I agree with the underlying theme of Tim’s concern, that adding process for the sake of process doesn’t help a project to thrive, but I’m just not convinced that’s the case here. However, I am admitting that I may not understand all of the subtle nuances so would love to be educated.
Finally I’d also like to understand from where this number of 80 projects having to move under the Eclipse process comes. I realise this may be the total number of Vert.x related projects out there, but I didn’t think that was the actual number that was required to move. Again, maybe someone can shed some light on this number and/or define what is a minimal-viable Eclipse Vert.x distribution?
Here is a minimal viable distribution of Vert.x:
http://repo1.maven.org/maven2/io/vertx/vertx-core/3.1.0/vertx-core-3.1.0.jar
Vert.x core is perfectly usable by itself, and that's already an Eclipse project, so if it's just about a "minimal viable distribution" we don't need to do move anything else to Eclipse.
http://repo1.maven.org/maven2/io/vertx/vertx-core/3.1.0/vertx-core-3.1.0.jar
Vert.x core is perfectly usable by itself, and that's already an Eclipse project, so if it's just about a "minimal viable distribution" we don't need to do move anything else to Eclipse.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/82EDADD9-BE91-41B8-9076-2120ED264980%40gmail.com.
Mark Little
Nov 26, 2015, 7:19:04 AM11/26/15
to ve...@googlegroups.com
We do a lot of IP checking for our projects these days too. Checking versions, building from source for certain releases, maintaining and supporting multiple branches concurrently etc. I don’t want this to become an advert for Red Hat though :)
Mark.
Mark.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5656EFA5.8030308%40gmail.com.
Martijn Verburg
Nov 26, 2015, 11:02:30 AM11/26/15
to ve...@googlegroups.com
Putting on my "I'm a vert.x user and its strategically impt to me" hat. As one data point - we don't need Eclipse's level of IP checking, but we need something pretty close to it, Eclipse checking it for me takes that burden away....
Cheers,
Martijn
Martijn
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56565ABC.9090901%40gmail.com.
jordan.h...@gmail.com
Nov 26, 2015, 5:37:42 PM11/26/15
to ve...@googlegroups.com
I think additional overhead is only part of it. The point with respect to overhead is not necessarily even that this change would definitely represent an insurmountable strain on the community, it's that it *could* represent an additional strain when there's nothing wrong with the existing process from the perspective of Vert.x's development, success, stability, and it's users. That is, there's *no* potential benefit to the added process for process's sake, as you call it, because there's nothing wrong with the current process. Therefore, there is *only* potential risk. Thus, if we're implementing process for process's sake, we're also apparently taking on risk for risk's sake. To what end? Presumably to benefit the Eclipse Foundation at the potential expense of Vert.x.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/82EDADD9-BE91-41B8-9076-2120ED264980%40gmail.com.
Mark Little
Nov 27, 2015, 3:00:29 AM11/27/15
to ve...@googlegroups.com
OK so first of all I think people need to stop painting Eclipse as the bad guy here. Go check the archives and re-read what I said yesterday: Eclipse was chosen by everyone involved in 2013 and there was an education effort about processes and requirements for the team, Pivotal and community both before the decision and after. As far as I can see all they’re trying to do is get us all to follow through on that agreement, and as Tim mentioned Eclipse is within their legal rights to do this. I’d much prefer it if we kept to the facts and unless someone from Eclipse turns around and explicitly states this is part of some grand evil plan to take over the Universe, we should give everyone the benefit of the doubt that they’re just trying to do the right thing. We should all try to work together collaboratively to figure out a path through this.
Secondly, it is wrong to suggest that there is no potential benefit to being in Eclipse. Myself and others have already mentioned several, including improved visibility/PR and IP checking. Red Hat views that latter bit as extremely important and it is definitely one of the reasons we have been able to increase our investments in Vert.x - companies which are not necessarily able to be vocally represented on this list find it easier to adopt projects that are known a priori to not be IP encumbered. As a developer, I’ll take upstream projects and use them in POCs without necessarily worrying too much about IP, but if I’m putting something into production I do want to know about IP; it’s an unfortunate fact that we live in a world where enforcing IP is often a daily reality.
We could continue to argue about the potential strain on process that additional overhead could or could not bring, but until someone does the mapping it’s all theoretical. As I said, if no one in the community wants to help Max get to the facts then we’ll do that ourselves and present it here.
Oh and in case people like myself were wondering about further responses from Eclipse, I suspect they’re delayed due to Thanksgiving holiday in the US.
Mark.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/13E3BBD3-2325-469E-839E-50EB9811E6F9%40gmail.com.
Ryan Chazen
Nov 27, 2015, 4:35:58 AM11/27/15
to vert.x
It seems like the main issue here is that Eclipse is demanding unpaid contributors to do bureaucratic work when they already have minimal time to contribute to real improvements when the bureaucratic work won't benefit them.
The solution seems pretty simple - vert.x contribution should continue identically to how it is now, but Eclipse and/or Redhat needs to hire additional employees to handle all of the beurocracy and maintain their own vertx-min project that is independent from the actual vert.x contribution community. That way vert.x releases can continue as they are now, and Eclipse Vert.x Enterprise releases can be made by Eclipse specific developers who will take the raw vert.x and go through the process of making it comply without any distractions to the real contributors.
If necessary, the community vert.x could rename to vert.x-community or vert.y or something and continue as before with Eclipse Vert.x handling the vert.x branding and official enterprise releases and IP issues. That seems to be best for everyone - everyone gets the improved code made possible by the community process, and enterprise customers and others who require the IP guarantees get those (albeit with slightly delayed release cycle). The cost to Eclipse/Redhat of the additional hires would surely be easily offset by large enterprise support plans so the resources shouldn't be an issue. Again, Eclipse/Redhat benefit from this just as much from the increased community contributions and quicker community evolution.
The solution seems pretty simple - vert.x contribution should continue identically to how it is now, but Eclipse and/or Redhat needs to hire additional employees to handle all of the beurocracy and maintain their own vertx-min project that is independent from the actual vert.x contribution community. That way vert.x releases can continue as they are now, and Eclipse Vert.x Enterprise releases can be made by Eclipse specific developers who will take the raw vert.x and go through the process of making it comply without any distractions to the real contributors.
If necessary, the community vert.x could rename to vert.x-community or vert.y or something and continue as before with Eclipse Vert.x handling the vert.x branding and official enterprise releases and IP issues. That seems to be best for everyone - everyone gets the improved code made possible by the community process, and enterprise customers and others who require the IP guarantees get those (albeit with slightly delayed release cycle). The cost to Eclipse/Redhat of the additional hires would surely be easily offset by large enterprise support plans so the resources shouldn't be an issue. Again, Eclipse/Redhat benefit from this just as much from the increased community contributions and quicker community evolution.
S
Nov 27, 2015, 8:20:55 AM11/27/15
to vert.x
Where do we stand now with the discussion? This is my understanding:
- there's no other project needed to move to Eclipse, so no more overhead (than it already is)
- only this project needs to do s/vert.x/eclipse vert.x/, hardly a killer
- I don't think Eclipse can impose to any not-Eclipse project how they choose to call vert.x, so this point is useless
- checking the IP is valuable for everybody and as I can see above hardly more effort
- ...whatever.
So why all the fuss? There's only ONE real problem which triggered the entire thread, namely that Tim needed two painful weeks for that ominous first release. Unfortunately I still see nothing about that source event, only fuzzy stuff and certainly not a list of real things which went sour. Sorry folks but "it was awful" is nothing one can work with and improve. Does anybody care to write down:
- what went wrong, so we can see was it because vert.x way or because of Eclipse way, and decide whether it can be done better/different
- is it expected to happen again, so we can understand was it by design or by omission of either side
- there's no other project needed to move to Eclipse, so no more overhead (than it already is)
- only this project needs to do s/vert.x/eclipse vert.x/, hardly a killer
- I don't think Eclipse can impose to any not-Eclipse project how they choose to call vert.x, so this point is useless
- checking the IP is valuable for everybody and as I can see above hardly more effort
- ...whatever.
So why all the fuss? There's only ONE real problem which triggered the entire thread, namely that Tim needed two painful weeks for that ominous first release. Unfortunately I still see nothing about that source event, only fuzzy stuff and certainly not a list of real things which went sour. Sorry folks but "it was awful" is nothing one can work with and improve. Does anybody care to write down:
- what went wrong, so we can see was it because vert.x way or because of Eclipse way, and decide whether it can be done better/different
- is it expected to happen again, so we can understand was it by design or by omission of either side
S
Nov 27, 2015, 8:25:34 AM11/27/15
to vert.x
PS: I volunteer to do the Eclipse vert.x replacements in the eclipse/vert.x GitHub repo (if there's more, let me know and I'll see what I can do).
I'm just not sure there's an agreement yet about it.
I'm just not sure there's an agreement yet about it.
Wayne Beaton
Nov 27, 2015, 2:59:56 PM11/27/15
to ve...@googlegroups.com
I can confirm that there is no evil plan.
The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community and accept Vert.x as an Eclipse project.
Part of the trademark ownership part is managing the trademark. For that--like many (most?) other organizations--we have trademark usage guidelines [1]. Trademark law manifests in interesting ways; our "Java development tools" project, for example must use lower-case letters on "development tools" to avoid violating Oracle's Java (tm) trademark.
I can assure you that we have no designs on taking over the Vert.x community. I have no idea, frankly, how we'd even do this if we wanted to (which we don't). My ideal would be to have the Vert.x community join with the Eclipse community to mutual benefit.
I picked migrating the various bits of code that make up the "Vert.x min" distribution into Eclipse Vert.x as the goal because that is what I observed to be the effective minimal useful bit of technology that could be described as "Eclipse Vert.x". Further, this distribution includes the functionality described in the original project proposal [2].
Wayne
[1] https://eclipse.org/legal/logo_guidelines.php
[2] https://www.eclipse.org/proposals/rt.vertx/
The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community and accept Vert.x as an Eclipse project.
Part of the trademark ownership part is managing the trademark. For that--like many (most?) other organizations--we have trademark usage guidelines [1]. Trademark law manifests in interesting ways; our "Java development tools" project, for example must use lower-case letters on "development tools" to avoid violating Oracle's Java (tm) trademark.
I can assure you that we have no designs on taking over the Vert.x community. I have no idea, frankly, how we'd even do this if we wanted to (which we don't). My ideal would be to have the Vert.x community join with the Eclipse community to mutual benefit.
I picked migrating the various bits of code that make up the "Vert.x min" distribution into Eclipse Vert.x as the goal because that is what I observed to be the effective minimal useful bit of technology that could be described as "Eclipse Vert.x". Further, this distribution includes the functionality described in the original project proposal [2].
Wayne
[1] https://eclipse.org/legal/logo_guidelines.php
[2] https://www.eclipse.org/proposals/rt.vertx/
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/E20C3DD0-6F68-4CF6-AD29-0CC5110559C8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
jordan.h...@gmail.com
Nov 27, 2015, 3:47:01 PM11/27/15
to ve...@googlegroups.com
I don't think Eclipse is a bad guy insofar as the requests are within their right and even seem fairly reasonable. And I don't think there's no benefit to being in Eclipse or some open source organization. Quite the contrary. You just listed them!
But, presumably, Vert.x has been enough of a part of Eclipse for Red Hat to support it up to this point. Vert.x core has always been maintained as an Eclipse project and I doubt there's much opposition to continuing to do so. It is the *expansion* of that role that is what I'm asking about. We are *expanding* the number of projects that must be managed by Eclipse processes. So, why the expansion? And again, by what criteria do we decide which projects must be intimately involved in Eclipse processes? And what's to say that role doesn't get expanded again in the future?
To be honest, I don't think these changes are that big of a deal. But as Vert.x continues to grow it will likely only become more attractive for Eclipse to push for greater involvement in the project. What prevents this from becoming an issue again when Eclipse becomes interested in the other repositories?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/E20C3DD0-6F68-4CF6-AD29-0CC5110559C8%40gmail.com.
Wayne Beaton
Nov 27, 2015, 4:03:32 PM11/27/15
to ve...@googlegroups.com
I think that maybe our messages crossed.
This is not so much of an expansion, but more of an attempt to align with the original intent of the exchange. As I stated in my earlier note, The Eclipse Foundation was asked to take on the Vert.x project and the "additional" functionality is the balance of the originally-intended functionality that was agreed would be part of the Eclipse project.
With success, the community may opt to move additional functionality into the Eclipse Vert.x project, but that will be the community and project team's call.
Wayne
This is not so much of an expansion, but more of an attempt to align with the original intent of the exchange. As I stated in my earlier note, The Eclipse Foundation was asked to take on the Vert.x project and the "additional" functionality is the balance of the originally-intended functionality that was agreed would be part of the Eclipse project.
With success, the community may opt to move additional functionality into the Eclipse Vert.x project, but that will be the community and project team's call.
Wayne
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/E627BA6E-2747-4F49-8016-1FC92B2358C0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
jordan.h...@gmail.com
Nov 27, 2015, 8:47:17 PM11/27/15
to ve...@googlegroups.com
Thanks for linking to the proposal. I re-read it again, and your statements are fair as it pertains to Vert.x and its languages. Like I said, this really won't be a big deal, particularly with Red Hat's help. And thus far I *do* think we should adopt their recommendations and try to take advantage of the situation and use the relationship with Eclipse more to our benefit than it has been thus far.
But I would still like to point out that it seems there's effectively nothing that prevents encroachment of Eclipse on the other x number of projects in the future (aside from forking Vert.x or just all the extra projects). This was effectively a one-man decision if your statement below is accurate ("I picked migrating various bits of code..."). You're quick to point at legal documents, but the one that you haven't pointed at is the one that prevents all the other projects from going through this same process. Indeed, I believe all those other projects are already included in some of these requirements. Effectively, you're saying "trust us," and anyone that's been in business for more than ten minutes knows that's never a good idea, particularly when one individual is making the decisions.
I suppose we'll just have to wait and see what the future brings.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5658B635.8010407%40eclipse.org.
Tim Fox
Nov 28, 2015, 3:04:33 AM11/28/15
to ve...@googlegroups.com
On 27/11/15 19:59, Wayne Beaton wrote:
I can confirm that there is no evil plan.
The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community
That's a key point. You were asked to take legal ownership of the
trademark _on behalf_ of the community. That means enabling the
community to continue to use the trademark in the way it did prior
to Eclipse taking it over in a way that helps the community and to
defend it against malicious third parties.
What I see here is Eclipse making unilateral decisions on usage of the trademark that is absolutely _not_ to the benefit of the community, but seems to solely serve Eclipse aims to satisfy it's own trademark guidelines.
What I see here is Eclipse making unilateral decisions on usage of the trademark that is absolutely _not_ to the benefit of the community, but seems to solely serve Eclipse aims to satisfy it's own trademark guidelines.
and accept Vert.x as an Eclipse project.
Part of the trademark ownership part is managing the trademark. For that--like many (most?) other organizations--we have trademark usage guidelines [1]. Trademark law manifests in interesting ways; our "Java development tools" project, for example must use lower-case letters on "development tools" to avoid violating Oracle's Java (tm) trademark.
I can assure you that we have no designs on taking over the Vert.x community. I have no idea, frankly, how we'd even do this if we wanted to (which we don't).
By using the trademark to attempt to force non Eclipse Vert.x
projects to come under Eclipse. I.e. exactly what you're doing now.
My ideal would be to have the Vert.x community join with the Eclipse community to mutual benefit.
I picked migrating the various bits of code that make up the "Vert.x min" distribution into Eclipse Vert.x as the goal because that is what I observed to be the effective minimal useful bit of technology
This is incorrect. Vertx-core is perfectly usable by itself. I have
made this point a few times and you have chosen to ignore it.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5658B635.8010407%40eclipse.org.
Tim Fox
Nov 28, 2015, 3:13:30 AM11/28/15
to ve...@googlegroups.com
On 27/11/15 21:03, Wayne Beaton wrote:
I think that maybe our messages crossed.
This is not so much of an expansion, but more of an attempt to align with the original intent of the exchange. As I stated in my earlier note, The Eclipse Foundation was asked to take on the Vert.x project and the "additional" functionality is the balance of the originally-intended functionality that was agreed would be part of the Eclipse project.
Please provide documentation explaining where this was agreed. The
only part of Vert.x project that was signed over to Eclipse in the
initial contribution. If you have evidence to the contrary please
show it, or stop making baseless claims.
The only Vert.x project that was signed over to Eclipse is what is now known as vertx-core. At that time there many other pieces of official Vert.x that weren't part of vertx-core and everyone, including Eclipse was well aware of that.
Eclipse has absolutely no claim on those other parts other than usage of the trademark, which Eclipse legally owns. It does not have a claim to those projects themselves.
Yes, there might have been a future intention to migrate further non Eclipse parts of Vert.x to Eclipse if the migration of Vert.x core had gone well and the community agreed that was to the benefit of the greater Vert.x, but it's pretty clear to me and probably to most people in the community that didn't happen.
If Eclipse wants the rest of Vert.x to come under Eclipse it should do that by actually making the Eclipse experience compelling and something that has value for Vert.x. If it can do that, we will _want_ to come to Eclipse. The way _not_ to go about it is to use ownership of a trademark to effectively threaten the community into submission.
The only Vert.x project that was signed over to Eclipse is what is now known as vertx-core. At that time there many other pieces of official Vert.x that weren't part of vertx-core and everyone, including Eclipse was well aware of that.
Eclipse has absolutely no claim on those other parts other than usage of the trademark, which Eclipse legally owns. It does not have a claim to those projects themselves.
Yes, there might have been a future intention to migrate further non Eclipse parts of Vert.x to Eclipse if the migration of Vert.x core had gone well and the community agreed that was to the benefit of the greater Vert.x, but it's pretty clear to me and probably to most people in the community that didn't happen.
If Eclipse wants the rest of Vert.x to come under Eclipse it should do that by actually making the Eclipse experience compelling and something that has value for Vert.x. If it can do that, we will _want_ to come to Eclipse. The way _not_ to go about it is to use ownership of a trademark to effectively threaten the community into submission.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5658C518.4060409%40eclipse.org.
Tim Fox
Nov 28, 2015, 3:57:50 AM11/28/15
to ve...@googlegroups.com
On 28/11/15 08:04, Tim Fox wrote:
On 27/11/15 19:59, Wayne Beaton wrote:
I can confirm that there is no evil plan.
The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community
That's a key point. You were asked to take legal ownership of the trademark _on behalf_ of the community. That means enabling the community to continue to use the trademark in the way it did prior to Eclipse taking it over in a way that helps the community
And to be clear, that's what Eclipse has done to date. Eclipse has
knowingly allowed us to use the trademark "Vert.x" for the past 2
years to describe parts other than the vertx-core project. It's only
now that Vert.x is becoming more popular that it's saying "hey, now
you must call it 'Eclipse Vert.x'". If the trademark guidelines are
so important why weren't they applied consistently from the
beginning, and why wasn't it made clear to the community?
Jordan Halterman
Nov 28, 2015, 4:26:40 AM11/28/15
to ve...@googlegroups.com
I just have to straighten this out, S...
Specifically, the projects that will be affected either now or in the future (some of which will likely become part of the minimum distribution) are:
You say "I don't think Eclipse can impose to any not-Eclipse project how they choose to call vert.x, so this point is useless." All of the projects I linked above are not called "Vert.x" and all of them are either included in this proposal now or will likely be in the future. All of them are currently maintained in the vert-x3 repository, not the Eclipse repository. Eclipse managing processes around Vert.x core is exactly not the issue at hand.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d2241308-b7d7-44e1-8ea7-b21886a90331%40googlegroups.com.
Asher Tarnopolski
Nov 28, 2015, 4:37:46 AM11/28/15
to vert.x
tim is right. eclipse is clearly playing politics here.
Jordan Halterman
Nov 28, 2015, 4:45:14 AM11/28/15
to ve...@googlegroups.com
How about a counter-proposal from the Vert.x community? It feels like this conversation is a whole lot of Eclipse pointing to documents and justifying why it can do what it wants to do. But that is utterly contrary to the spirit of open source, and it's that principal that is most disturbing about this discussion.
On Sat, Nov 28, 2015 at 1:37 AM, Asher Tarnopolski <ata...@gmail.com> wrote:
tim is right. eclipse is clearly playing politics here.
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/fbf8a3f9-853f-4b2e-aa4e-e638c37766a5%40googlegroups.com.
Max Rydahl Andersen
Nov 28, 2015, 7:10:15 AM11/28/15
to ve...@googlegroups.com
Tim,
Lets recognize Eclipse foundation have done what it could so far based on input from you and others:
GitHub issues allowed now
Cq process easier - don't need legal review for minor updates
Release reviews can be reduced to bare minimum
And I probably forget a few.
What seem to be missing here is that someone from vertx community steps forward and take part in this besides just me as red hat eclipse board representative.
About creating a stack for vertx by bringing over projects was discussed very early on and what eclipse foundation is doing here is just to make that same suggestion since There have not been any rational counter proposal on how to handle the upfront info that was in project name and trademark guidelines outlined.
The trademark and project are simply interlinked and just as we don't want to break up the vert.x community we also don't want to undermine the trademark and license backbone of how a foundation like eclipse, apache etc. is based on.
We can argue all you want about moral vs legal rights but please put that towards VMWare and the legal system which brought us into this.
I've said before that I think there are ways to resolve this but we need someone in vertx to be willing to go into that discussion to find that resolution.
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56596225.6090701%40gmail.com.
Tim Fox
Nov 28, 2015, 7:16:21 AM11/28/15
to ve...@googlegroups.com
On 28/11/15 12:09, Max Rydahl Andersen
wrote:
Tim,
Lets recognize Eclipse foundation have done what it could so far based on input from you and others:
GitHub issues allowed nowCq process easier - don't need legal review for minor updatesRelease reviews can be reduced to bare minimumAnd I probably forget a few.
What seem to be missing here is that someone from vertx community steps forward and take part in this besides just me as red hat eclipse board representative.
About creating a stack for vertx by bringing over projects was discussed very early on and what eclipse foundation is doing here is just to make that same suggestion since There have not been any rational counter proposal on how to handle the upfront info that was in project name and trademark guidelines outlined.
The trademark and project are simply interlinked and just as we don't want to break up the vert.x community we also don't want to undermine the trademark and license backbone of how a foundation like eclipse, apache etc. is based on.
We can argue all you want about moral vs legal rights but please put that towards VMWare and the legal system which brought us into this.
I've said before that I think there are ways to resolve this but we need someone in vertx to be willing to go into that discussion to find that resolution.
I'm not sure I understand what you mean. Aren't we having that
discussion right now?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/2C27785E-AD7C-442E-85B0-613D07B27B6D%40gmail.com.
Max Rydahl Andersen
Nov 28, 2015, 7:24:56 AM11/28/15
to ve...@googlegroups.com
> On 28 Nov 2015, at 09:57, Tim Fox <timv...@gmail.com> wrote:
>
>
> And to be clear, that's what Eclipse has done to date. Eclipse has knowingly allowed us to use the trademark "Vert.x" for the past 2 years to describe parts other than the vertx-core project. It's only now that Vert.x is becoming more popular that it's saying "hey, now you must call it 'Eclipse Vert.x'". If the trademark guidelines are so important why weren't they applied consistently from the beginning, and why wasn't it made clear to the community?
You and I had that talk very early on.
The guidelines were pointed to early on.
And we even discussed on this mailing list about the necessity to look into find a way to clearly identify which parts of vertx was eclipse verified distribution and what was external.
That eclipse foundation didn't push harder on it is more a sign of them trying to not disturb an already busy time and trying to work on a progressive move and change of things.
I know you and I have had the conversation early on to try and find solutions.
Now that mark little declared to add resource to handle the perceived overhead lets get this thing resolved instead of claiming ignorance of the problem.
P.s. Due to all this the eclipse board have earlier voted on enforcing the guidelines harder rather than just friendly asking so there is no doubt the guidelines actually exist for a reason.
/max
Max Rydahl Andersen
Nov 28, 2015, 7:27:33 AM11/28/15
to ve...@googlegroups.com
Exactly.
The foundation made the *proposal* based on the guidelines there exist in the foundation today.
Let's work together on what we can do.
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAKg5dm5AmFbRn4_Ni8d28LtitC5K%3DnSvYk330%3D3FyaY7Vg4-JQ%40mail.gmail.com.
Max Rydahl Andersen
Nov 28, 2015, 7:33:34 AM11/28/15
to ve...@googlegroups.com
On 28 Nov 2015, at 13:16, Tim Fox <timv...@gmail.com> wrote:
>> I've said before that I think there are ways to resolve this but we need someone in vertx to be willing to go into that discussion to find that resolution.
>
> I'm not sure I understand what you mean. Aren't we having that discussion right now?
If that is not what you meant then I apologize.
Anyone got an additional proposal on how to solve it within the realms of the foundation guidelines ?
Tim Fox
Nov 28, 2015, 8:00:06 AM11/28/15
to ve...@googlegroups.com
1. Eclipse seem to want to us to move further non Eclipse owned projects
under the Eclipse banner.
I can't see any pressing legal or other reason why we need to do this
right now. Eclipse doesn't own those projects and can't dictate terms as
to what the community does with those projects. As I said in another
reply if it makes sense in the future to move further projects to
Eclipse then the community can decide to do that if it wishes. I think
whether or not that happens depends on how compelling Eclipse can be and
what value add it can offer the community. But in any case, there is no
pressing need to do anything there right now.
2. Usage of the "Vert.x" trademark.
This is more tricky. Eclipse is the legal owner of the trademark and is
within its rights to determine usage of that trademark. If we don't use
the "Vert.x" trademark in the way Eclipse wants they could sue us. I
think we all agree we don't want to be in a situation that exposes us
legally and I know Red Hat would agree with that. So we do need to do
something urgently to resolve that.
I can see several outcomes which would stop us contravening the trademark:
a. The community forks Vertx-core and we rename Vert.x to something else.
b. We leave Eclipse and Eclipse signs over the Vert.x trademark to the
community.
c. We rename the non Eclipse parts of Vert.x to something else and
Vertx-core remains at Eclipse.
d. We rename the Eclipse Vert.x project to something else (e.g. VCore).
The rest of Vert.x can then continue using the Vert.x name as Vert.x
would no longer be an Eclipse project name and the Eclipse trademark
guidelines specifically refer to Eclipse project names.
e. Eclipse provides an exception to the trademark guidelines for Vert.x
f. We move all the projects that make up the Vert.x stack to Eclipse and
other projects have to reference Vert.x as "Eclipse Vert.x" (this is
what Eclipse wants).
I think it's up to the community to decide which one of these options to
go for. I believe only b) and e) would require Eclipse to agree, the
others can be done independently.
>
>
>
>
Tim Fox
Nov 28, 2015, 8:11:50 AM11/28/15
to ve...@googlegroups.com
has the minimum impact to the Vert.x community. So either b) d) or e).
Personally I would rule out a) and f) as it's too damaging and far
reaching for the community.
>
>
>>
>>
>>
>>
>
Max Rydahl Andersen
Nov 28, 2015, 8:28:57 AM11/28/15
to ve...@googlegroups.com
Thanks Tim! Something to work with.
Im currently traveling so I'll have wait with detailed follow up and give chance for others to chime in.
About what eclipse wants then I think it is much less about what projects move where.
More that there become clarity about what is in/outside of what the eclipse vert.x trademark and project (the technology not individual github projects) means - and a wish that vert.x community becomes active at eclipse rather than not with the expectation everyone grows and wins.
But that is my interpretation. I'm *not* speaking on behalf of eclipse in this.
/max
http://about.me/maxandersen
Im currently traveling so I'll have wait with detailed follow up and give chance for others to chime in.
About what eclipse wants then I think it is much less about what projects move where.
More that there become clarity about what is in/outside of what the eclipse vert.x trademark and project (the technology not individual github projects) means - and a wish that vert.x community becomes active at eclipse rather than not with the expectation everyone grows and wins.
But that is my interpretation. I'm *not* speaking on behalf of eclipse in this.
/max
http://about.me/maxandersen
> --
> You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659A811.9030601%40gmail.com.
> You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
jordan.h...@gmail.com
Nov 28, 2015, 8:37:16 AM11/28/15
to ve...@googlegroups.com
Thanks for listing these options Tim. This is what we (the Vert.x community) need.
I too would love to see b, d, or e happen.
(a) would be very painful.
Wouldn't (b) jeopardize corporate support?
(d) seems like the most viable option that should have a minimal impact on the Vert.x community.
If (e) were a possibility, we probably wouldn't event be having this discussion, but this seems like an ideal scenario.
Unfortunately, I'm not sure Eclipse will accept anything but (f). At least nothing thus far has indicated as much.
I too would love to see b, d, or e happen.
(a) would be very painful.
Wouldn't (b) jeopardize corporate support?
(d) seems like the most viable option that should have a minimal impact on the Vert.x community.
If (e) were a possibility, we probably wouldn't event be having this discussion, but this seems like an ideal scenario.
Unfortunately, I'm not sure Eclipse will accept anything but (f). At least nothing thus far has indicated as much.
> --
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659A552.9010805%40gmail.com.
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
jordan.h...@gmail.com
Nov 28, 2015, 8:39:24 AM11/28/15
to ve...@googlegroups.com
Also, are we sure (d) doesn't require Eclipse to agree?
> --
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659A552.9010805%40gmail.com.
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
Mark Little
Nov 28, 2015, 9:41:10 AM11/28/15
to ve...@googlegroups.com
> On 28 Nov 2015, at 08:04, Tim Fox <timv...@gmail.com> wrote:
>
> On 27/11/15 19:59, Wayne Beaton wrote:
>> I can confirm that there is no evil plan.
>>
>> The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community
>
> That's a key point. You were asked to take legal ownership of the trademark _on behalf_ of the community. That means enabling the community to continue to use the trademark in the way it did prior to Eclipse taking it over in a way that helps the community and to defend it against malicious third parties.
>
> What I see here is Eclipse making unilateral decisions on usage of the trademark that is absolutely _not_ to the benefit of the community, but seems to solely serve Eclipse aims to satisfy it's own trademark guidelines.
Next week we’ll begin to look at a mapping between the current process and what Eclipse has requested. I think that will be informative for everyone, especially those people who have come out expressing concern that there’s some additional overhead or red tape which will get in the way of their project releases. Not many people have been involved in Vert.x releases over the years so the exact details of what the team do and don’t do isn’t necessarily widely understood. Doing that map is a good next step.
>
>> and accept Vert.x as an Eclipse project.
>>
>> Part of the trademark ownership part is managing the trademark. For that--like many (most?) other organizations--we have trademark usage guidelines [1]. Trademark law manifests in interesting ways; our "Java development tools" project, for example must use lower-case letters on "development tools" to avoid violating Oracle's Java (tm) trademark.
>>
>> I can assure you that we have no designs on taking over the Vert.x community. I have no idea, frankly, how we'd even do this if we wanted to (which we don't).
>
> By using the trademark to attempt to force non Eclipse Vert.x projects to come under Eclipse. I.e. exactly what you're doing now.
>
>> My ideal would be to have the Vert.x community join with the Eclipse community to mutual benefit.
>>
>> I picked migrating the various bits of code that make up the "Vert.x min" distribution into Eclipse Vert.x as the goal because that is what I observed to be the effective minimal useful bit of technology
>
> This is incorrect. Vertx-core is perfectly usable by itself. I have made this point a few times and you have chosen to ignore it.
Mark.
Tim Fox
Nov 28, 2015, 11:03:57 AM11/28/15
to ve...@googlegroups.com
On 28/11/15 13:39, jordan.h...@gmail.com wrote:
> Also, are we sure (d) doesn't require Eclipse to agree?
I'm not sure it does.
> Also, are we sure (d) doesn't require Eclipse to agree?
If you look at the Eclipse trademark guidelines:
https://eclipse.org/legal/logo_guidelines.php
"Proper Usage of Eclipse Project Names and Logos"
This is the part that mandates that the project name should be preceeded
by "Eclipse". But it specifically refers to project names. So if
"Vert.x" is no longer a project name then it seems pretty clear that
those guidelines don't apply any more to "Vert.x".
Tim Fox
Nov 28, 2015, 11:08:50 AM11/28/15
to ve...@googlegroups.com
On 28/11/15 14:41, Mark Little wrote:
>> On 28 Nov 2015, at 08:04, Tim Fox <timv...@gmail.com> wrote:
>>
>> On 27/11/15 19:59, Wayne Beaton wrote:
>>> I can confirm that there is no evil plan.
>>>
>>> The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community
>> That's a key point. You were asked to take legal ownership of the trademark _on behalf_ of the community. That means enabling the community to continue to use the trademark in the way it did prior to Eclipse taking it over in a way that helps the community and to defend it against malicious third parties.
>>
>> What I see here is Eclipse making unilateral decisions on usage of the trademark that is absolutely _not_ to the benefit of the community, but seems to solely serve Eclipse aims to satisfy it's own trademark guidelines.
> When we agreed to move Vert.x from VMWare and VMWare agreed to transfer ownership to Eclipse, we agreed to follow their guidelines.
Agreed. I don't think anyone wants to break the Eclipse trademark
>> On 28 Nov 2015, at 08:04, Tim Fox <timv...@gmail.com> wrote:
>>
>> On 27/11/15 19:59, Wayne Beaton wrote:
>>> I can confirm that there is no evil plan.
>>>
>>> The Eclipse Foundation is attempting to do what we were asked to do by the Vert.x community: we were asked to take ownership of the project's trademark on behalf of the community
>> That's a key point. You were asked to take legal ownership of the trademark _on behalf_ of the community. That means enabling the community to continue to use the trademark in the way it did prior to Eclipse taking it over in a way that helps the community and to defend it against malicious third parties.
>>
>> What I see here is Eclipse making unilateral decisions on usage of the trademark that is absolutely _not_ to the benefit of the community, but seems to solely serve Eclipse aims to satisfy it's own trademark guidelines.
> When we agreed to move Vert.x from VMWare and VMWare agreed to transfer ownership to Eclipse, we agreed to follow their guidelines.
guidelines. I certainly don't.
That's why I put together a list of 6 options in a previous post
(numbered a to f), all of which allow us to continue without breaking
the trademark guidelines. I think the big question is, which one to
take. That's not a question anyone single party can answer.
> VMWare did not want to transfer ownership to any individual or to Red Hat and there was and remains no such legal entity as “The Vert.x Community” for it to be transferred to either. So we all chose Eclipse and we should follow the implications of that decision in 2013 in so far as it applies to those aspects of Vert.x which were transferred to the Eclipse Foundation. I’ve read through the thread from the past day or so and once it was explained that all the Eclipse Foundation is asking for is for projects to refer to Eclipse Vert.x on the first page there have been several people who own related projects that have come out saying that’s not too onerous a task after all. So for now let’s put that to one side for now.
>
> Next week we’ll begin to look at a mapping between the current process and what Eclipse has requested. I think that will be informative for everyone, especially those people who have come out expressing concern that there’s some additional overhead or red tape which will get in the way of their project releases. Not many people have been involved in Vert.x releases over the years so the exact details of what the team do and don’t do isn’t necessarily widely understood. Doing that map is a good next step.
that vertx-core is a perfectly viable project and there is no compulsion
for any other Vert.x projects to move so the mapping becomes moot.
Tim Fox
Nov 28, 2015, 11:13:28 AM11/28/15
to ve...@googlegroups.com
On 28/11/15 13:37, jordan.h...@gmail.com wrote:
> Thanks for listing these options Tim. This is what we (the Vert.x community) need.
>
> I too would love to see b, d, or e happen.
>
> (a) would be very painful.
>
> Wouldn't (b) jeopardize corporate support?
>
> (d) seems like the most viable option that should have a minimal impact on the Vert.x community.
I agree that d) seems like the most viable option. It has very little
> Thanks for listing these options Tim. This is what we (the Vert.x community) need.
>
> I too would love to see b, d, or e happen.
>
> (a) would be very painful.
>
> Wouldn't (b) jeopardize corporate support?
>
> (d) seems like the most viable option that should have a minimal impact on the Vert.x community.
impact on the Vert.x community and keeps Eclipse happy as we'll no
longer be breaking the project name trademark guidelines.
Win-win all round? :)
Michael Scholz
Nov 28, 2015, 11:58:08 AM11/28/15
to vert.x
The 'Eclipse Verticle' project?
Max Rydahl Andersen
Nov 28, 2015, 1:02:02 PM11/28/15
to ve...@googlegroups.com
Im not following how renaming the core project is going to change that the vert.x trademark is still at eclipse and part
of the project as its code is ?
Assuming it does (I don't think it does) The name of the project is given and checked at project incubation. I would imagine renaming would require similar check/process but I don't know that from top of my head.
/max
http://about.me/maxandersen
> You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
of the project as its code is ?
Assuming it does (I don't think it does) The name of the project is given and checked at project incubation. I would imagine renaming would require similar check/process but I don't know that from top of my head.
/max
http://about.me/maxandersen
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/vfpVYefCzjI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
> Visit this group at http://groups.google.com/group/vertx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659D069.2070203%40gmail.com.
Tim Fox
Nov 28, 2015, 2:05:25 PM11/28/15
to ve...@googlegroups.com
The trademark guidelines specifically
refer to Eclipse *project names*:
"... All Eclipse projects should be identified as being Eclipse
projects. Therefore, when referencing an Eclipse project, we ask
that the first reference to the project is identified as Eclipse
[project name],..."
If we rename the Eclipse project from "Vert.x" to something else (e.g. "VCore"), then there will be no Eclipse project called "Vert.x" any more and therefore there will be no requirement to Use "Eclipse Vert.x" in non Eclipse Vert.x projects.
If we rename the Eclipse project from "Vert.x" to something else (e.g. "VCore"), then there will be no Eclipse project called "Vert.x" any more and therefore there will be no requirement to Use "Eclipse Vert.x" in non Eclipse Vert.x projects.
Jordan Halterman
Nov 29, 2015, 1:29:16 AM11/29/15
to ve...@googlegroups.com
I think it does seem this would be legally viable if we could change the name of the core project. I don't think there's much to dispute that. But I think the question that is being asked here is whether we can change the name without Eclipse's approval. The Eclipse trademark guidelines do indeed simply refer to "project names," but it seems like Eclipse would have to agree to changing the name of an Eclipse project to make that viable. Of course, I'm certainly not an expert on that topic :-)
On a different note, I've seen assertions that Eclipse hasn't had enough of a positive influence on Vert.x to justify moving more projects under the Eclipse banner. TBH, unless I've missed it, I haven't really seen any effort on the part of Eclipse to dispute that. Can someone from Eclipse please enumerate the ways in which Eclipse has helped Vert.x since EclipseCon so we can hear both sides?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659FAF2.7020203%40gmail.com.
Tim Fox
Nov 29, 2015, 3:43:57 AM11/29/15
to ve...@googlegroups.com
On 29/11/15 06:29, Jordan Halterman
wrote:
I think it does seem this would be legally viable if we could change the name of the core project. I don't think there's much to dispute that. But I think the question that is being asked here is whether we can change the name without Eclipse's approval.
I am assuming there is a well documented, public and transparent
process which enables a community to rename an Eclipse project name,
but I can't find anything on the Eclipse web-site.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAKg5dm5B573xJG7%3DxqG4nP2Z2r-Bk-5tJD6UAtmOsJAaGxTXtw%40mail.gmail.com.
Max Rydahl Andersen
Nov 29, 2015, 4:55:25 AM11/29/15
to ve...@googlegroups.com
You seem to tie the Repo name to project name. Afaik it goes the other way around.
One eclipse project can have have zero to many repositories which tend to be named based on the eclipse project.
Thus what your suggestion does is equivalent to b as far as I can see. I.e. ask eclipse to release the trademark.
Something that would go against the agreement with VMWare and a bunch of issues around setting the precedence for that.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659FAF2.7020203%40gmail.com.
Tim Fox
Nov 29, 2015, 5:04:03 AM11/29/15
to ve...@googlegroups.com
This is nothing to do with repo names.
I am referring specifically to the Eclipse project name which is
currently "Vert.x".
The Eclipse trademark guidelines document *specifically* provides restrictions to the usage of Eclipse trademarks which are Eclipse project names. It does not provide restrictions to trademarks which are not Eclipse project names.
Therefore if the Eclipse project name is no longer "Vert.x" it seems pretty clear that those trademark guidelines don't apply any more.
What's not to understand?
This does not require Eclipse to release any trademark.
Also which agreement with VMware are you referring to? I am not aware of any contractual agreement between VMware and Eclipse other than the signing over of the trademark which was a very simple standard document for trademark transfer, and I was involved with the entire process at the time. You were not Max.
If there is such an agreement then please provide evidence of it or it didn't happen.
The Eclipse trademark guidelines document *specifically* provides restrictions to the usage of Eclipse trademarks which are Eclipse project names. It does not provide restrictions to trademarks which are not Eclipse project names.
Therefore if the Eclipse project name is no longer "Vert.x" it seems pretty clear that those trademark guidelines don't apply any more.
What's not to understand?
This does not require Eclipse to release any trademark.
Also which agreement with VMware are you referring to? I am not aware of any contractual agreement between VMware and Eclipse other than the signing over of the trademark which was a very simple standard document for trademark transfer, and I was involved with the entire process at the time. You were not Max.
If there is such an agreement then please provide evidence of it or it didn't happen.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4C4CA1BB-4489-49B7-967D-DCA1BD5D21CC%40gmail.com.
Max Rydahl Andersen
Nov 29, 2015, 6:56:32 AM11/29/15
to ve...@googlegroups.com
I'm not saying I was there. Just not following your logic.
I assume the handover was to have the trademark at the eclipse foundation not somewhere else ?
As I grok it you want eclipse to for the first time allow one of its trademarks be used without connection with eclipse ( which was one of the other options you listed) and allow it be used with things that are not governed by what eclipse other guidelines states, correct ?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565ACD8C.2060307%40gmail.com.
Max Rydahl Andersen
Nov 29, 2015, 6:59:40 AM11/29/15
to ve...@googlegroups.com
I don't think there are precedence for renaming.
The way I think I would work is that a project sunsets and gets archived and another gets incubated. These are both public and transparently defined.
This is just my understanding based on what I've seen at eclipse and apache.
Mike/Wayne should confirm.
/max
http://about.me/maxandersen
The way I think I would work is that a project sunsets and gets archived and another gets incubated. These are both public and transparently defined.
This is just my understanding based on what I've seen at eclipse and apache.
Mike/Wayne should confirm.
/max
http://about.me/maxandersen
Tim Fox
Nov 29, 2015, 9:54:38 AM11/29/15
to ve...@googlegroups.com
On 29/11/15 11:56, Max Rydahl Andersen
wrote:
I'm not saying I was there. Just not following your logic.
I assume the handover was to have the trademark at the eclipse foundation not somewhere else ?
Correct. I am not suggesting the trademark moves from the Eclipse
foundation.
As I grok it you want eclipse to for the first time allow one of its trademarks be used without connection with eclipse ( which was one of the other options you listed) and allow it be used with things that are not governed by what eclipse other guidelines states, correct ?
Yes, which I what I always expected Eclipse to do anyway. As I have
stated several times I consider Eclipse to be the custodians of the
trademark on behalf of the Vert.x community. I.e passively hold the
trademark for the community, and that is exactly what Eclipse have
done for the past two years anyway. I do not expect Eclipse to tell
the community how they can use their own trademark- which is what
Eclipse is now doing.
This suggestion is a way of getting back to the role the community wants Eclipse to have and what I thought was Eclipse's role (custodian), without transgressing any of the Eclipse trademark guidelines. The trademark guidelines clearly refer to Eclipse project names so it seems pretty clear that by renaming the project then we won't be transgressing the guidelines any more.
If you're now going to turn around and tell me that it's not actually just the Eclipse trademark guidelines that matter, and Eclipse won't let us rename, then that just tells me the real motivation here is not about trademarks, it's about asserting control over the project. If it really is just about trademarks then why not just let us rename?
This suggestion is a way of getting back to the role the community wants Eclipse to have and what I thought was Eclipse's role (custodian), without transgressing any of the Eclipse trademark guidelines. The trademark guidelines clearly refer to Eclipse project names so it seems pretty clear that by renaming the project then we won't be transgressing the guidelines any more.
If you're now going to turn around and tell me that it's not actually just the Eclipse trademark guidelines that matter, and Eclipse won't let us rename, then that just tells me the real motivation here is not about trademarks, it's about asserting control over the project. If it really is just about trademarks then why not just let us rename?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/22D9F53F-71B1-4B3F-A9C1-E5C07DB2075E%40gmail.com.
Tim Fox
Nov 29, 2015, 10:00:30 AM11/29/15
to ve...@googlegroups.com
On 29/11/15 14:54, Tim Fox wrote:
On 29/11/15 11:56, Max Rydahl Andersen wrote:
I'm not saying I was there. Just not following your logic.
I assume the handover was to have the trademark at the eclipse foundation not somewhere else ?
Correct. I am not suggesting the trademark moves from the Eclipse foundation.
As I grok it you want eclipse to for the first time allow one of its trademarks be used without connection with eclipse ( which was one of the other options you listed) and allow it be used with things that are not governed by what eclipse other guidelines states, correct ?
Yes, which I what I always expected Eclipse to do anyway. As I have stated several times I consider Eclipse to be the custodians of the trademark on behalf of the Vert.x community. I.e passively hold the trademark for the community, and that is exactly what Eclipse have done for the past two years anyway. I do not expect Eclipse to tell the community how they can use their own trademark- which is what Eclipse is now doing.
This suggestion is a way of getting back to the role the community wants Eclipse to have and what I thought was Eclipse's role (custodian), without transgressing any of the Eclipse trademark guidelines. The trademark guidelines
And btw, Eclipse should really stop calling them "guidelines" and
call them "mandatory requirements" since it's pretty obvious Eclipse
doesn't allow a single inch of flexibility here.
Tim Fox
Nov 29, 2015, 11:48:22 AM11/29/15
to ve...@googlegroups.com
At this point I'm not sure I have much more to add.
I've come up with a list of 6 options which seem pretty exhaustive
(unless anyone can think of any more?).
I think we need Eclipse to engage a little bit more in this conversation
if we're going to get anywhere (and I don't mean you Max).
Personally I won't partake in any solution that involves more pain for
Vert.x, but if the community agrees to go down that route I will
completely respect that and not obstruct anything. I've done very little
development in the last couple of months and it would be nice to get
back to some fun development without the shackles of bureaucracy and
politics.
I've come up with a list of 6 options which seem pretty exhaustive
(unless anyone can think of any more?).
I think we need Eclipse to engage a little bit more in this conversation
if we're going to get anywhere (and I don't mean you Max).
Personally I won't partake in any solution that involves more pain for
Vert.x, but if the community agrees to go down that route I will
completely respect that and not obstruct anything. I've done very little
development in the last couple of months and it would be nice to get
back to some fun development without the shackles of bureaucracy and
politics.
Tim Fox
Nov 29, 2015, 12:01:05 PM11/29/15
to ve...@googlegroups.com
A final thought:
If the Eclipse process was working so well we wouldn't be having this
conversation at all - we'd be rushing to adopt it as it clearly would be
adding so much value for Vert.x.
So instead of trying to ram something down our throats, how about fixing
the process first then we will WANT to adopt it.
If the Eclipse process was working so well we wouldn't be having this
conversation at all - we'd be rushing to adopt it as it clearly would be
adding so much value for Vert.x.
So instead of trying to ram something down our throats, how about fixing
the process first then we will WANT to adopt it.
Wayne Beaton
Nov 29, 2015, 3:01:07 PM11/29/15
to ve...@googlegroups.com
I'll try to address the other issues brought up in this thread, but
I'd like to address the "what have we done for Vert.x" question
first.
I believe that the trademark bit has been laboured enough, so I won't focus on that here.
I'll point out that Tim is listed as an owner of the vert-x GitHub organization, granting him the ability to create repositories and assemble teams as he sees fit (on behalf of the community, of course) without interference.
Tim delivered a keynote address about Vert.x at our EclipseCon 2013 conference [1]. We hosted a full Vert.x Day [2] dedicating an entire track to Vert.x. These sessions where, I recall, well attended. These conferences provide a means for the project team to get together for face-to-face work, and connect with individuals and organizations that you might not otherwise get to connect with. We currently host three Eclipse conferences every year in the US, France, and Germany.
Our Executive Director included discussion of Vert.x in his addresses at both EclipseCon 2013 and 2014, and in other conference appearances (including, I believe, at least one keynote address), briefings, and meetings with companies in the Eclipse ecosystem.
The project creation and a releases are announced to our member companies, which include the sorts of "enterprise" companies that I believe that the Eclipse Vert.x project and community are trying to connect with. This is one of the reasons why I ask for a short "elevator pitch" style description for release review documentation: it is far easier for us to tell people about the project with a concise paragraph than a handful of bullets.
In general, we use speaking opportunities at all kinds of conferences (including JavaOne and the many Devoxxes) to draw attention to our projects. Especially the cool ones (win-win). This is, again, where having good review documentation helps us help you. We have an exhibit hall presence at many of these conferences where committers from the Eclipse Vert.x project and members of the community can represent the project.
We have marketing resources that we have brought and can bring to bear for the Eclipse Vert.x project. We can help with things like press releases regarding the project, work with industry analysts to ensure that Eclipse Vert.x is part of the message that they deliver, blogging and social media outreach, and other similar things. The Eclipse Foundation's reach is different from that of the Vert.x community; joining channels is win-win.
The Eclipse Contributor License Agreement (CLA) infrastructure has been adopted by (I believe) all projects in the vert-x and vert-x3 GitHub organizations. Unlike some other CLAs, the Eclipse CLA does not require that the contributor assign ownership of the contribution.
While I hesitate to claim responsibility for this, it seems to me that the community projects have tightened up on processes since joining Eclipse. The Roadmap document [3], for example, that lays out a rudimentary plan for the project was created in March (it'd be nice to see tentative dates for future releases). Having this sort of planning is important for adopters who have to sort out their own schedules. Similarly, the Development Process document is new since joining Eclipse. Again, I hesitate to claim responsibility for this, but the creation of these documents does follow discussions that I had with Tim and Julien regarding striking a balance between an entirely agile process and planning releases.
The IP Due Diligence process found issues and initiated mitigating steps with some of the third-party libraries used by core. To the great credit of the project team, the IP team did not find any IP-related issues in the project code. The IP Team and project mentors did help the project team assemble the required licenses and notices.
Unfortunately, I haven't quite sorted out how to make engaging in the processes that support the above zero cost for the project team.
HTH,
Wayne
[1] https://www.eclipsecon.org/2013/node/1603.html
[2] https://www.eclipsecon.org/na2014/vertxday
[3] https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap
I believe that the trademark bit has been laboured enough, so I won't focus on that here.
I'll point out that Tim is listed as an owner of the vert-x GitHub organization, granting him the ability to create repositories and assemble teams as he sees fit (on behalf of the community, of course) without interference.
Tim delivered a keynote address about Vert.x at our EclipseCon 2013 conference [1]. We hosted a full Vert.x Day [2] dedicating an entire track to Vert.x. These sessions where, I recall, well attended. These conferences provide a means for the project team to get together for face-to-face work, and connect with individuals and organizations that you might not otherwise get to connect with. We currently host three Eclipse conferences every year in the US, France, and Germany.
Our Executive Director included discussion of Vert.x in his addresses at both EclipseCon 2013 and 2014, and in other conference appearances (including, I believe, at least one keynote address), briefings, and meetings with companies in the Eclipse ecosystem.
The project creation and a releases are announced to our member companies, which include the sorts of "enterprise" companies that I believe that the Eclipse Vert.x project and community are trying to connect with. This is one of the reasons why I ask for a short "elevator pitch" style description for release review documentation: it is far easier for us to tell people about the project with a concise paragraph than a handful of bullets.
In general, we use speaking opportunities at all kinds of conferences (including JavaOne and the many Devoxxes) to draw attention to our projects. Especially the cool ones (win-win). This is, again, where having good review documentation helps us help you. We have an exhibit hall presence at many of these conferences where committers from the Eclipse Vert.x project and members of the community can represent the project.
We have marketing resources that we have brought and can bring to bear for the Eclipse Vert.x project. We can help with things like press releases regarding the project, work with industry analysts to ensure that Eclipse Vert.x is part of the message that they deliver, blogging and social media outreach, and other similar things. The Eclipse Foundation's reach is different from that of the Vert.x community; joining channels is win-win.
The Eclipse Contributor License Agreement (CLA) infrastructure has been adopted by (I believe) all projects in the vert-x and vert-x3 GitHub organizations. Unlike some other CLAs, the Eclipse CLA does not require that the contributor assign ownership of the contribution.
While I hesitate to claim responsibility for this, it seems to me that the community projects have tightened up on processes since joining Eclipse. The Roadmap document [3], for example, that lays out a rudimentary plan for the project was created in March (it'd be nice to see tentative dates for future releases). Having this sort of planning is important for adopters who have to sort out their own schedules. Similarly, the Development Process document is new since joining Eclipse. Again, I hesitate to claim responsibility for this, but the creation of these documents does follow discussions that I had with Tim and Julien regarding striking a balance between an entirely agile process and planning releases.
The IP Due Diligence process found issues and initiated mitigating steps with some of the third-party libraries used by core. To the great credit of the project team, the IP team did not find any IP-related issues in the project code. The IP Team and project mentors did help the project team assemble the required licenses and notices.
Unfortunately, I haven't quite sorted out how to make engaging in the processes that support the above zero cost for the project team.
HTH,
Wayne
[1] https://www.eclipsecon.org/2013/node/1603.html
[2] https://www.eclipsecon.org/na2014/vertxday
[3] https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAKg5dm5B573xJG7%3DxqG4nP2Z2r-Bk-5tJD6UAtmOsJAaGxTXtw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
Wayne Beaton
@waynebeaton
The Eclipse Foundation
Wayne Beaton
Nov 29, 2015, 3:06:36 PM11/29/15
to ve...@googlegroups.com
I am not a lawyer and am by no means an expert in trademark law.
Ownership of the "Vert.x" trademark was passed to the Eclipse Foundation and so it is our responsibility to maintain it.
While it is possible that we can change the name of the Eclipse Vert.x project, that does not necessarily allow the trademarked term to be freely used.
But, like I said, I'm not expert on the topic. So I'll ask the experts and report back.
Wayne
Ownership of the "Vert.x" trademark was passed to the Eclipse Foundation and so it is our responsibility to maintain it.
While it is possible that we can change the name of the Eclipse Vert.x project, that does not necessarily allow the trademarked term to be freely used.
But, like I said, I'm not expert on the topic. So I'll ask the experts and report back.
Wayne
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659FAF2.7020203%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Wayne Beaton
Nov 29, 2015, 3:08:22 PM11/29/15
to ve...@googlegroups.com
While we do try to be comprehensive in our documentation, it's
impossible to cover every possible case. Renames happen very rarely.
Changing the name would be covered by a "restructuring review"
Wayne
On 29/11/15 03:43 AM, Tim Fox wrote:
> I am assuming there is a well documented, public and transparent
> process which enables a community to rename an Eclipse project name,
> but I can't find anything on the Eclipse web-site.
impossible to cover every possible case. Renames happen very rarely.
Changing the name would be covered by a "restructuring review"
Wayne
On 29/11/15 03:43 AM, Tim Fox wrote:
> I am assuming there is a well documented, public and transparent
> process which enables a community to rename an Eclipse project name,
> but I can't find anything on the Eclipse web-site.
Wayne Beaton
Nov 29, 2015, 3:11:15 PM11/29/15
to ve...@googlegroups.com
A restructuring review isn't nearly that involved :-)
We would need a description of the changes and approval from the PMC.
As I said earlier, however, I don't think that necessarily solves the
trademark issue.
Wayne
On 29/11/15 06:59 AM, Max Rydahl Andersen wrote:
> The way I think I would work is that a project sunsets and gets archived and another gets incubated. These are both public and transparently defined.
We would need a description of the changes and approval from the PMC.
As I said earlier, however, I don't think that necessarily solves the
trademark issue.
Wayne
On 29/11/15 06:59 AM, Max Rydahl Andersen wrote:
> The way I think I would work is that a project sunsets and gets archived and another gets incubated. These are both public and transparently defined.
It is loading more messages.
0 new messages