minutes of ESC call ...

[Bjoern Michaelsen]

Hi,

On Fri, Dec 09, 2016 at 08:57:03PM +0000, Michael Meeks wrote:
> 	Sure - question is if we want to check all the un-buildable binaries
> into a git repository; but we can do of course if it saves having a
> shell to download things.

Well, we could have the binaries in a submodule, so as not to pollute sane
environemnts. Maybe?

OTOH, since we are abondoning good taste anyway: We could also have all the
cygwin install as an image download, instead of bothering with installers
and setups -- AFAICR cygwin can be dumped pretty easily anywhere without much
need for "installers". Just mirroring a fixed cygwin install without bothering
for installer etc. might already kill a lot of the hurtful degrees of freedom.
 
> 	For me at least, none of that is relevant. We can pre-generate all of
> that and include it pre-built inside the 'something' that is downloaded.

You will spend more time discussing why e.g. (naive, not fully intentional) UNO
changes break the world in this setup than you will gain, I guess. I dont
think the target audience is aware at all about UNO or what "you cant do
incompatible changes" would mean. Note UNO is just one example here.
 
> 	Sure there are pain-points; and it is a rather artificial setup that is
> proposed - a newbie / starting developer setup. Having said that - you
> can get a -very- long way with just editing C++ files in a tree with
> pre-build python, ICU, etc. etc.

You can get a long way with just editing C++ files in the gerrit UI. Or with
Clophs pre-build remote Hackfest VM (which should probably include an IDE and
solutions e.g. kdevelop now). The question is what we achieve with that. There
seem to be two goals here:

1/ getting a newcomer to create their first patch ASAP
2/ becoming a somewhat selfsufficient contributor to LibreOffice

For 2/ getting a local Visual Studio setup might help a bit, while for 1/ both
Hackfest VMs and gerrit webediting are a lot better suited. Then again, we dont
see a lot of failure between 1/ and 2/, but we are hearing stories of untapped
possibilities that dont even get to 1/.

> 	Sure - and this then becomes an incremental task ;-) -iff- doing this
> generates interest from lots of new developers, which it might, then I
> suspect we get a set of manpower with motivation to make more and more
> of the code easily accessible on Windows ;-)

Fighting the dependency explosion is valuable in itself: Mostly because
"migrate tooling to be more native" is quite EasyHack-suitable and there might
be talent able to do it that wouldnt be able to contribute to core development
anyway ...

Best,

Bjoern