Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-12-05 Thread Thomas Broyer 


On Friday, November 17, 2017 at 5:37:59 PM UTC+1, Thomas Broyer wrote:
>
>
>
> On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:
>>
>> Sounds like there is enough diversity of opinion that this discussion 
>> should go on - first step seems to be deciding if we think the CLA
>>
>
> Some links about CLAs:
> https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ 
> & 
> https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/
>
> https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/
> http://contributoragreements.org/
> Some tools to manage CLAs: https://cla-assistant.io/ (by SAP), 
> https://www.clahub.com/
>
> As a) purely "community-driven projects", that b) won't even be used by 
> Google (their original author), I would say that we don't need CLAs (also, 
> the choice of the Apache License protects the users from a lot of things 
> already).
> That said, IANAL, and I'm not doing any work here on behalf of my 
> employer; so people for whom CLAs are important should weigh in.
>

Fwiw, Gradle, as a project lead by a company (Gradle, Inc.), which is not 
our case, just ditched CLAs in favor of 
https://developercertificate.org: 
https://discuss.gradle.org/t/change-in-the-contribution-process/25011

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/e1f40067-65c5-4243-beb2-1c7fbbd1c4be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-17 Thread Colin Alworth 
On Friday, November 17, 2017 at 10:37:59 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:
>>
>> Sounds like there is enough diversity of opinion that this discussion 
>> should go on - first step seems to be deciding if we think the CLA
>>
>
> Some links about CLAs:
> https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ 
> & 
> https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/
>
> https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/
> http://contributoragreements.org/
> Some tools to manage CLAs: https://cla-assistant.io/ (by SAP), 
> https://www.clahub.com/
>
> As a) purely "community-driven projects", that b) won't even be used by 
> Google (their original author), I would say that we don't need CLAs (also, 
> the choice of the Apache License protects the users from a lot of things 
> already).
> That said, IANAL, and I'm not doing any work here on behalf of my 
> employer; so people for whom CLAs are important should weigh in.
>  
>
>> and/or gerrit-style review is important for all artifacts deployed to 
>> org.gwtproject. 
>>
>
> I *love* Gerrit, and use it daily at work; but I cannot ignore that GitHub 
> pull requests have gotten a whole lot better those past years, and I have 
> absolutely no problem using them instead of Gerrit; which is a barrier to 
> entry that many don't even try passing (Go has had the same issue, they 
> built tooling around it instead, and documentation, and despite that it's 
> apparently still seen as a barrier to entry to many –Chrome and Android are 
> different, as they're much bigger beasts already).
> Keeping in mind that gwt.googlesource.com is maintained by Google which 
> wouldn't be involved in those projects, this poses the problem of who would 
> admin Gerrit, and whether Google would host it indefinitely for us (Google 
> is using pull requests for a lot of projects, and this includes j2cl –still 
> a private repository–, jsinterop-base, jsinterop-generator, and elemental2).
> This all pushes for using GitHub pull requests.
> Now, from my PoV, each project maintainer would be free to choose how to 
> manage code in their repo (see below): whether to use PRs for everything 
> (never push to master), choosing a branching and merging strategies (I for 
> one would use rebase and/or squash, possibly manually to squash some 
> commits and preserve others, and follow "trunk based development" 
>  –this is actually what we do for GWT 
> already; I'd love to see everyone embrace the same view, but I'm not sure 
> forcing a "standard" is the way to go –bikeshedding, etc.), and versioning 
> and release strategies (I think everyone would agree on using semver, but 
> what about maintaining several versions in parallel? releasing at a 
> scheduled cadence –like Guava and Dagger do for instance– vs. "release when 
> it's ready", etc.)
>
> For the time being, it sounds like individual groupIds are the way 
>> forward, with the expectation of migrating projects to org.gwtproject and 
>> github.com/gwtproject once they reach a certain level of quality and 
>> stability, once we decide what that is.
>>
>
> As far as I'm concerned, I'm formatting all my code using 
> google-java-format (and enforce it in build) and checking it with Error 
> Prone (FindBugs could possibly be a good addition).
> Wrt google-java-format, just like gofmt for Go, rustfmt for Rust, 
> prettier+eslint for JS/CSS/etc., ktlint for Kotlin, etc. prevents 
> bikeshedding on the formatting. I don't always like how it formats things, 
> but at least I don't have to worry about it. “Gofmt's style is no one's 
> favorite, yet gofmt is everyone's favorite.” 
> 
> Similarly for Error Prone, nothing to configure, just let it fail your 
> build (early, really early).
> But that's only a fraction of code quality (see also branching strategies 
> above for another fraction).
> With smaller projects, I think we might be able to run tests on 
> BrowserStack or SauceLabs, through Travis.
>
> Now, I'd like to advocate for more autonomy and responsibility for 
> maintainers: manage their project the way they want, release when they 
> want,  use Maven or Gradle as they prefer, etc. This means that there might 
> be projects that are more stable and/or of greater quality than others (but 
> so are modules inside gwt-user already actually).
> Jenkins CI host all their plugin in their GitHub organization, and I don't 
> remember someone being angry at the diverse levels of quality, stability, 
> etc. Everyone seems to understand that they're maintained by different 
> people and not "products from Jenkins". (btw, they don't seem to have a CLA 
> either).
>
All sounds reasonable, but I'd want to see

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-17 Thread Thomas Broyer 


