Agree with Christopher that "technically" this does not matter if branch is fork PR or branch PR. And I also see the usefulness of Dependabot. I used it in the past and it's been extremely easy and helpful - with all the changelogs/release notes right in the PR you could find in exactly the moment and place you needed them.
There is one very small difference - namely the visibility of those refs. When you have fork PR refs, you do not see them in the UI of GitHub outside of the PR, with a clear indication it comes from a fork. Whereas when you have PR in the repo, you see both PR and the branch in the "main" repo. For me it's not a problem though. I think the "3rd-party" motivation does not come from "visibility" but "technical feasibility of writing to the repo" But I am not sure what is the motivation behind the "3rd-party" rule, and what actually constitutes a 3rd-party. GitHub could very easily write a change to any of our repos and we probably would not notice (especially if you rebase and push --force often), We already implicitly trust GitHub and they are our "infrastructure provider" - we have business relationship with them, and I guess they do not qualify as 3rd-party because (I am guessing here) we have a legal agreement with them that allows to qualify them as not a "3rd-party" in this case. The ASF did not have a legal agreement with Dependabot. GitHub owns Dependabot and integrates them in their service. I wonder if our legal agreement with GitHub also covers subsidiaries (and I am not even sure - maybe Dependabot is just a brand after acquisition and legally they ARE GitHub) I think in this case both "3rd-party" and "add code to the repo" are defined well enough and they are open for interpretation. Who should interpret that ? Board? VP legal? I think it's worth considering revising the "no Dependabot" rule by the board. It made a lot of sense 2 years ago but I think a lot changed at the moment Dependabot was acquired by GitHub (so initially I even thought this is already a solved problem). Maybe that's a good time to review the stance taking that ownership change into consideration? J. On Fri, Sep 3, 2021 at 6:21 PM Christopher <ctubb...@apache.org> wrote: > I feel like people are getting a bit hung up on the fact that dependabot > creates branches in the repo directly when that isn't any different from > what GitHub is doing for pull requests. > > Dependabot creates refs in git under refs/heads/dependabot/* (this is > customizable, to some extent by the repo owners with a config file) > > GitHub natively creates refs for pull requests under refs/pull/* > > Both write directly to the repo. Neither is a problem. The only difference > is that we mirror some refs and not others by default, so we forget about > the PR refs. It should be noted that dependabot's refs (called branches, > only because the refs are under refs/heads/*) are trivial config changes, > and not really code and definitely don't contain any IP whose provenance > matters. The utility as branches rather than as non-branch refs like pull > requests is to provide a writable place for the devs to add commits to > resolve any actual code changes to make the version bumps function before > the PR is merged. > > I really don't see the problem here, but if we really don't want to mirror > these refs, like PR refs, we could just exclude them in the mirror process, > although I think that would cause problems if devs are adding commits to > these branches to resolve issues before merging. Either these branches > contain trivial changes, or they contain dev additions. So either way, I > don't see a problem mirroring them. But it could be done if policy > disallowed it. > > Personally, I think it should be allowed, as the branches are not > substantially different from PR refs, do not contain substantial IP unless > the devs add commits, are transient, and the tool is immensely useful. > Since the tool is managed by GitHub itself and not another third party, and > we have a relationship with GitHub as a hosting service for mirroring our > repos, I think the risk is further mitigated. We already trust GitHub to > write PR refs to the repos, and to function properly as a bidirectional > mirror, so why not trust them for this immensely useful tool that empowers > projects to develop more secure builds? > > I think we shouldn't let nitpicking over policy technicalities get in the > way of doing what is reasonable here. If we really don't trust these refs, > just exclude them from the mirror process to the gitbox copy. But I see no > reason we can't trust devs to enable this tool and decide for their own > workflows. > > On Fri, Sep 3, 2021, 06:15 sebb <seb...@gmail.com> wrote: > > > On Fri, 3 Sept 2021 at 01:09, Olivier Lamy <ol...@apache.org> wrote: > > > > > > On Fri, 3 Sept 2021 at 09:57, David Jencks <david.a.jen...@gmail.com> > > wrote: > > > > > > > I’m afraid I don’t understand your “the result is the same” argument. > > > > > > > > > > result == Apache committer merging the bot commit > > > > > > > But that is not the only change to the repo. > > The repo also has a branch containing code committed by the 3rd party. > > > > We cannot allow 3rd parties to add code directly to our repos. > > > > > > > > > > Let's say a company has 2 employees, Arthur, who is not an Apache > > > > committer on project X, and Bernadette who is. Arthur writes some > > code and > > > > submits a PR to project X. In scenario 1, Bernadette merges the PR > > and in > > > > scenario 2 Arthur does. The result is the same!! (at least the > > resulting > > > > code is the same, there will be some difference in the fields in the > > > > commit) So should we allow scenario 2? > > > > > > > > > > except in our case Arthur (i.e the bot never merge his pr but only > Apache > > > committer merge to master/main branches) > > > > > > > > > > > > > > > > > David Jencks > > > > > > > > > On Sep 2, 2021, at 4:42 PM, Olivier Lamy <ol...@apache.org> wrote: > > > > > > > > > > I perfectly understand this. > > > > > But my point was at the end the result is the same! > > > > > If we follow such reasoning, why do we use github as we do not > > control > > > > what > > > > > is happening there? > > > > > but yeah I'm having an already lost discussion :) > > > > > > > > > > On Fri, 3 Sept 2021 at 09:32, David Jencks < > david.a.jen...@gmail.com > > > > > > > wrote: > > > > > > > > > >> The difference is whether a non-committer has write access to an > > Apache > > > > >> repo. In this case the non-committer is some code GitHub > maintains > > > > that we > > > > >> have no control over. Why should we trust it not to modify a real > > > > branch? > > > > >> > > > > >> To now argue on the other side of the issue, the git website > > publishing > > > > >> workflow using .asf.yaml allows Jenkins jobs to automatically > > commit to > > > > >> specific branches in Apache repos as part of publishing > websites. I > > > > can’t > > > > >> say I’m all that clear on how the two situations differ. One > > > > difference is > > > > >> that the Jenkins script is set up and presumably written by an > > Apache > > > > >> committer: also infra restricts which branch(es) the Jenkins > script > > > > commits > > > > >> to. > > > > >> > > > > >> David Jencks > > > > >> > > > > >>> On Sep 2, 2021, at 4:16 PM, Olivier Lamy <ol...@apache.org> > wrote: > > > > >>> > > > > >>> So what happen here? > > > > >>> If I understand correctly dependabot creates a branch in a fork > > > > >> repository > > > > >>> with a commit then this commit is merged back to the Apache > GitHub > > repo > > > > >> by > > > > >>> a committer. > > > > >>> > > > > >>> In the previous model dependabot created a branch in the Apache > > GitHub > > > > >> repo > > > > >>> then a committer merged this back to master or any other branch. > > > > >>> > > > > >>> In both case there is a commit by a bot which has been merged by > a > > > > >>> committer.. > > > > >>> > > > > >>> What is exactly the difference at the end? > > > > >>> > > > > >>> On Fri, 3 Sep 2021 at 8:19 am, David Jencks < > > david.a.jen...@gmail.com> > > > > >>> wrote: > > > > >>> > > > > >>>> After thinking about it for a couple of minutes I’m fully behind > > > > Apache > > > > >>>> policy forbidding automated commits to an Apache repository. If > > > > Eclipse > > > > >>>> allows such commits I’d rather suspect they haven’t noticed > them. > > > > >>>> > > > > >>>> Assuming that dependabot can’t deal with making it’s branch in a > > > > >> separate > > > > >>>> repo it might be possible to make something like this work: > > > > >>>> > > > > >>>> 1. Someone fork the apache repo. > > > > >>>> 2. Use something like > > > > >>>> > > > > >> > > > > > > > https://mathieu.carbou.me/post/649318432483033088/automatic-fork-syncing-with-github > > > > >>>> to keep this fork up to date with the Apache repo. > > > > >>>> 3. Run dependabot on this fork. > > > > >>>> > > > > >>>> In these circumstances I’m not sure what the target of the > > dependabot > > > > PR > > > > >>>> would be or, if it’s the fork, how hard it would be to make a PR > > to > > > > the > > > > >>>> Apache repo. > > > > >>>> 4. Do something to apply the dependabot PR/changes to the apache > > repo. > > > > >>>> > > > > >>>> David Jencks > > > > >>>> > > > > >>>>> On Sep 2, 2021, at 2:48 PM, Olivier Lamy <ol...@apache.org> > > wrote: > > > > >>>>> > > > > >>>>> Hi, > > > > >>>>> Really? This sounds like a productivity killer to remove such > > > > >> feature... > > > > >>>>> the bot never write to master branch it just creates a branch > > and pr > > > > >>>> which > > > > >>>>> need to be validated/merged by a valid committer. > > > > >>>>> FYI eclipse foundation definitely accepts this without problem > > so I > > > > >> guess > > > > >>>>> we have a similar level of source management. > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> On Wed, 1 Sept 2021 at 05:33, Gary Gregory < > > garydgreg...@gmail.com> > > > > >>>> wrote: > > > > >>>>> > > > > >>>>>> I am missing something here: the whole point of dependabot is > > that > > > > it > > > > >>>>>> creates a branch in GitHub, runs a build, and creates a PR. If > > you > > > > >> like > > > > >>>> the > > > > >>>>>> results, you can click merge, a huge time saver. > > > > >>>>>> > > > > >>>>>> I really don't want to loose this killer feature. > > > > >>>>>> > > > > >>>>>> Gary > > > > >>>>>> > > > > >>>>>> On Tue, Aug 31, 2021, 11:33 Chris Lambertus <c...@apache.org> > > wrote: > > > > >>>>>> > > > > >>>>>>> Third party write access to code repositories is expressly > > > > forbidden > > > > >> by > > > > >>>>>>> Foundation policy: > > > > >>>>>>> > > > > >>>>>>> https://infra.apache.org/repository-access.html < > > > > >>>>>>> https://infra.apache.org/repository-access.html> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> Infra has worked with GitHub to prevent dependabot from being > > able > > > > to > > > > >>>>>>> write to our repos, but it appears that it is still able to > > under > > > > >> some > > > > >>>>>>> circumstances. We will open yet another support case with > > GitHub > > > > >>>>>> regarding > > > > >>>>>>> this. > > > > >>>>>>> > > > > >>>>>>> Here is an example of a third party commit: > > > > >>>>>>> > > > > >>>>>>> https://github.com/apache/commons-io/pull/264 < > > > > >>>>>>> https://github.com/apache/commons-io/pull/264> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > https://lists.apache.org/thread.html/ra4ca6fdfd6dd75e4579c334ca7f012df69ca00908dd48b645c1a7339%40%3Ccommits.commons.apache.org%3E > > > > >>>>>>> < > > > > >>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > > https://lists.apache.org/thread.html/ra4ca6fdfd6dd75e4579c334ca7f012df69ca00908dd48b645c1a7339@%3Ccommits.commons.apache.org%3E > > > > >>>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> This write access to commons-io appears to be in violation of > > the > > > > >>>>>>> aforementioned policy. > > > > >>>>>>> > > > > >>>>>>> Dependabot's email alerts are currently the only acceptable > > method > > > > >> for > > > > >>>>>>> working with the tool. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> -Chris > > > > >>>>>>> ASF Infra > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>>> On Aug 30, 2021, at 10:53 AM, Gary Gregory < > > > > garydgreg...@gmail.com> > > > > >>>>>>> wrote: > > > > >>>>>>>> > > > > >>>>>>>> The Apache git repo must be mirrored from Apache to GitHub, > > for > > > > >>>> example > > > > >>>>>>>> https://github.com/apache/commons-io, then you add a > .github > > > > folder > > > > >>>>>> and > > > > >>>>>>>> files (see above link). > > > > >>>>>>>> > > > > >>>>>>>> Gary > > > > >>>>>>>> > > > > >>>>>>>> On Mon, Aug 30, 2021, 09:43 Lewis John McGibbney < > > > > >> lewi...@apache.org> > > > > >>>>>>> wrote: > > > > >>>>>>>> > > > > >>>>>>>>> Thanks Gary and Sebb. > > > > >>>>>>>>> How do I turn dependabot on? Last time I tried I was > informed > > > > that > > > > >>>> due > > > > >>>>>>> to > > > > >>>>>>>>> the program requiring write permissions to the repository, > it > > > > >> wasn’t > > > > >>>>>>>>> possible… > > > > >>>>>>>>> This policy must have changed… > > > > >>>>>>>>> Thanks for any info. > > > > >>>>>>>>> lewismc > > > > >>>>>>>>> > > > > >>>>>>>>> On 2021/08/29 14:42:00 Gary Gregory wrote: > > > > >>>>>>>>>> Most of Apache Common's components' are happy users of > > > > Dependabot, > > > > >>>>>>> which > > > > >>>>>>>>> is > > > > >>>>>>>>>> used on our GitHub mirrored repositories. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Gary > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>>> On Sun, Aug 29, 2021, 10:38 lewis john mcgibbney < > > > > >>>> lewi...@apache.org > > > > >>>>>>> > > > > >>>>>>>>> wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>>> Hi builds@, > > > > >>>>>>>>>>> I was advised to ask my question here instead of > > > > >> general@incubator. > > > > >>>>>>>>>>> Thanks for any feedback > > > > >>>>>>>>>>> > > > > >>>>>>>>>>>> I understand that we cannot use automated tooling, > > > > specifically > > > > >>>>>>>>> Dependbot > > > > >>>>>>>>>>> ( > > > > >>>>>>>>>>>> https://dependabot.com/) because it requests write > > access to > > > > >> the > > > > >>>>>> ASF > > > > >>>>>>>>>>>> project source code. > > > > >>>>>>>>>>>> I have found this functionality to be really useful and > > > > wondered > > > > >>>> if > > > > >>>>>>>>> there > > > > >>>>>>>>>>>> are any suggestions out there for automating the > > dependency > > > > >>>>>>>>> management > > > > >>>>>>>>>>>> workflow? > > > > >>>>>>>>>>>> Thanks for any feedback. > > > > >>>>>>>>>>>> lewismc > > > > >>>>>>>>>>> -- > > > > >>>>>>>>>>> http://home.apache.org/~lewismc/ > > > > >>>>>>>>>>> http://people.apache.org/keys/committer/lewismc > > > > >>>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> -- > > > > >>>>> Olivier Lamy > > > > >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > >>>> > > > > >>>> -- > > > > >>> Olivier Lamy > > > > >>> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > >> > > > > >> > > > > > > > > > > -- > > > > > Olivier Lamy > > > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > > > > > > > > > > -- > > > Olivier Lamy > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > >
