You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Casey Stella <ce...@gmail.com> on 2017/04/28 21:47:31 UTC

Started the infrastructure requests to move to TLP

I have begun the process as described in
http://incubator.apache.org/guides/graduation.html#project-first-steps and
http://www.apache.org/dev/infra-contact#requesting-graduation to move out
of the incubator.

First off, I'm sorry it took so long, but it's started now.  I will be
sending followup emails in the ensuing days around instructions for
developers and mailing list subscribers.  I will be sure to send them as
soon as I figure out what to send.

Here we go, hell for leather, baby bird's gotta fly. :)

Casey

Re: Started the infrastructure requests to move to TLP

Posted by Matt Foley <mf...@hortonworks.com>.
Definitely helps, thanks.  I wasn’t sure how mirror repos work, and was allowing for the possibility they might be substantially different from ordinary repos.  This makes things easier.


On 4/29/17, 6:35 PM, "Greg Stein" <gs...@gmail.com> wrote:

    On Sat, Apr 29, 2017 at 12:24:53AM -0700, Matt Foley wrote:
    >...
    > ‘B’ may or may not be important, depending on how
    > Apache INFRA goes about changing the name of the Github apache/metron
    > mirror repo.  If they use the standard Github owner’s command
    > for renaming a repo, then Github maintains semantics for users of the
    > prior name.  Then, you wouldn’t have to do anything about the
    > name change unless you wanted to.
    
    Yes, we just rename it via the web UI. I'm not sure what other
    alternatives are even remotely viable :-P
    
    >...
    > ‘D’ finally is perhaps the most difficult question.  Every fork repo in Github “knows” what repo it was forked from, and uses that as the default for Pull Requests generated from the fork.  Can this be changed?
    > 
    > If Apache INFRA respects the Github protocol for repo renaming, then
    > we don’t need to change anything.  We can just rely on the
    > semantic preservation in the protocol and new PRs generated will
    > automatically point at the renamed Apache repository, directly or
    > indirectly.  That would be best, because Github does NOT provide any
    > easy means for changing the “fork upstream” pointer.
    
    Yup. Just a rename. We don't want to lose a project's associated
    GitHub data (issues, PRs, etc)
    
    >...
    
    Hope that helps,
    Greg Stein
    Infrastructure Administrator, ASF
    
    


Re: Started the infrastructure requests to move to TLP

Posted by Greg Stein <gs...@gmail.com>.
On Sat, Apr 29, 2017 at 12:24:53AM -0700, Matt Foley wrote:
>...
> \u2018B\u2019 may or may not be important, depending on how
> Apache INFRA goes about changing the name of the Github apache/metron
> mirror repo.  If they use the standard Github owner\u2019s command
> for renaming a repo, then Github maintains semantics for users of the
> prior name.  Then, you wouldn\u2019t have to do anything about the
> name change unless you wanted to.

Yes, we just rename it via the web UI. I'm not sure what other
alternatives are even remotely viable :-P

>...
> \u2018D\u2019 finally is perhaps the most difficult question.  Every fork repo in Github \u201cknows\u201d what repo it was forked from, and uses that as the default for Pull Requests generated from the fork.  Can this be changed?
> 
> If Apache INFRA respects the Github protocol for repo renaming, then
> we don\u2019t need to change anything.  We can just rely on the
> semantic preservation in the protocol and new PRs generated will
> automatically point at the renamed Apache repository, directly or
> indirectly.  That would be best, because Github does NOT provide any
> easy means for changing the \u201cfork upstream\u201d pointer.

Yup. Just a rename. We don't want to lose a project's associated
GitHub data (issues, PRs, etc)

>...

Hope that helps,
Greg Stein
Infrastructure Administrator, ASF

Re: Started the infrastructure requests to move to TLP

Posted by Matt Foley <mf...@hortonworks.com>.
Hi Jon,
I’ve now withdrawn RC2 (in the other thread), pending completion of the graduation transition and the fix for square brackets in ES config.  If other fixes also come along, they’ll be included too.  If further blocker problems are found in the meantime, by all means bring them up.
Thanks,
--Matt


