Hi.
This time a small blueprint that can be easily done in one or two days. I think that, if successful, we could apply this pattern to other tools to cut down the number of parts we need to release.
(offtopic) If successful I'd like to schedule the following merges:
lava-dashboard-tool + lava-dashboard -> lava-dashboard lava-scheduler-tool + lava-scheduler -> lava-scheduler lava-server + lava-tool -> lava-core
The last part would define the core dependency of any lava component. This may be a good idea or a bad idea, depending on how you think about it. Feel free to think about it and comment but please keep the separation of concerns so that this (dashboard focused) blueprint can be considered without runaway discussion. (ontopic)
The blueprint is on the lava-dashboard-tool project. Please comment here on the mailing list.
https://blueprints.launchpad.net/lava-dashboard-tool/+spec/lava-dashboard-to...
Thanks ZK
I think the obvious concern for me here is that now we would be proposing to require a growing stack of web components, django, etc in order to just get a cli tool to submit a job. That seems like quite a lot of overhead for such a simple thing. I'm a little surprised you wouldn't rather group all the cli tools together. Also, from the BP summary, it's not clear to me what the benefit is that you are trying to achieve. On Mar 26, 2012 1:07 PM, "Zygmunt Krynicki" zygmunt.krynicki@linaro.org wrote:
Hi.
This time a small blueprint that can be easily done in one or two days. I think that, if successful, we could apply this pattern to other tools to cut down the number of parts we need to release.
(offtopic) If successful I'd like to schedule the following merges:
lava-dashboard-tool + lava-dashboard -> lava-dashboard lava-scheduler-tool + lava-scheduler -> lava-scheduler lava-server + lava-tool -> lava-core
The last part would define the core dependency of any lava component. This may be a good idea or a bad idea, depending on how you think about it. Feel free to think about it and comment but please keep the separation of concerns so that this (dashboard focused) blueprint can be considered without runaway discussion. (ontopic)
The blueprint is on the lava-dashboard-tool project. Please comment here on the mailing list.
https://blueprints.launchpad.net/lava-dashboard-tool/+spec/lava-dashboard-to...
Thanks ZK -- Zygmunt Krynicki Linaro Validation Team
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
W dniu 26.03.2012 22:47, Paul Larson pisze:
I think the obvious concern for me here is that now we would be proposing to require a growing stack of web components, django, etc in order to just get a cli tool to submit a job. That seems like quite a lot of overhead for such a simple thing. I'm a little surprised you wouldn't rather group all the cli tools together. Also, from the BP summary, it's not clear to me what the benefit is that you are trying to achieve.
You misunderstood my proposal. The dependencies are separate. The technique I'm using creates extras, optional components of a package that have additional dependencies.
In this case lava-dashboard-tool would be a transitional package that depends on lava-dashboard [tool]
It would not pull django ;-)
Thanks ZK
On Mar 26, 2012 1:07 PM, "Zygmunt Krynicki" <zygmunt.krynicki@linaro.org mailto:zygmunt.krynicki@linaro.org> wrote:
Hi. This time a small blueprint that can be easily done in one or two days. I think that, if successful, we could apply this pattern to other tools to cut down the number of parts we need to release. (offtopic) If successful I'd like to schedule the following merges: lava-dashboard-tool + lava-dashboard -> lava-dashboard lava-scheduler-tool + lava-scheduler -> lava-scheduler lava-server + lava-tool -> lava-core The last part would define the core dependency of any lava component. This may be a good idea or a bad idea, depending on how you think about it. Feel free to think about it and comment but please keep the separation of concerns so that this (dashboard focused) blueprint can be considered without runaway discussion. (ontopic) The blueprint is on the lava-dashboard-tool project. Please comment here on the mailing list. https://blueprints.launchpad.net/lava-dashboard-tool/+spec/lava-dashboard-tool-meged-with-lava-dashboard Thanks ZK -- Zygmunt Krynicki Linaro Validation Team _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org <mailto:linaro-validation@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-validation
On Mon, Mar 26, 2012 at 3:56 PM, Zygmunt Krynicki < zygmunt.krynicki@linaro.org> wrote:
W dniu 26.03.2012 22:47, Paul Larson pisze:
I think the obvious concern for me here is that now we would be proposing to require a growing stack of web components, django, etc in order to just get a cli tool to submit a job. That seems like quite a lot of overhead for such a simple thing. I'm a little surprised you wouldn't rather group all the cli tools together. Also, from the BP summary, it's not clear to me what the benefit is that you are trying to achieve.
You misunderstood my proposal. The dependencies are separate. The technique I'm using creates extras, optional components of a package that have additional dependencies.
In this case lava-dashboard-tool would be a transitional package that depends on lava-dashboard [tool]
It would not pull django ;-)
Transitional package? are you talking about debian packages here?
You mean if I am going to install a client tool (cli) for example cli for scheduler, I will get the scheduler install as well ? Do I understand you well ?
BR
/Chi Thu On 28 March 2012 07:11, Paul Larson paul.larson@linaro.org wrote:
On Mon, Mar 26, 2012 at 3:56 PM, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 26.03.2012 22:47, Paul Larson pisze:
I think the obvious concern for me here is that now we would be proposing to require a growing stack of web components, django, etc in order to just get a cli tool to submit a job. That seems like quite a lot of overhead for such a simple thing. I'm a little surprised you wouldn't rather group all the cli tools together. Also, from the BP summary, it's not clear to me what the benefit is that you are trying to achieve.
You misunderstood my proposal. The dependencies are separate. The technique I'm using creates extras, optional components of a package that have additional dependencies.
In this case lava-dashboard-tool would be a transitional package that depends on lava-dashboard [tool]
It would not pull django ;-)
Transitional package? are you talking about debian packages here?
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
W dniu 28.03.2012 13:59, Le.chi Thu pisze:
You mean if I am going to install a client tool (cli) for example cli for scheduler, I will get the scheduler install as well ? Do I understand you well ?
I'm not really sure what you mean.
There seems to be a lot of misunderstanding around this topic:
1) I'm only discussing python packages now, not debian packages 2) I'm proposing to merge -tool and -server parts for some of our projects (starting with dashboard and scheduler) 3) I'm proposing to use setuptools 'extras' feature to split dependencies between the client and server parts of each package 4) To use the client part you'd have to install lava-dashboard[client] 5) To use the server part you'd have to install lava-dashboard[server] 6) Installing plain lava-dashboard would only install library components common to all extras 7) Debian packages could split them again to lava-dashboard-client and lava-dashboard-server to maintain separate dependencies.
That is all.
Thanks ZK
BR
/Chi Thu On 28 March 2012 07:11, Paul Larson paul.larson@linaro.org wrote:
On Mon, Mar 26, 2012 at 3:56 PM, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
W dniu 26.03.2012 22:47, Paul Larson pisze:
I think the obvious concern for me here is that now we would be proposing to require a growing stack of web components, django, etc in order to just get a cli tool to submit a job. That seems like quite a lot of overhead for such a simple thing. I'm a little surprised you wouldn't rather group all the cli tools together. Also, from the BP summary, it's not clear to me what the benefit is that you are trying to achieve.
You misunderstood my proposal. The dependencies are separate. The technique I'm using creates extras, optional components of a package that have additional dependencies.
In this case lava-dashboard-tool would be a transitional package that depends on lava-dashboard [tool]
It would not pull django ;-)
Transitional package? are you talking about debian packages here?
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
W dniu 26.03.2012 22:47, Paul Larson pisze:
I think the obvious concern for me here is that now we would be proposing to require a growing stack of web components, django, etc in order to just get a cli tool to submit a job. That seems like quite a
No, they would not be installed if all you are after is the CLI part.
lot of overhead for such a simple thing. I'm a little surprised you wouldn't rather group all the cli tools together. Also, from the BP summary, it's not clear to me what the benefit is that you are trying to achieve.
There are two benefits:
1) We reduce the number of projects 2) We could introduce changes that require new tool commands consistently
There are no downsides, when installing lava-dashboard you'd simply specify that you want the 'cli' part of it.
On Mar 26, 2012 1:07 PM, "Zygmunt Krynicki" <zygmunt.krynicki@linaro.org mailto:zygmunt.krynicki@linaro.org> wrote:
Hi. This time a small blueprint that can be easily done in one or two days. I think that, if successful, we could apply this pattern to other tools to cut down the number of parts we need to release. (offtopic) If successful I'd like to schedule the following merges: lava-dashboard-tool + lava-dashboard -> lava-dashboard lava-scheduler-tool + lava-scheduler -> lava-scheduler lava-server + lava-tool -> lava-core The last part would define the core dependency of any lava component. This may be a good idea or a bad idea, depending on how you think about it. Feel free to think about it and comment but please keep the separation of concerns so that this (dashboard focused) blueprint can be considered without runaway discussion. (ontopic) The blueprint is on the lava-dashboard-tool project. Please comment here on the mailing list. https://blueprints.launchpad.net/lava-dashboard-tool/+spec/lava-dashboard-tool-meged-with-lava-dashboard Thanks ZK -- Zygmunt Krynicki Linaro Validation Team _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org <mailto:linaro-validation@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-validation
On Mon, 26 Mar 2012 20:07:07 +0200, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Hi.
This time a small blueprint that can be easily done in one or two days. I think that, if successful, we could apply this pattern to other tools to cut down the number of parts we need to release.
I guess I'm sort of +0 on this. It would reduce the slightly excessive number of project we have, but otoh the client side packages have been very stable so it's not like the change will save all that much actual effort.
Cheers, mwh
linaro-validation@lists.linaro.org
-
Le.chi Thu -
Michael Hudson-Doyle -
Paul Larson -
Zygmunt Krynicki