New Branch: http://svn.apache.org/repos/asf/openmeetings/branches/OPENMEETINGS-745/ based on trunk r1512224 <https://issues.apache.org/jira/browse/OPENMEETINGS-752#> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=swagner> Jenkins Job is at: https://builds.apache.org/job/OPENMEETINGS-745/
Sebastian 2013/8/10 seba.wag...@gmail.com <seba.wag...@gmail.com> > https://issues.apache.org/jira/browse/OPENMEETINGS-745 > > is a summary jira, actual work is broken down in sub issues. > > Sebastian > > > 2013/8/10 seba.wag...@gmail.com <seba.wag...@gmail.com> > > Maxim, >> >> just one thing: The "new" implemention will of course also "silently" >> overwrite the timezone string with every login. >> Otherwise we would send invitations to that user in a potentially wrong >> configured timezone. >> >> >> >> >> 2013/8/10 seba.wag...@gmail.com <seba.wag...@gmail.com> >> >> My vote is also 2. I will create a couple of jiras later today. >>> We can create a feature branch based on trunk and do the work inside >>> that. >>> >>> Sebastian >>> On Aug 9, 2013 11:33 PM, "Vasiliy Degtyarev" <va...@unipro.ru> wrote: >>> >>>> My vote is for Alternative 2. >>>> >>>> Vasiliy >>>> >>>> >>>> On 09.08.2013 14:24, seba.wag...@gmail.com wrote: >>>> >>>>> So probably we can put this up for a vote? >>>>> >>>>> The only alternative I see as a short term fix is to overwrite the >>>>> users >>>>> "OmTimeZone" with the current timezone of the browser. >>>>> >>>>> Alternative 1: >>>>> Short term fix, default OmTimeZone to current timezone in browser, >>>>> overwrite everytime the user logs in (Estimated 1-2 weeks of work) >>>>> >>>>> Alternative 2: >>>>> Rewrite and refactor to get rid of entire OmTimeZone (as described in >>>>> attached discussion or thread: http://markmail.org/message/** >>>>> rem2snf74srvftnt <http://markmail.org/message/rem2snf74srvftnt>) >>>>> (Estimated 1-2 months of work) >>>>> >>>>> The effort estimates are including time that is needed for fixing bugs >>>>> and >>>>> do the testing. >>>>> >>>>> Vote for 1 if you like to see this implemented as part of OpenMeetings >>>>> 3.0.0, vote for Alternative 2 if you want to see this implemented as >>>>> part >>>>> of OpenMeetings 3.0.0. >>>>> >>>>> Thanks, >>>>> Sebastian >>>>> >>>>> >>>>> 2013/8/8 seba.wag...@gmail.com <seba.wag...@gmail.com> >>>>> >>>>> That is the major question. >>>>>> >>>>>> Basically status now is that the Calendar UI is not ready to be >>>>>> released. >>>>>> The UI is simply not working when your browser timezone is different >>>>>> from >>>>>> the timezone in your OpenMeetings profile. >>>>>> >>>>>> So either we can do the proposed fixes around getting rid of the >>>>>> OmTimeZone completely or we try to do some kind of workaround in >>>>>> OpenMeetings 3.0.0 and do the refactoring later. >>>>>> >>>>>> Sebastian >>>>>> >>>>>> >>>>>> 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> >>>>>> >>>>>> Can we define any useful JUnit tests so that we don't need to do so >>>>>>>>>> >>>>>>>>> much manual testing ? >>>>>>> I believe so, but what version will be affected with this change? >>>>>>> 3.0.0 or >>>>>>> 3.1.0? >>>>>>> >>>>>>> >>>>>>> On Wed, Aug 7, 2013 at 1:43 PM, seba.wag...@gmail.com < >>>>>>> seba.wag...@gmail.com >>>>>>> >>>>>>>> wrote: >>>>>>>> "I would default server time zone to the time zone of the server. >>>>>>>> It is up to admin to set it to the different value." >>>>>>>> ok >>>>>>>> >>>>>>>> "Additionally Appointment, I guess." >>>>>>>> Nope, Appointment does not have timezone information. The start/end >>>>>>>> >>>>>>> date of >>>>>>> >>>>>>>> the appointment is always in the server time zone. Actually _an_ >>>>>>>> >>>>>>> date/time >>>>>>> >>>>>>>> that is stored is always the server time. >>>>>>>> We only need timezone information when we need to display that time >>>>>>>> for >>>>>>>> >>>>>>> any >>>>>>> >>>>>>>> _user_ to generate a localized representation of the date/time. >>>>>>>> For instance an Appointment can be 8am GMT but for one user 1am >>>>>>>> >>>>>>> GMT/Berlin >>>>>>> >>>>>>>> should be displayed as 6pm NZDT/Auckland and for yet another >>>>>>>> >>>>>>> MeetingMember >>>>>>> >>>>>>>> it has to be displayed as 2am EDT/New York. >>>>>>>> >>>>>>>> So from my point of view the User, MeetingMember and Invitations >>>>>>>> Entity >>>>>>>> >>>>>>> are >>>>>>> >>>>>>>> the right place. And that is already as it is now. So you can >>>>>>>> replace >>>>>>>> OmTimeZone in all those classes with the new attribute that stored >>>>>>>> the >>>>>>>> timezone. >>>>>>>> >>>>>>>> Can we define any useful JUnit tests so that we don't need to do so >>>>>>>> much >>>>>>>> manual testing ? >>>>>>>> >>>>>>>> Sebastian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>> >>>>>>>> I would default server time zone to the time zone of the server. >>>>>>>>> It is up to admin to set it to the different value. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 7, 2013 at 12:09 PM, seba.wag...@gmail.com < >>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> I basically don't mind about the component in the UI. I just >>>>>>>>>> thought >>>>>>>>>> initially that 650 in a combobox is too much. >>>>>>>>>> However it does not seem to be an issue for the UI as such. >>>>>>>>>> >>>>>>>>>> My basic question is what we use as default: Do we default to the >>>>>>>>>> >>>>>>>>> server >>>>>>>> >>>>>>>>> timezone or to the client site user timezone ? >>>>>>>>>> >>>>>>>>>> Sebastian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2013/8/7 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>> >>>>>>>>>> The correct URL is http://timezonepicker.com/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 7, 2013 at 9:30 AM, Maxim Solodovnik < >>>>>>>>>>> >>>>>>>>>> solomax...@gmail.com >>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>> I believe we can use something like this: >>>>>>>>>>>> >>>>>>>>>>> https://timezonepicker.com >>>>>>>> >>>>>>>>> (sources are here: >>>>>>>>>>>> >>>>>>>>>>> https://github.com/**quicksketch/timezonepicker<https://github.com/quicksketch/timezonepicker> >>>>>>> ) >>>>>>> >>>>>>>> The only issues I can see right now: >>>>>>>>>>>> 1) it has no License set in the moment ( >>>>>>>>>>>> https://github.com/**quicksketch/timezonepicker/**issues/2<https://github.com/quicksketch/timezonepicker/issues/2> >>>>>>>>>>>> ) >>>>>>>>>>>> 2) It last updated 9 months ago >>>>>>>>>>>> >>>>>>>>>>>> So maybe additional googling is required :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Aug 7, 2013 at 4:50 AM, seba.wag...@gmail.com < >>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> One thing that is not on our list now is the default timezone >>>>>>>>>>>>> >>>>>>>>>>>> of >>>>>>> >>>>>>>> the >>>>>>>> >>>>>>>>> server. >>>>>>>>>>>>> Currently when you install OpenMeetings you choose a timezone. >>>>>>>>>>>>> >>>>>>>>>>>>> The questions are: >>>>>>>>>>>>> 1) Where do we populate the timezones from in that list, >>>>>>>>>>>>> >>>>>>>>>>>> displaying >>>>>>>> >>>>>>>>> 650 >>>>>>>>>> >>>>>>>>>>> timezones of java.util.Timezone is not practical >>>>>>>>>>>>> 2) If we default that timezone to some value, what shall it >>>>>>>>>>>>> >>>>>>>>>>>> be? >>>>>>> >>>>>>>> The >>>>>>>> >>>>>>>>> timezone of the server or the timezone of the client browser? >>>>>>>>>>>>> => In theory this default timezone is used whenever we >>>>>>>>>>>>> >>>>>>>>>>>> can't >>>>>>> >>>>>>>> find a >>>>>>>>>> >>>>>>>>>>> suitable timezone. So potentially we can default it to the >>>>>>>>>>>>> >>>>>>>>>>>> browsers >>>>>>>> >>>>>>>>> timezone that is currently installing OpenMeetings. >>>>>>>>>>>>> This default timzeone will be used whenever there is no >>>>>>>>>>>>> >>>>>>>>>>>> timezone >>>>>>>>> >>>>>>>>>> available for a user or if the timezone of the user is >>>>>>>>>>>>> >>>>>>>>>>>> corrupted. >>>>>>> >>>>>>>> Sebastian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> Additionally Appointment, I guess. >>>>>>>>>>>>>> Non-existent XML attribute will be ignored by >>>>>>>>>>>>>> >>>>>>>>>>>>> simpleframework. >>>>>>> >>>>>>>> I believe we can let timezones.xml live in our sources and >>>>>>>>>>>>>> >>>>>>>>>>>>> convert >>>>>>>> >>>>>>>>> backups >>>>>>>>>>>>> >>>>>>>>>>>>>> based on it >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 5:28 PM, seba.wag...@gmail.com < >>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> That might be another approach. >>>>>>>>>>>>>>> So you are saying we get rid of the Entity OmTimeZone in >>>>>>>>>>>>>>> >>>>>>>>>>>>>> total? >>>>>>>> >>>>>>>>> Even if we have the timezone in the each of those object,I >>>>>>>>>>>>>>> >>>>>>>>>>>>>> think >>>>>>>> >>>>>>>>> there >>>>>>>>>>> >>>>>>>>>>>> should be a fallback mechanism. Cause with every Java >>>>>>>>>>>>>>> >>>>>>>>>>>>>> update >>>>>>> >>>>>>>> (or I >>>>>>>>> >>>>>>>>>> think >>>>>>>>>>>>> >>>>>>>>>>>>>> you can even do it manually) you can get updates to the >>>>>>>>>>>>>>> >>>>>>>>>>>>>> number/offset >>>>>>>>>>> >>>>>>>>>>>> of >>>>>>>>>>>>> >>>>>>>>>>>>>> the timezones (appearently every year such and such >>>>>>>>>>>>>>> >>>>>>>>>>>>>> countries >>>>>>> >>>>>>>> for >>>>>>>>> >>>>>>>>>> instance >>>>>>>>>>>>>> >>>>>>>>>>>>>>> "decide" to switch to have not a Daylight saving time, et >>>>>>>>>>>>>>> >>>>>>>>>>>>>> cetera, >>>>>>>>> >>>>>>>>>> or >>>>>>>>>> >>>>>>>>>>> there >>>>>>>>>>>>>> >>>>>>>>>>>>>>> is even a brand new timezone). >>>>>>>>>>>>>>> So it could happen one day that we have timezone string in >>>>>>>>>>>>>>> >>>>>>>>>>>>>> our >>>>>>> >>>>>>>> application >>>>>>>>>>>>>> >>>>>>>>>>>>>>> that is neither known to java.util.Timezone nor to >>>>>>>>>>>>>>> net.fortuna.ical4j.model.**TimeZone. Or a timezone exists in >>>>>>>>>>>>>>> >>>>>>>>>>>>>> the >>>>>>> >>>>>>>> one >>>>>>>>> >>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>>>> does >>>>>>>>>>>>>> >>>>>>>>>>>>>>> not exist in the other. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we should go the extra mile and try to outline the >>>>>>>>>>>>>>> >>>>>>>>>>>>>> technical >>>>>>>>>> >>>>>>>>>>> part >>>>>>>>>>>>> >>>>>>>>>>>>>> upfront doing anything concretly. It could save us a lot of >>>>>>>>>>>>>>> >>>>>>>>>>>>>> time. >>>>>>>>> >>>>>>>>>> Also it >>>>>>>>>>>>> >>>>>>>>>>>>>> might be good to discuss this publicly as more then one >>>>>>>>>>>>>>> >>>>>>>>>>>>>> person >>>>>>> >>>>>>>> can >>>>>>>>> >>>>>>>>>> then >>>>>>>>>>>>> >>>>>>>>>>>>>> work on it in parallel. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As far as I can judge you can't save the type >>>>>>>>>>>>>>> >>>>>>>>>>>>>> java.util.Timezone >>>>>>>> >>>>>>>>> in >>>>>>>>>> >>>>>>>>>>> a >>>>>>>>>>> >>>>>>>>>>>> database. >>>>>>>>>>>>>>> So it has to be either a string or you store an Integer >>>>>>>>>>>>>>> (utcTimeZoneOffset). But I really don't like the latter as >>>>>>>>>>>>>>> >>>>>>>>>>>>>> it >>>>>>> >>>>>>>> does >>>>>>>>> >>>>>>>>>> not >>>>>>>>>>> >>>>>>>>>>>> handle Daylight savings times. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So the Entities that hold an attribute "omTimeZone" that >>>>>>>>>>>>>>> >>>>>>>>>>>>>> would >>>>>>> >>>>>>>> need >>>>>>>>>> >>>>>>>>>>> to be >>>>>>>>>>>>> >>>>>>>>>>>>>> changed: >>>>>>>>>>>>>>> User >>>>>>>>>>>>>>> Invitations >>>>>>>>>>>>>>> MeetingMembers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and they all get a new attribute "String tz" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> How would we imagine could the export and import work if >>>>>>>>>>>>>>> >>>>>>>>>>>>>> you >>>>>>> >>>>>>>> import >>>>>>>>>> >>>>>>>>>>> an >>>>>>>>>>> >>>>>>>>>>>> old >>>>>>>>>>>>>> >>>>>>>>>>>>>>> backup where the OmTimeZone is set in the user? I guess we >>>>>>>>>>>>>>> >>>>>>>>>>>>>> need >>>>>>>> >>>>>>>>> a >>>>>>>>> >>>>>>>>>> converter >>>>>>>>>>>>>> >>>>>>>>>>>>>>> that can handle OmTimeZone to the new format. >>>>>>>>>>>>>>> However would that even work currently with >>>>>>>>>>>>>>> org.simpleframework.xml.**Element, when you have an >>>>>>>>>>>>>>> attribute >>>>>>>>>>>>>>> >>>>>>>>>>>>>> that >>>>>>>> >>>>>>>>> does >>>>>>>>>>> >>>>>>>>>>>> just >>>>>>>>>>>>>> >>>>>>>>>>>>>>> no more exist ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any other considerations that are not yet covered? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2013/8/6 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I like the idea of having less custom issues >>>>>>>>>>>>>>>> I believe TZ field in all our objects can easily be just >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a >>>>>>> >>>>>>>> string >>>>>>>>>> >>>>>>>>>>> like: >>>>>>>>>>>>> >>>>>>>>>>>>>> "Europe/Berlin" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 3:36 PM, Maxim Solodovnik < >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> solomax...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> I have: It is impossible to get User timezone (you only >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> can >>>>>>>> >>>>>>>>> get >>>>>>>>>> >>>>>>>>>>> tz >>>>>>>>>>> >>>>>>>>>>>> shift >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and/or dst shift and if dst is in effect) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> According to iCal4J time zone mapping I guess the name >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> should >>>>>>>>> >>>>>>>>>> be >>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>>> same >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Aug 6, 2013 at 3:17 PM, seba.wag...@gmail.com< >>>>>>>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Okay, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> after a bit of back and forth using the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wicket-jquery-ui >>>>>>> >>>>>>>> library >>>>>>>>>>> >>>>>>>>>>>> I >>>>>>>>>>>>> >>>>>>>>>>>>>> think >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>> might be worth re-evaluating our timezone behaviour. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Basically it seems like the approach to show the UI >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> in a >>>>>>> >>>>>>>> timezone >>>>>>>>>>> >>>>>>>>>>>> different >>>>>>>>>>>>>>>>>> from the users browser/os is a non common approach. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And >>>>>>> >>>>>>>> eventually >>>>>>>>>>>>> >>>>>>>>>>>>>> we >>>>>>>>>>>>>> >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> directly migrate away from it. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So the proposal would be: >>>>>>>>>>>>>>>>>> Show the calendar UI and any timezone relevant >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> information >>>>>>>> >>>>>>>>> in >>>>>>>>> >>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>>> browser's >>>>>>>>>>>>>>>>>> timezone. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To resolve the issues in the invitations I would >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> suggest >>>>>>> >>>>>>>> the >>>>>>>>> >>>>>>>>>> following >>>>>>>>>>>>>> >>>>>>>>>>>>>>> changes: >>>>>>>>>>>>>>>>>> - When the user signs up the timezone is no more >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> editable/not >>>>>>>>>> >>>>>>>>>>> even >>>>>>>>>>>>> >>>>>>>>>>>>>> shown >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> maybe or read only and taken from the browser/client >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> os >>>>>>> >>>>>>>> - Everytime the user logs in the timezone field in >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the >>>>>>> >>>>>>>> users >>>>>>>>> >>>>>>>>>> profile >>>>>>>>>>>>>> >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> updated with the current timezone of the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> browser/client >>>>>>> >>>>>>>> os. >>>>>>>> >>>>>>>>> The idea might be that we add a new entry in the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> table >>>>>>> >>>>>>>> OmTimeZone >>>>>>>>>>>>> >>>>>>>>>>>>>> whenever >>>>>>>>>>>>>>>>>> we detect any user with a new timezone. >>>>>>>>>>>>>>>>>> - Login view the Flash application will no more be >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> possible. >>>>>>>>> >>>>>>>>>> The >>>>>>>>>>> >>>>>>>>>>>> Openlaszlo application will only be used for the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> conference >>>>>>>> >>>>>>>>> room >>>>>>>>>>> >>>>>>>>>>>> itself >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> By doing that it should basically all just work fine. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But now comes the elefant :) We need a mapping between >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> iCal4J >>>>>>>>> >>>>>>>>>> timezones >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> java.util.Timezone. >>>>>>>>>>>>>>>>>> iCal4J is using net.fortuna.ical4j.model.**TimeZone and >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> we >>>>>>> >>>>>>>> only >>>>>>>>> >>>>>>>>>> have >>>>>>>>>>>>> >>>>>>>>>>>>>> java.util.TimeZones. This is the historical reason why >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the >>>>>>>> >>>>>>>>> code >>>>>>>>>> >>>>>>>>>>> is a >>>>>>>>>>>>> >>>>>>>>>>>>>> little >>>>>>>>>>>>>>>>>> bit messed up with various timezone calculations and >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> fallbacks. >>>>>>>>>> >>>>>>>>>>> So it will be a major refactoring that should be >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> planned >>>>>>> >>>>>>>> and >>>>>>>>> >>>>>>>>>> broken >>>>>>>>>>>>> >>>>>>>>>>>>>> down >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> several phases. >>>>>>>>>>>>>>>>>> We will change and touch all and any kind of >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> functionality >>>>>>>> >>>>>>>>> in >>>>>>>>> >>>>>>>>>> OpenMeetings. >>>>>>>>>>>>>>>>>> It will require quite a bit of regression testing to >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> check >>>>>>>> >>>>>>>>> if >>>>>>>>> >>>>>>>>>> nothing >>>>>>>>>>>>>> >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> broken. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We generall said refactorings like this are not part >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> of >>>>>>> >>>>>>>> OpenMeetings >>>>>>>>>>>>> >>>>>>>>>>>>>> 3.0. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> And once we start this there is no way back. It will >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> delay >>>>>>>> >>>>>>>>> any >>>>>>>>>> >>>>>>>>>>> potential >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> release by 1 - 2 months. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What is the general opinion about this ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> WBR >>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> WBR >>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> WBR >>>>>>>>>>> Maxim aka solomax >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Sebastian Wagner >>>>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>>>> http://www.webbase-design.de >>>>>>>>>> http://www.wagner-sebastian.**com<http://www.wagner-sebastian.com> >>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> WBR >>>>>>>>> Maxim aka solomax >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sebastian Wagner >>>>>>>> https://twitter.com/#!/dead_**lock<https://twitter.com/#!/dead_lock> >>>>>>>> http://www.webbase-design.de >>>>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com> >>>>>>>> seba.wag...@gmail.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> WBR >>>>>>> Maxim aka solomax >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Sebastian Wagner >>>>>> https://twitter.com/#!/dead_**lock <https://twitter.com/#!/dead_lock> >>>>>> http://www.webbase-design.de >>>>>> http://www.wagner-sebastian.**com <http://www.wagner-sebastian.com> >>>>>> seba.wag...@gmail.com >>>>>> >>>>>> >>>>> >>>>> >>>> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> seba.wag...@gmail.com >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
