Before I get into the details, let me just say that nothing in the proposal changes my overall perception, I remain fork neutral and any plug-in I develop will work on both if at all technically possible.
From my point of view I am mostly positive towards the proposal,
- I think this is a good move, bringing it to eclipse can hopefully reduce some of the bad blood and knee-jerk reactions when people mention Hudson/Oracle, and in time this will hopefully manifest as better corporation between the two projects.
- I am very pleased that this has made sonatype contribute even more to the open source version instead of hudson pro. :-)
- It is nice to see that more companies are investing in Hudson, for people like me that tries to remain fork neutral it is good to see that the effort is not "wasted".
but it does leave me with some concerns and questions:
- One of mentioned reasons for going with Eclipse is the better governance model, but I haven't seen any explanation on how this governance will be performed except that 2 people are listed as project lead. Maybe it is just following a standard eclipse governance ? (which I haven't found the link for yet). Some basic clarification would be nice, like: Will it be the comiters who are in control, or will there be some sort of governance board ? if a board how is the election process?
- I can see why Oracle want to move to a neutral 3. party, but I haven't understood why eclipse and not something like Apache ?
- How will the re-licensing affect the possibility to port fixes between the forks ? my initial understanding is that since MIT code can be re-licensed as EPL but not the other way, fixes can be ported only from Jenkins to Hudson. Am I correct ?
- One of my major concerns with this move is the requirement to use eclipse infrastructure. I haven't been a comitter to eclipse based projects so I am not overly familiar with it, but looking at it does appear somewhat dated compared to java.net + github. I am especially concerned about loosing the easy fork and pull workflow. Are we really loosing that functionality entirely, and if so what is the replacement?
- Another of my concerns is that contributing to the core seems more geared towards company sponsored development, leaving less room for individual free-time contributors like me to help out or get a say in the development. Maybe it is just caused by my own lack of knowledge, but perhaps someone can clarify ?
- I haven't seen any discussion on the developer mailing list or JIRA on how to replace the LGPL components. This discussion should be started.
So in summary: Good move, but more details should be posted