On 4/29/17, 11:04 AM, "Zeolla@GMail.com" <ze...@gmail.com> wrote:

    Does this officially mean 0.4.0 is on hold until the migration is
    complete?  I assume the vote based on RC2 failed (for more reason than
    one), but also can we assume that work in progress now is more likely to
    get into 0.4.0?  I would love some more time to QA master as it currently
    is - which I'm working on.  I have fumbled upon a fair amount of issues
    lately and I'm concerned that the more I look the more I'll find.  That
    said, I definitely would not vote to hold things up to wait on my efforts
    because it could be weeks before it's entirely done and tested
    appropriately, I'm just wondering if that will be a natural byproduct of
    our graduation.
    
    Jon
    
    On Sat, Apr 29, 2017, 3:24 AM Matt Foley <ma...@apache.org> wrote:
    
    > A brief guide to changing our github remotes from
    > “apache/metron-incubating” to “apache/metron”
    > [also applies to “incubator-metron-bro-plugin-kafka” →
    > “metron-bro-plugin-kafka” ]
    >
    > Hey all, as a result of un-incubating, the github apache repo names will
    > change.  Some people have expressed concerns whether this will impact their
    > development environments.  This potentially affects four areas:
    > A. Changing local repo names to match
    > B. Changing local repos’ upstream pointers to point at the new apache repo
    > names
    > C. Changing the names of personal fork repos in Github to match
    > D. Changing the upstream “source” apache repo that your personal fork
    > repos in Github point at for purposes of Pull Requests
    >
    > ‘B’ is the only important one, but we’ll talk about them in order.
    >
    > ‘A’ is the least important.  You can call a local repo anything you want,
    > because the name of the local clone is just a directory name, and not
    > strictly part of the repository at all.  If you want to change its name,
    > just `mv` the base directory name.  It doesn’t matter.  You probably
    > already call them something other than “incubator-metron”  anyway :-)
    >
    > ‘B’ may or may not be important, depending on how Apache INFRA goes about
    > changing the name of the Github apache/metron mirror repo.  If they use the
    > standard Github owner’s command for renaming a repo, then Github maintains
    > semantics for users of the prior name.  Then, you wouldn’t have to do
    > anything about the name change unless you wanted to.
    >
    > However, if they use a technique that doesn’t respect Github’s protocol
    > (or if that protocol doesn’t work with mirror repos), or if you just want
    > to keep things neat and avoid confusion, here is how you change local
    > repos’ upstream pointers to point at the new apache repo names:
    >
    > 1. cd to the base directory of the local git repo
    > 2. Give the command `git remote -v`
    > 3. You’ll probably see something like:
    >
    > apache  https://github.com/apache/incubator-metron.git (fetch)
    > apache  https://github.com/apache/incubator-metron.git (push)
    > origin    https://github.com/mattf-horton/incubator-metron.git (fetch)
    > origin    https://github.com/mattf-horton/incubator-metron.git (push)
    >
    > 4. In this case, you could give the command:
    > `git remote set-url apache https://github.com/apache/metron.git`
    > <https://github.com/apache/metron.git>
    > 5. Now the command `git remote -v` will show:
    >
    > apache  https://github.com/apache/metron.git (fetch)
    > apache  https://github.com/apache/metron.git (push)
    > origin    https://github.com/mattf-horton/incubator-metron.git (fetch)
    > origin    https://github.com/mattf-horton/incubator-metron.git (push)
    >
    > and thereafter, every reference to the remote named “apache” would refer
    > to apache/metron instead of apache/incubator-metron.
    >
    > ‘C’ is if you want to rename your personal fork repositories in Github.
    > Again it doesn’t matter that much, but you may wish to do so for
    > appearance’ sake, or to avoid confusion.  Instructions for renaming a
    > personal repo are here:
    > https://help.github.com/articles/renaming-a-repository/ .  (Note you must
    > have “owner” privs for the repo.)  The instructions say that if you follow
    > these instructions, and don’t create a new repo with the old name, then
    > Github will maintain semantics for users of the prior name, so you don’t
    > have to do any other adjustments.  Nevertheless, you would then probably
    > want to do something like this command within the above example repo:
    > `git remote set-url origin https://github.com/mattf-horton/metron.git`
    > <https://github.com/mattf-horton/metron.git>
    > Thereafter references to “origin” in your local repo would refer directly
    > to your renamed fork repo in Github.
    >
    > ‘D’ finally is perhaps the most difficult question.  Every fork repo in
    > Github “knows” what repo it was forked from, and uses that as the default
    > for Pull Requests generated from the fork.  Can this be changed?
    >
    > If Apache INFRA respects the Github protocol for repo renaming, then we
    > don’t need to change anything.  We can just rely on the semantic
    > preservation in the protocol and new PRs generated will automatically point
    > at the renamed Apache repository, directly or indirectly.  That would be
    > best, because Github does NOT provide any easy means for changing the “fork
    > upstream” pointer.
    >
    > If the Github protocol is not respected, and the default fork upstream
    > reference becomes invalid, the easiest thing to do is simply set it
    > manually when you create each new PR.  That’s not difficult, and is only a
    > minor nuisance.
    >
    > If you truly need to change the fork upstream pointer, the only way to do
    > so is:
    > 1. Create a new Github fork from the new apache repo (with a new name).
    > 2. Clone a new local repo from your old Github fork, and fetch all
    > branches and all tags
    > 3. Change origin with `git remote set-url` to point at your new Github fork
    > 4. Push all branches and tags (with -f if needed) to the new origin
    >
    > Now consider your new Github fork to be a “renamed” copy of the old, and
    > apply ‘C’ to other local repos as necessary.
    > This does not necessarily preserve other Github resources related to the
    > personal fork repo, such as Issues or Wikis.  There may be ways to migrate
    > those resources, but I’m not familiar with them.
    >
    > That’s about it.  Don’t go overboard on this stuff until we find out
    > whether it’s actually needed.  I’m sure there will be more to discuss as we
    > experience the actual effects of un-incubation.
    >
    > Committers’ tools that access apache git (git-wip-us.apache.org) will
    > also need to be tweaked, but that will probably be obvious to those who
    > work with them.
    >
    > Cheers,
    > --Matt
    >
    > On 4/28/17, 2:47 PM, "Casey Stella" <ce...@gmail.com> wrote:
    >
    >     I have begun the process as described in
    >     http://incubator.apache.org/guides/graduation.html#project-first-steps
    > and
    >     http://www.apache.org/dev/infra-contact#requesting-graduation to move
    > out
    >     of the incubator.
    >
    >     First off, I'm sorry it took so long, but it's started now.  I will be
    >     sending followup emails in the ensuing days around instructions for
    >     developers and mailing list subscribers.  I will be sure to send them
    > as
    >     soon as I figure out what to send.
    >
    >     Here we go, hell for leather, baby bird's gotta fly. :)
    >
    >     Casey
    >
    >
    >
    > --
    
    Jon
    


