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.
--
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.
The Eclipse Board has decided that Eclipse projects will be able to use GitHub Issues rather than Bugzilla for their issue tracking.
--
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5655D06F.5080900%40gmail.com.
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....?
I'll try outline that asap once I'm at a more decent keyboard :)
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....?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAP7YuASDE2%3D2atmfZiDUDx%2B8LBedVjLB2O5f5tJ_1cHw%3Dg82Xg%40mail.gmail.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
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....?
--
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.
--
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.
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.
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.
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.
--
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.
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5656162D.9%40eclipse.org.
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.
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.
--
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.
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.
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.
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 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 :)
--
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.
--
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56562256.1000505%40eclipse.org.
I'll address the "how is this valuable" question shortly.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565620C7.6050602%40eclipse.org.
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).
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAP7YuAReOTQmkWRGV2M9SwCqBs9J%2BrV5S6mGO-WucUzgSkkpEQ%40mail.gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565658A1.8050800%40gmail.com.
On 25/11/15 20:57, Wayne Beaton wrote:
I'll address the "how is this valuable" question shortly.
Please answer that first.
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.
--
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.
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.
--
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/B381B356-68F0-420D-BBBF-31D261FB09A6%40gmail.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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/AD374CF2-7450-47BC-88FF-89F084CD2C95%40gmail.com.
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 view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5656CD59.1010707%40gmail.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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/DB7880F0-CC13-4228-B75F-5C644AFF496B%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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/0fe69646-6604-4650-a72e-d4e3a777ede7%40googlegroups.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?
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/82EDADD9-BE91-41B8-9076-2120ED264980%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5656EFA5.8030308%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/56565ABC.9090901%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/82EDADD9-BE91-41B8-9076-2120ED264980%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/13E3BBD3-2325-469E-839E-50EB9811E6F9%40gmail.com.
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/E20C3DD0-6F68-4CF6-AD29-0CC5110559C8%40gmail.com.
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5658B635.8010407%40eclipse.org.
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
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5658B635.8010407%40eclipse.org.
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5658C518.4060409%40eclipse.org.
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
--
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.
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.
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,
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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/2C27785E-AD7C-442E-85B0-613D07B27B6D%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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAKg5dm5AmFbRn4_Ni8d28LtitC5K%3DnSvYk330%3D3FyaY7Vg4-JQ%40mail.gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659FAF2.7020203%40gmail.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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAKg5dm5B573xJG7%3DxqG4nP2Z2r-Bk-5tJD6UAtmOsJAaGxTXtw%40mail.gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5659FAF2.7020203%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/4C4CA1BB-4489-49B7-967D-DCA1BD5D21CC%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/565ACD8C.2060307%40gmail.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/22D9F53F-71B1-4B3F-A9C1-E5C07DB2075E%40gmail.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
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.
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.