tag for last NCSA-based commit?

[Mike Beckerle <mb...@tresys.com>]

I believe this:

945a1c1ab363485003ebf14fef3463055d4fab37

Is the last commit using the old file structure, old packages, etc.


I suspect it would be prudent to make a tag for this. This would be in case some developer has lots of outstanding changes based on earlier commits. They could first rebase to here, get everything working again, and then do the rebase that changes all the names and such.


Naming convention? I suspect a somewhat verbose tag name would be better than just a numbering convention, as the key concept here is that this is still edu.illinois.ncsa daffodil packages. So something with the words "final" and "edu.illinois.ncsa" as well as capturing that it is pre-2.1.0 release.

Re: tag for last NCSA-based commit?

[Mike Beckerle <mb...@tresys.com>]

I have about 5 development branches that I've rebased yesterday onto the last edu.illnois.ncsa commit. I will try to rebase them onto the current master and let you know the outcome. If this goes smoothly, then yeah I would agree with you.

________________________________
From: Steve Lawrence <sl...@apache.org>
Sent: Thursday, February 8, 2018 9:45:31 AM
To: dev@daffodil.apache.org; Mike Beckerle
Subject: Re: tag for last NCSA-based commit?

I'm not sure a tag would add a whole lot of value, and would add a
little bit of clutter. I don't think splitting a rebase into two will
help very much (and if it is, the commit of interest just a few commits
before the soon to be created 2.1.0-rc1 tag). The hard part is knowing
how to deal with conflicts. Two rebases wont' minimize those all that much.

I've rebased this Apache patchset onto master many times and have gotten
really good with dealing with the conflicts. If anyone has any branches
that are pre-Apache switch, I'd be happy to help rebase those changes
onto master and deal with conflicts.

- Steve

On 02/08/2018 09:18 AM, Mike Beckerle wrote:
> I believe this:
>
> 945a1c1ab363485003ebf14fef3463055d4fab37
>
> Is the last commit using the old file structure, old packages, etc.
>
>
> I suspect it would be prudent to make a tag for this. This would be in case some developer has lots of outstanding changes based on earlier commits. They could first rebase to here, get everything working again, and then do the rebase that changes all the names and such.
>
>
> Naming convention? I suspect a somewhat verbose tag name would be better than just a numbering convention, as the key concept here is that this is still edu.illinois.ncsa daffodil packages. So something with the words "final" and "edu.illinois.ncsa" as well as capturing that it is pre-2.1.0 release.
>
>

Re: tag for last NCSA-based commit?

[Steve Lawrence <sl...@apache.org>]

I'm not sure a tag would add a whole lot of value, and would add a
little bit of clutter. I don't think splitting a rebase into two will
help very much (and if it is, the commit of interest just a few commits
before the soon to be created 2.1.0-rc1 tag). The hard part is knowing
how to deal with conflicts. Two rebases wont' minimize those all that much.

I've rebased this Apache patchset onto master many times and have gotten
really good with dealing with the conflicts. If anyone has any branches
that are pre-Apache switch, I'd be happy to help rebase those changes
onto master and deal with conflicts.

- Steve

On 02/08/2018 09:18 AM, Mike Beckerle wrote:
> I believe this:
> 
> 945a1c1ab363485003ebf14fef3463055d4fab37
> 
> Is the last commit using the old file structure, old packages, etc.
> 
> 
> I suspect it would be prudent to make a tag for this. This would be in case some developer has lots of outstanding changes based on earlier commits. They could first rebase to here, get everything working again, and then do the rebase that changes all the names and such.
> 
> 
> Naming convention? I suspect a somewhat verbose tag name would be better than just a numbering convention, as the key concept here is that this is still edu.illinois.ncsa daffodil packages. So something with the words "final" and "edu.illinois.ncsa" as well as capturing that it is pre-2.1.0 release.
> 
>