Re: Started the infrastructure requests to move to TLP

Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
Does this officially mean 0.4.0 is on hold until the migration is
complete?  I assume the vote based on RC2 failed (for more reason than
one), but also can we assume that work in progress now is more likely to
get into 0.4.0?  I would love some more time to QA master as it currently
is - which I'm working on.  I have fumbled upon a fair amount of issues
lately and I'm concerned that the more I look the more I'll find.  That
said, I definitely would not vote to hold things up to wait on my efforts
because it could be weeks before it's entirely done and tested
appropriately, I'm just wondering if that will be a natural byproduct of
our graduation.

Jon

On Sat, Apr 29, 2017, 3:24 AM Matt Foley <ma...@apache.org> wrote:

> A brief guide to changing our github remotes from
> “apache/metron-incubating” to “apache/metron”
> [also applies to “incubator-metron-bro-plugin-kafka” →
> “metron-bro-plugin-kafka” ]
>
> Hey all, as a result of un-incubating, the github apache repo names will
> change.  Some people have expressed concerns whether this will impact their
> development environments.  This potentially affects four areas:
> A. Changing local repo names to match
> B. Changing local repos’ upstream pointers to point at the new apache repo
> names
> C. Changing the names of personal fork repos in Github to match
> D. Changing the upstream “source” apache repo that your personal fork
> repos in Github point at for purposes of Pull Requests
>
> ‘B’ is the only important one, but we’ll talk about them in order.
>
> ‘A’ is the least important.  You can call a local repo anything you want,
> because the name of the local clone is just a directory name, and not
> strictly part of the repository at all.  If you want to change its name,
> just `mv` the base directory name.  It doesn’t matter.  You probably
> already call them something other than “incubator-metron”  anyway :-)
>
> ‘B’ may or may not be important, depending on how Apache INFRA goes about
> changing the name of the Github apache/metron mirror repo.  If they use the
> standard Github owner’s command for renaming a repo, then Github maintains
> semantics for users of the prior name.  Then, you wouldn’t have to do
> anything about the name change unless you wanted to.
>
> However, if they use a technique that doesn’t respect Github’s protocol
> (or if that protocol doesn’t work with mirror repos), or if you just want
> to keep things neat and avoid confusion, here is how you change local
> repos’ upstream pointers to point at the new apache repo names:
>
> 1. cd to the base directory of the local git repo
> 2. Give the command `git remote -v`
> 3. You’ll probably see something like:
>
> apache  https://github.com/apache/incubator-metron.git (fetch)
> apache  https://github.com/apache/incubator-metron.git (push)
> origin    https://github.com/mattf-horton/incubator-metron.git (fetch)
> origin    https://github.com/mattf-horton/incubator-metron.git (push)
>
> 4. In this case, you could give the command:
> `git remote set-url apache https://github.com/apache/metron.git`
> <https://github.com/apache/metron.git>
> 5. Now the command `git remote -v` will show:
>
> apache  https://github.com/apache/metron.git (fetch)
> apache  https://github.com/apache/metron.git (push)
> origin    https://github.com/mattf-horton/incubator-metron.git (fetch)
> origin    https://github.com/mattf-horton/incubator-metron.git (push)
>
> and thereafter, every reference to the remote named “apache” would refer
> to apache/metron instead of apache/incubator-metron.
>
> ‘C’ is if you want to rename your personal fork repositories in Github.
> Again it doesn’t matter that much, but you may wish to do so for
> appearance’ sake, or to avoid confusion.  Instructions for renaming a
> personal repo are here:
> https://help.github.com/articles/renaming-a-repository/ .  (Note you must
> have “owner” privs for the repo.)  The instructions say that if you follow
> these instructions, and don’t create a new repo with the old name, then
> Github will maintain semantics for users of the prior name, so you don’t
> have to do any other adjustments.  Nevertheless, you would then probably
> want to do something like this command within the above example repo:
> `git remote set-url origin https://github.com/mattf-horton/metron.git`
> <https://github.com/mattf-horton/metron.git>
> Thereafter references to “origin” in your local repo would refer directly
> to your renamed fork repo in Github.
>
> ‘D’ finally is perhaps the most difficult question.  Every fork repo in
> Github “knows” what repo it was forked from, and uses that as the default
> for Pull Requests generated from the fork.  Can this be changed?
>
> If Apache INFRA respects the Github protocol for repo renaming, then we
> don’t need to change anything.  We can just rely on the semantic
> preservation in the protocol and new PRs generated will automatically point
> at the renamed Apache repository, directly or indirectly.  That would be
> best, because Github does NOT provide any easy means for changing the “fork
> upstream” pointer.
>
> If the Github protocol is not respected, and the default fork upstream
> reference becomes invalid, the easiest thing to do is simply set it
> manually when you create each new PR.  That’s not difficult, and is only a
> minor nuisance.
>
> If you truly need to change the fork upstream pointer, the only way to do
> so is:
> 1. Create a new Github fork from the new apache repo (with a new name).
> 2. Clone a new local repo from your old Github fork, and fetch all
> branches and all tags
> 3. Change origin with `git remote set-url` to point at your new Github fork
> 4. Push all branches and tags (with -f if needed) to the new origin
>
> Now consider your new Github fork to be a “renamed” copy of the old, and
> apply ‘C’ to other local repos as necessary.
> This does not necessarily preserve other Github resources related to the
> personal fork repo, such as Issues or Wikis.  There may be ways to migrate
> those resources, but I’m not familiar with them.
>
> That’s about it.  Don’t go overboard on this stuff until we find out
> whether it’s actually needed.  I’m sure there will be more to discuss as we
> experience the actual effects of un-incubation.
>
> Committers’ tools that access apache git (git-wip-us.apache.org) will
> also need to be tweaked, but that will probably be obvious to those who
> work with them.
>
> Cheers,
> --Matt
>
> On 4/28/17, 2:47 PM, "Casey Stella" <ce...@gmail.com> wrote:
>
>     I have begun the process as described in
>     http://incubator.apache.org/guides/graduation.html#project-first-steps
> and
>     http://www.apache.org/dev/infra-contact#requesting-graduation to move
> out
>     of the incubator.
>
>     First off, I'm sorry it took so long, but it's started now.  I will be
>     sending followup emails in the ensuing days around instructions for
>     developers and mailing list subscribers.  I will be sure to send them
> as
>     soon as I figure out what to send.
>
>     Here we go, hell for leather, baby bird's gotta fly. :)
>
>     Casey
>
>
>
> --

