What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14, 1:14 AM, John Marino wrote:
> On 1/25/2014 09:55, Alfred Perlstein wrote:
>> On 1/24/14, 11:45 PM, John Marino wrote:
>>> On 1/25/2014 05:16, Alfred Perlstein wrote:
>>>>> Thus, are you volunteering for this role?  It's not my call, but if you
>>>>> really want to do clean out and triage the all PRs on an ongoing basis,
>>>>> my guess is that would be very welcome and we'd figure out a way to set
>>>>> that up.  It would definitely help, especially for those maintainer
>>>>> that
>>>>> "approve" patches but the PRs never get opened (or set to a better
>>>>> state
>>>>> than "open").
>>>>>
>>>>> At some point we'll have a new PR system, that fact might be having an
>>>>> impact on current PRs as well...
>>>> To me it would speak of tooling as opposed to anything.
>>>> Does the ports system have a 1 or 2 click interface for merging PRs like
>>>> for instance github?
>>> The SCM part of the ports process is not the bottleneck.
>>>
>>>> Could ports take PRs in the form of pull requests on github?
>>>> Wouldn't that just turn the number of updates into a few minor clicks?
>>> This makes a fatal and untrue assumption: That was is submitted just
>>> needs to be committed.  In my brief experience, I can tell you that's
>>> simply not true.  If a submission can be taken without a single change,
>>> that is truly an exception.  It's not even the submitters fault often,
>>> sometimes the infrastructure changes but the submitter didn't know or
>>> account for it, or the PR came before the infrastructure change.
>>>
>>> One can RARELY take a submission as-is.  Thus, pull requests turn into
>>> merge conflict exercises and cause more work, not less IMO.
>> Your opinion is completely incorrect.  It is trivial for someone to take
>> a pull request and resolve the differences and it is MUCH easier (orders
>> of magnitude) to collab using git/github than it is to mail around
>> patches over and over.  I really believe you don't understand how
>> git/github works.
> First, that's presumptuous.  I have a github account that I use.  DPorts
> and DeltaPorts are both hosted on GitHub, and based on git.  I know how
> what it can do.
>
> Secondly, ports is SVN, not git, and it's not going to be based on git.
>   So it's a moot discussion.

Still missing the point.  Git can sit on top of svn.

> Thirdly, we don't mail patches around.  You just pull the patch from
> GNATS.  Applying patches is not hard.  I personally prefer rejected
> hunks than editing merge conflicts.  Sure I can do both.  I find
> rejected hunks easier to deal with than yours/his/merged/common etc.

Basically "we don't carry floppies from computer to computer!!!  we use 
zip disks!! mlaaah".

OK, got it!

 From what I'm reading you may know how to use git casually, but not in 
any other fashion than "it's like svn, but I have to commit twice".

> Lastly: you are skipping steps.  There's review and testing to be done.
>   You don't just merge and commit.  Using pull requests (even if it were
> possible on SVN) doesn't significantly change anything.

I'm not skipping steps if you read the rest of my mail.

>>>> (also wouldn't it make it easier for ports submitters)?
>>> personally I don't really think so, plus I don't see the current or
>>> future PR system as the barrier for port submitters.
>>>
>>>> (maybe there is some great ports system that I'm not aware of that makes
>>>> this all as easy github, but I somehow doubt that.)
>>> I would like to see something where the submission gets tested in
>>> Redports automatically, and automatically annotates if the port passes
>>> on all platforms or not.  Then the submitter gets notice it needs fixing
>>> immediately and FreeBSD folks don't have to take the PR, test it, reject
>>> it, and state why.  That iteration can take a few cycles and automated
>>> testing could cut that process time tremendously.
>> That would be interesting.  If you could get it to work with github
>> you'd find a lot more people active and willing to participate.
>>
>> Basically, if my workflow was:
>>
>> start:
>>   git pull request -> creates redport submission -> then
>>     either:
>>       1) submission compiles and works -> promotes to "qualified" pull
>> request -> either auto merged or given to maintainer to merge in 1 click.
>>       2) submission fails, then either I fix and resubmit the pull
>> request, or I collab with the submitter to get it to work and then
>> resubmit GOTO start.
> Well, that's not what I said above.  That gets freebsd committers
> involved before the patch is verified to build.  I was trying to get
> freebsd committers not to see patches that don't even build and make
> sure they get fixed before committers spend any time on it.
>
>> That said, you'll have to be up for learning new tools, and that doesn't
>> leave me very optimistic of this ever happening.
> IIUC, you are trying to start a git migration from subversion
> discussion.
No you do not "IIUC".  The point here is to encourage the use of 
existing tooling to solve a problem or enhance a process.

> While I am happy with either one (given that DragonFly
> Ports and sources is hosted on git), I don't see the acceptance by
> others.
Yes, because change can never happen because some people don't like 
change.  Sad.  Forever in 2004.


>   The "use git tools and/or github" discussion is not going to go
> far, no.  It's not a new tools thing either.  The replace of GNATS is a
> big tool change that freebsd people are impatiently waiting for.
Ha!  I've heard that for the past 10 years.  Not holding my breath.

By the way, this wasn't about switching to git (although that would be 
nice), this is about leveraging existing tools.

One can very easily use git-svn bridge to push git changes into 
subversion. Or you can try to re-implement a patch queue based system 
yourself using a bunch of duct tape and bailing wire and likely get 
frustrated and either never complete it OR complete it and it's just not 
even half as good as git as a patch manager.

Use the existing tools.

I implore you to explore the idea of using existing tools to solve the 
problem, or at least solve a part of the problem, instead of trying to 
reinvent functionality that already exists.

-Alfred