Re: [xwiki-devs] [VOTE] Remove all duplicated information from folders names on git repositories

From the rename, I would suspect some possible build issues having folder

On Thu, 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>

> > > >> > >> On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <sergiu(a)xwiki.org>

> >> > >>> 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&gt; wrote: > >>>> > >>>>> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <

> 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

> 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

> >>>>> simply can't use the standard git tools in the Windows world like

> >>>>> 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

> >>>>> dev will try to clone XWiki repository with the git tool he is

> to > >>>>> and will simply can't, period. > >>>> > >>>> What I'm saying is that I don't think it's worth the effort. By

> I mean the ratio between the effort and problems it'll require from us

> the # of windows dev not using cygwin that'll want to develop for the

> 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

> >>> 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

> do this but some other don't for some valid reason then it's not going

> 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

> to something that gets broken frequently. To overcome this we'd need

> windows agent and this means supporting that agent and making sure it

> 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

> this move but doing cowboy-coding without thinking about the

> 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

> a > >>> directory from the command line. Going into one subdirectory means > >>> having to press "x tab <right prefix of the submodule> tab". The

> >>> 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

> >>> 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

> >>> with the right planning. > >> > >> So to reiterate and to be constructive, before we start any actual

> 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

I usually use my IDE for exploring history, not the command line, so this is not that simple IMO. You say it will work for most files, it is just a guess... we should check that for real. > > 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,

Are you thinking about non-commiters ? * 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. And any patches maintained by potential existing users for their own use. > * 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

> > * 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

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs