Re: idea: light-weight pull requests

[Paul Wise]

On Tue, 2017-02-07 at 03:11 +, Eric Wong wrote:

> How would discussion and review happen?  People seem to use
> either mail, or centralized messaging (and the latter often
> involves non-Free systems like GitHub or Slack).

It would depend on the setup for the particular repo. Information about
where that happens could be part of the output of the git push.

> This is a big one.  Maybe CRM114 or another generic/trainable
> option can be made usable; but I think there'll always be cases
> where hardcoded rules need to be written (for SpamAssassin,
> at least) and real-time blacklists need to be checked.

TBH, I doubt spam would become a problem at all.

> Anyways, I ultimately decided it would be better to continue
> supporting and improving email (which is at least entrenched in
> a few communities, like this one), rather than trying to get
> people to adopt something new.

Email is great for people used to the old ways but it is gradually
being replaced by APIs and web interfaces :(

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

Re: idea: light-weight pull requests

[Eric Wong]

Paul Wise  wrote:
> Hi all,
> 
> I had an idea that might be interesting to git folks:
> 
> light-weight pull requests:
> 
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.

I considered something similar to this a few years ago,
but decided it wasn't worth the effort (see below).

> Advantages:
> 
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
> 
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
> 
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
> 
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
> 
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
> 
> Contributions from people without an account on those services are
> possible.
> 
> Contributions from people without any git repository hosting of their
> own are possible.

All of these are great goals which I'd love to see realized, but...

> Contributions from people who don't use or dislike MUAs are possible.

How would discussion and review happen?  People seem to use
either mail, or centralized messaging (and the latter often
involves non-Free systems like GitHub or Slack).

> Disadvantages:
> 
> Pull request spam, could be mitigated with configuration options.

This is a big one.  Maybe CRM114 or another generic/trainable
option can be made usable; but I think there'll always be cases
where hardcoded rules need to be written (for SpamAssassin,
at least) and real-time blacklists need to be checked.

At some point, you might end up having to recreate everything we
have in place to combat email spam.  Or, use blockchain or
something similarly expensive for reputation, which isn't good
for poor folks with slow computers.

Anyways, I ultimately decided it would be better to continue
supporting and improving email (which is at least entrenched in
a few communities, like this one), rather than trying to get
people to adopt something new.

Re: idea: light-weight pull requests

[Paul Wise]

On Mon, 2017-02-06 at 19:57 -0500, Santiago Torres wrote:

> IMHO, the notion of a PR/MR is more specific to Git repository
> management tools (e.g., GitHub, GitLab). They all have specific
> concepts/ways to manage the way how their hosted repositories behave ---
> and I believe this flexibility is one of the beauties in Git . I could
> see how this could be implemented by tools like this rather easily
> (e.g., using symlinks + inotify or something less hacky).

Right, but I would like to see this everywhere (including kernel.org),
so support in git-daemon and the http/ssh equivalents is needed too.
git already has support for anonymous push but this idea is more complex.

> I'm wondering if standardizing this would be more interesting to those
> communities?

I've pitched this to github.com/contact but couldn't find any feature
request address for GitLab.

> I would like to see what becomes of this.

Likewise :)

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

Re: idea: light-weight pull requests

[Santiago Torres]

Hello, pabs.

IMHO, the notion of a PR/MR is more specific to Git repository
management tools (e.g., GitHub, GitLab). They all have specific
concepts/ways to manage the way how their hosted repositories behave ---
and I believe this flexibility is one of the beauties in Git . I could
see how this could be implemented by tools like this rather easily
(e.g., using symlinks + inotify or something less hacky).

I'm wondering if standardizing this would be more interesting to those
communities?

I would like to see what becomes of this.

Cheers!
-Santiago.

On Tue, Feb 07, 2017 at 08:32:17AM +0800, Paul Wise wrote:
> Hi all,
> 
> I had an idea that might be interesting to git folks:
> 
> light-weight pull requests:
> 
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.
> 
> Advantages:
> 
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
> 
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
> 
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
> 
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
> 
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
> 
> Contributions from people without an account on those services are
> possible.
> 
> Contributions from people without any git repository hosting of their
> own are possible.
> 
> Contributions from people who don't use or dislike MUAs are possible.
> 
> Disadvantages:
> 
> Pull request spam, could be mitigated with configuration options.
> 
> Extra configuration and complexity on the server side. This is once
> only and means less complexity on the pull requester side.
> 
> Will not work with typical setups where the git/http/ssh user does not
> have write access to the repositories. A workaround could be some sort
> of hybrid-repository setup with the new refs and objects in a second
> repository which would be shared by all pull requesters.
> 
> -- 
> bye,
> pabs
> 
> http://bonedaddy.net/pabs3/




signature.asc
Description: PGP signature

idea: light-weight pull requests

[Paul Wise]

Hi all,

I had an idea that might be interesting to git folks:

light-weight pull requests:

Anonymous and ssh/http-identified users should be able to push just
using git, within the refs/pull/ namespace, to any non-existent branch
name or to a branch they created when previously identified, without
forking off a new repository.

Advantages:

Removes the need to look up who to send the pull request notification
to since configuring that is up to the project itself.

Removes the annoying scenario of having lots of remotes that have been
removed after the corresponding pull request was closed.

Moves popular git hosting services from primarily a model of forests of
forks to one of contributions to well maintained ongoing projects.

Allows users to use their preferred git clients to issue pull requests
instead of using web interfaces of popular git hosting services.

Creates a new standard for contributing to repositories on all git
repository hosting services.

Contributions from people without an account on those services are
possible.

Contributions from people without any git repository hosting of their
own are possible.

Contributions from people who don't use or dislike MUAs are possible.

Disadvantages:

Pull request spam, could be mitigated with configuration options.

Extra configuration and complexity on the server side. This is once
only and means less complexity on the pull requester side.

Will not work with typical setups where the git/http/ssh user does not
have write access to the repositories. A workaround could be some sort
of hybrid-repository setup with the new refs and objects in a second
repository which would be shared by all pull requesters.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part