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, "[email protected]" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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
