About Jim’s video requirement. and many users to many bitbake servers mapping.
maybe there are some problems maybe to solve.
Some my questions:
1. running builds remaining time. difficult to estimate.
when a user check all the builds status, whether they are done or not.
the remaining time, it is difficult to estimate. cause in bitbake server. I
donot accurately
to know current build when it starts, how long it will finish for this build.
so to give an accurate remaining time for user. it is difficult.
2. Add users own layers. how to implement?
one user wanna to add own layers. so he uploads own layer by browser to put
in web server firstly.
then we need let web server do one thing. to copy the layer to bitbake server.
so my problem.
1).if user upload a unavailable compression layer folder. how to check the
folder whether it is
a real layer or not. If it is hack shells or hack software. How to deal
with it?
2).if user next operation is time out during building, for example, after
building package,
User donot select package to build image for long time, so system will
trigger a time out event to stop and cancel this build .
next time, we need to assign a new bitbake for this user.
in fact. user only wanna to continue his operation based on last time
build. Donot need a new bitbake sever to repeat build.
And now all of user build, we only use one build directory. So it is
difficult to remain last different users build status.
3.after build completed in browser. it is difficult to test and deploy image
directly. how to solve these problems?
we only can download and upload files in browser. We cannot write or read a
local machine files and do some operation in browser.
So to test and deploy images by browser. It is difficult. So maybe we need to
develop a single client to solve this problem.
But we know. If develop a client. Whether we satisfy different OS. For example,
window xp, window 7, linux different version, mac os.
________________________________________
发件人: [email protected] [[email protected]] 代表 Barros
Pena, Belen [[email protected]]
发送时间: 2012年6月14日 16:37
到: Osier-mixon, Jeffrey; Stewart, David C
Cc: Jim Kosem; [email protected]; Konstantinos Papagiannopoulos
主题: Re: [yocto] Web HOB planning discussion
Hi all,
Thanks for the feedback: loads of interesting stuff there. We'll keep it all in
mind when working on the next iteration.
If you think of anything else, please post it here.
Cheers
Belen
From: <Osier-mixon>, Jeffrey
<[email protected]<mailto:[email protected]>>
Date: Wednesday, 13 June 2012 19:00
To: "Stewart, David C"
<[email protected]<mailto:[email protected]>>
Cc: Konstantinos Papagiannopoulos
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, Jim Kosem
<[email protected]<mailto:[email protected]>>
Subject: Re: [yocto] Web HOB planning discussion
I agree, it is looking really interesting. Some comments below.
On Wed, Jun 13, 2012 at 10:39 AM, Stewart, David C
<[email protected]<mailto:[email protected]>> wrote:
* This could be a great way for an organization to implement a workflow process
using YP, rather than try to invent one themselves. We have gotten the feedback
that some larger organizations want something like this, so I'm pleased with
that direction.
Agreed - I have fielded a few questions about this as well
* With the above in mind, a key meta-usage is installing and configuring the
server. For example, I could imagine an organization wanting to easily
customize the home page with their own news and design information, etc.
* I could also see the opportunity for an OSV or service provider to brand the
interface with their own goodness and extending it with their own features so
this might be another meta-usage.
* And while I'm on a roll... whenever we talk about how the administrator
installs this, we need consider how they update from a previous version,
particularly if they have customized the home screen or other bits.
If branding & customization happen in CSS, the whole customization part should
be portable from one version to another (as long as no one breaks anything
structural). If we want to enable customization of functionality, though - e.g.
pre-filter package selection, restrict certain features... - I could see that
being tricky to implement in a portable way.
* Project creation and member add/remove should perhaps be an administrator
role and password protected?
I vote yes on user management, but why password-protect project creation?
Other thoughts:
My feeling is that both Hob and WebHob will be most useful as tools to get
people started. At some point, anyone who is doing more esoteric work than the
Hob allows will need to learn how to get their hands dirty with recipes, config
files, etc. For that reason, I really like the workflow focus, as that
translates directly to the expected workflow of the whole build system. I
suggest a future step might be guided configuration, guided recipe (and layer?)
creation, and other progressive types of features that also show the workflow
in action the way the current Hob does.
And I totally agree that the usability work you guys have done is making a huge
difference in design. I like it! Want more!
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel
http://yoctoproject.org<http://yoctoproject.org/>
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
