Thanks a lot, this sounds like a good start. We definitely do not want to
re-invent the wheel - if there's some setup we can copy, I'd love to do
that as well!
Something we need is the possibility to have projects with subtasks and the
ability for any contributor (not committer) to contribute to
Very curious to hear that. I contacted several customers, most of them are
waiting for 1.2 to be ready on the internal system. Did they fork by their
own? If they changed the codes, will them submit their changes?
On Sat, Jun 9, 2018 at 2:51 PM, Marco de Abreu wrote:
> We received a few pull
Yes, I think all of our customers don't use internal build systems but work
off GitHub directly. I can't go into details about it, but usually we work
together with them and then our team submits the necessary fixes.
Mu Li schrieb am So., 10. Juni 2018, 03:54:
> Very curious to hear that. I
We received a few pull requests for the 1.2 branch which are not from key
contributors. I'm also aware of a few Amazon internal customers who are
currently actively working off the 1.2 branch to prepare for 1.2.1 release,
so I'd rather err on the side of caution here.
-marco
Mu Li schrieb am
how would it be devastating? it is just squashing a bunch of commits
together into 1 commit.
On Sat, Jun 9, 2018 at 1:18 PM, Marco de Abreu wrote:
> I think we should never ever force push to a publish repository since we
> don't know what depends on it. I'd say we take this as a lesson learned
You should never force push to master branch because it messes up people's
commit history. Ideally, you shall never push to the release branch and PR
is preferred. Given no people will continue work on the release branch, the
impact of squash commits is minimalized and is fine in this case, given
Would there be any benefit besides cosmetics? I'd propose to just leave it
as-is.
Tianqi Chen schrieb am Sa., 9. Juni 2018, 22:28:
> This would only happen if somebody pushed some changes on these new commits
> pushed 1.2.0 branch.
>
> That is if I checked out 1.2.0 before the change is pushed,
Hi Naveen,
Thanks for the clarification. Is there necessary to keep these commits
submitted by the maveen plugin in the repo? Otherwise, can we squash these
commits and force push it to a single commit? It's good to have a stable
release only patched with meaningful commits.
Best,
Mu
> On
I agree we should never rewrite history on the master branch, master
branch is protected so you won't be able to push to it without a PR. The
issue here was the release branch was not protected.
I am only squashing commits that are after the tag creation.
On Sat, Jun 9, 2018 at 1:24 PM,
This would only happen if somebody pushed some changes on these new commits
pushed 1.2.0 branch.
That is if I checked out 1.2.0 before the change is pushed, and rebase
against the code after squash, it will be fine. The problem will only
happen if someone checked out 1.2.0 after these commits get
I think we should never ever force push to a publish repository since we
don't know what depends on it. I'd say we take this as a lesson learned and
leave it as it is.
The impact could be way more devastating than the benefits
-Marco
Naveen Swamy schrieb am Sa., 9. Juni 2018, 21:39:
> Hi Mu,
On 6/9/2018 5:01 PM, Marco de Abreu wrote:
> Would you mind creating a proposal document at
> [1], describing what you would have in mind and how project planning,
> -management, development, planning, third-party-engagements and other
> things you can think of would look like then?
Yes of
Hi Mu,
No, it isn't necessary to have those commits. I did not want to rewrite the
history, thats why I did not attempt. I can try to squash and force push,
I'll let you know if I am able to force-push.
Thanks, Naveen
On Sat, Jun 9, 2018 at 12:28 PM, Mu Li wrote:
> Hi Naveen,
>
> Thanks for
It would be a history rewrite. Everybody would receive an error if they
checked out the branch and try to merge or rebase.
Naveen Swamy schrieb am Sa., 9. Juni 2018, 22:21:
> how would it be devastating? it is just squashing a bunch of commits
> together into 1 commit.
>
> On Sat, Jun 9, 2018
One potential problem is that, if a release is tagged to a certain hash
code, and that specific commit get squashed, the previous tagged release is
no longer valid, so at least make sure that did not happen
Tianqi
On Sat, Jun 9, 2018 at 1:23 PM, Tianqi Chen
wrote:
> You should never force push
The proposal is squash commits made from May 21 to June 7 into a single commit
for the 1.2 branch. https://github.com/apache/incubator-mxnet/commits/v1.2.0 t
should not affect the master branch. But it may affect developers if they
cloned and 1.2 some day between May 21 and June 7 and want to
I like the idea, it's similar to the label aaron just introduced. I don't
think there is a need to separate these two. I'd say we use GitHub for high
level things and topics that have not been investigated yet. JIRA would be
for clearly actionable things. Your proposal could be included with these
Hi,
thanks for your feedback!
I think the big problem is that we have nobody who maintains JIRA properly.
If we had a dedicated person who owns that system, I'm sure we could excell
at it's usage and it would provide better value. About the plugins, I have
to agree that we can just request
+0.5
I think we can separate our JIRA issue to two groups, one is a simpler
group to the new who wants to contribute to MXNET but haven't become a
contributer yet and will be published in the github issue, another for only
contributer to access, which of course will have some more harder to answer
I guess you should add instructions about speaking on various event like
conf., meetups - to present the whole project team.
On Fri, Jun 8, 2018 at 11:15 PM, Sheng Zha wrote:
> Hi,
>
> There have been a couple of offline inquiries from contributors about
> becoming a committer. From those
On 6/9/2018 12:43 PM, Marco de Abreu wrote:
> I think the big problem is that we have nobody who maintains JIRA properly.
> If we had a dedicated person who owns that system, I'm sure we could excell
> at it's usage and it would provide better value. About the plugins, I have
> to agree that we
Hello Yasser,
welcome to MXNet then! I'm glad you are enjoying it :)
Thanks a lot for the offer! Would you mind creating a proposal document at
[1], describing what you would have in mind and how project planning,
-management, development, planning, third-party-engagements and other
things you
22 matches
Mail list logo
