On Sun, 2014-03-30 at 13:25 +0200, Martin Jansa wrote: > On Mon, Mar 17, 2014 at 11:03:06AM +0000, Paul Eggleton wrote: > > On Monday 17 March 2014 10:38:05 Richard Purdie wrote: > > > On Mon, 2014-03-17 at 10:25 +0100, Martin Jansa wrote: > > > > * useful when distro wants to collect build statistics from > > > > > > > > all users/developers without any manual interaction from them > > > > > > > > Signed-off-by: Martin Jansa <[email protected]> > > > > --- > > > > > > > > meta/classes/report-error.bbclass | 103 > > > > ++++++++++++++++++++++++++++++++++- > > > > meta/conf/local.conf.sample.extended > > > > | 20 +++++++ > > > > 2 files changed, 121 insertions(+), 2 deletions(-) > > > > > > I get worried about this as people could (rightly) be very nervous about > > > the system sharing information with a remote server without their > > > knowledge. Adding in this functionality makes it look as if that is the > > > intent of the system. > > > > > > This is why there was a two step process, first to save out the data and > > > second to have the user upload it (once they'd looked at what it was > > > sharing). > > > > > > Does anyone else have thoughts on this? > > > > I have the same concerns. It's fine if people enable this in their own > > build > > server's local.conf / auto.conf; but if someone were to put this into their > > distro config which is downloaded and used by someone to do their own > > builds > > with configuration or additional components that they do not wish to share, > > there's the potential for that person to be unaware that their build > > failures > > will be uploaded and shared automatically. > > My use-case was private distro, where it's imho valid to gather > build stats from every build which happens in the company (we're using > it to find builds which weren't configured correctly, e.g. referencing > non-existent premirror/sstate-mirror etc). > > Should I just change the description and commit message so that it > doesn't promote it for distro config to use it or should I keep it all > private? > > I'm thinking about using this also in my bitbake world builds and it's > also easier to enable it in config there, than parsing the log and > calling send-error-report from jenkins job config when report was > created.
I can see the usecase for this, equally, we do need to be mindful of the privacy concerns. FWIW, I do want to see the class in use on the yoctoproject autobuilders, however I had envisaged we'd just add a command after the "bitbake" one which would hoover up any errors and report them. I think I'm ok with the idea, as long as it only gets triggered if the user adds a specific file into HOME. I don't like the idea of using raw_input() in the bbclass file, I think this is fragile and likely to cause issues. How about we have an external script which handles setup of this file? I'd like to see a big warning the user has to acknowledge in setting up this such that they realise that all build errors may get reported. I'd also like to have two separate classes since I'd like to have the "saving errors" part enabled by default for everyone. The "sending errors" part would enough happen automatically if configured, otherwise the user could run it manually. > Should I use error-report-web installed on yoctoproject.org or create my own > instance somewhere? I'm hoping we can try and share a server in the hope that we can then figure out statistics on errors. If 50 people see a given error we can then prioritise it compared to an error only 2 people see. I know Michael is working on setting something up. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
