On Thu, Aug 7, 2014 at 8:27 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Amit,
On 06/08/14 12:35, Amit Kucheria wrote:
Hi Juri,
On Wed, Aug 6, 2014 at 3:38 PM, Juri Lelli juri.lelli@arm.com wrote:
Hi Vincent,
I'm actually adding Chris to Cc: as he is also part of the original discussion about rt-app.
On 05/08/14 22:45, Vincent Guittot wrote:
Hi Juri,
Here is the pull request for the changes that create a workload generator tool
Regards,
The following changes since commit 17be4548c4260b80be623e0e1317e98a770dea7a:
copyright added (2014-04-11 09:28:27 +0200)
are available in the git repository at:
git://git.linaro.org/power/rt-app.git master
for you to fetch changes up to 8cbaad65d00e3c64c4f941139bc11f4d07822474:
add a web browsing use case (2014-08-01 15:43:47 +0200)
Thanks for sharing changes in your repository, but IMHO it is somewhat difficult to review them in this form, as behavioural changes are intermixed with small fixes. Also, it would be good if we can integrate changes keeping git history clean. Ideally we could introduce functional changes followed by (or together with) examples showing what feature the change introduces. I know that this is time consuming, so I'm actually asking if you think you have some time to work on rearranging things.
Vincent is on vacations until the end of the month. After that, I expect he'll be busy with Linaro Connect preparations.
Yes, the timing of all this sucks given that we want to announce the tools this week to give 2 weeks of lead time before Kernel Summit.
Having a proper history could also ease review. I'd say we could try two different methods. I created a GitHub organization that now hosts the rt-app repo: https://github.com/scheduler-tools/rt-app. I also created a branch for the original version of the tool so that we can integrate changes on master.
Method 1) We use GitHub pull request feature to discuss changes and finally integrate them.
Method 2) You post the patchset (based on master) on linaro-dev mailing list, discussion happens on the mailing list (everybody can participate), after discussion I apply patches resulting from discussion on master.
I'd personally prefer method 2 as it is simpler and can probably get contributions from a wider audience. What other thinks?
I prefer Method 2 myself but it is going to be hard to get anything refactored until late September.
So, I'd say we wait for the actual review process to happen when feasible anyway.
I agree. Admittedly the kernel summit deadlines and vacation schedules among other things have forced us to take some shortcuts.
We'll feed these patches back in small chunks over time. In the meanwhile, for the sake of the tools announcement, we'll just refer to the tree on g.l.o
We also said that the name of the tool could be changed, any opinions on this? Something like workload-gen or wload-gen ?
IMHO, the name change is just a nice to have and not critical to the success of this project.
Workload Generator is the obvious choice of name but not very Google-friendly. Can someone think of a suitable qualifier before it? It'd stick with rt-app until then.
Regards, Amit