On Thu, Jun 08, 2017 at 12:57AM, Evans Ye wrote: > Cos, > Thanks a lot! > > Olaf, > My original thought was to remove those puppet code which no one has > interest to fix it. > But you're right. Some of them are broken at package level... > > I've dig a bit in and found some of them are failing due to Java not > presented before daemons starting up. > I've uploaded a patch in BIGTOP-2775, which should fix the problem. > But we still got many others failing for various reasons. > > Roman, > Good idea. We can track them via JIRAs. > > All, > I still hope that 1.2.1 can be released before DataWorks Summit. > However, at this point I'd like to get everybody's thoughts that whether we > should release it and mark these stuffs as known issues, or we get them > fixed and then release a fully functional release. > Which one you're in favor?
Eitherway is good for me. Making the release before the mid of next week is only possible if we have everything in place right now and only need to do the release itself and vote on it. Otherwise, the timeframe is too tight... Cos > 2017-06-07 6:15 GMT+08:00 Roman Shaposhnik <[email protected]>: > > > On Sun, Jun 4, 2017 at 9:32 PM, Evans Ye <[email protected]> wrote: > > > Hi Bigtopers, > > > > > > I've shared this on my Apache Big Data talk, but haven't got a chance to > > > share with you yet. > > > This is a Jenkins matrix job to show the healthy status of our component > > > deployment code. > > > Each run deploys hdfs + Y on X, where X is the OS and Y is the component > > > shown on the matrix: > > > > > > https://ci.bigtop.apache.org/view/Provisioner/job/Bigtop- > > trunk-deployments/45/ > > > > This is super awesome! Thanks for spending time on putting it together! > > > > > Generally speaking, the status of our deployment code needs a lot of > > effort > > > to polish. > > > So, for 1.2.1 release, I think we should make some changes: > > > > > > 1). Remove unmaintained failing components > > > 2). Get maintained components fixed > > > > > > 1) might be easier to achieve, while 2) takes time. > > > In order to maintain a good code quality, I suggest proceed with 1). > > > > > > Any different thoughts? > > > > Shall we at least start with filing JIRAs for everything that's > > failing -- we can discuss > > the particulars on the JIRAs then. > > > > I can try filing some tomorrow if nobody beats me to it (please do ;-)) > > > > Thanks, > > Roman. > >
