You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by john wass <jw...@gmail.com> on 2020/10/07 13:16:52 UTC

Re: Subproject renaming - check for consensus

What was the reasoning on the daf- prefix again?

I looked back through but didnt see what the value add of the prefix was.


On Wed, Oct 7, 2020 at 9:09 AM Interrante, John A (GE Research, US) <
interran@research.ge.com> wrote:

> I've created an issue (https://issues.apache.org/jira/browse/DAFFODIL-2406)
> to rename Daffodil subprojects for better clarity.  I'd like to ask devs if
> the issue has everyone's consensus and ask for a volunteer to perform the
> renaming since I'm going to be refactoring classes and changing code in my
> own pull request (daffodil-2202-runtime2) for at least the next few days.
>
> Does this proposal look acceptable to everyone?
> Phase 1
>
>   *   containers
>   *   daf-backend-c-generator (ignore - not in main yet, but will be later)
>   *   daf-backend-scala-parser
>   *   daf-backend-scala -unparser
>   *   daf-cli
>   *   daf-io
>   *   daf-lib
>   *   daf-macro-lib
>   *   daf-propgen
>   *   daf-sapi
>   *   daf-schema-compiler (was daffodil-core)
>   *   daf-tdml-lib
>   *   daf-tdml-processor
>   *   project
>   *   test-suite-daf
>   *   test-suite-ibm
>   *   test-suite-std
>   *   tutorials
> Phase 2
> Merge daf-backend-scala-parser and daf-backend-scala-unparser together
> into daf-backend-scala.
>

Re: Subproject renaming - check for consensus

Posted by john wass <jw...@gmail.com>.
OK.  Agreed on shortening it.  The prefix all together seemed unnecessary
to me.  My only comment on that would be perhaps to invert prefixing that
it is only be present on the special cases.

Just thoughts, no strong opinions here either.  Also relatively new to the
code, so could be missing some other considerations.

On Wed, Oct 7, 2020 at 9:22 AM Steve Lawrence <sl...@apache.org> wrote:

> I think the concern was the "daffodil-" prefix is a bit long and a bit
> unnecessary, but it is potentially nice since it helps distinguish code
> related subprojects from non-code (e.g. tests, infrastructure). So
> "daf-" is a decent middle ground.
>
> I think the "daf-" was suggested for me, and I don't feel strong about
> it, so I'm not against dropping the daf- prefix entirely if others don't
> like it.
>
> On 10/7/20 9:16 AM, john wass wrote:
> > What was the reasoning on the daf- prefix again?
> >
> > I looked back through but didnt see what the value add of the prefix was.
> >
> >
> > On Wed, Oct 7, 2020 at 9:09 AM Interrante, John A (GE Research, US) <
> > interran@research.ge.com> wrote:
> >
> >> I've created an issue (
> https://issues.apache.org/jira/browse/DAFFODIL-2406)
> >> to rename Daffodil subprojects for better clarity.  I'd like to ask
> devs if
> >> the issue has everyone's consensus and ask for a volunteer to perform
> the
> >> renaming since I'm going to be refactoring classes and changing code in
> my
> >> own pull request (daffodil-2202-runtime2) for at least the next few
> days.
> >>
> >> Does this proposal look acceptable to everyone?
> >> Phase 1
> >>
> >>   *   containers
> >>   *   daf-backend-c-generator (ignore - not in main yet, but will be
> later)
> >>   *   daf-backend-scala-parser
> >>   *   daf-backend-scala -unparser
> >>   *   daf-cli
> >>   *   daf-io
> >>   *   daf-lib
> >>   *   daf-macro-lib
> >>   *   daf-propgen
> >>   *   daf-sapi
> >>   *   daf-schema-compiler (was daffodil-core)
> >>   *   daf-tdml-lib
> >>   *   daf-tdml-processor
> >>   *   project
> >>   *   test-suite-daf
> >>   *   test-suite-ibm
> >>   *   test-suite-std
> >>   *   tutorials
> >> Phase 2
> >> Merge daf-backend-scala-parser and daf-backend-scala-unparser together
> >> into daf-backend-scala.
> >>
> >
>
>

Re: Subproject renaming - check for consensus

Posted by Steve Lawrence <sl...@apache.org>.
I think the concern was the "daffodil-" prefix is a bit long and a bit
unnecessary, but it is potentially nice since it helps distinguish code
related subprojects from non-code (e.g. tests, infrastructure). So
"daf-" is a decent middle ground.

I think the "daf-" was suggested for me, and I don't feel strong about
it, so I'm not against dropping the daf- prefix entirely if others don't
like it.

On 10/7/20 9:16 AM, john wass wrote:
> What was the reasoning on the daf- prefix again?
> 
> I looked back through but didnt see what the value add of the prefix was.
> 
> 
> On Wed, Oct 7, 2020 at 9:09 AM Interrante, John A (GE Research, US) <
> interran@research.ge.com> wrote:
> 
>> I've created an issue (https://issues.apache.org/jira/browse/DAFFODIL-2406)
>> to rename Daffodil subprojects for better clarity.  I'd like to ask devs if
>> the issue has everyone's consensus and ask for a volunteer to perform the
>> renaming since I'm going to be refactoring classes and changing code in my
>> own pull request (daffodil-2202-runtime2) for at least the next few days.
>>
>> Does this proposal look acceptable to everyone?
>> Phase 1
>>
>>   *   containers
>>   *   daf-backend-c-generator (ignore - not in main yet, but will be later)
>>   *   daf-backend-scala-parser
>>   *   daf-backend-scala -unparser
>>   *   daf-cli
>>   *   daf-io
>>   *   daf-lib
>>   *   daf-macro-lib
>>   *   daf-propgen
>>   *   daf-sapi
>>   *   daf-schema-compiler (was daffodil-core)
>>   *   daf-tdml-lib
>>   *   daf-tdml-processor
>>   *   project
>>   *   test-suite-daf
>>   *   test-suite-ibm
>>   *   test-suite-std
>>   *   tutorials
>> Phase 2
>> Merge daf-backend-scala-parser and daf-backend-scala-unparser together
>> into daf-backend-scala.
>>
>