Tommi Laukkanen wrote: > I apologise that I linked the latter chapter to this specific thread. > I should have posted it as a separate message as it was a more general > comment on our decission making process. > > I guess it sprung from my wonderment about how the decission turned > out to be not to fix the overtly long config file in the way justincc > suggested. I think that the decission did not take into account people > like administrators and developers who use the system. Yes the > framework code can be more complex but it can produce benefits for > administrators and developers who need to deal with the long ini file. > I would even say that almost anything which splits the file is an > improvement to the current system.
It's okay, Tommi. I can see the point that a single .ini file is simpler. However, I don't think that it will be sustainable in the long run. But sometimes (often?) I'm wrong - witness the first config preview with lots of subfolders which I agree now was pretty horrendous. In many cases, us core developers can simply go and implement our own approach in the code. But in this case there is already an existing well known config mechanism that people are using, and my use of OpenSim almost certainly doesn't reflect the many possible setups that are out there. So I went through the preview process precisely to get as much review feedback as possible. I would be very disappointed if people were making posts by following somebody else's opinion rather than thinking for themselves. But I really don't think that was the case. Sometimes you do need to take decisions which are not 100% popular. And normally, I would push on and keep previewing things because I'm quite a stubborn sonofabitch. But I genuinely do need to turn some attention towards other things. I'll also admit that the consultation process takes quite a lot of energy. This is not necessarily a bad thing - I personally think that big disruptive changes shouldn't be undertaken lightly. Maybe leaning more towards simply changing things and fixing (or reverting) them afterwards would have achieved quicker results, though it's not an approach that I would take here. > > Putting down an effort which tries to fix a problem at least can be > said to be counter productive. I should reformulate my message: We > should in general suggest alternatives rather than just say "ouch I > dont like this". Our vote has consequences and if we use it we should > spend a little time to look into the issue and help the team to find a > better solution. To be fair, I think there were quite a few constructive suggestions. Unfortunately, it's not always possible to synthesize them all without turning the whole process into design-by-committee (which is not a good extreme, imo). > > -tommi > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
