You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by jan i <ja...@apache.org> on 2015/08/05 22:48:16 UTC
Release_0.1
Hi all
I have created branch Release_0.1, this is not intended to be a temporary
branch.
All changes we make to get the release out, goes in here and are (depending
on the change)
also done on master.
Please do not make changes on this branch, unless we have discussed it.
Peter@ you said you would do README.md and CONTRIBUTORS.md in root ?
My next steps are to update LICENSE and NOTICE files.
Then one of the IPMC release checkers have promised to look through it,
before we waste
vote time etc.
After that, we vote (Andrea provided a fab. link).
And finally it is time for the IPMC to vote (a step we bypass once we are
TLP).
Hope we can make a release this month.
rgds
jan i.
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
On 9 August 2015 at 18:50, Peter Kelly <pm...@apache.org> wrote:
> > On 9 Aug 2015, at 11:26 pm, jan i <ja...@apache.org> wrote:
> >
> > On 9 August 2015 at 18:11, Dennis E. Hamilton <de...@acm.org>
> > wrote:
> >
> >> I notice that files ending in "~" can show up in the repository. These
> >> are usually local backups of files that have been edited and should not
> be
> >> in the repository.
> >>
> > That is correct, I spent time removing them in the source zip.
>
> That doesn’t sound like a fun...
>
well to be honest, I was not thinking. After having removed some, I simply
did "git clone" in a new directory, a lot easier
>
> >> I also notice that the .gitignore does not eliminate other artifacts
> that
> >> are not needed in the repository. I have updated the .gitignore (on
> >> master, at least) to ignore more cases of artifacts that may arise in
> >> editing and building but that are not part of the repository or released
> >> code. Some of this may simply be valuable as documentation for what we
> >> keep out of the repository in direct form.
> >>
> > I tend to disagree here. When I edit I also do the cleanup, if we add too
> > much to .gitignore it just becomes more complex to isolate the actual
> > source.
> >
> > I will not veto that it is being done, but just state that I am not happy
> > with it.
>
> I think we should have a few more standard entries in there, including
> files ending in ~, given that these tend to show up a lot. There was
> actually a number of entries in .gitignore that got removed somewhere along
> the way which I only noticed recently. I added the notorious .DS_Store
> files which OS X loves to spray everywhere.
>
No problem with me....but I do have a big problem adding msc files, because
that is a real error, and should never happen. I am also strongly against
adding directories like "externals".
I have f.x.
build.win32
build.win64
build.ubuntu
build.xcode
Should I also add those to .gitignore and bother everyone else.
just my 2ct
rgds
jan i.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
On Friday, August 14, 2015, Dennis E. Hamilton <de...@acm.org>
wrote:
> Responses in-line
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org <javascript:;>]
> Sent: Thursday, August 13, 2015 11:49
> To: dev@corinthia.incubator.apache.org <javascript:;>; Dennis Hamilton <
> dennis.hamilton@acm.org <javascript:;>>
> Subject: Re: Release_0.1
>
> On 13 August 2015 at 20:32, Dennis E. Hamilton <dennis.hamilton@acm.org
> <javascript:;>>
> wrote:
>
> > With regard to the question asked below,
> >
> > My only wish about the voting process is that there be enough time for
> > anyone to vet the release candidate. Also, votes should not be based on
> > sentiment but by actually checking the release candidate in some way
> > (verifying digital signatures and hashes, verifying the code installs in
> a
> > fresh machine, verifying that whatever builds and tests by following the
> > instructions works without incident other than limitations described in
> any
> > README, etc.). This is a [P]PMC responsibility, although it will be nice
> > if others on this list also did so.
> >
> would 7 days be sufficient ?
> <orcmid>
> Yes
> </orcmid>
>
> [ ... ]
> > Possible Clarification
> > ----------------------
> >
> > I think that if binaries are provided, the LICENSE and NOTICE files that
> > install with the binaries must reflect the license conditions on
> everything
> > (and only that) included in the binary distribution. A README or related
> > file and to acknowledge contributions and dependencies is useful for
> > information that is not legally required in NOTICE.
> >
> We do not provide binaries. If you think of a compiled version of corinthia
> it is not part of the release but made available e.g. by PPMC members.
> <orcmid>
> Understood. There is no need to consider the different LICENSE and NOTICE
> files that might apply to binaries.
> </orcmid>
>
> >
> > I don't understand "- If we only link to a third party library and do not
> > include it in the license, we do not need to mention it anywhere (as is
> > this is no legal issue)." Do you mean "If we only link to a third party
> > library and do not include it in the [source] code ..."?
> >
> I did did mean "LICENSE" file, but your wording is better. Justin made me
> aware that if you only link to a library, and do not include it in the
> source zip, it does not belong in LICENSE. We do not supply any third party
> libraries in binary form (we supply a single in source form, and that is
> mentioned in LICENSE)
>
> >
> > Also, if it is a mandatory dependency in order to build the released
> > source into a functional result, license of the third party library still
> > matters with regard to ASF policy (which goes beyond what is legally
> > required).
> >
> Well is Justin tells me it has no legal effect and should not be mentioned
> in LICENSE; then I do believe him (he wets 5-6 releases every month, so he
> surely have more experience).
> <orcmid>
> I was not clear. I was not talking about LICENSE but the fact of a
> license on an external dependency necessary to build usable source.
> </orcmid>
Ok, but I am only concerned about the release and for that we have dine
what is needed.
> >
> > It would be very useful if Justin communicated here directly and we could
> > resolve any nuances of understanding with him.
> >
> MIght be, but we will not take a license discussion in here. We discuss
> whether or not the release will pass and when Justin tells me he is
> prepared to vote +1 for the source zip then I am satisfied.
>
> I have not been discussing at all with Justin, but simply made the changes
> he asked for, and I suggest we as podling do not question that judgement.
> Whether or not link dependencies should be included in the LICENSE in
> general is outside our scope.
> <orcmid>
> I think it would be good to have such discussions/requests recorded on
> our public list, whatever their nature.
> </orcmid>
have a look at the commit log, every suggestion from justin ended in a
commit. Again there have been no discussion, in that case I would have made
it public (as I did with the first response from justin).
You see the same thing happening with the findings from Daniel.
rgds
jan i
>
> rgds
> jan i.
>
>
--
Sent from My iPad, sorry for any misspellings.
RE: Release_0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Responses in-line
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Thursday, August 13, 2015 11:49
To: dev@corinthia.incubator.apache.org; Dennis Hamilton <de...@acm.org>
Subject: Re: Release_0.1
On 13 August 2015 at 20:32, Dennis E. Hamilton <de...@acm.org>
wrote:
> With regard to the question asked below,
>
> My only wish about the voting process is that there be enough time for
> anyone to vet the release candidate. Also, votes should not be based on
> sentiment but by actually checking the release candidate in some way
> (verifying digital signatures and hashes, verifying the code installs in a
> fresh machine, verifying that whatever builds and tests by following the
> instructions works without incident other than limitations described in any
> README, etc.). This is a [P]PMC responsibility, although it will be nice
> if others on this list also did so.
>
would 7 days be sufficient ?
<orcmid>
Yes
</orcmid>
[ ... ]
> Possible Clarification
> ----------------------
>
> I think that if binaries are provided, the LICENSE and NOTICE files that
> install with the binaries must reflect the license conditions on everything
> (and only that) included in the binary distribution. A README or related
> file and to acknowledge contributions and dependencies is useful for
> information that is not legally required in NOTICE.
>
We do not provide binaries. If you think of a compiled version of corinthia
it is not part of the release but made available e.g. by PPMC members.
<orcmid>
Understood. There is no need to consider the different LICENSE and NOTICE files that might apply to binaries.
</orcmid>
>
> I don't understand "- If we only link to a third party library and do not
> include it in the license, we do not need to mention it anywhere (as is
> this is no legal issue)." Do you mean "If we only link to a third party
> library and do not include it in the [source] code ..."?
>
I did did mean "LICENSE" file, but your wording is better. Justin made me
aware that if you only link to a library, and do not include it in the
source zip, it does not belong in LICENSE. We do not supply any third party
libraries in binary form (we supply a single in source form, and that is
mentioned in LICENSE)
>
> Also, if it is a mandatory dependency in order to build the released
> source into a functional result, license of the third party library still
> matters with regard to ASF policy (which goes beyond what is legally
> required).
>
Well is Justin tells me it has no legal effect and should not be mentioned
in LICENSE; then I do believe him (he wets 5-6 releases every month, so he
surely have more experience).
<orcmid>
I was not clear. I was not talking about LICENSE but the fact of a
license on an external dependency necessary to build usable source.
</orcmid>
>
> It would be very useful if Justin communicated here directly and we could
> resolve any nuances of understanding with him.
>
MIght be, but we will not take a license discussion in here. We discuss
whether or not the release will pass and when Justin tells me he is
prepared to vote +1 for the source zip then I am satisfied.
I have not been discussing at all with Justin, but simply made the changes
he asked for, and I suggest we as podling do not question that judgement.
Whether or not link dependencies should be included in the LICENSE in
general is outside our scope.
<orcmid>
I think it would be good to have such discussions/requests recorded on our public list, whatever their nature.
</orcmid>
rgds
jan i.
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
On 13 August 2015 at 20:32, Dennis E. Hamilton <de...@acm.org>
wrote:
> With regard to the question asked below,
>
> My only wish about the voting process is that there be enough time for
> anyone to vet the release candidate. Also, votes should not be based on
> sentiment but by actually checking the release candidate in some way
> (verifying digital signatures and hashes, verifying the code installs in a
> fresh machine, verifying that whatever builds and tests by following the
> instructions works without incident other than limitations described in any
> README, etc.). This is a [P]PMC responsibility, although it will be nice
> if others on this list also did so.
>
would 7 days be sufficient ?
>
> It is likely that members of the Incubator PMC will do the same.
>
This is a separate issue, not connected to our voting period. But
considering that we are 2 IPMC members (Dave and I) that are also PPMC, 1
IPMC member that are mentor (Daniel) and 1 IPMC (Justin) are controlling
the release in advance, I do not think that vote will be a problem.
> Possible Clarification
> ----------------------
>
> I think that if binaries are provided, the LICENSE and NOTICE files that
> install with the binaries must reflect the license conditions on everything
> (and only that) included in the binary distribution. A README or related
> file and to acknowledge contributions and dependencies is useful for
> information that is not legally required in NOTICE.
>
We do not provide binaries. If you think of a compiled version of corinthia
it is not part of the release but made available e.g. by PPMC members.
>
> I don't understand "- If we only link to a third party library and do not
> include it in the license, we do not need to mention it anywhere (as is
> this is no legal issue)." Do you mean "If we only link to a third party
> library and do not include it in the [source] code ..."?
>
I did did mean "LICENSE" file, but your wording is better. Justin made me
aware that if you only link to a library, and do not include it in the
source zip, it does not belong in LICENSE. We do not supply any third party
libraries in binary form (we supply a single in source form, and that is
mentioned in LICENSE)
>
> Also, if it is a mandatory dependency in order to build the released
> source into a functional result, license of the third party library still
> matters with regard to ASF policy (which goes beyond what is legally
> required).
>
Well is Justin tells me it has no legal effect and should not be mentioned
in LICENSE; then I do believe him (he wets 5-6 releases every month, so he
surely have more experience).
Anything that is included in the source, must be described in
LICENSE/NOTICE, anything not included in the source does not belong in
LICENSE/NOTICE. If we were to document "in order to build the released
source in a functional result"; we should also include the tool chain.
>
> It would be very useful if Justin communicated here directly and we could
> resolve any nuances of understanding with him.
>
MIght be, but we will not take a license discussion in here. We discuss
whether or not the release will pass and when Justin tells me he is
prepared to vote +1 for the source zip then I am satisfied.
I have not been discussing at all with Justin, but simply made the changes
he asked for, and I suggest we as podling do not question that judgement.
Whether or not link dependencies should be included in the LICENSE in
general is outside our scope.
rgds
jan i.
RE: Release_0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
With regard to the question asked below,
My only wish about the voting process is that there be enough time for anyone to vet the release candidate. Also, votes should not be based on sentiment but by actually checking the release candidate in some way (verifying digital signatures and hashes, verifying the code installs in a fresh machine, verifying that whatever builds and tests by following the instructions works without incident other than limitations described in any README, etc.). This is a [P]PMC responsibility, although it will be nice if others on this list also did so.
It is likely that members of the Incubator PMC will do the same.
Possible Clarification
----------------------
I think that if binaries are provided, the LICENSE and NOTICE files that install with the binaries must reflect the license conditions on everything (and only that) included in the binary distribution. A README or related file and to acknowledge contributions and dependencies is useful for information that is not legally required in NOTICE.
I don't understand "- If we only link to a third party library and do not include it in the license, we do not need to mention it anywhere (as is this is no legal issue)." Do you mean "If we only link to a third party library and do not include it in the [source] code ..."?
Also, if it is a mandatory dependency in order to build the released source into a functional result, license of the third party library still matters with regard to ASF policy (which goes beyond what is legally required).
It would be very useful if Justin communicated here directly and we could resolve any nuances of understanding with him.
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Thursday, August 13, 2015 04:11
To: dev@corinthia.apache.org <de...@corinthia.incubator.apache.org>
Subject: Fwd: Release_0.1
---------- Forwarded message ----------
From: jan i <ja...@apache.org>
Date: 13 August 2015 at 12:00
Subject: Re: Release_0.1
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org
>
Hi
Sorry for top posting.
Justin have been an enormous help in getting the licenses etc correct,
there was a couple of new things to me.
- If we only link to a third party library and do not include it in the
license, we do not need to mention it anywhere (as is this is no legal
issue)
- I wanted to play fair to our users, and have made a LINK_DEPENDENCY file
- DEVELOPERS got a short description of why these names and not others.
I hope I have just sent the last version to justin for checking and then
get started on the voting process (2 fold, first us, then IPMC).
Are there any special wishes regarding the voting process ?
Please remember a release cannot be vetoed with a -1.
rgds
jan i.
[ ... ]
Re: Fwd: Release_0.1
Posted by Andrea Pescetti <pe...@apache.org>.
On 14/08/2015 jan i wrote:
> - DEVELOPERS got a short description of why these names and not others.
Would (it is a question, not a proposal) naming it "THANKS" be better?
So that the file remains the same, but it is more flexible for future
use. Like it happens for any non-required choice, the best
implementation is the one that can avoid all possible controversy...
I would add the @apache.org e-mail address to developers listed in the
file, since this is helpful for auditing reasons (i.e., it exposes the
fact that all developers are Apache Committers, thus have an ICLA on
file, thus reviewers won't worry and won't be confused).
Regards,
Andrea.
Fwd: Release_0.1
Posted by jan i <ja...@apache.org>.
---------- Forwarded message ----------
From: jan i <ja...@apache.org>
Date: 13 August 2015 at 12:00
Subject: Re: Release_0.1
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org
>
Hi
Sorry for top posting.
Justin have been an enormous help in getting the licenses etc correct,
there was a couple of new things to me.
- If we only link to a third party library and do not include it in the
license, we do not need to mention it anywhere (as is this is no legal
issue)
- I wanted to play fair to our users, and have made a LINK_DEPENDENCY file
- DEVELOPERS got a short description of why these names and not others.
I hope I have just sent the last version to justin for checking and then
get started on the voting process (2 fold, first us, then IPMC).
Are there any special wishes regarding the voting process ?
Please remember a release cannot be vetoed with a -1.
rgds
jan i.
On 10 August 2015 at 05:56, Peter Kelly <pm...@apache.org> wrote:
> > On 10 Aug 2015, at 1:00 am, jan i <ja...@apache.org> wrote:
> >
> > On 9 August 2015 at 19:42, Dennis E. Hamilton <de...@acm.org>
> > wrote:
> >
> >> The exclusion of build-tool artifacts is more a safeguard against
> >> developers doing IDE editing and testing in the tree in inappropriate
> >> places, just like the "~" case but more serious.
> >>
> > a lot more serious....e.g. a .sln file can only be there if you ask cmake
> > to generate it.
> >
> >
> >>
> >> I eliminated those likely suspects because GitHub has found it
> important.
> >> I included it in .gitignore as a precautionary reminder. I did not
> bring
> >> back in all other cases. But I know Visual Studio builds are sort of
> >> encouraged for Windows.
> >>
> >> I am not attached to doing that. It does strike me as harmless though.
> >>
> > I feel strongly about it, because you supress a signal that the system is
> > being build wrongly.
> > Visual studio uses the sln directory (and subdirs) for all its files
> (with
> > our current cmake), so it is a real error if we see them elsewhere,
> > something the developer should see and not be silently ignored.
> >
> > I read peter as also being against having them in .gitignore, so if you
> > are not attached to it, please revert that part (together with
> iconv.txt).
>
> Yes; CMake is supposed to be run outside of the source directory. If you
> run it inside the source directory, and do a “git status”, then these will
> show up as “untracked files”. These serve as an easy-to-see warning.
>
> In by build directory (inside the root of the repository), with files
> generated for Xcode, here’s what I currently have:
>
> CMakeCache.txt
> CMakeFiles/
> CMakeScripts/
> Corinthia.build/
> Corinthia.xcodeproj/
> DerivedData/
> DocFormats/
> cmake_install.cmake
> consumers/
> experiments/
>
> If I run cmake -G Xcode . inside the root of the repository, without yet
> building anything, here’s what I see in git status:
>
> On branch master
> Your branch is up-to-date with 'apache/master'.
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
>
> CMakeCache.txt
> CMakeFiles/
> CMakeScripts/
> Corinthia.xcodeproj/
> DocFormats/api/cmake_install.cmake
> DocFormats/cmake_install.cmake
> DocFormats/core/cmake_install.cmake
> DocFormats/filters/latex/cmake_install.cmake
> DocFormats/filters/odf/cmake_install.cmake
> DocFormats/filters/ooxml/cmake_install.cmake
> DocFormats/platform/cmake_install.cmake
> DocFormats/unittest/cmake_install.cmake
> cmake_install.cmake
> consumers/dfconvert/src/cmake_install.cmake
> consumers/dftest/src/cmake_install.cmake
> consumers/dfutil/src/cmake_install.cmake
> experiments/flat/src/cmake_install.cmake
>
> If I instead run cmake -G “Unix Makefiles”, there are even more - about 40.
>
> So using the source directory as the build directory gets really messy - I
> suspect there’d be even more files show up after a successful build, but
> I’ve just found the Unix Makefiles build is currently not working (at least
> on my machine; I’ll look into this shortly). We want to explicitly
> discourage people from trying this, and make it clear that a separate
> directory should be used instead.
>
> Also, everyone uses different subdirectories for build outputs. I use
> “build” and “winbuild” for OS X and Windows. Jan uses “build.win32”,
> “build.win64”, “build.ubuntu”, and “build.xcode”. Others will presumably
> use different names again.
>
> I also have a bunch of .flat and .exp files that I use for temporary
> testing that I want in the directory but aren’t supposed to be in the
> repository. They shouldn’t be in .gitignore because they’re my personal
> temporary names.
>
> So I think it’s a bad idea to include Vistual Studio/XCode project files
> and the like in .gitignore.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Release_0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 10 Aug 2015, at 1:00 am, jan i <ja...@apache.org> wrote:
>
> On 9 August 2015 at 19:42, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
>> The exclusion of build-tool artifacts is more a safeguard against
>> developers doing IDE editing and testing in the tree in inappropriate
>> places, just like the "~" case but more serious.
>>
> a lot more serious....e.g. a .sln file can only be there if you ask cmake
> to generate it.
>
>
>>
>> I eliminated those likely suspects because GitHub has found it important.
>> I included it in .gitignore as a precautionary reminder. I did not bring
>> back in all other cases. But I know Visual Studio builds are sort of
>> encouraged for Windows.
>>
>> I am not attached to doing that. It does strike me as harmless though.
>>
> I feel strongly about it, because you supress a signal that the system is
> being build wrongly.
> Visual studio uses the sln directory (and subdirs) for all its files (with
> our current cmake), so it is a real error if we see them elsewhere,
> something the developer should see and not be silently ignored.
>
> I read peter as also being against having them in .gitignore, so if you
> are not attached to it, please revert that part (together with iconv.txt).
Yes; CMake is supposed to be run outside of the source directory. If you run it inside the source directory, and do a “git status”, then these will show up as “untracked files”. These serve as an easy-to-see warning.
In by build directory (inside the root of the repository), with files generated for Xcode, here’s what I currently have:
CMakeCache.txt
CMakeFiles/
CMakeScripts/
Corinthia.build/
Corinthia.xcodeproj/
DerivedData/
DocFormats/
cmake_install.cmake
consumers/
experiments/
If I run cmake -G Xcode . inside the root of the repository, without yet building anything, here’s what I see in git status:
On branch master
Your branch is up-to-date with 'apache/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
CMakeCache.txt
CMakeFiles/
CMakeScripts/
Corinthia.xcodeproj/
DocFormats/api/cmake_install.cmake
DocFormats/cmake_install.cmake
DocFormats/core/cmake_install.cmake
DocFormats/filters/latex/cmake_install.cmake
DocFormats/filters/odf/cmake_install.cmake
DocFormats/filters/ooxml/cmake_install.cmake
DocFormats/platform/cmake_install.cmake
DocFormats/unittest/cmake_install.cmake
cmake_install.cmake
consumers/dfconvert/src/cmake_install.cmake
consumers/dftest/src/cmake_install.cmake
consumers/dfutil/src/cmake_install.cmake
experiments/flat/src/cmake_install.cmake
If I instead run cmake -G “Unix Makefiles”, there are even more - about 40.
So using the source directory as the build directory gets really messy - I suspect there’d be even more files show up after a successful build, but I’ve just found the Unix Makefiles build is currently not working (at least on my machine; I’ll look into this shortly). We want to explicitly discourage people from trying this, and make it clear that a separate directory should be used instead.
Also, everyone uses different subdirectories for build outputs. I use “build” and “winbuild” for OS X and Windows. Jan uses “build.win32”, “build.win64”, “build.ubuntu”, and “build.xcode”. Others will presumably use different names again.
I also have a bunch of .flat and .exp files that I use for temporary testing that I want in the directory but aren’t supposed to be in the repository. They shouldn’t be in .gitignore because they’re my personal temporary names.
So I think it’s a bad idea to include Vistual Studio/XCode project files and the like in .gitignore.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Release_0.1
Posted by Gabriela Gibson <ga...@gmail.com>.
You could always have your personal .gitignore and use a script to
reclone your stuff and then copy your personal preference over.
Linux example: https://github.com/apache/incubator-corinthia/blob/master/scripts/build-corinthia-on-linux
just add a line for your favourite .gitignore.
(we could do with a version of that script for windows btw, hint hint :-)
That said, there has been more than one times when a ~ file saved my (bad) day.
As an idea, would it make sense to offer a choice of .gitignore files
since there is a plethora of systems that ppl use?
G
On Sun, Aug 9, 2015 at 7:00 PM, jan i <ja...@apache.org> wrote:
> On 9 August 2015 at 19:42, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
>> The exclusion of build-tool artifacts is more a safeguard against
>> developers doing IDE editing and testing in the tree in inappropriate
>> places, just like the "~" case but more serious.
>>
> a lot more serious....e.g. a .sln file can only be there if you ask cmake
> to generate it.
>
>
>>
>> I eliminated those likely suspects because GitHub has found it important.
>> I included it in .gitignore as a precautionary reminder. I did not bring
>> back in all other cases. But I know Visual Studio builds are sort of
>> encouraged for Windows.
>>
>> I am not attached to doing that. It does strike me as harmless though.
>>
> I feel strongly about it, because you supress a signal that the system is
> being build wrongly.
> Visual studio uses the sln directory (and subdirs) for all its files (with
> our current cmake), so it is a real error if we see them elsewhere,
> something the developer should see and not be silently ignored.
>
> I read peter as also being against having them in .gitignore, so if you
> are not attached to it, please revert that part (together with iconv.txt).
>
> rgds
> jan i.
>
>
>> - Dennis
>>
>> PS: I removed the external/* entry.
>>
>>
>>
>> -----Original Message-----
>> From: Peter Kelly [mailto:pmkelly@apache.org]
>> Sent: Sunday, August 9, 2015 09:59
>> To: dev@corinthia.incubator.apache.org
>> Subject: Re: Release_0.1
>>
>> [ ... ] I’ve just had a look at the latest .gitignore and I think some of
>> the entries do not belong there. Things like .DS_Store and *~ which would
>> reasonably exist in the source tree are fine in my opinion, but for example
>> *.sln, *.vcxproject etc are not, since they are supposed to be inside other
>> directories. On my setup I have a “build” (for OS X) and “winbuild” (for
>> Windows) directories (on my Linux VM I use a separate dir); these just show
>> up as “untracked files” which do not cause problems.
>>
>> Visual studio files, XCode project files, Makefiles etc. are not supposed
>> to go in any source directories other than a custom “build” (or
>> similarly-named) directory if you want (you can also do it outside of the
>> tree).
>>
>> As Jan mentioned, external is dead now as we’re using a pre-built zip file
>> of all the libraries.
>>
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org
>>
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>>
>>
>>
--
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
On 9 August 2015 at 19:42, Dennis E. Hamilton <de...@acm.org>
wrote:
> The exclusion of build-tool artifacts is more a safeguard against
> developers doing IDE editing and testing in the tree in inappropriate
> places, just like the "~" case but more serious.
>
a lot more serious....e.g. a .sln file can only be there if you ask cmake
to generate it.
>
> I eliminated those likely suspects because GitHub has found it important.
> I included it in .gitignore as a precautionary reminder. I did not bring
> back in all other cases. But I know Visual Studio builds are sort of
> encouraged for Windows.
>
> I am not attached to doing that. It does strike me as harmless though.
>
I feel strongly about it, because you supress a signal that the system is
being build wrongly.
Visual studio uses the sln directory (and subdirs) for all its files (with
our current cmake), so it is a real error if we see them elsewhere,
something the developer should see and not be silently ignored.
I read peter as also being against having them in .gitignore, so if you
are not attached to it, please revert that part (together with iconv.txt).
rgds
jan i.
> - Dennis
>
> PS: I removed the external/* entry.
>
>
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Sunday, August 9, 2015 09:59
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Release_0.1
>
> [ ... ] I’ve just had a look at the latest .gitignore and I think some of
> the entries do not belong there. Things like .DS_Store and *~ which would
> reasonably exist in the source tree are fine in my opinion, but for example
> *.sln, *.vcxproject etc are not, since they are supposed to be inside other
> directories. On my setup I have a “build” (for OS X) and “winbuild” (for
> Windows) directories (on my Linux VM I use a separate dir); these just show
> up as “untracked files” which do not cause problems.
>
> Visual studio files, XCode project files, Makefiles etc. are not supposed
> to go in any source directories other than a custom “build” (or
> similarly-named) directory if you want (you can also do it outside of the
> tree).
>
> As Jan mentioned, external is dead now as we’re using a pre-built zip file
> of all the libraries.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
>
RE: Release_0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The exclusion of build-tool artifacts is more a safeguard against developers doing IDE editing and testing in the tree in inappropriate places, just like the "~" case but more serious.
I eliminated those likely suspects because GitHub has found it important. I included it in .gitignore as a precautionary reminder. I did not bring back in all other cases. But I know Visual Studio builds are sort of encouraged for Windows.
I am not attached to doing that. It does strike me as harmless though.
- Dennis
PS: I removed the external/* entry.
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Sunday, August 9, 2015 09:59
To: dev@corinthia.incubator.apache.org
Subject: Re: Release_0.1
[ ... ] I’ve just had a look at the latest .gitignore and I think some of the entries do not belong there. Things like .DS_Store and *~ which would reasonably exist in the source tree are fine in my opinion, but for example *.sln, *.vcxproject etc are not, since they are supposed to be inside other directories. On my setup I have a “build” (for OS X) and “winbuild” (for Windows) directories (on my Linux VM I use a separate dir); these just show up as “untracked files” which do not cause problems.
Visual studio files, XCode project files, Makefiles etc. are not supposed to go in any source directories other than a custom “build” (or similarly-named) directory if you want (you can also do it outside of the tree).
As Jan mentioned, external is dead now as we’re using a pre-built zip file of all the libraries.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Release_0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 9 Aug 2015, at 11:50 pm, Peter Kelly <pm...@apache.org> wrote:
>
>>> I also notice that the .gitignore does not eliminate other artifacts that
>>> are not needed in the repository. I have updated the .gitignore (on
>>> master, at least) to ignore more cases of artifacts that may arise in
>>> editing and building but that are not part of the repository or released
>>> code. Some of this may simply be valuable as documentation for what we
>>> keep out of the repository in direct form.
>>>
>> I tend to disagree here. When I edit I also do the cleanup, if we add too
>> much to .gitignore it just becomes more complex to isolate the actual
>> source.
>>
>> I will not veto that it is being done, but just state that I am not happy
>> with it.
>
> I think we should have a few more standard entries in there, including files ending in ~, given that these tend to show up a lot. There was actually a number of entries in .gitignore that got removed somewhere along the way which I only noticed recently. I added the notorious .DS_Store files which OS X loves to spray everywhere.
Actually I’ve just had a look at the latest .gitignore and I think some of the entries do not belong there. Things like .DS_Store and *~ which would reasonably exist in the source tree are fine in my opinion, but for example *.sln, *.vcxproject etc are not, since they are supposed to be inside other directories. On my setup I have a “build” (for OS X) and “winbuild” (for Windows) directories (on my Linux VM I use a separate dir); these just show up as “untracked files” which do not cause problems.
Visual studio files, XCode project files, Makefiles etc. are not supposed to go in any source directories other than a custom “build” (or similarly-named) directory if you want (you can also do it outside of the tree).
As Jan mentioned, external is dead now as we’re using a pre-built zip file of all the libraries.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Release_0.1
Posted by Peter Kelly <pm...@apache.org>.
> On 9 Aug 2015, at 11:26 pm, jan i <ja...@apache.org> wrote:
>
> On 9 August 2015 at 18:11, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
>> I notice that files ending in "~" can show up in the repository. These
>> are usually local backups of files that have been edited and should not be
>> in the repository.
>>
> That is correct, I spent time removing them in the source zip.
That doesn’t sound like a fun...
>> I also notice that the .gitignore does not eliminate other artifacts that
>> are not needed in the repository. I have updated the .gitignore (on
>> master, at least) to ignore more cases of artifacts that may arise in
>> editing and building but that are not part of the repository or released
>> code. Some of this may simply be valuable as documentation for what we
>> keep out of the repository in direct form.
>>
> I tend to disagree here. When I edit I also do the cleanup, if we add too
> much to .gitignore it just becomes more complex to isolate the actual
> source.
>
> I will not veto that it is being done, but just state that I am not happy
> with it.
I think we should have a few more standard entries in there, including files ending in ~, given that these tend to show up a lot. There was actually a number of entries in .gitignore that got removed somewhere along the way which I only noticed recently. I added the notorious .DS_Store files which OS X loves to spray everywhere.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
On 9 August 2015 at 19:19, Dennis E. Hamilton <de...@acm.org>
wrote:
> I have no objection to external/ being removed altogether.
>
> I did not know for certain that it is no longer being used.
>
> I think it showed up as uncommitted content on my system because I had
> material there from an older build. That was useful in hunting down
> iconv.h, though[;<).
>
> I have removed the external/ directory in my clone. That should resolve
> that one case.
>
> I'll remove the clause in .gitignore.
>
thanks for correcting this.
Would you please also remove the microsoft files (.sln) etc, as peter
explained, those should not be ignored, it is a real error if they appear
outside build*
And the iconv.txt file, which basically referred to external (and I have
corrected the only other reference).
rgds
jan i.
>
> - Dennis
>
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Sunday, August 9, 2015 09:27
> To: dev@corinthia.incubator.apache.org; Dennis Hamilton <
> dennis.hamilton@acm.org>
> Subject: Re: Release_0.1
>
> On 9 August 2015 at 18:11, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
> > I notice that files ending in "~" can show up in the repository. These
> > are usually local backups of files that have been edited and should not
> be
> > in the repository.
> >
> That is correct, I spent time removing them in the source zip.
>
> >
> > I also notice that the .gitignore does not eliminate other artifacts that
> > are not needed in the repository. I have updated the .gitignore (on
> > master, at least) to ignore more cases of artifacts that may arise in
> > editing and building but that are not part of the repository or released
> > code. Some of this may simply be valuable as documentation for what we
> > keep out of the repository in direct form.
> >
> I tend to disagree here. When I edit I also do the cleanup, if we add too
> much to .gitignore it just becomes more complex to isolate the actual
> source.
>
> I will not veto that it is being done, but just state that I am not happy
> with it.
>
> >
> > I have also added external/download/* to the .gitignore. Is the folder
> > used any longer?
> > (I can no longer find the scripts that were used to download and extract
> > the externals for Windows builds. Have they been removed and I simply
> > missed it?)
> >
> That went away a while ago, when we made the 32/64bit CMAKEfiles. It was
> announced on dev@ and of course as commits.
>
> This is a good example why I do not want to expand .gitignore, the right
> thing would be to remove the directory on your local computer.
>
>
> >
> > Please review for others that might be needed, especially for non-Windows
> > platform cases.
> >
> hereby done.
>
> >
> > PS: I notice that under Editor/src/3rdparty/showdown there is a
> > license.txt file that has requirements for NOTICE. (The license is
> > BSD-like.)
> >
> Yes and ??? I hope you have noticed that it is not part of the release.
>
> You should look at branch Release_0.1 for all release relevant material.
>
> rgds
> jan I.
>
>
> >
> >
> > - Dennis
> >
> >
> >
> > -----Original Message-----
> > From: jan i [mailto:jani@apache.org]
> > Sent: Sunday, August 9, 2015 02:23
> > To: jan i <ja...@apache.org>
> > Cc: dev@corinthia.incubator.apache.org
> > Subject: Re: Release_0.1
> >
> > Release branch should now be ready for testing (after the zip error is
> done
> > with).
> >
> > I will continue with LICENSE and NOTICE later today
> >
> > Before somebody tells me, yes I did overwrite README.md on trunk, but it
> is
> > because I try to make sure all Release changes go back to trunk,
> > and with that it is easier to expand README.md for our next release, than
> > to make the changes already made.
> >
> > rgds
> > jan I.
> >
> >
> > On 5 August 2015 at 22:48, jan i <ja...@apache.org> wrote:
> >
> > > Hi all
> > >
> > > I have created branch Release_0.1, this is not intended to be a
> temporary
> > > branch.
> > >
> > > All changes we make to get the release out, goes in here and are
> > > (depending on the change)
> > > also done on master.
> > >
> > > Please do not make changes on this branch, unless we have discussed it.
> > >
> > > Peter@ you said you would do README.md and CONTRIBUTORS.md in root ?
> > >
> > > My next steps are to update LICENSE and NOTICE files.
> > >
> > > Then one of the IPMC release checkers have promised to look through it,
> > > before we waste
> > > vote time etc.
> > >
> > > After that, we vote (Andrea provided a fab. link).
> > >
> > > And finally it is time for the IPMC to vote (a step we bypass once we
> are
> > > TLP).
> > >
> > > Hope we can make a release this month.
> > > rgds
> > > jan i.
> > >
> > >
> >
> >
>
>
RE: Release_0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I have no objection to external/ being removed altogether.
I did not know for certain that it is no longer being used.
I think it showed up as uncommitted content on my system because I had material there from an older build. That was useful in hunting down iconv.h, though[;<).
I have removed the external/ directory in my clone. That should resolve that one case.
I'll remove the clause in .gitignore.
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Sunday, August 9, 2015 09:27
To: dev@corinthia.incubator.apache.org; Dennis Hamilton <de...@acm.org>
Subject: Re: Release_0.1
On 9 August 2015 at 18:11, Dennis E. Hamilton <de...@acm.org>
wrote:
> I notice that files ending in "~" can show up in the repository. These
> are usually local backups of files that have been edited and should not be
> in the repository.
>
That is correct, I spent time removing them in the source zip.
>
> I also notice that the .gitignore does not eliminate other artifacts that
> are not needed in the repository. I have updated the .gitignore (on
> master, at least) to ignore more cases of artifacts that may arise in
> editing and building but that are not part of the repository or released
> code. Some of this may simply be valuable as documentation for what we
> keep out of the repository in direct form.
>
I tend to disagree here. When I edit I also do the cleanup, if we add too
much to .gitignore it just becomes more complex to isolate the actual
source.
I will not veto that it is being done, but just state that I am not happy
with it.
>
> I have also added external/download/* to the .gitignore. Is the folder
> used any longer?
> (I can no longer find the scripts that were used to download and extract
> the externals for Windows builds. Have they been removed and I simply
> missed it?)
>
That went away a while ago, when we made the 32/64bit CMAKEfiles. It was
announced on dev@ and of course as commits.
This is a good example why I do not want to expand .gitignore, the right
thing would be to remove the directory on your local computer.
>
> Please review for others that might be needed, especially for non-Windows
> platform cases.
>
hereby done.
>
> PS: I notice that under Editor/src/3rdparty/showdown there is a
> license.txt file that has requirements for NOTICE. (The license is
> BSD-like.)
>
Yes and ??? I hope you have noticed that it is not part of the release.
You should look at branch Release_0.1 for all release relevant material.
rgds
jan I.
>
>
> - Dennis
>
>
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Sunday, August 9, 2015 02:23
> To: jan i <ja...@apache.org>
> Cc: dev@corinthia.incubator.apache.org
> Subject: Re: Release_0.1
>
> Release branch should now be ready for testing (after the zip error is done
> with).
>
> I will continue with LICENSE and NOTICE later today
>
> Before somebody tells me, yes I did overwrite README.md on trunk, but it is
> because I try to make sure all Release changes go back to trunk,
> and with that it is easier to expand README.md for our next release, than
> to make the changes already made.
>
> rgds
> jan I.
>
>
> On 5 August 2015 at 22:48, jan i <ja...@apache.org> wrote:
>
> > Hi all
> >
> > I have created branch Release_0.1, this is not intended to be a temporary
> > branch.
> >
> > All changes we make to get the release out, goes in here and are
> > (depending on the change)
> > also done on master.
> >
> > Please do not make changes on this branch, unless we have discussed it.
> >
> > Peter@ you said you would do README.md and CONTRIBUTORS.md in root ?
> >
> > My next steps are to update LICENSE and NOTICE files.
> >
> > Then one of the IPMC release checkers have promised to look through it,
> > before we waste
> > vote time etc.
> >
> > After that, we vote (Andrea provided a fab. link).
> >
> > And finally it is time for the IPMC to vote (a step we bypass once we are
> > TLP).
> >
> > Hope we can make a release this month.
> > rgds
> > jan i.
> >
> >
>
>
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
On 9 August 2015 at 18:11, Dennis E. Hamilton <de...@acm.org>
wrote:
> I notice that files ending in "~" can show up in the repository. These
> are usually local backups of files that have been edited and should not be
> in the repository.
>
That is correct, I spent time removing them in the source zip.
>
> I also notice that the .gitignore does not eliminate other artifacts that
> are not needed in the repository. I have updated the .gitignore (on
> master, at least) to ignore more cases of artifacts that may arise in
> editing and building but that are not part of the repository or released
> code. Some of this may simply be valuable as documentation for what we
> keep out of the repository in direct form.
>
I tend to disagree here. When I edit I also do the cleanup, if we add too
much to .gitignore it just becomes more complex to isolate the actual
source.
I will not veto that it is being done, but just state that I am not happy
with it.
>
> I have also added external/download/* to the .gitignore. Is the folder
> used any longer?
> (I can no longer find the scripts that were used to download and extract
> the externals for Windows builds. Have they been removed and I simply
> missed it?)
>
That went away a while ago, when we made the 32/64bit CMAKEfiles. It was
announced on dev@ and of course as commits.
This is a good example why I do not want to expand .gitignore, the right
thing would be to remove the directory on your local computer.
>
> Please review for others that might be needed, especially for non-Windows
> platform cases.
>
hereby done.
>
> PS: I notice that under Editor/src/3rdparty/showdown there is a
> license.txt file that has requirements for NOTICE. (The license is
> BSD-like.)
>
Yes and ??? I hope you have noticed that it is not part of the release.
You should look at branch Release_0.1 for all release relevant material.
rgds
jan I.
>
>
> - Dennis
>
>
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Sunday, August 9, 2015 02:23
> To: jan i <ja...@apache.org>
> Cc: dev@corinthia.incubator.apache.org
> Subject: Re: Release_0.1
>
> Release branch should now be ready for testing (after the zip error is done
> with).
>
> I will continue with LICENSE and NOTICE later today
>
> Before somebody tells me, yes I did overwrite README.md on trunk, but it is
> because I try to make sure all Release changes go back to trunk,
> and with that it is easier to expand README.md for our next release, than
> to make the changes already made.
>
> rgds
> jan I.
>
>
> On 5 August 2015 at 22:48, jan i <ja...@apache.org> wrote:
>
> > Hi all
> >
> > I have created branch Release_0.1, this is not intended to be a temporary
> > branch.
> >
> > All changes we make to get the release out, goes in here and are
> > (depending on the change)
> > also done on master.
> >
> > Please do not make changes on this branch, unless we have discussed it.
> >
> > Peter@ you said you would do README.md and CONTRIBUTORS.md in root ?
> >
> > My next steps are to update LICENSE and NOTICE files.
> >
> > Then one of the IPMC release checkers have promised to look through it,
> > before we waste
> > vote time etc.
> >
> > After that, we vote (Andrea provided a fab. link).
> >
> > And finally it is time for the IPMC to vote (a step we bypass once we are
> > TLP).
> >
> > Hope we can make a release this month.
> > rgds
> > jan i.
> >
> >
>
>
RE: Release_0.1
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I notice that files ending in "~" can show up in the repository. These are usually local backups of files that have been edited and should not be in the repository.
I also notice that the .gitignore does not eliminate other artifacts that are not needed in the repository. I have updated the .gitignore (on master, at least) to ignore more cases of artifacts that may arise in editing and building but that are not part of the repository or released code. Some of this may simply be valuable as documentation for what we keep out of the repository in direct form.
I have also added external/download/* to the .gitignore. Is the folder used any longer?
(I can no longer find the scripts that were used to download and extract the externals for Windows builds. Have they been removed and I simply missed it?)
Please review for others that might be needed, especially for non-Windows platform cases.
PS: I notice that under Editor/src/3rdparty/showdown there is a license.txt file that has requirements for NOTICE. (The license is BSD-like.)
- Dennis
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Sunday, August 9, 2015 02:23
To: jan i <ja...@apache.org>
Cc: dev@corinthia.incubator.apache.org
Subject: Re: Release_0.1
Release branch should now be ready for testing (after the zip error is done
with).
I will continue with LICENSE and NOTICE later today
Before somebody tells me, yes I did overwrite README.md on trunk, but it is
because I try to make sure all Release changes go back to trunk,
and with that it is easier to expand README.md for our next release, than
to make the changes already made.
rgds
jan I.
On 5 August 2015 at 22:48, jan i <ja...@apache.org> wrote:
> Hi all
>
> I have created branch Release_0.1, this is not intended to be a temporary
> branch.
>
> All changes we make to get the release out, goes in here and are
> (depending on the change)
> also done on master.
>
> Please do not make changes on this branch, unless we have discussed it.
>
> Peter@ you said you would do README.md and CONTRIBUTORS.md in root ?
>
> My next steps are to update LICENSE and NOTICE files.
>
> Then one of the IPMC release checkers have promised to look through it,
> before we waste
> vote time etc.
>
> After that, we vote (Andrea provided a fab. link).
>
> And finally it is time for the IPMC to vote (a step we bypass once we are
> TLP).
>
> Hope we can make a release this month.
> rgds
> jan i.
>
>
Re: Release_0.1
Posted by jan i <ja...@apache.org>.
Release branch should now be ready for testing (after the zip error is done
with).
I will continue with LICENSE and NOTICE later today
Before somebody tells me, yes I did overwrite README.md on trunk, but it is
because I try to make sure all Release changes go back to trunk,
and with that it is easier to expand README.md for our next release, than
to make the changes already made.
rgds
jan I.
On 5 August 2015 at 22:48, jan i <ja...@apache.org> wrote:
> Hi all
>
> I have created branch Release_0.1, this is not intended to be a temporary
> branch.
>
> All changes we make to get the release out, goes in here and are
> (depending on the change)
> also done on master.
>
> Please do not make changes on this branch, unless we have discussed it.
>
> Peter@ you said you would do README.md and CONTRIBUTORS.md in root ?
>
> My next steps are to update LICENSE and NOTICE files.
>
> Then one of the IPMC release checkers have promised to look through it,
> before we waste
> vote time etc.
>
> After that, we vote (Andrea provided a fab. link).
>
> And finally it is time for the IPMC to vote (a step we bypass once we are
> TLP).
>
> Hope we can make a release this month.
> rgds
> jan i.
>
>