Date: Sat, 25 Jan 2014 18:59:47 +0100 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: John Marino <dragonflybsd@marino.st>, marino@freebsd.org, freebsd-ports@freebsd.org Subject: Re: What is the problem with ports PR reaction delays? Message-ID: <20140125175947.GC67191@ithaqua.etoilebsd.net> In-Reply-To: <52E3F03C.1060503@freebsd.org> References: <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> <52E3806D.4020902@marino.st> <52E3F03C.1060503@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 25, 2014 at 09:11:24AM -0800, Alfred Perlstein wrote: >=20 > 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 ba= sis, > >>>>> 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 click= s? > >>> 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 chang= e, > >>> 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 ta= ke > >> a pull request and resolve the differences and it is MUCH easier (orde= rs > >> 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. >=20 > Still missing the point. Git can sit on top of svn. Oh you have a nice way to allow git-svn to properly handle properties? >=20 > > 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. >=20 > Basically "we don't carry floppies from computer to computer!!! we use= =20 > zip disks!! mlaaah". >=20 > OK, got it! >=20 > From what I'm reading you may know how to use git casually, but not in= =20 > any other fashion than "it's like svn, but I have to commit twice". >=20 > > 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. >=20 > I'm not skipping steps if you read the rest of my mail. >=20 > >>>> (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 m= akes > >>>> 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 fix= ing > >>> immediately and FreeBSD folks don't have to take the PR, test it, rej= ect > >>> 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 cli= ck. > >> 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=20 > existing tooling to solve a problem or enhance a process. Once again we already have tools to get the patches out of gnats and applyi= ng them automatically, those tools will be even easier with bugzilla. >=20 > > 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=20 > change. Sad. Forever in 2004. >=20 >=20 > > 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. >=20 > By the way, this wasn't about switching to git (although that would be=20 > nice), this is about leveraging existing tools. >=20 > One can very easily use git-svn bridge to push git changes into=20 > subversion. Or you can try to re-implement a patch queue based system=20 > yourself using a bunch of duct tape and bailing wire and likely get=20 > frustrated and either never complete it OR complete it and it's just not= =20 > even half as good as git as a patch manager. git-svn is broken and cannot work 100% of the time as-is with the ports tree >=20 > Use the existing tools. >=20 > I implore you to explore the idea of using existing tools to solve the=20 > problem, or at least solve a part of the problem, instead of trying to=20 > reinvent functionality that already exists. Those tools does exists! Sure they can be improved, but the problem is not = the tools, but rather humans. People willing to go through the different PR, wi= lling to spend time building everything needed (deps) and the port itself, doing = all the Q/A checks (all of them cannot be automated even if most can and are already). and do the runtime tests! which often cannot be automated. regards, Bapt --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlLj+5MACgkQ8kTtMUmk6ExzeACfUPNzF4vMVMfe/w60vq7rpWzW Jp0An3iIs/dvG6JPBTrFOxDwEYyZHv10 =nAZh -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140125175947.GC67191>