20 Jun
2013
20 Jun
'13
9:42 a.m.
Linking the issue in case someone will work on this in the future
http://jira.xwiki.org/browse/XWIKI-8275
Thanks,
Caty
On Wed, May 22, 2013 at 1:55 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
So here are the winners on platform/XE master:
xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-test/xwiki-platform-administration-test-tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif
(270)
xwiki-enterprise-installers/xwiki-enterprise-installer-generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed
(296)
which gives after refactoring
core/administration/test/tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif
(174)
installers/generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed
(252)
On Tue, May 21, 2013 at 11:54 AM, Vincent Massol <vincent(a)massol.net>
wrote:
Note that this kind of path does not exist, looks like you extracted a
XE in your platform project for test purpose. The actual test data is
extracted in
/Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/wiki
and /data/extension/repository is empty.
> That's 375 characters
> With the new rule that would be:
/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar
> That's still 301 characters.
> Thomas has done an extensive search
and he'll be able to give more
details on other long paths.
> Also note that we have an issue at
runtime with too long paths:
> [2/11/13 1:22:10 PM] Ionut Maxim: !
C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The
archive is corrupt
> What we could do to solve both
problems would be to reduce the path
length used by the EM to store metadata. For example:
/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/artifact.xar
> which gives 236 chars. Still pretty
close so another solution would be
to use some random directory names (since the names are not used by the EM):
/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/dfdsf4fszz3lmbf567/artifact.xar
> which would be around 200 chars.
> Now what would be interesting would
be to give indications to xwiki
builders and xwiki users as to what is the max path prefix they're allowed
to use for xwiki to build/work. In my example below I'm using
"/Users/vmassol/dev/xwiki/git" chars (i.e. 28 chars).
> Thanks
> -Vincent
> On May 16, 2013, at 7:02 PM, Sergiu
Dumitriu <sergiu(a)xwiki.org> wrote:
>> On 05/16/2013 12:16 PM, Vincent
Massol wrote:
>>>
>>> On May 16, 2013, at 6:09 PM, Vincent Massol <vincent(a)massol.net>
wrote:
>
_______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
FTR Thomas and I have discussed this a bit and
one thing Thomas has
started checking is the longest path we currently have.
One that we have found is:
/Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/xwiki-platform-ircbot-test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar
!
C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip:
The archive is
corrupt
> …
!
C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip:
Cannot create
xwiki-enterprise-jetty-hsqldb-4.5-rc-1\data\extension\repository\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui\4.5-rc-1\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-4.5-rc-1.xed
> Total path and file name length must not exceed 260 characters
>>
>>>
>>> On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <sergiu(a)xwiki.org>
wrote:
>>>
>>>> On 05/16/2013 10:54 AM, Vincent Massol wrote:
>>>>>
>>>>> On May 16, 2013, at 4:47 PM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com> wrote:
>>>>>
>>>>>> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <
vincent(a)massol.net> wrote:
>>>>>>> I'm rather -0 ATM
and very close to -1 because:
>>>>>>>
>>>>>>> 1) I haven't heard from a windows dev for a long time, I
don't
think that happens that often
>>>>>>
>>>>>> And it's surely not going to improve...
>>>>>>
>>>>>>>
>>>>>>> 2) It's a *huge* change and it should definitely not be
done
lightly. We would need to plan a period like 2 full days, all devs would
need to stop working on what they do and help out. For example all pages on
xwiki.org having some github links are going to be broken and will need
to be updated (that's probably around hunded of pages overall)
>>>>>>>
>>>>>>
>>>>>> Yes it's a huge change, that's why it's a vote.
>>>>>>
>>>>>>> 3) Windows devs have a simple solution which is to use cygwin
so
it's not a blocker
>>>>>>
>>>>>> It's not as trivial as you seems to think and it also mean
that you
>>>>>> simply can't use the standard git tools in the Windows world
like
the
>>>>>> Github application or
Tortoisegit without speaking or any EDI git
>>>>>> integration... so not it really can't be seen as some
obvious
>>>>>> solution. And it's not like using Cygwin was some king of
standard
for
>>>>>> Windows dev. "use
cyggwin" is easy to say but the reality is that a
>>>>>> dev will try to clone XWiki repository with the git tool he is
used to
>>>>>> and will simply
can't, period.
>>>>>
>>>>> What I'm saying is that I don't think it's worth the
effort. By
worth I mean the ratio between the effort and problems it'll require
from
us vs the # of windows dev not using cygwin that'll want to develop for the
xwiki project…
>>>>
>>>> But this is why we have a democracy and not a dictatorship. If the
>>>> community considers it is worth the effort, and at least some devs
are
>>>> willing to work on this, then I
think it's their right to do this.
>>>
>>> 1) You should re-read the governance. It's a meritocracy, i.e we vote
important changes and devs need to be ok. So if one or a few devs want to
do this but some other don't for some valid reason then it's not going to
happen until we reach a decision.
>>>
>>> 2) It's all the devs that will bear the cost of maintaining the new
environment, no just the dev who's willing to do the initial work.
>>>
>>> BTW none of us work on a windows environment and I think it's a bad
idea to implement support for something that we never use. It can only lead
to something that gets broken frequently. To overcome this we'd need some
windows agent and this means supporting that agent and making sure it works
all the time (we tried in the past and failed for a very simple reason:
none of the devs use windows and thus we don't care).
>>>
>>>> It's not a good move to veto the will of the community.
>>>
>>> Again (in case you didn't understand) I'm ok on the principle of
doing this move but doing cowboy-coding without thinking about the
consequences and letting other fix your stuff by only doing half of the
work isn't my preferred style…
>>>
>>> We've had enough bad examples of the dev environment being broken for
week(s not so long ago that it's normal to want to be careful...
>>>
>>>> Anyway, there are other reasons to make the change, not just Windows
>>>> compatibility. It saves about 2 seconds each time a dev wants to go
to a
>>>> directory from the command line.
Going into one subdirectory means
>>>> having to press "x tab <right prefix of the submodule>
tab". The
first
>>>> two keys are superfluous since
they're the same all the time. The
deeper
>>>> the hierarchy, the longer the
time it takes to go there. It adds up
to
>>>> more than an hour wasted per year
per dev, and I don't think it will
>>>> really take a whole month of every dev to do the migration. If
everybody
>>>> contributes and we do a
systematic effort, it could be done in an
hour
>>>> with the right planning.
>>>
>>> So to reiterate and to be constructive, before we start any actual
work on this I'd like that we do more evaluation. This means:
>>> * see a list of windows coders who
have expressed a need (apart from
Florin who I know already) and who have a real
will to participate after
the move. Do we have at least one?
>
> This is not just about Windows. The committers that vote +1 vote for
> their own environment, not just to fix a problem for hypothetical
> contributors.
>
> And it's not about improving something for existing contributors, but
> removing a blocker standing in the way of future contributors. The
> easier it is for a new potential community member to join, the more of
> these tentative users will actually stick around. And XWiki isn't
> overwhelmed by the number of contributors to afford to voluntarily keep
> out those not motivated enough to actually try to find out why the
> checkout fails and what needs to be done to actually have a working
> environment and go through all the painful process of installing cygwin
> and the the command line tools that work with cygwin.
>
>>> * that we list what needs to be done precisely. I've identified some
so far:
>>> ** the git path changes
>>> ** modify all the xwiki.org pages linking to code
>>> ** git history, will we loose ability to see history of files?
>
> Not really. In some cases we might have to add --find-copies-harder to
> some commands, but it should work out of the box for most files.
>
> Viewing the commits that affect a file on GitHub might not list pre-move
> commits, but the history will s
>
>>> ** others?
>
> * The move will break uncommitted local changes, so all devs should try
> to commit their local changes, at least in a separate local branch if
> not on github. But devs shouldn't keep uncommitted changes anyway,
right?
>
> * Depending on how they're configured, our IDEs might freak out when
> pulling for the first time, since everything will be moved around.
>
> * Existing pull request should still work, but Jira patches will break;
> they're probably broken already anyway, since we didn't really allow new
> patches to be put there for a while, and most of the paths have changed
> since 1-2 years ago.
>
> * Does anything on Jenkins depend on paths? I hope not, configurations
> use module names, and they will continue to point to the right POM.
>
> * I guess this still counts as xwiki.org changes, but we should make
> sure the pages that work with remote files, like the syntax
> documentation and syntax completion report, will also need to be
updated.
>
> * Existing links in emails (and other places with answers like
> stackoverlow) will be broken, but that already happens whenever we move
> a module, for example to make room for api+ui+test submodules, and this
> happened a lot recently, so it's not a new problem.
>
> * Most annoying: forgetting our own reflex of typing x+tab when changing
> the path :-)
>
>> ** what happens to the JIRA links to commits in the Commits tab? Will
they
still work?
>
> Yes, the existing commits will not change.
>
>> Thanks
>> -Vincent
>>
>>> * to list who is ok to participate actively in the move
>>> * that we agree on a date so that it doesn't impact our planned
roadmap
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>> We're going to loose at least a month before we've finished
that
migration completely and I'm really worried about the toll it'll have
on
our releases...
>>>>>
>>>>> Thanks
>>>>> -Vincent
>>>>>
>>>>> PS: With the same group effort we could release a first version of
the new model for example ;)
>>>>>>