On Fri, May 17, 2013 at 12:28 AM, Denis Gervalle <[email protected]> wrote: > On Thu, May 16, 2013 at 7:02 PM, Sergiu Dumitriu <[email protected]> wrote: > >> On 05/16/2013 12:16 PM, Vincent Massol wrote: >> > >> > On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]> wrote: >> > >> >> >> >> On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> wrote: >> >> >> >>> On 05/16/2013 10:54 AM, Vincent Massol wrote: >> >>>> >> >>>> On May 16, 2013, at 4:47 PM, Thomas Mortagne < >> [email protected]> wrote: >> >>>> >> >>>>> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> >> 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. >> > > I usually use my IDE for exploring history, not the command line, so this > is not that simple IMO.
--follow is not an exotic option and Eclipse allow to enable it so I'm sure you can enable it too some way in Intellij > You say it will work for most files, it is just a guess... we should check > that for real. > Please guys don't act as if it was the first time in our history we rename something. We broke everything in 3.0/3.1 and recently we refactored most of platform projects to separate API/UI/tests, I did not seen anyone complained. > >> >> 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? >> > > 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 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 ;) >> >>>> >> >>> >> >>> -- >> >>> Sergiu Dumitriu >> >> -- >> Sergiu Dumitriu >> http://purl.org/net/sergiu >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
