On 23.11.2015 20:41, Konstantin Boudnik wrote: > On Mon, Nov 23, 2015 at 09:08AM, Branko Čibej wrote: >> On 23.11.2015 04:13, Konstantin Boudnik wrote: >>> On Sun, Nov 22, 2015 at 02:16PM, Dmitriy Setrakyan wrote: >>>> Cos, >>>> >>>> I believe this is the ticket: >>>> https://issues.apache.org/jira/browse/INFRA-10798 >>>> >>>> This policy does seem myopic, would be great if Ignite could get an >>>> exemption. >>> Thanks! I already have sent email to the board where this discussion is >>> going >>> right now. Hopefully, this ban will be lifted soon. >> The best way to get this changed is to invent a workflow that doesn't >> delete important information. "Important" in this case meaning "always >> knowing where a particular bit of code came from". Most "optimal" Git >> workflows tend to happily rebase and squash such info out the window. > How it is different if I take _all_ code in an SVN trunk, pack into a giant > tarball, then create a fresh branch and commit that blob as a single commit?
Not different at all. But my point is that Git allows you to do that with one command, and many workflows based on Git actively encourage (dare I say mandate) that sort of thing. Whereas it's less likely that anyone using SVN would propose such a workflow, since it'd be such a huge pain to follow. > The situation isn't git specific - it's people specific. Solving people > problem with tech never works, really. That's why I wrote "Git workflows", not "Git"; workflows are invented by people, not software. I agree that the prohibition on branch deletions isn't a solution; it's a stopgap, which everyone admits. >> Case in point: when Ignite was incubating, we had an issue where we >> could not track the IP of the JSR166 backports (ConcurrentHashMap et >> al.), neither in the ASF repo (which was sort-of expected) nor in the >> original GridGain repo, because info about the original import was lost. >> We ended up having to remove those files and re-import them from the >> canonical source, so that we could be certain about the license. In this >> case, by sheer luck, the solution was simple. > The assumption that it happened because of git is non consequential, actually. > Most likely that was a result of some mundane reasons like moving > repos/re-importing the code from one place to another, etc. Keep in mind, the > code base is like 8 years old, and wasn't in git originally. Perhaps it was > sitting in SVN and brought-up to git with fast-import, which shouldn't be used > really. Did I say it's "because of Git"? I did not; I said it's because of the workflows people tend to use with Git. Let's not make this a Git vs. SVN debate, because it's not and the embers (not flames yet) are just distracting from the topic. I guess my example wasn't well chosen; I should've looked for one that happened recently in ASF code. >> The ASF promises its users that we have complete oversight of the IP in >> our released source and can easily audit any single byte of source all >> the way to its original author. Deleting a branch in Git (and other >> destructive changes) can make auditing extremely hard, in some cases >> impossible. >> >> Granted that forbidding branch deletions isn't the only way to solve >> this problem; but it certainly goes a long way towards fixing it. Now >> it's up to *you* guys (i.e., every project at the ASF that uses Git >> repos) to come up with a workflow that allows branch deletions but >> doesn't lose the ability to audit the source; forbidding squashed merges >> would probably do it, but I'm sure there are other ways. > That sounds like tossing the problem from one side of the fence to another. > PMC should be in control of the project IP and all other paraphernalia. PMC is > responsible before the board for this type if policy commotions. I am not > trying > to dismiss the importance of the paper-trail for IP-related issues. All I am > saying that disabling a perfectly valid functionality because there's a chance > of somebody misusing it, is like UK prohibiting the sales of the butter-knives > to the under aged: ludicrous at best. You'll note that the board told Infra to do this as a stopgap to prevent "responsible PMCs" from further messing up our IP provenance. Clearly, some PMCs are not responsible. It's painful that the restriction hurt all PMCs. Instead of complaining to me, it'd be far more useful to work with those other PMCs to produce a set of rules for using Git -- *not* a single blessed workflow -- that prevent losing important information about the code base. Ideally, the rules would be easily implemented as checks in Git hooks. The idea being to prevent mistakes, not to constrain developers. One proposal was to archive push logs indefinitely ... i.e., maintaining version control history outside the version control system. It made me mildly amused to see such a proposal; but only mildly, because the implication that the VCS is missing the "C" isn't funny. I'm amazed that such a discussion did not happen earlier; still, it is what it is. Infra cannot invent such rules, neither can the Board. It's up to the PMCs to show that "collaboration" isn't just a buzzword, but that they can come up with sensible, cross-project solutions, too. -- Brane >>>> On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <c...@apache.org> >>>> wrote: >>>> >>>>> Raul >>>>> >>>>> is there are a ticket for this INFRA ticket? Sorry if I missed it... >>>>> >>>>> I regurgitate about this no-branch-delete policy imposed by a myopic >>>>> "policy" >>>>> considerations. And I want to increase the pressure on board@ for this >>>>> sort of >>>>> things. Would appreciate the pointer if exist. >>>>> >>>>> Thanks! >>>>> Cos >>>>> >>>>> On Thu, Nov 19, 2015 at 11:47AM, Raul Kripalani wrote: >>>>>> Ok. So Infra replied and referred to an email on November 3rd which I >>>>>> somehow missed, indicating that it is indeed an ASF-wide temporary >>>>>> restriction. >>>>>> >>>>>> +1 to liberty of options to contribute/commit and to temporarily keeping >>>>>> track of branches to delete in the Wiki. >>>>>> >>>>>> Regards, >>>>>> >>>>>> *Raúl Kripalani* >>>>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and >>>>>> Messaging Engineer >>>>>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >>>>>> http://blog.raulkr.net | twitter: @raulvk >>>>>> >>>>>> On Thu, Nov 19, 2015 at 10:21 AM, Semyon Boikov <sboi...@gridgain.com> >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <voze...@gridgain.com >>>>>>> wrote: >>>>>>> >>>>>>>> I agree that there is absolutely no problems of have multiple ways to >>>>>>>> provide contributions. >>>>>>>> >>>>>>>> If you are contributor, you can: >>>>>>>> - Provide a patch; >>>>>>>> - Provide a PR using GitHub mirror. >>>>>>>> >>>>>>>> If you are committer, you can: >>>>>>>> - Provide a patch; >>>>>>>> - Provide a PR using GitHub mirror; >>>>>>>> - Use branch in ASF repo and remove it in the end. >>>>>>>> >>>>>>>> ASF branches removal is temporary restricted by INFRA. As soon as it >>>>> is >>>>>>>> enabled again why not using it? It is the easiest way to provide >>>>>>>> contributions and review them. >>>>>>>> >>>>>>>> On Thu, Nov 19, 2015 at 12:49 PM, Raul Kripalani <ra...@apache.org> >>>>>>> wrote: >>>>>>>>> Lads, >>>>>>>>> >>>>>>>>> It is not clear to me whether branch deletion is prohibited >>>>> ASF-wide >>>>>>>>> (Dmitriy: "we *cannot* delete branches") or by express project >>>>> request. >>>>>>>>> I've understood both things from the thread. So let's wait for >>>>> INFRA to >>>>>>>>> clarify: [1]. >>>>>>>>> >>>>>>>>> Can someone please explain why we resort to Github in the first >>>>> place? >>>>>>>> Was >>>>>>>>> it for CI integration purposes? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>> https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-10798 >>>>>>>>> *Raúl Kripalani* >>>>>>>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big >>>>> Data >>>>>>> and >>>>>>>>> Messaging Engineer >>>>>>>>> http://about.me/raulkripalani | >>>>>>> http://www.linkedin.com/in/raulkripalani >>>>>>>>> http://blog.raulkr.net | twitter: @raulvk >>>>>>>>> >>>>>>>>> On Thu, Nov 19, 2015 at 9:34 AM, Pavel Tupitsyn < >>>>>>> ptupit...@gridgain.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I'd like to add that there is virtually no difference between >>>>> using a >>>>>>>>>> branch in original repo and a branch in your personal fork on >>>>> GitHub. >>>>>>>>>> Merges and other operations work seamlessly between multiple >>>>> remotes. >>>>>>>>>> Committers don't even have to create PRs (except to run a TC >>>>> build). >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> On Thu, Nov 19, 2015 at 12:28 PM, Yakov Zhdanov < >>>>> yzhda...@apache.org >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> But this leads to tons of garbage in repo and abandoned >>>>> branches, >>>>>>>> etc. >>>>>>>>>>> --Yakov >>>>>>>>>>> >>>>>>>>>>> 2015-11-19 12:19 GMT+03:00 Raul Kripalani <r...@evosent.com>: >>>>>>>>>>> >>>>>>>>>>>> As I said: "Pull requests make sense when outsiders want to >>>>> make >>>>>>>>>>>> contributions." >>>>>>>>>>>> >>>>>>>>>>>> Committers with write access to ASF Git have no reason to >>>>> develop >>>>>>>> in >>>>>>>>>>>> Github. >>>>>>>>>>>> On 19 Nov 2015 09:13, "Yakov Zhdanov" <yzhda...@apache.org> >>>>>>> wrote: >>>>>>>>>>>>> Disagree. This means none but committer can contribute. >>>>>>>>>>>>> >>>>>>>>>>>>> --Yakov >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-11-19 12:08 GMT+03:00 Raul Kripalani < >>>>> r...@evosent.com>: >>>>>>>>>>>>>> I disagree. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Code should be in the ASF infra. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Pull requests make sense when outsiders want to make >>>>>>>>> contributions. >>>>>>>>>>>>>> The usage of ASF infra is not a mere formality. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Raúl. >>>>>>>>>>>>>> On 19 Nov 2015 08:57, "Yakov Zhdanov" < >>>>> yzhda...@gridgain.com >>>>>>>>>> wrote: >>>>>>>>>>>>>>> Guys, therefore, let's develop new functionality in >>>>>>> personal >>>>>>>>>> forks, >>>>>>>>>>>>> test >>>>>>>>>>>>>> on >>>>>>>>>>>>>>> TC with pull requests and then merge to apache git as >>>>>>>> described >>>>>>>>>>> here >>>>>>>>>>>> - >>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >>>>>>>>>>>>>>> We should create new branches only if this is really >>>>>>>> necessary. >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Yakov Zhdanov, Director R&D >>>>>>>>>>>>>>> *GridGain Systems* >>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-11-18 23:04 GMT+03:00 Dmitriy Setrakyan < >>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>> : >>>>>>>>>>>>>>>> Raul, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ASF is currently prohibiting deletion of GIT branches >>>>>>> until >>>>>>>>>>> further >>>>>>>>>>>>>>> notice. >>>>>>>>>>>>>>>> Please add your branch to this Wiki page, so we don’t >>>>>>> loose >>>>>>>>>>> track: >>>>> https://cwiki.apache.org/confluence/display/IGNITE/Git+branches+to+delete >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> D. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Nov 18, 2015 at 10:16 AM, Raul Kripalani < >>>>>>>>>>> ra...@apache.org >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Fellows, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm trying to push a branch deletion and the ASF >>>>> Git >>>>>>>> tells >>>>>>>>> me >>>>>>>>>>>> that >>>>>>>>>>>>>>> branch >>>>>>>>>>>>>>>>> deletion is prohibited. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Has someone changed something? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [raul@~/Workbench/Source/ignite$] git push -f >>>>> origin >>>>>>>>>>>> :ignite-1790 >>>>>>>>>>>>>>>>> remote: error: denying ref deletion for >>>>>>>>>> refs/heads/ignite-1790 >>>>>>>>>>>>>>>>> To https://git-wip-us.apache.org/repos/asf/ignite >>>>>>>>>>>>>>>>> ! [remote rejected] ignite-1790 (deletion >>>>> prohibited) >>>>>>>>>>>>>>>>> error: failed to push some refs to ' >>>>>>>>>>>>>>>>> https://git-wip-us.apache.org/repos/asf/ignite' >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Raúl Kripalani* >>>>>>>>>>>>>>>>> PMC & Committer @ Apache Ignite, Apache Camel | >>>>>>>>> Integration, >>>>>>>>>>> Big >>>>>>>>>>>>> Data >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> Messaging Engineer >>>>>>>>>>>>>>>>> http://about.me/raulkripalani | >>>>>>>>>>>>>>> http://www.linkedin.com/in/raulkripalani >>>>>>>>>>>>>>>>> http://blog.raulkr.net | twitter: @raulvk >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> Pavel Tupitsyn >>>>>>>>>> GridGain Systems, Inc. >>>>>>>>>> www.gridgain.com >>>>>>>>>> >>
