Hi Xiangdong,

No worries, that's what I'm here for. But let's not call it reading. For me and 
probably all of your mentors reading Chinese documents will stay almost 
impossible. Same for non Chinese committers and ppmc members. I did some 
pattern matching to guess what the document might say.

When basing your core processes on Chinese, you should pay attention to have an 
identical English translation. Everything else ist just not inclusive. And 
makes giving support difficult.

I think you saw some of the sideeffects with all of these failed RCs in the 
past.

Chris
________________________________
Von: Xiangdong Huang <saint...@gmail.com>
Gesendet: Dienstag, 3. Dezember 2019 03:27:20
An: dev@iotdb.apache.org <dev@iotdb.apache.org>
Betreff: Re: Avoid packing incorrect files into source-release.zip

Hi Chris,

> And you should guide the RM to the target/checkout/target directory
instead of the target directory.

I think this is what makes the error. I used target/*-source-release.zip*
rather than target/checkout/target/ .

Many thanks, and thanks for reading Chinese documents...

Best,
-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


Christofer Dutz <christofer.d...@c-ware.de> 于2019年12月2日周一 下午11:46写道:

> Hi Xiangdong,
>
> I think I know what the general problem is:
> From that page (not much I can actually understand much)
> But it does mention the release:perform step and immediately after that I
> mentions the source and binary distributions.
> Also it mentions validating the source and binaries build by the prepare
> step and does the release perform after that.
>
> You have to execute the perform step and then validate the signatures of
> the artifacts built by that.
>
> So you should move the source and bin distribution validation guilde to
> after the release:perform.
> And you should guide the RM to the target/checkout/target directory
> instead of the target directory.
>
> Chris
>
>
>
> Am 02.12.19, 14:42 schrieb "Xiangdong Huang" <saint...@gmail.com>:
>
>     Hi Chris,
>
>     I am sure that I ran `mvn release:perform` after ran `mvn
>     release:prepare`.  On page [1], step 3.1 and 3.2 are  `mvn
> release:prepare`
>     and `mvn release:perform`
>
>     As I am going to generate RC2 of 0.8.2, I can try once again.
>
>     [1]
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130027555
>
>     Best,
>     -----------------------------------
>     Xiangdong Huang
>     School of Software, Tsinghua University
>
>      黄向东
>     清华大学 软件学院
>
>
>     Christofer Dutz <christofer.d...@c-ware.de> 于2019年12月2日周一 下午4:59写道:
>
>     > Hi Xiangdong,
>     >
>     > the "mvn release:prepare" step does the following:
>     > - Checks if there are uncommitted filed
>     > - Updates the version to the release version
>     > - Checks if there are remaining SNAPSHOT dependencies
>     > - Runs a full build including tests with this version
>     > - If this build succeeds, It commits the changes and tags this commit
>     > - Then it changes the versions to the next development version
>     > - Then it commits this version too
>     > - Then it pushes the changes
>     >
>     > The step you have to do now is run the "mvn release:perform"
>     > - Check out the tagged version from git into the main
> "target/checkout"
>     > directory
>     > - Spawns a "mvn -P apache-release deploy" build in that directory
>     > - This builds the source bundle in "target/checkout/target" and
> creates
>     > the hashes and signs the artifacts
>     > - During the build it also deploys the maven artifacts to the apache
> nexus
>     >
>     > As soon as that's done, you:
>     > - Go to the Apache nexus and close the staging repo
>     > - Create a new staged release by uploading the RELEASE_NOTES, README
> and
>     > the source bundle together with the hashes and signatures to SVN
>     >
>     > To me it looks as if you're simply uploading the stuff created in the
>     > first step, which is not correct as it isn't
>     > executed from a clean checkout and it will contain other stuff
> that's just
>     > laying around in your workspace.
>     >
>     > Chris
>     >
>     >
>     > Am 01.12.19, 15:35 schrieb "Xiangdong Huang" <saint...@gmail.com>:
>     >
>     >     Hi,
>     >
>     >     > it will checkout the git revision the prepare goal tagged as
> release
>     >     version. It will checkout this into the target/checkout
> directory.
>     >     If so, it is quite strange that why there was something
> incorrect in
>     >     previous releases..
>     >
>     >     Now the command is `mvn release:prepare
> -DautoVersionSubmodules=true`,
>     > I am
>     >     not sure whether it download source code from github first, I
> need to
>     > check
>     >     it when I run release next time..
>     >
>     >     > So I guess you re-ran the release build more than once
>     >     Yes it may be. Sometime I ran `mvn release:prepare` .... and if
> I find
>     >     failures, I ran `mvn release:rollback` and run
> `relrease:prepare` again
>     >     after fixing problems and didnot ran `mvn clean`..
>     >
>     >     >The other problem you are having is that the build is generating
>     > things
>     >     outside the target directory.
>     >     A PR is available[1], which is proposed by a new contributor. A
> PPCM
>     > has
>     >     reviewed the codes and approved on github.
>     >     But we need to guarantee that new committers also obey the rule
> in the
>     >     future. So be careful in the code review stage.
>     >
>     >     By the way, I think an assembly file is useful for the following
>     > scenario:
>     >
>     >     > What is more, it is very helpful when we switch different
> branches
>     > for
>     >     releasing. for example, in v0.9.0, there is a module called
> session,
>     > which
>     >     does not exist in 0.8.0. So, if I switch the branch from 0.9 to
> 0.8 (or
>     >     rel/0.8) for a minor version releasing (e.g., 0.8.2), I have to
> remove
>     > the
>     >     session folder manually. If I forgot that, a dirty
> source-release.zip
>     > is
>     >     generated. But if we have an assembly.xml,  it will avoid that.
>     >
>     >     As I am using IDEAJ, there is a plain text file  `session.iml`
> (like
>     >     .classpath and .project in Eclipse) in session's directory. The
> file
>     > does
>     >     not disappear when I switch to 0.8, and even `mvn clean` does not
>     > delete
>     >     the file.
>     >      I am not sure whether `mvn release:prepare
>     > -DautoVersionSubmodules=true`
>     >     will ignore it ( yes if the command download source codes from
>     > github), but
>     >     if I try `mvn package -Papache-release -DskipTests`, the file
> will be
>     >     packed, which is incorrect.
>     >
>     >     [1] https://github.com/apache/incubator-iotdb/pull/578
>     >
>     >     Best,
>     >     -----------------------------------
>     >     Xiangdong Huang
>     >     School of Software, Tsinghua University
>     >
>     >      黄向东
>     >     清华大学 软件学院
>     >
>     >
>     >     Christofer Dutz <christofer.d...@c-ware.de> 于2019年12月1日周日
> 下午8:57写道:
>     >
>     >     > HI all,
>     >     >
>     >     > I think the problem was that you were not doing the releases
> right
>     > or not
>     >     > staging the right artifacts.
>     >     > If you run release:perform ... it will checkout the git
> revision the
>     >     > prepare goal tagged as release version.
>     >     > It will checkout this into the target/checkout directory.
> There it
>     > will
>     >     > run a "mvn deploy" build without the maven-wrapper.
>     >     >
>     >     > As it is doing this there simply can't be any class or jar
> file in
>     > the
>     >     > .mvn directory of the checkout directory.
>     >     > So then the assembly packs up everything in there, it simply
> can't
>     > pack up
>     >     > any class or jar files.
>     >     >
>     >     > The other problem you are having is that the build is
> generating
>     > things
>     >     > outside the target directory.
>     >     > That's a problem you definitely have to fix. As soon as that's
> done,
>     > there
>     >     > shouldn't be any problems as the target directories are
> automatically
>     >     > excluded.
>     >     > But in general the assembly would build the source bundle
> before
>     > actually
>     >     > running any tests and therefore there shouldn't be any binary
>     > resources.
>     >     > So I guess you re-ran the release build more than once ...
>     >     >
>     >     > So instead of fixing the symptoms, I would suggest to fix the
> cause.
>     > The
>     >     > cause is that you're not executing the release steps for Maven
> builds
>     >     > correctly.
>     >     >
>     >     > Chris
>     >     >
>     >     >
>     >     >
>     >     > But I definitely
>     >     >
>     >     > Am 01.12.19, 06:46 schrieb "Xiangdong Huang" <
> saint...@gmail.com>:
>     >     >
>     >     >     Sorry the PR link is [1].
>     >     >
>     >     >     [1] https://github.com/apache/incubator-iotdb/pull/610
>     >     >
>     >     >     Best,
>     >     >     -----------------------------------
>     >     >     Xiangdong Huang
>     >     >     School of Software, Tsinghua University
>     >     >
>     >     >      黄向东
>     >     >     清华大学 软件学院
>     >     >
>     >     >
>     >     >     Xiangdong Huang <saint...@gmail.com> 于2019年12月1日周日
> 下午1:45写道:
>     >     >
>     >     >     > Hi,
>     >     >     >
>     >     >     > Considering we packed some incorrect files in the last
> release
>     > (RC1
>     >     > to
>     >     >     > RC4), I think writing an assembly.xml file for
> generating the
>     >     >     > source-release.zip is a good way to avoid that.
>     >     >     >
>     >     >     > What is more, it is very helpful when we switch different
>     > branches
>     >     > for
>     >     >     > releasing. for example, in v0.9.0, there is a module
> called
>     > session,
>     >     > which
>     >     >     > does not exist in 0.8.0. So, if I switch the branch from
> 0.9
>     > to 0.8
>     >     > (or
>     >     >     > rel/0.8) for a minor version releasing (e.g., 0.8.2), I
> have to
>     >     > remove the
>     >     >     > session folder manually. If I forgot that, a dirty
>     >     > source-release.zip is
>     >     >     > generated. But if we have an assembly.xml,  it will
> avoid that.
>     >     >     >
>     >     >     > I have written the source-assembly.xml now in PR [1]. The
>     > assembly
>     >     > file
>     >     >     > looks ugly because we have to declare the files one by
> one. (I
>     > tried
>     >     > the
>     >     >     > <moduleSet> tag, which is more convenient. But because
> our
>     >     >     > module.artifactId != module.folder name, there is some
> issues
>     > that I
>     >     > can
>     >     >     > not solve. Finally I gave up using <moduleSet> tag).
>     >     >     >
>     >     >     > If the PR is accepted, then for all contributors please
> notice
>     > that:
>     >     >     >
>     >     >     > (1) If you add new source files into a src/ docs/ license
>     > folder, it
>     >     > is ok.
>     >     >     > (2) If you add a new module,  create a new folder, or
> write a
>     > plain
>     >     > text
>     >     >     > file under the project's (or a module's) root directory,
> you
>     > have to
>     >     >     > maintain the source-assembly.xml file.. Otherwise the
> new added
>     >     > files will
>     >     >     > not be packed into source-release.zip.
>     >     >     >
>     >     >     > Hope in this way, we can no longer get  dirty
>     > source-release.zip
>     >     > files.
>     >     >     >
>     >     >     > [1]
>     >     >     > Best,
>     >     >     > -----------------------------------
>     >     >     > Xiangdong Huang
>     >     >     > School of Software, Tsinghua University
>     >     >     >
>     >     >     >  黄向东
>     >     >     > 清华大学 软件学院
>     >     >     >
>     >     >
>     >     >
>     >     >
>     >
>     >
>     >
>
>
>

Reply via email to