+1 On Nov 12, 2013 9:48 AM, "Stephen Connolly" <[email protected]> wrote:
> I am less keen on Gerrit. If anything this recent experience has me > feeling that I don;t want Gerrit anywhere near my workflow > > > On 12 November 2013 15:43, Kevin Fleming (BLOOMBERG/ 731 LEXIN) < > [email protected]> wrote: > >> 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-userwe >>> 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/[pluginname]-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. >> > > -- > 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.
