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
