svn commit: r300961 - vendor/one-true-awk/dist

[Cy Schubert]

In message <1b8c118d-0743-ba8f-5796-65b165bc8efd at FreeBSD.org>, Pedro 
Giffuni wr
ites:
> 
> 
> 
> On 05/29/16 14:06, Cy Schubert wrote:
> > In message <201605291817.u4TIHnN7040344 at slippy.cwsent.com>, Cy Schubert
> > writes:
> >> In message <574B2EAC.3010908 at FreeBSD.org>, Pedro Giffuni writes:
> >>>
> >>>
> >>>
> >>> On 29/05/2016 12:37, Cy Schubert wrote:
> >>>> In message <201605291618.u4TGItNJ024583 at repo.freebsd.org>, "Pedro F.
> >>>> Giffuni" w
> >>>> rites:
> >>>>> Author: pfg
> >>>>> Date: Sun May 29 16:18:55 2016
> >>>>> New Revision: 300961
> >>>>> URL: https://svnweb.freebsd.org/changeset/base/300961
> >>>>>
> >>>>> Log:
> >>>>>    one-true-awk: replace 0 with NULL for pointers
> >>>>>
> >>>>>    Also remove a redundant semicolon.
> >>>>>    Submitted upstream already.
> >>>>>
> >>>>> Modified:
> >>>>>    vendor/one-true-awk/dist/b.c
> >>>>>    vendor/one-true-awk/dist/lex.c
> >>>>>    vendor/one-true-awk/dist/maketab.c
> >>>>>    vendor/one-true-awk/dist/parse.c
> >>>>>    vendor/one-true-awk/dist/run.c
> >>>>>    vendor/one-true-awk/dist/tran.c
> >>>>>
> >>>> Was this commit and r300962 obtained from the upline or vendor or were
> >>>> these commits local to FreeBSD only?
> >>>>
> >>>>
> >>> There is no public awk public repository AFAICT, but bwk acknowledged
> >>> the submission.
> >>>
> >>> The change to openresolv was merged to the public repository.
> >>
> >> As they've acknowledged the submissions, can you please tag the new
> >> versions of awk and openresolve with the correct upstream version numbers,
> >> please?
> >
> > Additionally, if there are no new version numbers, what reason is there for
> > polluting the vendor branch with local patches to it? Is not the vendor
> > branch for virgin code retrieved (or received) from the vendor (or upline)?
> >
> >
> 
> Heck!

Sorry but this particular issue of committing local patches to the vendor 
branch is something I've meant to raise for a long time. This is not meant 
against you. If you felt that then I apologize.

> 
> Can't you simply trust the committer knows what he is doing?

It's not a matter of trust. it's a matter of history. Someone may see a 
certain commit a couple of years from now and wonder from where it came 
from, if it was from the vendor and how it was obtained from the vendor.

In regard to patches submitted upstream, IMHO I don't think they belong in 
the vendor branch. Local patches submitted upstream and either not yet 
accepted or accepted but not incorporated into the vendor's code base IMO 
should only be imported into the vendor branch when the authorized code is 
either committed to or released by the vendor. Admittedly this is a gray 
area and open to interpretation and thus different folks on The Project may 
have different opinions. IMO vendor branch is only for fully accepted and 
committed code by the vendor. If it's a gray area then is it really vendor 
or is it ours? IMO it would be ours.

Why? Two reasons: One. History. Secondly, should we discover some anomaly 
(not that your commits would cause that), being able to look at the virgin 
code in the vendor branch and compare it with what's in HEAD might help to 
understand why the anomaly. (And I talked myself out of a third reason.)

> 
> http://roy.marples.name/projects/openresolv/info/12cb1c1fb10df107
> 
> For nawk there is not public repository but bwk's acknowlegement said:
> 
> "Thanks -- that's something that I should have done long long ago."
> 
> So I think both changes are pretty much vendor code now.

If they don't have a public repository then that's cool. I suppose 
"obtained from:" or "discussed with:" would provide good documentation.

While on this topic. I have correspondence with folks upline for software 
in src/ and some ports/ that provide some interesting history that cannot 
be captured in commit log messages. I'm at the age that I'll retire from 
this one day and go back to growing potatoes on the farm (well, maybe not) 
or more likely not be around any more. It would be nice to archive some of 
this correspondence one day so that those who follow can still have this 
history. I cc my former mentor on all correspondence with our ipfilter 
upline so that someone else on the project will have a copy of the 
correspondence going forward, just so someone on The Project has a copy 
should I become incapacitated or unable. I think history is important. I 
think how we got here is important.The fact that freebsd.org archives this 
email is important because if the group makes a decision because of what is 
in this email (not that this particular email is all that important, but 
you know what I mean), people can go back and see how we got here. I think 
that's important.

Once again, if I appeared hard on you, I'm sorry. That was not my intent.


-- 
Cheers,
Cy Schubert <Cy.Schubert at komquats.com> or <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.