-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GroupId & packages -> com.expediagroup. Docker hub org -> expediagrou… #175
Conversation
.../src/main/java/com/expediagroup/streamplatform/streamregistry/StreamRegistryApplication.java
Outdated
Show resolved
Hide resolved
...java/com/expediagroup/streamplatform/streamregistry/provider/impl/KafkaInfraManagerTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM... I will setup a MIGRATION.md file in eg-master
to track major items that will be necessary for HA team when they migrate.
To the degree possible when PRs are being merged in eg-master
it would be nice (not required, but nice) to update the list with the PR and any necessary actions.
See #177 |
@@ -1,6 +1,6 @@ | |||
# | |||
# Copyright HomeAway, Inc 2018-Present. All Rights Reserved. | |||
# Copyright Expedia, Inc 2018-2019. All Rights Reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but this actually needs to be like this:
Copyright (C) 2018-2019 Expedia, Inc.
We should definitely do a stripped down eg-oss-parent POM which has all this stuff in it but for now maybe a small new PR with this change ^?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, yes. Please submit new PR with this change.
Good catch @massdosage
/* Copyright (c) 2018-Present Expedia Group. | ||
* All rights reserved. http://www.homeaway.com | ||
|
||
/* Copyright (C) 2018-2019 Expedia, Inc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this is correct, so maybe just an issue with that .properties file above? I assume that one is done manually not by the plugin or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep
## Legal | ||
This project is available under the [Apache 2.0 License](http://www.apache.org/licenses/LICENSE-2.0.html). | ||
|
||
Copyright 2016-2019 Expedia, Inc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2018 is the inception year for this project not 2016 right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. This should be 2018... and we should probably update the text to be
2018-Present
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the lawyers like "Present" as it doesn't have a concrete meaning and is incorrect if the project isn't changed for example next year. We should use the date that the project was last updated as the end year. The license plugin will handle it to make the changes everywhere when a new year begins and a commit is made at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small nits, rest looks good.
@neoword - thanks for reviewing. Our convention up to now is that we require two reviewers to approve before a merge can be done and that the person who raised the PR does the merge (as they might be working on related PRs and know best what order to do them in etc.) Up to this team to decide if they want to adopt this convention or something else.
|
In our experience the people actively working on the project are the ones also raising the PRs and reviewing each other's work so they usually do have commit rights. I know there are times when I want to get the acceptance done but don't want it merged until I'm ready with some other thing. Depends on the PR, one can go with either approach and then the person raising the PR can put a comment like "please don't merge yet" etc. I'd say let the team of main committers on this choose what they want to do. |
…p. Addresses #162
stream-registry PR
Changed
com.expediagroup.streamplatform
com.expediagroup.streamplatform.streamregistry
PR Checklist Forms