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.
I believe we are in agreement here, just nibbling around the edges. Say, in 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 I am not really complaining, but having an interesting (to me at least) 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 <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 > >>>>>>>>>> > >> >
signature.asc
Description: Digital signature