On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:
>
> Sounds like there is enough diversity of opinion that this discussion 
> should go on - first step seems to be deciding if we think the CLA
>

Some links about CLAs:
https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ 
& 
https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/
https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/
http://contributoragreements.org/
Some tools to manage CLAs: https://cla-assistant.io/ (by 
SAP), https://www.clahub.com/

As a) purely "community-driven projects", that b) won't even be used by 
Google (their original author), I would say that we don't need CLAs (also, 
the choice of the Apache License protects the users from a lot of things 
already).
That said, IANAL, and I'm not doing any work here on behalf of my employer; 
so people for whom CLAs are important should weigh in.
 

> and/or gerrit-style review is important for all artifacts deployed to 
> org.gwtproject. 
>

I *love* Gerrit, and use it daily at work; but I cannot ignore that GitHub 
pull requests have gotten a whole lot better those past years, and I have 
absolutely no problem using them instead of Gerrit; which is a barrier to 
entry that many don't even try passing (Go has had the same issue, they 
built tooling around it instead, and documentation, and despite that it's 
apparently still seen as a barrier to entry to many –Chrome and Android are 
different, as they're much bigger beasts already).
Keeping in mind that gwt.googlesource.com is maintained by Google which 
wouldn't be involved in those projects, this poses the problem of who would 
admin Gerrit, and whether Google would host it indefinitely for us (Google 
is using pull requests for a lot of projects, and this includes j2cl –still 
a private repository–, jsinterop-base, jsinterop-generator, and elemental2).
This all pushes for using GitHub pull requests.
Now, from my PoV, each project maintainer would be free to choose how to 
manage code in their repo (see below): whether to use PRs for everything 
(never push to master), choosing a branching and merging strategies (I for 
one would use rebase and/or squash, possibly manually to squash some 
commits and preserve others, and follow "trunk based development" 
 –this is actually what we do for GWT 
already; I'd love to see everyone embrace the same view, but I'm not sure 
forcing a "standard" is the way to go –bikeshedding, etc.), and versioning 
and release strategies (I think everyone would agree on using semver, but 
what about maintaining several versions in parallel? releasing at a 
scheduled cadence –like Guava and Dagger do for instance– vs. "release when 
it's ready", etc.)

For the time being, it sounds like individual groupIds are the way forward, 
> with the expectation of migrating projects to org.gwtproject and 
> github.com/gwtproject once they reach a certain level of quality and 
> stability, once we decide what that is.
>

As far as I'm concerned, I'm formatting all my code using 
google-java-format (and enforce it in build) and checking it with Error 
Prone (FindBugs could possibly be a good addition).
Wrt google-java-format, just like gofmt for Go, rustfmt for Rust, 
prettier+eslint for JS/CSS/etc., ktlint for Kotlin, etc. prevents 
bikeshedding on the formatting. I don't always like how it formats things, 
but at least I don't have to worry about it. “Gofmt's style is no one's 
favorite, yet gofmt is everyone's favorite.” 

Similarly for Error Prone, nothing to configure, just let it fail your 
build (early, really early).
But that's only a fraction of code quality (see also branching strategies 
above for another fraction).
With smaller projects, I think we might be able to run tests on 
BrowserStack or SauceLabs, through Travis.

