On 27 May 2012, at 20:12, Igor Fedorenko wrote:
I believe this *appears* worse than it actually is.
This belief is based on what, exactly? That you don't think it's likely that projects will be on both old and new servers at the same time?
The problem is triggered when both<0.15 and 0.15+ projects have shared
artifacts in local repository and 0.15+ projects either produce or
specifically consume packed artifacts. The problem won't appear in all
other cases, so I don't expect to see it too often even on large CI
servers like hudson.eclipse.org
The problem is that as the larger the CI servers grow, the more likely such a collision occurs. When it does occur, you only need one project based on 0.15 to cause problems for everything else, and naturally projects tend to evolve at different paces - so it will always be the case that initially, one product will move forwards whilst the others will be left behind. What's more, it's often not trivial to determine what bases a project on a packed artefact and what doesn't - for example, I suspect any RCP based app will be dependent upon packed artefacts. And any of the EPP type builds thinking of moving to Tycho will do the same.
But worse of all, none of this will be visible to users of Tycho<0.15. All they'll know is that a build that worked before, hasn't been changed (and for maintenance reasons may need to stay on an older one) will suddenly fail to work. And developers won't be able to test, because it will work fine on their machines.
Any project with at least some level of development activity should be
able to migrate to a new Tycho version or use a separate local repo,
which is literally single configuration toggle in Hudson. I believe this
applies both to current "master" branch and maintenance branches.
The problem isn't that this is not possible to work around; the fact is that a single 0.15 build can take down any number (tens, hundreds, thousands …) with potentially significant impact. If you're only looking at one or two builds, this isn't a problem. If you're looking at one or two hundred, it can be.
The problem is caused by a bug in Tycho<0.15. We could change metadata
format used by 0.15+ as a workaround, but I don't see why we should
perpetuate old bugs, especially at the cost of more complicated metadata
structure and the code needed to maintain it going forward.
There's "perpetuating old bugs" and then there's "causing potentially thousands of jobs to fail". I agree, one shouldn't always be stuck in the past - but in this case, there's a clear problem with corruption of older builds.
Perhaps a solution is to use a different named artifacts file for 0.15+, like artifacts+pack200.xml. That way, 0.15 will use its own copy of the repo, and<0.14 will use their own copy of the repo. At some point, maybe for the 1.0 relesae, you can switch back to a plain artifacts.xml on the assumption that everyone will have upgraded by then. But marking as WONTFIX is going to cause many problems for organisations who don't plan their builds according to best practice.
Alex
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
