The clean-up work can actually be split by modules. Though it is generally a good practice to follow, my concern is the clean-up is likely to cause conflicts with some on-going changes. If I may suggest, the dedicated clean-up tasks should avoid - modules that are undergoing multiple feature changes/PRs - modules that are planned to have major refactoring due to design changes (since clean-up can be done altogether during refactoring)
On Tue, Jan 21, 2020 at 4:17 AM Vinoth Chandar <[email protected]> wrote: > Not sure if I fully agree with sweeping statements being made. But, +1 for > structuring this work via Jiras and having some committer “accept” the > issue first. Some of these tend to be subjective and we do need to make > different tradeoffs. > > On Tue, Jan 21, 2020 at 1:28 AM vino yang <[email protected]> wrote: > > > Hi Pratyaksh, > > > > Thanks for your thought. > > > > Let's listen to others' comments. If there is no objection, we will > follow > > this way. > > > > Best, > > Vino > > > > > > Pratyaksh Sharma <[email protected]> 于2020年1月21日周二 下午4:56写道： > > > > > Hi Vino, > > > > > > Big +1 for this initiative. I have done this code cleanup for test > > classes > > > in the past and strongly feel there is a need to do the same at other > > > places as well. I would definitely like to volunteer for this. > > > > > > On Tue, Jan 21, 2020 at 1:52 PM vino yang <[email protected]> > wrote: > > > > > > > Hi folks, > > > > > > > > Currently, the code quality of some Hudi module is not very well. As > > many > > > > developers have seen, the Intellij IDEA has shown many intellisense > > about > > > > cleanup and improvement. The community does not object to doing the > > > cleanup > > > > and improvement work and the work has been started via some direct > > > "minor" > > > > PRs by some volunteers. The current way is unorganized and hard to > > > manage. > > > > For tracking this work, I prefer to manage this work with the Jira > > issue. > > > > We can create an umbrella issue. Then, split the work into several > > > > subtasks. > > > > > > > > Since those "bad smell" lays anywhere in the whole project. It's > > > difficult > > > > to give a standard to split the subtasks. For example, some files > have > > a > > > > lot while some modules have few. So I suggest the standard would > depend > > > on > > > > the volume of the changes. Before working, any subtask should find a > > > > committer as a mentor who would judge and approve the scope is > > suitable. > > > > > > > > What do you think? > > > > > > > > Any comments and suggestions would be appreciated. > > > > > > > > Best, > > > > Vino > > > > > > > > > >