Now, I'd like to advocate for more autonomy and responsibility for 
maintainers: manage their project the way they want, release when they 
want,  use Maven or Gradle as they prefer, etc. This means that there might 
be projects that are more stable and/or of greater quality than others (but 
so are modules inside gwt-user already actually).
Jenkins CI host all their plugin in their GitHub organization, and I don't 
remember someone being angry at the diverse levels of quality, stability, 
etc. Everyone seems to understand that they're maintained by different 
people and not "products from Jenkins". (btw, they don't seem to have a CLA 
either).
 

> As per our name use policy, that should fall to the steering committee to 
> decide, but I at least would welcome more feedback from contributors on 
> what those standards might look like.
>

This is a good question Colin!
Fwiw, I never had the intention to ever publis

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-17 Thread Colin Alworth 
Sounds like there is enough diversity of opinion that this discussion 
should go on - first step seems to be deciding if we think the CLA and/or 
gerrit-style review is important for all artifacts deployed to 
org.gwtproject. 

For the time being, it sounds like individual groupIds are the way forward, 
with the expectation of migrating projects to org.gwtproject and 
github.com/gwtproject once they reach a certain level of quality and 
stability, once we decide what that is. As per our name use policy, that 
should fall to the steering committee to decide, but I at least would 
welcome more feedback from contributors on what those standards might look 
like.

Likewise from that name use document, we should avoid the use of 
org.gwtproject packages as well until that time. This might make migration 
a little trickier (changing packages multiple times) as we refactor various 
modules out from gwt-user. For my part, I would like to see this line 
blurred slightly or at least clarified - code which started its life in 
com.google.gwt but isn't presently "controlled" by the committee due it it 
being in progress should perhaps not be restricted in this way (in the same 
way that Vaadin ships a GWT fork, but still uses com.google.gwt packages 
for compatibility). We could phrase this in individual projects as "This 
code came from GWT, and is incubating here until it is contributed back to 
GWT", making it clear that the project is not intended to be a third party 
tool, but is using the name in good faith that this will be again part of 
GWT soon.


On Wednesday, November 15, 2017 at 2:23:02 PM UTC-6, Goktug Gokdogan wrote:
>
> It could be hard to communicate and set expectations with a live 
> work-in-progress gwt-project repository and via publishing on maven 
> central. I agree with Jens on first setting up a foundation, rules and also 
> maturing what GWT3 is; and in the meantime let people iterate in their own 
> repos which will set expectation accordingly.
>
> On Wed, Nov 15, 2017 at 9:31 AM, Jens > 
> wrote:
>
>> Oh and if its just about making these small projects more discoverable 
>> then one could also create a single project, e.g. gwtproject/gwt3-migration 
>> and use the wiki for documentation and/or git submodules to link in all 
>> these small projects as well.
>>
>> -- J.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/ee2066ec-2b18-4921-8476-6a2195cffecc%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/a7b91aa5-c26d-496b-ae1a-95fb5dd42d84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread 'Goktug Gokdogan' via GWT Contributors 
It could be hard to communicate and set expectations with a live
work-in-progress gwt-project repository and via publishing on maven
central. I agree with Jens on first setting up a foundation, rules and also
maturing what GWT3 is; and in the meantime let people iterate in their own
repos which will set expectation accordingly.

On Wed, Nov 15, 2017 at 9:31 AM, Jens  wrote:

> Oh and if its just about making these small projects more discoverable
> then one could also create a single project, e.g. gwtproject/gwt3-migration
> and use the wiki for documentation and/or git submodules to link in all
> these small projects as well.
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/google-web-toolkit-contributors/ee2066ec-2b18-
> 4921-8476-6a2195cffecc%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1v4ZO8f0QRTok-g0vfSWDr_2v-8W%3D8Qc7hg4SOOAT4Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Jens 
Oh and if its just about making these small projects more discoverable then 
one could also create a single project, e.g. gwtproject/gwt3-migration and 
use the wiki for documentation and/or git submodules to link in all these 
small projects as well.

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/ee2066ec-2b18-4921-8476-6a2195cffecc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Colin Alworth 
I've been over your gwt-events - looked good from 30 mins or so of poking 
around, but largely copy/paste, so that makes sense right?

