jan i wrote:
Now we have the next issue CentOS 5 versus CentOS 6. It is correct that the ticket is quite clear, so INFRA should have asked (and I dont know how this happened, at hipchat we actually discussed CentOS 5).
I see it as a simple misunderstanding, nothing more: the discussion about a "CentOS 5 VM" became a discussion about the "CentOS VM" and at a certain point a CentOS 6 VM was set up, for mere lack of communication. But our baseline is CentOS 5, so surely we will need CentOS 5. CentOS 6 or the latest Ubuntu is equivalent: it is a Linux system higher than our baseline. [For the record, this can't be your fault at all: I spent hours talking to Gavin years ago, before you got involved with Infra; and of course the problem is that we let too much time pass and details were lost]
We could easily have a directory with old gLibC library and header files.
I don't know if it is easy: glibc was an example, but other libraries are in the same situation.
Please remember we are not talking a vm for runtime, but a buildbot.
While we are configuring a VM+buildbot from scratch, it would make a lot of sense to align it with our release options, so that builds produced by that buildbot are equal to our standard builds. Our current Linux buildbots already produce builds that are compatible with newer systems only, but when configuring a new one it would be good to align the two.
Another little hickup, I can see multiple people have commented on the ticket, but if infra should do something, it might be a good idea to open the ticket.
Ahem... good suggestion! Well, if we decide that the right way is to go for tethys then I'll reopen the ticket.
As I see it (still being positive) we have several options a) Leave centOS 6, and install old gLibC, which will give us a buildbot for both centOS 5 and centOS6. b) Ask INFRA to redo the job, someone should reopen the ticket c) Ask INFRA to get tethys back (a physical machine), then we can have all the VMs there as we want (INFRA-6217)
Option A seems not optimal: we want our 4.1.x builds (for sure; and possibly later ones too) to build on CentOS 5, so I don't see a big benefit in "simulating" CentOS 5 on CentOS 6 when we can have the real one.
If we want a fast result we should go for a), but if we want something that can be expanded we should go for c). I have asked infra about c), which just happens to be the ticket pescetti refers to.
Realistically, how big is option C in comparison to option A? Weeks vs. hours? Can we do something in parallel, like preparing a VM offline? And what format should it be in? These are probably stupid questions, but if we know that then we can look for help with clearer ideas.
So much about the technical issues, now to my real concern. Could we not try to change attitude.....complaining and telling what does not work, is not exactly a good way to get things moving. We are pretty good at making people who try to help very very tired.
Let me disagree about the attitude (not in general, but in this case). Actually in this case people were doing stuff and not complaining. I created the account for Ariel, Ariel started setting up the environment and then figured out it was the wrong system version. At this point we need a decision and then we can surely resume work. In this case, there are surely people ready to work.
We dont get a community up and running, by telling each other all the mistakes we do....it would be a lot more efficient to help each other.
We are here to help. I'm not a big fan of option A simply because I have a different setup on my machine (if I need a CentOS 5 setup, I install a CentOS 5 VM and that's it), which is not a really compelling reason. If you say it's better to go for A rather than C in our situation, A is fine. If you say that in this weekend, working together, we can have a CentOS 5 VM setup as per option C, I would surely go for option C.
Regards, Andrea. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
