Date: Sat, 25 Jan 2014 10:45:24 +0000 From: Big Lebowski <spankthespam@gmail.com> To: Alfred Perlstein <alfred@freebsd.org> Cc: marino@freebsd.org, freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: What is the problem with ports PR reaction delays? Message-ID: <CAHcXP%2BeUM=f%2BuHh%2B_2ThtwZ4zc_rXZ0XPxMj8Okc8q%2BDGcJZKw@mail.gmail.com> In-Reply-To: <52E37C16.5080901@freebsd.org> References: <CAHcXP%2Bf6e-t--XbQPTH1goJp_CL7P=zTj5trZVWd4YZ_EsO9gw@mail.gmail.com> <52E2FA36.5080106@marino.st> <CAHcXP%2BfRDeKXjz0_sifgzeXC2dA-eDnoV5NH1yvF2D6R8JRmAg@mail.gmail.com> <52E303CB.6020304@marino.st> <CAHcXP%2Be9p2HrQ=M9HmPecMbWtXRuYPzH9kwfLGqgdrUrhvLuEA@mail.gmail.com> <52E30990.2060903@marino.st> <52E33AA7.3080205@freebsd.org> <52E36BA1.5030900@marino.st> <52E37C16.5080901@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 25, 2014 at 8:55 AM, Alfred Perlstein <alfred@freebsd.org>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. > > > > >> (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. > > That would be pretty awesome. *A* problem (notice: not "the problem") is > that the cycle is too slow and cumbersome. Hook this into a DVCS that > works well and suddenly you'll see productivity take off as well as people > willing and wanting to submit patches. > This is exactly something I was thinking about: if there could be automated process that takes the PR with a patch, tests the patch and either rejects it or accepts it to a queue, when a human can make decision about making a commit, changing it (goes back to automated queue) or rejecting. Also, where a PR exists, but original sender abandoned his email and there is no one else talking about that PR and asking for it status, acceptance and so on, why not simply reject such PR's? Apparently the author is no loger interested, other people are not interested (lack of comments on the original PR or similar PR submissions) then why this really need to involve a time of human being it no one really cares of it? If this changes, then a new PR would be submitted, checked automatically, and then followed the process. That would free up some human resources to do the work that counts for people, and would reduce false amount of work that needs to be done. > > In fact it will free up time from the people that qualify the code in > order to quality and approve more code. > > That said, you'll have to be up for learning new tools, and that doesn't > leave me very optimistic of this ever happening. That's a problem with *every* change, human nature doesnt like them, but I believe if the process would really improve the experience of being commiter for FreeBSD ports tree, they that alone would make people learn the new tools and processes. B. > > > -Alfred > > > John >> >> >> > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHcXP%2BeUM=f%2BuHh%2B_2ThtwZ4zc_rXZ0XPxMj8Okc8q%2BDGcJZKw>