On Thu, 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).
We are supposed to do automated tests on IE and that require being able to clone it. Since we offcially support IE this is just a new reason to start working on fixing our build on our Windows agents. So yes we do have an easy way to check that it's not broken. > >> 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? I really don't think that's relevant. This is taking the thing the wrong way for me, you are never going to have anybody expressing a string will to participate when he can't even clone the source. > * 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 We can do retro compatibility for all the links that use scm macro. > ** git history, will we loose ability to see history of files? git log --follow > ** others? > * to list who is ok to participate actively in the move Me of course. > * 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 > _______________________________________________ > 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