Removing old browsers seems reasonable - if we get issues filed asking for 
old browser support, we can deal with that as needed, but these are meant 
to be modern builds of modules that still have support for old browsers. 
GWT 3 won't support the modern browsers, and even IE11 doesn't support 
Promises, so implementing Scheduler.scheduleFinally might not be possible 
without JSNI and $entry anyway... That's always been my understanding of 
the approach at least.

I'll read those other three today, but if the tests pass and the API holds 
(aside from renaming packages), it sounds like they could already be out 
there and ready for use ;). So what's the holdup? I'm being facetious, but 
I'm hoping we can make a plan that even we active contributors can follow, 
and set an easy example for others to follow.

That said, with Jens's reply in mind: If we want a CLA for projects that 
get under gwtproject.org, if we want strict code review (though I did put 
the checkstyle in my sample project), I'm going to advocate strongly for 
individual projects and personal groupIds to start with, until people who 
want to build that process are happy with it and have it deployed. The 
downside of having strict standards seems clear: not even active 
contributors are trying to meet them. At least Git gives us the ability to 
look back in history, and see where code came from in an external project, 
make sure everyone is on board with moving to gwtproject.

On Wednesday, November 15, 2017 at 11:14:34 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>>
>> Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
>> projects so far in their own repos, and not in github.com/gwtproject - I 
>> was following that example. If you guys are ready to move them now and ship 
>> them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
>> objection.
>>
>> My main goal was to lower the barrier to entry - if we don't ship things 
>> that aren't under gwtproject, and we don't even put *our own projects* 
>> on gwtproject, I was concerned about how this might look to external 
>> contributors, especially given how many small projects we're going to need 
>> to have started and finished in the near future. 
>>
>> If you guys can move your projects and get them out on central,
>>
>
> I'd prefer if someone reviewed them before (particularly gwt-events; 
> gwt-http, gwt-window and gwt-history have nothing controversial in there 
> IIRC, except maybe for the fact I removed support for "old browsers" –they 
> should theoretically work in IE10+, Firefox ESR, and evergreen browsers).
> Also wrt the choice of groupId and artifactId.
> If you'd prefer that I don't wait before I move them, that works for me; 
> but I'd rather have a second pair of (critical) eyes look at the code 
> before I push anything to Central (btw, we need to ask Sonatype OSSRH for 
> the org.gwtproject groupId, and grant release rights to a few people; who 
> does that?)
>
> I'll change my yet-unpublished advice to be "start the project in your own 
>> repo, and ask it be moved once it is ready" or perhaps "ask for a new repo 
>> to be created in gwtproject, then push your sources there in a large pull 
>> request"?
>>
>
> I'd rather go for the second advice then.
>
> (fwiw, I tried to follow your yet-unpublished blog post for gwt-http, 
> gwt-window and gwt-history, and have it show clearly and cleanly in the 
> commit history; it took some time but at least they can serve as examples)
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/ac438217-1e68-4d98-9b4f-b53fded66538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Jens 
You don't build a house starting with the windows, you need a solid 
foundation. 

IMHO you/we first need to figure out how these smaller projects should be 
handled in the future. Does the gwtproject organization enforce 
requirements on these projects or are they totally independent and just 
sharing a common groupId? Does gwtproject organization still forces CLAs? 
Who would store them? Still Google even though they will probably become 
less involved into gwtproject.org in the future once they are fully moved 
to J2CL? Is it allowed for maintainers to switch from CLA to DCO and use 
pull requests + Github review instead? Or should maintainers store CLAs on 
their own? Maybe it is easier to put everything under the gwtproject 
umbrella into the same repository so a future "Complete GWT SDK" is easier 
to manage/build. 

