Branch deletion prohibited

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

dsetrakyan
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
> > > > > >
> > > > >
> > > >
> > >
>
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Konstantin Boudnik-2
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
> > > > > > >
> > > > > >
> > > > >
> > > >
> >

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Branko Čibej
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
>>>>>>>>


Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Konstantin Boudnik-2
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?

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.
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.

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
> >>>>>>>>
>
>

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Raul Kripalani-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Raul Kripalani
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
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Konstantin Boudnik-2
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).
As far as I see, direct pulls from other repos isn't usually a case. Even if
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

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Konstantin Boudnik-2
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.
Going into extreme here, if the file is hosted in the repo itself, then an
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

signature.asc (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Branko Čibej
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
>>>>>>>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Branko Čibej
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
Reply | Threaded
Open this post in threaded view
|

Re: Branch deletion prohibited

Konstantin Boudnik-2
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.
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 <[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
> >>>>>>>>>>
> >>
>

signature.asc (237 bytes) Download Attachment
12