Jon

Re: Started the infrastructure requests to move to TLP

Posted by Matt Foley <ma...@apache.org>.
A brief guide to changing our github remotes from “apache/metron-incubating” to “apache/metron”
[also applies to “incubator-metron-bro-plugin-kafka” → “metron-bro-plugin-kafka” ]

Hey all, as a result of un-incubating, the github apache repo names will change.  Some people have expressed concerns whether this will impact their development environments.  This potentially affects four areas:
A. Changing local repo names to match
B. Changing local repos’ upstream pointers to point at the new apache repo names
C. Changing the names of personal fork repos in Github to match
D. Changing the upstream “source” apache repo that your personal fork repos in Github point at for purposes of Pull Requests

‘B’ is the only important one, but we’ll talk about them in order.

‘A’ is the least important.  You can call a local repo anything you want, because the name of the local clone is just a directory name, and not strictly part of the repository at all.  If you want to change its name, just `mv` the base directory name.  It doesn’t matter.  You probably already call them something other than “incubator-metron”  anyway :-)

‘B’ may or may not be important, depending on how Apache INFRA goes about changing the name of the Github apache/metron mirror repo.  If they use the standard Github owner’s command for renaming a repo, then Github maintains semantics for users of the prior name.  Then, you wouldn’t have to do anything about the name change unless you wanted to.
	