Maybe most questions have already been answered behind closed doors but for 
me personally there is just to much unanswered questions that I wouldn't 
push anything to org.gwtproject and instead leave things as they are: 
experiments of contributors using their own groupIds. First figure out and 
set in stone the way gwtproject organization, contribution and possibly 
centralized releases (like eclipse releases) should work in the future.

IMHO official libs must go through some official, defined process to ensure 
quality.

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/dd643fda-f7ff-4d49-b9d8-78a34320029a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Thomas Broyer 


On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>
> Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
> projects so far in their own repos, and not in github.com/gwtproject - I 
> was following that example. If you guys are ready to move them now and ship 
> them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
> objection.
>
> My main goal was to lower the barrier to entry - if we don't ship things 
> that aren't under gwtproject, and we don't even put *our own projects* on 
> gwtproject, I was concerned about how this might look to external 
> contributors, especially given how many small projects we're going to need 
> to have started and finished in the near future. 
>
> If you guys can move your projects and get them out on central,
>

I'd prefer if someone reviewed them before (particularly gwt-events; 
gwt-http, gwt-window and gwt-history have nothing controversial in there 
IIRC, except maybe for the fact I removed support for "old browsers" –they 
should theoretically work in IE10+, Firefox ESR, and evergreen browsers).
Also wrt the choice of groupId and artifactId.
If you'd prefer that I don't wait before I move them, that works for me; 
but I'd rather have a second pair of (critical) eyes look at the code 
before I push anything to Central (btw, we need to ask Sonatype OSSRH for 
the org.gwtproject groupId, and grant release rights to a few people; who 
does that?)

I'll change my yet-unpublished advice to be "start the project in your own 
> repo, and ask it be moved once it is ready" or perhaps "ask for a new repo 
> to be created in gwtproject, then push your sources there in a large pull 
> request"?
>

I'd rather go for the second advice then.

(fwiw, I tried to follow your yet-unpublished blog post for gwt-http, 
gwt-window and gwt-history, and have it show clearly and cleanly in the 
commit history; it took some time but at least they can serve as examples)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/c2e3904a-8eee-4257-b7a9-a3b9d91d570d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Colin Alworth 
Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
projects so far in their own repos, and not in github.com/gwtproject - I 
was following that example. If you guys are ready to move them now and ship 
them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
objection.

My main goal was to lower the barrier to entry - if we don't ship things 
that aren't under gwtproject, and we don't even put *our own projects* on 
gwtproject, I was concerned about how this might look to external 
contributors, especially given how many small projects we're going to need 
to have started and finished in the near future. 

If you guys can move your projects and get them out on central, I'll change 
my yet-unpublished advice to be "start the project in your own repo, and 
ask it be moved once it is ready" or perhaps "ask for a new repo to be 
created in gwtproject, then push your sources there in a large pull 
request"?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/7e14e048-a2ba-4d56-b314-909a19cc55b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Thomas Broyer 

On Wednesday, November 15, 2017 at 5:40:11 PM UTC+1, Andrei Korzhevskii 
wrote:
>
> I vote for boring way, ie allocate these (module) projects on github and 
> follow usual pull requests workflow and deploy it as snapshots during 
> development.
> Reasoning is that I don't see much sense in spreading community efforts in 
> multiple projects and then picking the right one.
>

