-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[Maintenance] The Gofrs would like to adopt logrus #799
Comments
Hi Tim, love the initiative. Unfortunately, I think that migrating to an organization is not worth the cost. I am not saying this out of my ego, I am not thrilled about having my name in all projects—however, judging by the Logrus lowercasegate—I do not want to cause another stir. That already decreased Logrus trust globally significantly. Perhaps you're seeing a path there I am not? I would be happy to add you as collaborators, however, my biggest priority for Logrus is that it never breaks for anyone. That means maintaining full backwards compatibility of all public APIs, which, unfortunately, due to Go's packaging continues to include my name in the import... 😭 |
hi @sirupsen I understand your worries and it totally makes sense. I was one of many affected by the My suggestion is to have an hard fork at https://github.com/gofrs/logrus that starts with version v2. Then we update the README of https://github.com/sirupsen/logrus explaning that this repository will not be maintained anymore pointing to https://github.com/gofrs/logrus So v1 would use https://github.com/sirupsen/logrus and v2 onwards https://github.com/gofrs/logrus. In doing so I think we could achieve your priority:
|
If we do this, we could certainly discuss some breaking changes for few users (e.g. getting rid of formatters, and just make them hooks) as part of the transition. If a repository is importing both |
👍
AFAIK this is a problem only if one file (not a repository) is importing both. Even doing so it's possible to do something like: import logrusv1 "https://github.com/sirupsen/logrus"
import logrusv2 "https://github.com/gofrs/logrus" Also, from https://golang.org/doc/code.html#PackageNames:
|
Hey @sirupsen, Thank you so much for getting back to me. We really appreciate it.
I think we can both agree that keeping To your comment about an organization migration, that actually isn't too disruptive as GitHub will redirect users to the new location (as long as you don't happen to create a new However, I see the move as being a long-term possibility if we mutually come to the decision that it's too painful to have a group contribute to the repository as it is today. I'll admit I'm not familiar with what types of permissions you can grant to people contributing to a repository on your account, so it's possible this won't be an issue. (Edit: I am now, and you can't grant them anything in terms of repository administration. 😢)
We're definitely on the same page there. I'd like to learn more about the API compatibility you want to stick to. Are you against making breaking changes even if it's done with a major version bump (e.g., going from 1.x => 2.x), and then cutting an appropriate git tag? Are you saying that the I think one bias I have is that at this point most consumers of Go are using something beyond pure To the point made by @franciscocpg, I'd personally much prefer to avoid a hard fork if possible. I find it extremely valuable to retain the issue and PR history of a project. There are sometimes very useful bits of context in there that would otherwise be lost. It's why I prefer to either contribute where it currently lives, or to migrate to a new location and let us cheat using GitHub redirects. |
@theckman |
Hello, I could not find any documentation for migrating a repository from a user to an organization. Could someone post here a documentation referencing the process of such a migration ? |
I believe these are the docs you're looking for: This article also mentions the one limitation I called out a few messages above:
This means that so as long as a new
I don't think anyone in this thread is advocating for a move right now, and I tried to be explicit about that in my original comment:
I wasn't looking to discuss it now or make it part of the plan, as mentioned by saying "we can cross that bridge when we get to it". However, since it seems like it's become a focus of this discussion it's probably best that I transparently share my thoughts on why a migration may be something we need down the road. Before doing that though, some context is that The Gofrs is being built as a team of people to take on the maintenance of repositories. The big reason for this being a team effort is that I don't want the burden of project maintenance to fall on a single person, even within The Gofrs. We want it to be a shared responsibility to try and avoid burnout and to provide different sets of perspectives on things. Having said that, with repositories on single user accounts only that user (e.g., When you consider that last scenario, it's a bit scary to think that we on The Gofrs would not be able to revoke commit access if a user's account was somehow compromised. We require the use of two-factor authentication to be in our organization which reduces that risk, but we cannot make the same enforcement on a repo on a single user's account. So a user with contributor access could disable two-factor authentication and still have commit access to that repo. We've configured The Gofrs organization to disallow that. @dgsb The thing I'm now curious about, if you consider the thousands of people who import |
Just an idea for backwards compatibility, couldn't a mirror be setup for the old repo to the new repo? This would make sure inattentive users can still get logrus without thinking it's been abandoned. |
This seems so fragile. What happens if |
@franciscocpg if he's aware we have moved the repo and he shouldn't create a repo with the same name, what do you believe the likelihood that it'll happen? Do you think it would happen without that person engaging the people who moved the repo first? To provide some context, looking at this issue, and the project in general, it's clear to me that Simon cares about people's ability to use the package and the overall success of the project. Considering that I don't anticipate what you mention being a large risk. |
I see. Just to be clear. I'm not trying to judge sirupsen's character or something like that. But maybe it worth the trade-off. |
@franciscocpg I think it was a great question to ask, and I didn't personally read it as a judgement of character. I was only hoping to share my context as to why I didn't perceive it as being too risky as a long-term option. |
Still about
Another thing that comes to my mind now: |
@franciscocpg Maybe. Some of that may be mitigated by making him a contributor on our repo, since he could push branches and open PRs. |
A fork can be created in another account, renamed, and transferred. I've done this in the past to prevent clobbering redirects. |
For the record here is the documentation page which describes the redirect upon repository transfer: https://help.github.com/articles/about-repository-transfers/ |
Sorry for the silence here. Had a bunch of things come up. I am extremely committed to get this into your capable hands, I just want to ensure we don't break anything. I wouldn't create a new repo if we can transfer it with a redirect, it seems good to me. I don't want to create another I agree that today, most are using modern version control for Go. What I worry about are the 100s to 1000s of gists lying around that would no longer work if we broke compatibility with What if we maintained |
As we receive some backward incompatible pr from time to time, I've created this issue #815 in order to reach consensus. |
To me, that's the key decision here. If we can agree on that structure, I see no issue making this handle permanently a redirect and update the README with the new governance and repository structure. |
@sirupsen no worries; GopherCon prep had me busy as well. There is one case[1] I know of where a simple repository migration won't work, but I've confirmed logrus doesn't fall in to that bucket. In having some discussions with people in Denver around this effort, I think there's value in doing some small experiments with migrating a repository of mine to the organization to re-validate my earlier observations. I plan on moving one of my projects this week, and making sure things work as-expected.
I don't think it's crazy, because it would keep that guarantee. However, I don't know how well that will play with the modules system introduced in Go 1.11. I can also see it causing confusion with some people opening PRs/issues against the wrong branch, or code diving and spending time grokking a different implementation. [1] The one case I know of is when your project has an |
Much of that can be mitigated by making a version branch like 2.x and updating the repository HEAD to point to the latest version branch. |
It took a little longer than I anticipated to get the one outstanding PR merged, but I've done the migration now. The original project was hosted at https://github.com/theckman/go-flock. I then migrated it to the GitHub has set up redirects to send the original two URLs to https://github.com/gofrs/flock. |
I would really like to see that happen, since its currently impossible for me to import With this migration (and especially the v2) I could finally make all my projects work with go modules + logrus. @theckman may I assist to get this going again? |
@trusch where are you seeing the old ( |
@trusch I'm currently on vacation in Japan, and part of my time is going to be spent working on personal projects (while relaxing home with my wife's family). I'm also going to be budgeting out specific hours each week to dedicate my time to our projects moving forward. So I'm going to start working towards this in the coming days, with dedicate time to continue working on it, and so depending on what help I need I'll be in touch. |
@thaJeztah I see it in the 17.05.0-ce tag and the latest v1.* Tag which is considered the latest stable tag following semver (this gets automatically selected by go mod tidy) |
Right, so there's a couple of issues there;
|
Okay so I've been doing some digging here, and with modules support enabled now it seems like our original migration plan is no longer possible. It does mean we need to come up with an alternative plan. This totally was my fault and I'm really sorry. 😞 In summary because the I'm doing a bit of traveling to visit family in Japan so I've not been able to spend my usual amount of time thinking about it, but so far there are a few options. Option A
The end result is that this repository, with full issue/pr history, would be located at That said, there are some cons with this approach:
Option BThe only other option we would be to fork the repo, request GitHub support detach it from One upside of the toil, if you can call it that, is it'd be a good filter for issues/pull requests. If it doesn't get reopened, maybe it wasn't that important. Option CI started a conversation here, where @bcmills made a suggestion:
I'm not sure I fully understand how we'd accomplish this on the I'd love to hear the thoughts of others on this one. I'd also be good if those more experienced with modules can 👀 this as well. |
@theckman There are obviously some module-specific pieces here, but to help level-set on the nature of what some of the problems are, I wanted to briefly mention that there is some overlap with how before modules the In other words, taking a simpler pre-modules example, uber couldn't just tell people to use a new vanity url for I think part of the intent from uber's perspective is to prevent someone from accidentally importing The This is not any advice or suggested solution, but wanted to re-cap some of the behaviors to consider as different solutions are evaluated. edit: some related snippets from the official https://golang.org/cmd/go/#hdr-Import_path_checking
edit 2: first cut was slightly mangled. Sorry. |
I think you'd have two possible approaches, depending on how far back you want compatibility and a couple of other factors. Using the major-subdirectory layout, you can do the whole thing in one commit, so that's what I'll describe first — it's probably simplest. You can tag that commit as both At the repo root, you'd want something like:
/*
Package logrus is a structured logger for Go, completely API compatible with the standard library logger.
[…]
*/
package logrus // import "github.com/sirupsen/logrus"
import (
v2 "github.com/gofrs/logrus/v2"
)
// […]
func Info(args ...interface{}) {
// Might need to add a “depth” variant in v2 to pick up the right caller info;
// see glog.InfoDepth for an example.
v2.InfoDepth(1, args...)
}
// […]
type Logger = v2.Logger
// […]
func New() *Logger { return v2.New() }
[…] // etc.
/*
Package logrus is a structured logger for Go, completely API compatible with the standard library logger.
[…]
*/
package logrus // import "github.com/gofrs/logrus/v2"
|
In theory the |
Actually testing that change would be tricky, unfortunately: you'd need to use |
Note that you can implement forwarding regardless of whether you start a new (forked) repo or move the existing one. (It's not so much “option C” as “A with forwarding” or “B with forwarding”.) In my opinion, forwarding is only viable way to change the import path: options A and B would both break the semantics of |
If you want to avoid moving the files into a With that approach, you'd issue one commit tagged |
@bcmills thank you for taking time to reply and explain our options. That final option may be the best result, but probably worth simulating to make sure we're happy with the result. So: Option DOption E |
@bcmills wrote:
This might be possible as an alternative to publishing both commits at same time:
And at that point, it is live (without needing to have committed to a At some later date, as new tags get applied without Also, a |
Hey guys, I don't want to sound harsh, but what you want to do seems highly complicated with no clear added value to me. |
@dgsb the value add is that we can have multiple users with administrative access to the repo. Edit: Unless it changed recently, contributors cannot be administrators if the repo is on a single user's account. |
Setting aside for the moment the question who fixes what where... On the technical aspects of the migration question, my perhaps incorrect understanding is:
If that is correct, then a simpler option (compared to some of the options discussed in the comments above) might be something like:
In other words, if that is acceptable, and if that works, that might be simpler than any type aliasing / forwarding / I think that would be similar in spirit to how some projects in the past like
Under the option outlined in this comment, I think then any discussion about a v2+ version could be a separate / future matter? All that said, I am not intimately familiar with the history of logrus, so sorry if any or all of this is off base... |
@thepudds thank you for taking the time to write that up. I think that final option is our best bet, and would be the one we'd likely pursue. In doing some research we found the error the modules code presents when the module path differs isn't very actionable[1]. I've just raised a CL[2] to fix an issue with the unexpected module path error to be a bit more actionable. If that change, or a similar one, gets merged it should improve the error in a way that would let people know what they have to do to fix it being the wrong import. I think that would then give us the cleanest migration path forward. [1] golang/go#28489 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hi @sirupsen,
A few of us over in the Go community have started a bit of a working group to share the work of maintaining projects that are extremely important to the Go ecosystem. It goes without saying, logrus is absolutely one of those.
We've opened up a way for the community to suggest projects to adopt and logrus was one of them (gofrs/help-requests#2).
I wanted to reach out to see what your preference is for a team like The Gofrs taking over this project. Because this repo is on your personal GitHub account, and not an organization, it seems like we may be fairly limited in the type of shared responsibility we can take on. There are currently 20 members in the organization, so as a first step we could maybe add myself and a few others as collaborators so that we can share the load.
Beyond that, in the interest of full transparency, we may need to consider migrating the project to an organization to allowed richer management of collaborators. That said we can cross that bridge when we get to it.
Cheers!
-Tim
The text was updated successfully, but these errors were encountered: