why would we need to justify lines of code inside scriptbuilder?  that
collapses the header into one?  Is there a rule that says we need headers
randomly placed inside files templating systems generate?


On Thu, May 16, 2013 at 1:18 PM, Andrew Bayer <[email protected]>wrote:

> We'll have to justify that to the IPMC/mentors etc when we release - be
> prepared for that.
>
> A.
>
> On Thu, May 16, 2013 at 1:15 PM, Adrian Cole <[email protected]
> >wrote:
>
> > Ignasi,
> >
> > I'm with you on this.  Let's have a follow-up pull request to strip
> > comments inside scriptbuilder.
> >
> > -A
> >
> >
> > On Thu, May 16, 2013 at 1:14 PM, Ignasi <[email protected]>
> wrote:
> >
> > > I really don't like adding headers to script "fragments". I understand
> > > the need to have a license header in a script, but when it comes to
> > > compose them to produce one single file that will be copied to the
> > > deployed nodes and then executed, then we'll end up with scripts with
> > > the license headers at random parts.
> > >
> > > Script execution would not be affected, but reading the script and
> > > seeing license texts here and there, IMHO gives a feeling of something
> > > broken, or something that did not get properly generated.
> > >
> > > If we must add the license headers to the script fragments, I'd like
> > > to consider modifying the scriptbuilder to strip comments.
> > >
> > > On 16 May 2013 22:11, Adrian Cole <[email protected]> wrote:
> > > > cool. thanks
> > > >
> > > >
> > > > On Thu, May 16, 2013 at 1:09 PM, Andrew Bayer <
> [email protected]
> > > >wrote:
> > > >
> > > >> I changed a few places in src/test/resources to deal with
> > scriptbuilder
> > > >> functions that now spit out test headers - that's reasonable to me
> > > being as
> > > >> far as we go.
> > > >>
> > > >> A.
> > > >>
> > > >> On Thu, May 16, 2013 at 1:04 PM, Adrian Cole <
> [email protected]
> > > >> >wrote:
> > > >>
> > > >> > Fair enough.  I'll risk breaking folks to avoid perpetual
> > > explanations :)
> > > >> >
> > > >> > So, the creativity clause seems to help justify lack of checking
> > > >> > src/test/resource, which only includes test expectation data.  I'm
> > > going
> > > >> to
> > > >> > make a call and continue to filter this out, as otherwise we'd
> have
> > to
> > > >> > change our unit tests to emit license headers.
> > > >> >
> > > >> > I'll take care of the src/main/resources things (like script
> > > fragments)
> > > >> in
> > > >> > a separate commit as it will break unit tests.
> > > >> >
> > > >> > -A
> > > >> >
> > > >> >
> > > >> > On Thu, May 16, 2013 at 1:00 PM, Andrew Bayer <
> > [email protected]
> > > >> > >wrote:
> > > >> >
> > > >> > > And fwiw, I already added headers to a bunch of .sh files to
> meet
> > > RAT
> > > >> > > checks.
> > > >> > >
> > > >> > > A.
> > > >> > >
> > > >> > > On Thu, May 16, 2013 at 12:46 PM, David Nalley <[email protected]>
> > > wrote:
> > > >> > >
> > > >> > > > On Thu, May 16, 2013 at 3:16 PM, Adrian Cole <
> > > >> [email protected]>
> > > >> > > > wrote:
> > > >> > > > > Hi, all.
> > > >> > > > >
> > > >> > > > > per
> > > >> https://github.com/jclouds/jclouds/pull/6#issuecomment-18022286
> > > >> > > > >
> > > >> > > > > jclouds includes a utility called scriptbuilder, which
> > generates
> > > >> > shell
> > > >> > > > > scripts from other fragments.  We've not added license
> headers
> > > in
> > > >> the
> > > >> > > > past
> > > >> > > > > as these scripts are combined at runtime.
> > > >> > > > >
> > > >> > > > > Ex. you can imagine that doing a command like below, the
> > > resulting
> > > >> > > shell
> > > >> > > > > script would senselessly have multiple ASF license headers
> > > inlined.
> > > >> > > > >
> > > >> > > > > runScript = new StatementList(installJDK, addRoot);
> > > >> > > > >
> > > >> > > > > I seriously have objections about insisting adding license
> > > headers
> > > >> to
> > > >> > > > > script fragments, not only from the efficiency concern, but
> > also
> > > >> that
> > > >> > > it
> > > >> > > > > adds a chance of hard-to-troubleshoot bugs.  For example, if
> > we
> > > >> added
> > > >> > > > > license headers to the script fragment for nohup, everything
> > > that
> > > >> > uses
> > > >> > > > > nohup will have an extra 14 lines of comments, or we'd have
> to
> > > >> write
> > > >> > > code
> > > >> > > > > to remove it.  In cases where scriptBuilder is used as EC2
> > > instance
> > > >> > > data,
> > > >> > > > > it might push us over the limit.
> > > >> > > > >
> > > >> > > > > Bottom-line question is:
> > > >> > > > >
> > > >> > > > > Does the ASF require license header on inputs to commands,
> > such
> > > as
> > > >> > > shell
> > > >> > > > > script fragments that are inputs to ScriptBuilder?
> > > >> > > > >
> > > >> > > > > -A
> > > >> > > >
> > > >> > > > So the default answer is that everything human-readable
> > requires a
> > > >> > > > license header.
> > > >> > > > There is an exception, namely:
> > > >> > > > http://www.apache.org/legal/src-headers.html#faq-exceptions
> > > >> > > >
> > > >> > > > I went and looked at some of the functions and while I might
> > agree
> > > >> > > > that something like abort.sh might qualify for the above
> > > exception,
> > > >> > > > something like setupPublicCurl.sh doesn't IMO.
> > > >> > > >
> > > >> > > > Additionally - you'll have folks (mentors and other IPMC
> > members)
> > > >> > > > reviewing this and their purpose is to catch problems - so you
> > (or
> > > >> the
> > > >> > > > release manager) will have to justify not including licenses
> > > headers
> > > >> > > > for each of those license-header-excluded files.
> > > >> > > >
> > > >> > > > There has been a discussion on legal-discuss about adding a
> > short
> > > >> form
> > > >> > > > license header for short files - that would be two comment
> lines
> > > >> > > > instead of 16, but it is not established policy. Take a look
> at
> > > that
> > > >> > > > thread and at links from that file.
> > > >> > > > http://markmail.org/thread/xvrxxkela4goxmk2
> > > >> > > >
> > > >> > > > --David
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Reply via email to