Well, that would mean that merging a pull request on GitHub (especially the quick way, using the web UI) wouldn't update the canonical repository; the repo maintainer would need to push that change to the canonical repository, potentially dealing with a second round of merge conflicts if that repo's master branch has moved on. Sounds a bit complex :-)
There's been some discussion about using Gerrit as a front-end for all the repository activity, and I'd definitely support that move. The GitHub repos would then just be a distribution/forking point, but the workflow would be through Gerrit. ----- Original Message ----- From: [email protected] To: [email protected] At: Nov 12 2013 10:13:13 On 12 November 2013 14:40, Kevin Fleming (BLOOMBERG/ 731 LEXIN) <[email protected]> wrote: When you say 'canonical' in this proposal, do you mean the repositories used for making releases I mean that they are the "official" repositories and all others are just mirrors... this is the way GIT at ASF works... , or the repositories where development (and especially, pull requests) would be handled? If it's the former, I could see that being worthwhile, especially if *nobody* has permissions to push to the canonical repositories; No, I'd let developers be able to push to the canonical repositories... but just not `git push --force`. There are a set of git permissions that basically ensure you cannot rewrite the past, and those would be applied to the canonical repositories. I would then perhaps prevent developers from pushing to github... but there are possibly ways to permit that. Pull requests, forking etc would still work at github though, so no major change there... this would just introduce a set of "one true repositories" if a developer pushes code to the master branch of their repo on GitHub, they'd have to wait a short time for that update to be mirrored to the release repo before they could make a release. Of course, this would put extra pressure on the people who are maintaining the project infrastructure, to be sure that this mirroring process is working reliably all the time. ----- Original Message ----- From: [email protected] To: [email protected] At: Nov 12 2013 05:17:15 I think part of the issue is that our canonical repositories are on github... I would favour jenkins-ci.org being masters of its own destiny... hence I would recommend hosting canonical repos on project owned hardware and using GIT as a mirror of those canonical repositories... much like the way ASF uses GIT. That would allow us to implement policies such as preventing forced push to specific branches, etc... Of course that would be another pom.xml <scm> update change, namely the <developerConnection> would point to the canonical repo while the <connection> would point to the github repo... (with some use of http://developer.github.com/v3/users/keys/#list-public-keys-for-a-user we should be able to let users just register their keys in github) e.g. the <scm> details would look like: <scm> <connection>scm:git:git://github.com/jenkinsci/[plugin name]-plugin.git</connection> <developerConnection>scm:git:git.jenkins-ci.org:jenkinsci/[plugin name]-plugin.git</developerConnection> <url>http://github.com/jenkinsci/[plugin name]-plugin</url> </scm> Maven will then do the "right thing" for pushing releases *even if you checkout from github*... and we just have the canonical repos force push to github and put proper permission sets on the canonical repos... most developers will thus see no effective difference :-) On 12 November 2013 06:25, Kohsuke Kawaguchi <[email protected]> wrote: Now that the commits have been recovered and things are almost back to normal, I think it's time to think about how to prevent this kind of incidents in the future. Our open commit access policy was partly made possible by the idea that any bad commits can be always rolled back. But where I failed to think through was that the changes to refs aren't by themselves version controlled, and so it is possible to lose commits by incorrect ref manipulation, such as "git push -f", or by deleting a branch. I still feel strongly that we maintain the open commit access policy. This is how we've been operating for the longest time, and it's also because otherwise adding/removing developers to repositories would be prohibitively tedious. So my proposal is to write a little program that uses GitHub events API to keep track of push activities in our repositories. For every update to a ref in the repository, we can record the timestamp, SHA1 before and after, the user ID. We can maintain a text file for every ref in every repository, and the program can append lines to it. In other words, effectively recreate server-side reflog outside GitHub. The program should also fetch commits, so that it has a local copy for every commit that ever landed on our repositories. Doing this also allows the program to detect non fast-forward. It should warn us in that situation, plus it will create a ref on the commit locally to prevent it from getting lost. We can then make these repositories accessible via rsync to encourage people to mirror them for backup, or we can make them publicly accessible by hosting them on GitHub as well, although the latter could be confusing. WIth a scheme like this, pushes can be safely recorded within a minute or so (and this number can go down even further if we use webhooks.) If a data loss occurs before the program gets to record newly pushed commits, we should still be able to record who pushed afterward to identify who has the commits that were lost. With such a small time window between the push and the record, the number of such lost commits should be low enough such that we can recover them manually. -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
