On Thu, Feb 19, 2015 at 09:57PM, Evans Ye wrote: > Sorry to chime in late. It was Chinese new year started yesterday. BTW, > happy new year to bigtop:)
Happy New Year! > A script would be a lot of help for testing, so probably we can have a > directory to store some dev tools like this, or put it on wiki first. Many years in the field thought me one thing: once you add little scriptlets to ease development workflow - you create a mess that will eat you eventually. If the scripts are detached - they will rot; if they are the part of the source code - they will inevitably inflate as all developers are different and they will want to get some tweak to meet there requirements. If we do anything - it has to be baked into the build system. But I don't we can do a generic enough tooling for every body. > My origin question is about the patch naming convention. > In wiki > <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+Contribute> we > suggest contributors to upload same name for different patch attempts to > better track the version. > A problem for this is that there's a scenario which I'd like to vimdiff two > different patches to know what has been changed. Same naming for patches > would require me to rename patches in different names by myself, which > might cause confusing, and probably result in a wrong version being > committed. > To be picky, named patches the same required tester to know how jira sort > the patches(asc or desc), which I think is a little bit non-intuition. > To sum up, I think it would be better to name them differently with a > simple version number. If the name of the patch remains the same JIRA makes only the latest patch link to be bright blue and the rest of them are sorta grey'ish - which requires no thinking when you need to pick up the latest one. Otherwise, you one has to look at the series and understand whot's the sequence, or change the sort order, or else. Basically, I found same-name approach to be very consistent. If you need to diff two patches you can always do wget oneversion wget anotherversion and if second wget detects that the file with the same name already exists it will add a numerical suffix to the later download. It has been already thought through - just use the power of Unix tools ;) As for the workflow - it's pretty straight, I think: - download - apply - build if needed - deploy (if a deployment script) - run tests (if required) - review/comment The flow can be interrupted after each step if expectations aren't met. Cos > However, there might be a smarter way to do so. So it would be great if you > guys can share your magic how to do the testing:) > 2015/2/18 下午9:47 於 "jay vyas" <[email protected]> 寫道： > > hi bigtop. evans asked me an interesting question about how to maintain > patches and test them and so on without getting mixed up in the bigtop > patch review process. > > testing patches is tricky sometimes in bigtop, esp with so many different > sections of the code base that we work on, and with needing to do things > like create VMs dockerfiles and so on. > > This is all i do at the moment: A shell script which takes patch URL as > argument, creates a new git branch, clears vagrant boxes. If folks have a > workflow in their head, we can use this or something similar to expand upon > for a unified test flow. > > or maybe we can think of a creative way to locally leverage and reuse the > jenkins work folks are doing? > > > #function to clean vagrant boxes, not in this snippet. > delete_vagrant_boxes > echo "Bigtop patch tester : $0, wgets the patch, applies in a new > unique-named branch" > if [ $# -eq 0 ]; then > echo "USAGE: Takes patch url as input, applies it in a new branch" > exit > fi > patch="`echo $1 | rev | cut -d'/' -f 1 | rev`" > echo "PATCH = $patch" > wget $1 -O /tmp/$patch > wc -l /tmp/*patch > > echo "Checkout root branch and clean it?" > read x > git checkout jay_dev > git clean -i > > echo "apply patch in new branch ?" > read x > git checkout jay_dev > git checkout -b "$patch-`date | tr ' ' '_' | tr ':' '_'`" > > echo "apply patch now in this branch `git branch` .... ?" > read x > git am /tmp/$patch > # shows the applied patch. > git log | head > > > > > -- > jay vyas
