Hi Jacques, Thanks for looking into this and help. I agree with your concern that it is hard to review many subtickets. Also it would be more easy to apply/review patch from one relevant ticket. For the same reason I started commiting multiple patches from different ticket in one commit.
The reason behind the current approach with OFBIZ-7828 is that, on community day multiple people can work on different part of a same ticket. Devs working on subtickets are responsible for development, self review and testing. Small chunks facilitate devs to follow this procedure for each entity. So we can say, all services added till now completely tested from webtools by devs. So its easy to do distributed efforts on this long on going ticket by sub-tickets. And for reviewing purpose I started committing multiple tickets in single commit. I'll continue on picking multiple tickets and do single commit. -- Thanks & Regards --- Arun Patidar Manager,Enterprise Software Development HotWax Mediawww.hotwaxsystems.com On Sun, Oct 16, 2016 at 3:46 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > I have a proposition about tasks with many trivial subtasks like > OFBIZ-8413, OFBIZ-7828 or OFBIZ-7334, etc. > > When I look at https://issues.apache.org/jira > /secure/Dashboard.jspa?selectPageId=12310800 I see that we have some > difficulties to cope with all these subtasks > > Yesterday, while reviewing one related commit by Arun with 20 subtasks > embedded : http://svn.apache.org/viewvc?view=revision&revision=1765077 > > I wanted to help on OFBIZ-7828 but it's really a pain to > > 1. open so many subtasks > 2. download the patches > 3. apply them one by one > > When it's actually so easy to review the commit Arun did, so it would be > the same before committing. > > So I suggest we don't create so many subtasks when they are trivial. We > could rather create component, class or alike named patches and attach them > to only 1 Jira. > > Then using a tool to download simultaneously a bunch of files from a page > (I use http://www.downthemall.net/) and catenate them in one file it's > very easy to achieve the same. > > Jacques > > > > Le 25/09/2016 à 09:42, Jacques Le Roux a écrit : > >> I have proposed a remedy with my answer in a new thread forked from the >> flat grey vote one. >> >> BTW, what are you opinions on the "Community Days" and alike days by >> HotWax? >> >> I understand they happen on weekends when people have more spare time and >> it's amazing to see people working together. >> So I much appreciate the result of these days, but I find hard to follow >> and review those bursts of activity. >> >> I have though nothing to remedy that, apart delaying reviews which is not >> always a good solution. >> Because it's sometimes too late when commits results are entangled and >> then hard to ask to revert. >> >> Jacques >> >> >> Le 25/09/2016 à 01:44, Scott Gray a écrit : >> >>> As an aside to this, and also what I mentioned in the flat grey vote >>> thread: >>> >>> I think you rely on lazy consensus too much. Not many contributors have >>>> as much time as you to give to the project and formulating an argument >>>> against something (and then continuing the discussion) can take up a >>>> lot of >>>> time and energy. In my experience people are generally very quick to >>>> agree >>>> to good ideas (because it takes no effort other than to reply +1) so if >>>> you >>>> get *no* responses then you should IMO take pause before pushing ahead. >>>> >>>> Out of curiosity I took a look at your activity this month: >>> 24 discussion begun >>> 11 commits that triggered a discussion >>> 80 other commits that presumably required some level of review >>> >>> While your contributions are appreciated, please be aware of the burden >>> this high level of activity places on the rest of the active contributors >>> and the time consumed is time that those contributors could be putting >>> into >>> pursuing their own priorities. >>> >>> Given this, do you really think it is fair to get annoyed when people >>> don't >>> respond quickly enough for you? Does it seem wise to apply lazy >>> consensus >>> to decisions that don't receive much feedback? >>> >>> Regards >>> Scott >>> >>> On 25 September 2016 at 11:00, Scott Gray <scott.g...@hotwaxsystems.com> >>> wrote: >>> >>> Calm down Jacques, I'm sure Michael will respond when he has a chance. >>>> This isn't a big deal and I don't see why there would be any rush to >>>> fill >>>> your request. >>>> >>>> Regards >>>> Scott >>>> >>>> On 23 September 2016 at 21:38, Jacques Le Roux < >>>> jacques.le.r...@les7arts.com> wrote: >>>> >>>> After 4 days clearly nobody cares. I guess Michael does not want to >>>>> "open >>>>> source" his process and nobody cares about having this information >>>>> monthly >>>>> in the blog or not. >>>>> >>>>> Closed >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> Le 19/09/2016 à 10:26, Jacques Le Roux a écrit : >>>>> >>>>> Hi All, Michael, >>>>>> >>>>>> Like we have a dedicated page for releases creation[1] in wiki, and >>>>>> though it's of less importance, I think we should have a such page >>>>>> for the >>>>>> "monthly Jira issues list" creation in the blog >>>>>> >>>>>> Currently it's done by Michael, based on a work he previously did and >>>>>> continue to do but only in German (eg https://www.ecomify.de/blog/ap >>>>>> ache-ofbiz-news-august-2016-1250/) >>>>>> >>>>>> It should be at least documented in order to not only depend on >>>>>> Michael >>>>>> but to also possibly lighten the burden brought on him. >>>>>> >>>>>> I know you voluntarily proposed to do it Michael, and again I thank >>>>>> you >>>>>> for that! >>>>>> >>>>>> Unfortunately this adds again some burden on you, because AFAIK you >>>>>> are >>>>>> currently the one person able to create this wiki page. Thanks! >>>>>> >>>>>> [1] https://cwiki.apache.org/confluence/display/OFBADMIN/Release >>>>>> +Management+Guide+for+OFBiz >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> >>>>>> >> >> >