That would work too (basically what my "review and move" suggestion does, 
but with pull requests).
But it doesn't really prevent spreading community efforts; there still 
needs some coordination to prevent two people from starting working on the 
same project (Colin has a spreadsheet already for that coordination effort, 
so there's no real need for "picking the right one" in the end)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/84f8e9df-122d-450a-af2e-821f19f7e1df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Andrei Korzhevskii 
I vote for boring way, ie allocate these (module) projects on github and 
follow usual pull requests workflow and deploy it as snapshots during 
development.
Reasoning is that I don't see much sense in spreading community efforts in 
multiple projects and then picking the right one.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/a889ecc5-ec3f-41f9-a7f5-99b4f0bcbfba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Thomas Broyer 


On Wednesday, November 15, 2017 at 5:00:59 PM UTC+1, Colin Alworth wrote:
>
> I'm about to put out a blog post with a bunch of details on how one might 
> port gwt-user.jar modules out (thanks to the hard work of those who have 
> started this effort already, especially Dan Kurka and Thomas Broyer), and 
> once those are ready to be consumed, we'll certainly want the various 
> artifacts on maven central. The goal in this is to start motivating 
> contributors and community members to assist in the migration work 
> necessary to get us within reach of a GWT 3 ecosystem.
>
> The topic of "where we deploy early efforts" has come up a few times 
> behind relatively closed doors - multiple times in steering calls, and of 
> course at length at GwtCon this year. So, opening it up for broad 
> discussion: should we expect to start pushing release to org.gwtproject.* 
> right away, and if not, are we encouraging individual contributors to push 
> to their own groupIds until we *are* ready?
>
> Case for org.gwtproject: "centralized" jenkins server with creds to push, 
> making it easy to add a project (automatically?) and get it out there so 
> others can use it. Might want some manual checks on what is going out (or 
> else whoever is responsible for the groupId will look silly if it turns out 
> we are shipping malware), which implies full or partial review (manual 
> process) of each release before pushing the button. Makes it clear right 
> away to people searching maven central that they have found the right new 
> modules, since they are all under the org.gwtproject umbrella.
>
> Case for individual groupIds: makes it clear to early adopters that these 
> are "incubator" projects, and they should probably vet them themselves, or 
> they are relying on the community and goodwill of other developers, and 
> that these migrated modules are *not* official - at least not yet. Lower 
> friction, gets snapshots and releases out faster.
>
> No matter how we go, I am certain that we'll want to push to 
> org.gwtproject once these modules are stabilizing and we (gwt maintainers 
> and contributors) are confident in the code being shipped. 
>
> Thoughts? Which ever way we go, I'd like to see the already ready-for-use 
> artifacts deployed within a few days - if that is too soon for 
> org.gwtproject, then I think that makes the choice clear, or else who knows 
> how long we'll be waiting.
>

I don't really have a strong opinion, except that:

   - IFF we go with org.gwtproject, then we should only publish 0.* 
   versions (or possibly 1.0.0-beta-* versions).
   - I would also expect all projects under the org.gwtproject groupId to 
   be hosted in the https://github.com/gwtproject GitHub organization (or 
   gwt.googlesource.com, but I don't even know who exactly has admin rights to 
   create new projects there) and with a first "review" step by a GWT core 
   contributor (besides the author). So this is maybe too soon if you want to 
   get things out "within a few days".
   - Fwiw, I'm happy with using JitPack for my 
   "experiments": https://jitpack.io/#tbroyer/gwt-events, 
   https://jitpack.io/#tbroyer/gwt-http, 
https://jitpack.io/#tbroyer/gwt-window, https://jitpack.io/#tbroyer/gwt-history 
   (fwiw, I've been using Gradle composite builds before I pushed code to 
   GitHub; something you can do with Maven using an ad-hoc aggregator POM)

So, IMO, the steps are, in order:

   1. review candidate projects (the review includes the choice of groupId 
   and artifactId; for example, should it be org.gwtproject.event or 
   org.gwtproject.events? gwt-event or gwt-events? or maybe just 'event' or 
   'events'? gwt-event-compat or gwt-compat-event? org.gwtproject.window or 
   org.gwtproject.user.window? or just org.gwtproject?)
   2. move projects to gwtproject organization
   3. deploy snapshots to Sonatype OSSRH (or any other Maven repo, like 
   BinTray/JCenter, but OSSRH is already widely used I believe); I'd expect 
   this to be consistent across every org.gwtproject artifact. Possibly setup 
   build.gwtproject.org to deploy snapshots automatically (but probably use 
   Travis CI for pull requests).
   4. cut pre-releases (I'd only expect us to release a 1.0 final once we 
   get to a state where it's usable with j2cl –and this includes settling 
   first on how artifacts should look like for j2cl; but I'm open to 
   discussion on this, e.g. release 1.0 for gwt2 only, and a 2.0 with j2cl 
   support, depending on the needed changes to get that support, might not be 
   needed at all)

Those steps would also apply to candidate projects from the community in 
the future.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-tool