However, if they use a technique that doesn’t respect Github’s protocol (or if that protocol doesn’t work with mirror repos), or if you just want to keep things neat and avoid confusion, here is how you change local repos’ upstream pointers to point at the new apache repo names:

1. cd to the base directory of the local git repo
2. Give the command `git remote -v`
3. You’ll probably see something like:

apache  https://github.com/apache/incubator-metron.git (fetch)
apache  https://github.com/apache/incubator-metron.git (push)
origin    https://github.com/mattf-horton/incubator-metron.git (fetch)
origin    https://github.com/mattf-horton/incubator-metron.git (push)

4. In this case, you could give the command:
`git remote set-url apache https://github.com/apache/metron.git`
5. Now the command `git remote -v` will show:

apache  https://github.com/apache/metron.git (fetch)
apache  https://github.com/apache/metron.git (push)
origin    https://github.com/mattf-horton/incubator-metron.git (fetch)
origin    https://github.com/mattf-horton/incubator-metron.git (push)

and thereafter, every reference to the remote named “apache” would refer to apache/metron instead of apache/incubator-metron.

‘C’ is if you want to rename your personal fork repositories in Github.  Again it doesn’t matter that much, but you may wish to do so for appearance’ sake, or to avoid confusion.  Instructions for renaming a personal repo are here: https://help.github.com/articles/renaming-a-repository/ .  (Note you must have “owner” privs for the repo.)  The instructions say that if you follow these instructions, and don’t create a new repo with the old name, then Github will maintain semantics for users of the prior name, so you don’t have to do any other adjustments.  Nevertheless, you would then probably want to do something like this command within the above example repo:
`git remote set-url origin https://github.com/mattf-horton/metron.git`
Thereafter references to “origin” in your local repo would refer directly to your renamed fork repo in Github.

‘D’ finally is perhaps the most difficult question.  Every fork repo in Github “knows” what repo it was forked from, and uses that as the default for Pull Requests generated from the fork.  Can this be changed?

If Apache INFRA respects the Github protocol for repo renaming, then we don’t need to change anything.  We can just rely on the semantic preservation in the protocol and new PRs generated will automatically point at the renamed Apache repository, directly or indirectly.  That would be best, because Github does NOT provide any easy means for changing the “fork upstream” pointer.

If the Github protocol is not respected, and the default fork upstream reference becomes invalid, the easiest thing to do is simply set it manually when you create each new PR.  That’s not difficult, and is only a minor nuisance.

If you truly need to change the fork upstream pointer, the only way to do so is:
1. Create a new Github fork from the new apache repo (with a new name).
2. Clone a new local repo from your old Github fork, and fetch all branches and all tags
3. Change origin with `git remote set-url` to point at your new Github fork
4. Push all branches and tags (with -f if needed) to the new origin

Now consider your new Github fork to be a “renamed” copy of the old, and apply ‘C’ to other local repos as necessary.
This does not necessarily preserve other Github resources related to the personal fork repo, such as Issues or Wikis.  There may be ways to migrate those resources, but I’m not familiar with them.

That’s about it.  Don’t go overboard on this stuff until we find out whether it’s actually needed.  I’m sure there will be more to discuss as we experience the actual effects of un-incubation.

Committers’ tools that access apache git (git-wip-us.apache.org) will also need to be tweaked, but that will probably be obvious to those who work with them.

Cheers,
--Matt

On 4/28/17, 2:47 PM, "Casey Stella" <ce...@gmail.com> wrote:

    I have begun the process as described in
    http://incubator.apache.org/guides/graduation.html#project-first-steps and
    http://www.apache.org/dev/infra-contact#requesting-graduation to move out
    of the incubator.
    
    First off, I'm sorry it took so long, but it's started now.  I will be
    sending followup emails in the ensuing days around instructions for
    developers and mailing list subscribers.  I will be sure to send them as
    soon as I figure out what to send.
    
    Here we go, hell for leather, baby bird's gotta fly. :)
    
    Casey