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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.