> 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.
Agree. I wasn't thinking thoroughly. Thanks for sharing your valuable experience. > JIRA makes only the latest patch link to be bright blue and the rest of them are sorta grey'ish I'm wondering that why I didn't figure this our over years! This solved my issue totally. Thanks! > and if second wget detects that the file with the same name already exists it > will add a numerical suffix to the later download. The auto suffixing mechanism can be confusing if one wget same patch twice and then wget a new patch. If so, the version of patch will be messed up. However, I admit that this is trivial. I don't think its a real problem. Just want to add some power on my original thought;) 2015-02-25 15:00 GMT+08:00 Konstantin Boudnik <[email protected]>: > On Wed, Feb 25, 2015 at 01:08AM, Jay Vyas wrote: > > Good point on integrate it with CI. > > > > Maybe what we all need is a way to run a subset of the bigtop ci locally > ? It sounds like it's getting close to > > The point where this might be possible? > > I think that quite within the reach: standard CI containers and admittedly > slow progress of making gradle build a focal point of everything should do > it! > > > > > > On Feb 24, 2015, at 11:30 PM, Konstantin Boudnik <[email protected]> > wrote: > > > > > >> 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 >
