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. D. On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <[hidden email]> 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 <[hidden email]> > > wrote: > > > > > +1 > > > > > > On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <[hidden email] > > > > > 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 <[hidden email]> > > > 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 < > > > [hidden email]> > > > > > 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 < > [hidden email] > > > > > > > > > > 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 <[hidden email]>: > > > > > > > > > > > > > > > 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" <[hidden email]> > > > wrote: > > > > > > > > > > > > > > > > > Disagree. This means none but committer can contribute. > > > > > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > 2015-11-19 12:08 GMT+03:00 Raul Kripalani < > [hidden email]>: > > > > > > > > > > > > > > > > > > > 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" < > [hidden email] > > > > > > > > > > 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 < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > [hidden email] > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > |
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. Cos > > D. > > On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <[hidden email]> 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 <[hidden email]> > > > wrote: > > > > > > > +1 > > > > > > > > On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <[hidden email] > > > > > > > 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 <[hidden email]> > > > > 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 < > > > > [hidden email]> > > > > > > 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 < > > [hidden email] > > > > > > > > > > > > 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 <[hidden email]>: > > > > > > > > > > > > > > > > > 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" <[hidden email]> > > > > wrote: > > > > > > > > > > > > > > > > > > > Disagree. This means none but committer can contribute. > > > > > > > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > 2015-11-19 12:08 GMT+03:00 Raul Kripalani < > > [hidden email]>: > > > > > > > > > > > > > > > > > > > > > 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" < > > [hidden email] > > > > > > > > > > > > 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 < > > > > > > > > [hidden email] > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > [hidden email] > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > |
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. 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 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. -- Brane >> D. >> >> On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <[hidden email]> 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 <[hidden email]> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <[hidden email] >>>>> 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 <[hidden email]> >>>>> 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 < >>>>> [hidden email]> >>>>>>> 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 < >>> [hidden email] >>>>>>>> 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 <[hidden email]>: >>>>>>>>> >>>>>>>>>> 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" <[hidden email]> >>>>> wrote: >>>>>>>>>>> Disagree. This means none but committer can contribute. >>>>>>>>>>> >>>>>>>>>>> --Yakov >>>>>>>>>>> >>>>>>>>>>> 2015-11-19 12:08 GMT+03:00 Raul Kripalani < >>> [hidden email]>: >>>>>>>>>>>> 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" < >>> [hidden email] >>>>>>>> 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 < >>>>>>>>> [hidden email] >>>>>>>>>>> : >>>>>>>>>>>>>> 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 < >>>>>>>>> [hidden email] >>>>>>>>>>>>> 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 >>>>>>>> |
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. tarball, then create a fresh branch and commit that blob as a single commit? The situation isn't git specific - it's people specific. Solving people problem with tech never works, really. > 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. > 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. 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. Cos > >> On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <[hidden email]> 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 <[hidden email]> > >>>> wrote: > >>>> > >>>>> +1 > >>>>> > >>>>> On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <[hidden email] > >>>>> 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 <[hidden email]> > >>>>> 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 < > >>>>> [hidden email]> > >>>>>>> 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 < > >>> [hidden email] > >>>>>>>> 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 <[hidden email]>: > >>>>>>>>> > >>>>>>>>>> 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" <[hidden email]> > >>>>> wrote: > >>>>>>>>>>> Disagree. This means none but committer can contribute. > >>>>>>>>>>> > >>>>>>>>>>> --Yakov > >>>>>>>>>>> > >>>>>>>>>>> 2015-11-19 12:08 GMT+03:00 Raul Kripalani < > >>> [hidden email]>: > >>>>>>>>>>>> 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" < > >>> [hidden email] > >>>>>>>> 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 < > >>>>>>>>> [hidden email] > >>>>>>>>>>> : > >>>>>>>>>>>>>> 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 < > >>>>>>>>> [hidden email] > >>>>>>>>>>>>> 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 > >>>>>>>> > > |
In reply to this post by Branko Čibej
Hi Brane,
I hadn't joined the project back then, so I don't know the history, but my guess is that the loss of traceability might have occurred as a result of importing the code from an external repository. I don't see why they could be attributed to branch deletion – probably I'm not feeling creative enough today ;-) The current prohibition seems to be temporary. There's was fragility in the current scenario – since any committer could delete any Git head from the repo, including fundamental ones which should be protected by all means: master, develop, maintenance streams, etc. So if a dev accidentally deleted master, and you were unlucky enough that the Git server decided to run gc between then and the time you tried to recover from reflog, you could be pretty screwed. Well – not so much, because presumably other devs would be having local copies of master and could re-push them. But it's still a hardcore vulnerability! In Ignite, the branches we create to implement JIRA issues originate from our ASF Git repo itself, so traceability is feasible at all times. A different story would be to pull from a remote repo (Github – this could be problematic in terms of IP) into the ASF. In my opinion, Board does need to regulate that, because using GH for pull requests may lead to some dubious situations with regards to IP. (I can elaborate if you guys are interested to discuss). 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 |
In reply to this post by Konstantin Boudnik-2
On Mon, Nov 23, 2015 at 3:13 AM, Konstantin Boudnik <[hidden email]> wrote:
> Thanks! I already have sent email to the board where this discussion is > going > right now. Hopefully, this ban will be lifted soon. > Nice, thanks, Cos! Please keep us informed of their progress on protecting branches. Maybe repos could have a special branch: .protection with a file protected_branches.txt, where the project lists which heads should be protected. The Git server would need a hook to check whether a given branch deletion is permitted or not, based on that file. *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 |
In reply to this post by Raul Kripalani-2
On Mon, Nov 23, 2015 at 08:02PM, Raul Kripalani wrote:
> Hi Brane, > > I hadn't joined the project back then, so I don't know the history, but my > guess is that the loss of traceability might have occurred as a result of > importing the code from an external repository. I don't see why they could > be attributed to branch deletion – probably I'm not feeling creative enough > today ;-) > > The current prohibition seems to be temporary. There's was fragility in the > current scenario – since any committer could delete any Git head from the > repo, including fundamental ones which should be protected by all means: > master, develop, maintenance streams, etc. So if a dev accidentally deleted > master, and you were unlucky enough that the Git server decided to run gc > between then and the time you tried to recover from reflog, you could be > pretty screwed. Well – not so much, because presumably other devs would be > having local copies of master and could re-push them. But it's still a > hardcore vulnerability! > > In Ignite, the branches we create to implement JIRA issues originate from > our ASF Git repo itself, so traceability is feasible at all times. A > different story would be to pull from a remote repo (Github – this could be > problematic in terms of IP) into the ASF. In my opinion, Board does need to > regulate that, because using GH for pull requests may lead to some dubious > situations with regards to IP. (I can elaborate if you guys are interested > to discuss). one has two remotes - one for ASF git & another for GH - and cherry-pick a commit from GH to ASF, it is traceable by the virtue of associated JIRA tickets, etc. So, yes - while a potential pain in the butt - a solvable situation. Cos > 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 |
In reply to this post by Raul Kripalani
On Mon, Nov 23, 2015 at 08:03PM, Raul Kripalani wrote:
> On Mon, Nov 23, 2015 at 3:13 AM, Konstantin Boudnik <[hidden email]> wrote: > > > Thanks! I already have sent email to the board where this discussion is > > going > > right now. Hopefully, this ban will be lifted soon. > > > > Nice, thanks, Cos! Please keep us informed of their progress on protecting > branches. Maybe repos could have a special branch: .protection with a file > protected_branches.txt, where the project lists which heads should be > protected. The Git server would need a hook to check whether a given branch > deletion is permitted or not, based on that file. attacker can modify it and then wipe out some branches, if desired. Perhaps, forbidding all tags and branches with keyword release in them might solve the issue. Will see. Cos > > *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 |
In reply to this post by Konstantin Boudnik-2
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 <[hidden email]> 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 <[hidden email]> >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <[hidden email] >>>>>>> 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 <[hidden email]> >>>>>>> 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 < >>>>>>> [hidden email]> >>>>>>>>> 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 < >>>>> [hidden email] >>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>> >>>>>>>>>>>> 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" <[hidden email]> >>>>>>> wrote: >>>>>>>>>>>>> Disagree. This means none but committer can contribute. >>>>>>>>>>>>> >>>>>>>>>>>>> --Yakov >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-11-19 12:08 GMT+03:00 Raul Kripalani < >>>>> [hidden email]>: >>>>>>>>>>>>>> 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" < >>>>> [hidden email] >>>>>>>>>> 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 < >>>>>>>>>>> [hidden email] >>>>>>>>>>>>> : >>>>>>>>>>>>>>>> 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 < >>>>>>>>>>> [hidden email] >>>>>>>>>>>>>>> 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 >>>>>>>>>> >> |
On 24.11.2015 05:53, Branko Čibej wrote:
> 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. On the topic of hooks: Subversion allows changes to revision properties (not by default of course) that would be quite inappropriate; for example, you could, theoretically, change the name of the author of a commit. At the ASF we have a specific hook to allow changing log messages, but none of the other revision properties; and the commit mailer sends diffs of changed log messages to the project's mailing list. This is an example of the sort of rule I'm talking about: it does not impose any particular workflow; it allows changing log messages and provides a permanent audit trail (in list archives); it does not allow changing commit date, author, etc., because those would be obvious mistakes. (And FWIW: Yes, Subversion has a design bug in not maintaining an archive of previous values of revision properties to provide that audit trail.) -- Brane |
In reply to this post by Branko Čibej
On Tue, Nov 24, 2015 at 05:53AM, Branko Čibej wrote:
> 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. Bigtop we aren't even discussing things like force-pushing master or release branches. On the other hand, what ppl are doing with their integration/dev branches is no one else business, really. > >> 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 exchane of opinions ;) Cos > 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 <[hidden email]> 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 <[hidden email]> > >>>>>> wrote: > >>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov <[hidden email] > >>>>>>> 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 <[hidden email]> > >>>>>>> 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 < > >>>>>>> [hidden email]> > >>>>>>>>> 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 < > >>>>> [hidden email] > >>>>>>>>>> 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 <[hidden email]>: > >>>>>>>>>>> > >>>>>>>>>>>> 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" <[hidden email]> > >>>>>>> wrote: > >>>>>>>>>>>>> Disagree. This means none but committer can contribute. > >>>>>>>>>>>>> > >>>>>>>>>>>>> --Yakov > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2015-11-19 12:08 GMT+03:00 Raul Kripalani < > >>>>> [hidden email]>: > >>>>>>>>>>>>>> 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" < > >>>>> [hidden email] > >>>>>>>>>> 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 < > >>>>>>>>>>> [hidden email] > >>>>>>>>>>>>> : > >>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>> [hidden email] > >>>>>>>>>>>>>>> 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 > >>>>>>>>>> > >> > |
Free forum by Nabble | Edit this page |