You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2013/03/18 06:28:42 UTC
should we branch v2.1 ?
Hi Maxim,
I wonder if the release does lock you from committing improvements to
trunk. For example the red5 update that you mentioned to be already
somewhere in your pipe.
Do you think it makes sense to create a branch for the 2.1 release?
So that you can commit changes to trunk (that would not got into the 2.1
branch anyway)
I guess any kind of fixes that will be committed to branch 2.1 might be
minor enhancements or security / bug fixes anyway. But I guess the process
will take several days. And creating a TAG in the SVN for the Vote does not
mean that trunk is available to commit new things again. Actually you would
need to wait until there is really a release approved and done.
So by optimistic estimation might be next week, pessimistic estimation
might be 2-3 weeks.
Sebastian
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: should we branch v2.1 ?
Posted by Irina Arkhipets <ir...@gmail.com>.
Maxim,
OK, let's not change the import/export process.
Please note that exported/imported fields of the type string have NULL
values, not "null" string.
So, possible decision could be:
- Do not show "null" string in the text fields in the User details screen
if these fields are actially contain NULL values - leave null fields blank
instead (as it's done for the empty strings, i.e. for "")
- Do not show "Duplicated email" error message for such "problem" records
after the attempt to save the changes. I.e. allow have several records with
NULL value in the email field. For now it works for blank email fields, but
not for those which are NULL.
It seems like in such case fields exported from the old backups will not
cause problems.
Best regards,
Irina.
On Mon, Mar 18, 2013 at 11:51 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> And how this will affect old backups? (already contain "null" strings in
> xml files)?
>
> Also I'm afraid
> "Export both empty and null strings in the text fields as empty strings" is
> not a good idea since it will affect all code and will have unpredictable
> side effects.
>
> The only thing can be fixed is importing old backups (this my original
> question was about)
>
>
> On Mon, Mar 18, 2013 at 11:37 PM, Irina Arkhipets <
> irina.arkhipets@gmail.com
> > wrote:
>
> > Maxim,
> >
> > I don't know the history of the changes for import/export in all the
> > details.
> >
> > For now I've investigated the database on demo.dataved.ru and it seems
> > that:
> >
> > - There are several records in the address table where email field is a
> > null string. Saving any update for such records causes "Duplicated
> e-mail"
> > error. Such null strings are shown as "null" text in the e-mail database
> > - There is one record with the string "null" in email field in the
> address
> > table. It is also shown as "null" in the user screen.
> >
> > When I add a new user and do not fill in email text field, email field is
> > filled with the empty (not null!) string in the database and it is empty
> in
> > the user settings screen.
> > Having several users with the empty emails do not cause "Duplicated
> email"
> > error during the user settings update.
> >
> > The same is true for other text fields, for example, phone, name, etc.
> >
> > So my suggestion is:
> >
> > - Export both empty and null strings in the text fields as empty strings
> > - Leave all as is for the user settings changes, i.e. for new users save
> > text fields as empty (not null) if the fields were not clearly filled
> with
> > some values
> >
> > Best regards,
> > Irina.
> >
> > On Mon, Mar 18, 2013 at 7:23 PM, Maxim Solodovnik <solomax666@gmail.com
> > >wrote:
> >
> > > Hello Irina,
> > >
> > > What do you think is the best way to handle it:
> > > 1) replace all String fields which value is "null" with null object
> > > 2) process only user emails so "null" email will be null object?
> > >
> > >
> > >
> > > On Mon, Mar 18, 2013 at 5:59 PM, Irina Arkhipets
> > > <ir...@gmail.com>wrote:
> > >
> > > > Hi All,
> > > >
> > > > I believe that
> > https://issues.apache.org/jira/browse/OPENMEETINGS-572is a
> > > > blocker for the release.
> > > >
> > > > The following problem appears here as a side effect of this issue:
> > > >
> > > > If user had an empty e-mail, after the import-export his e-mail is
> > shown
> > > as
> > > > 'null'.
> > > > Now if some user data has been changed in the user parameters screen,
> > > it's
> > > > impossible to save the changes - "Duplicated e-mail" error always
> > appears
> > > > in this case. This happens if there several users with such _null_
> > e-mail
> > > > address in the database.
> > > > At the same time, all is OK for the just created user. His e-mail is
> > > shown
> > > > as an empty string, and even if there are several such users, making
> > > update
> > > > is OK for him.
> > > >
> > > > Best regards,
> > > > Irina.
> > > >
> > > > On Mon, Mar 18, 2013 at 12:32 PM, Maxim Solodovnik <
> > solomax666@gmail.com
> > > > >wrote:
> > > >
> > > > > Hello Sebastian,
> > > > > I was hoping we can release today/tomorrow?
> > > > > Maybe we can name our current blockers? (currently there is no
> > > unresolved
> > > > > issues for 2.1)
> > > > >
> > > > > Separate branch means additional build target, double commits, etc.
> > > > > I would release in nearest couple of days with no additional branch
> > > > >
> > > > > what do you think?
> > > > >
> > > > >
> > > > > On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
> > > > > seba.wagner@gmail.com> wrote:
> > > > >
> > > > > > Hi Maxim,
> > > > > >
> > > > > > I wonder if the release does lock you from committing
> improvements
> > to
> > > > > > trunk. For example the red5 update that you mentioned to be
> already
> > > > > > somewhere in your pipe.
> > > > > >
> > > > > > Do you think it makes sense to create a branch for the 2.1
> release?
> > > > > > So that you can commit changes to trunk (that would not got into
> > the
> > > > 2.1
> > > > > > branch anyway)
> > > > > > I guess any kind of fixes that will be committed to branch 2.1
> > might
> > > > be
> > > > > > minor enhancements or security / bug fixes anyway. But I guess
> the
> > > > > process
> > > > > > will take several days. And creating a TAG in the SVN for the
> Vote
> > > does
> > > > > not
> > > > > > mean that trunk is available to commit new things again. Actually
> > you
> > > > > would
> > > > > > need to wait until there is really a release approved and done.
> > > > > > So by optimistic estimation might be next week, pessimistic
> > > estimation
> > > > > > might be 2-3 weeks.
> > > > > >
> > > > > > Sebastian
> > > > > >
> > > > > > --
> > > > > > Sebastian Wagner
> > > > > > https://twitter.com/#!/dead_lock
> > > > > > http://www.webbase-design.de
> > > > > > http://www.wagner-sebastian.com
> > > > > > seba.wagner@gmail.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > WBR
> > > > > Maxim aka solomax
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: should we branch v2.1 ?
Posted by Maxim Solodovnik <so...@gmail.com>.
And how this will affect old backups? (already contain "null" strings in
xml files)?
Also I'm afraid
"Export both empty and null strings in the text fields as empty strings" is
not a good idea since it will affect all code and will have unpredictable
side effects.
The only thing can be fixed is importing old backups (this my original
question was about)
On Mon, Mar 18, 2013 at 11:37 PM, Irina Arkhipets <irina.arkhipets@gmail.com
> wrote:
> Maxim,
>
> I don't know the history of the changes for import/export in all the
> details.
>
> For now I've investigated the database on demo.dataved.ru and it seems
> that:
>
> - There are several records in the address table where email field is a
> null string. Saving any update for such records causes "Duplicated e-mail"
> error. Such null strings are shown as "null" text in the e-mail database
> - There is one record with the string "null" in email field in the address
> table. It is also shown as "null" in the user screen.
>
> When I add a new user and do not fill in email text field, email field is
> filled with the empty (not null!) string in the database and it is empty in
> the user settings screen.
> Having several users with the empty emails do not cause "Duplicated email"
> error during the user settings update.
>
> The same is true for other text fields, for example, phone, name, etc.
>
> So my suggestion is:
>
> - Export both empty and null strings in the text fields as empty strings
> - Leave all as is for the user settings changes, i.e. for new users save
> text fields as empty (not null) if the fields were not clearly filled with
> some values
>
> Best regards,
> Irina.
>
> On Mon, Mar 18, 2013 at 7:23 PM, Maxim Solodovnik <solomax666@gmail.com
> >wrote:
>
> > Hello Irina,
> >
> > What do you think is the best way to handle it:
> > 1) replace all String fields which value is "null" with null object
> > 2) process only user emails so "null" email will be null object?
> >
> >
> >
> > On Mon, Mar 18, 2013 at 5:59 PM, Irina Arkhipets
> > <ir...@gmail.com>wrote:
> >
> > > Hi All,
> > >
> > > I believe that
> https://issues.apache.org/jira/browse/OPENMEETINGS-572is a
> > > blocker for the release.
> > >
> > > The following problem appears here as a side effect of this issue:
> > >
> > > If user had an empty e-mail, after the import-export his e-mail is
> shown
> > as
> > > 'null'.
> > > Now if some user data has been changed in the user parameters screen,
> > it's
> > > impossible to save the changes - "Duplicated e-mail" error always
> appears
> > > in this case. This happens if there several users with such _null_
> e-mail
> > > address in the database.
> > > At the same time, all is OK for the just created user. His e-mail is
> > shown
> > > as an empty string, and even if there are several such users, making
> > update
> > > is OK for him.
> > >
> > > Best regards,
> > > Irina.
> > >
> > > On Mon, Mar 18, 2013 at 12:32 PM, Maxim Solodovnik <
> solomax666@gmail.com
> > > >wrote:
> > >
> > > > Hello Sebastian,
> > > > I was hoping we can release today/tomorrow?
> > > > Maybe we can name our current blockers? (currently there is no
> > unresolved
> > > > issues for 2.1)
> > > >
> > > > Separate branch means additional build target, double commits, etc.
> > > > I would release in nearest couple of days with no additional branch
> > > >
> > > > what do you think?
> > > >
> > > >
> > > > On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
> > > > seba.wagner@gmail.com> wrote:
> > > >
> > > > > Hi Maxim,
> > > > >
> > > > > I wonder if the release does lock you from committing improvements
> to
> > > > > trunk. For example the red5 update that you mentioned to be already
> > > > > somewhere in your pipe.
> > > > >
> > > > > Do you think it makes sense to create a branch for the 2.1 release?
> > > > > So that you can commit changes to trunk (that would not got into
> the
> > > 2.1
> > > > > branch anyway)
> > > > > I guess any kind of fixes that will be committed to branch 2.1
> might
> > > be
> > > > > minor enhancements or security / bug fixes anyway. But I guess the
> > > > process
> > > > > will take several days. And creating a TAG in the SVN for the Vote
> > does
> > > > not
> > > > > mean that trunk is available to commit new things again. Actually
> you
> > > > would
> > > > > need to wait until there is really a release approved and done.
> > > > > So by optimistic estimation might be next week, pessimistic
> > estimation
> > > > > might be 2-3 weeks.
> > > > >
> > > > > Sebastian
> > > > >
> > > > > --
> > > > > Sebastian Wagner
> > > > > https://twitter.com/#!/dead_lock
> > > > > http://www.webbase-design.de
> > > > > http://www.wagner-sebastian.com
> > > > > seba.wagner@gmail.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > > >
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
--
WBR
Maxim aka solomax
Re: should we branch v2.1 ?
Posted by Irina Arkhipets <ir...@gmail.com>.
Maxim,
I don't know the history of the changes for import/export in all the
details.
For now I've investigated the database on demo.dataved.ru and it seems that:
- There are several records in the address table where email field is a
null string. Saving any update for such records causes "Duplicated e-mail"
error. Such null strings are shown as "null" text in the e-mail database
- There is one record with the string "null" in email field in the address
table. It is also shown as "null" in the user screen.
When I add a new user and do not fill in email text field, email field is
filled with the empty (not null!) string in the database and it is empty in
the user settings screen.
Having several users with the empty emails do not cause "Duplicated email"
error during the user settings update.
The same is true for other text fields, for example, phone, name, etc.
So my suggestion is:
- Export both empty and null strings in the text fields as empty strings
- Leave all as is for the user settings changes, i.e. for new users save
text fields as empty (not null) if the fields were not clearly filled with
some values
Best regards,
Irina.
On Mon, Mar 18, 2013 at 7:23 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> Hello Irina,
>
> What do you think is the best way to handle it:
> 1) replace all String fields which value is "null" with null object
> 2) process only user emails so "null" email will be null object?
>
>
>
> On Mon, Mar 18, 2013 at 5:59 PM, Irina Arkhipets
> <ir...@gmail.com>wrote:
>
> > Hi All,
> >
> > I believe that https://issues.apache.org/jira/browse/OPENMEETINGS-572is a
> > blocker for the release.
> >
> > The following problem appears here as a side effect of this issue:
> >
> > If user had an empty e-mail, after the import-export his e-mail is shown
> as
> > 'null'.
> > Now if some user data has been changed in the user parameters screen,
> it's
> > impossible to save the changes - "Duplicated e-mail" error always appears
> > in this case. This happens if there several users with such _null_ e-mail
> > address in the database.
> > At the same time, all is OK for the just created user. His e-mail is
> shown
> > as an empty string, and even if there are several such users, making
> update
> > is OK for him.
> >
> > Best regards,
> > Irina.
> >
> > On Mon, Mar 18, 2013 at 12:32 PM, Maxim Solodovnik <solomax666@gmail.com
> > >wrote:
> >
> > > Hello Sebastian,
> > > I was hoping we can release today/tomorrow?
> > > Maybe we can name our current blockers? (currently there is no
> unresolved
> > > issues for 2.1)
> > >
> > > Separate branch means additional build target, double commits, etc.
> > > I would release in nearest couple of days with no additional branch
> > >
> > > what do you think?
> > >
> > >
> > > On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
> > > seba.wagner@gmail.com> wrote:
> > >
> > > > Hi Maxim,
> > > >
> > > > I wonder if the release does lock you from committing improvements to
> > > > trunk. For example the red5 update that you mentioned to be already
> > > > somewhere in your pipe.
> > > >
> > > > Do you think it makes sense to create a branch for the 2.1 release?
> > > > So that you can commit changes to trunk (that would not got into the
> > 2.1
> > > > branch anyway)
> > > > I guess any kind of fixes that will be committed to branch 2.1 might
> > be
> > > > minor enhancements or security / bug fixes anyway. But I guess the
> > > process
> > > > will take several days. And creating a TAG in the SVN for the Vote
> does
> > > not
> > > > mean that trunk is available to commit new things again. Actually you
> > > would
> > > > need to wait until there is really a release approved and done.
> > > > So by optimistic estimation might be next week, pessimistic
> estimation
> > > > might be 2-3 weeks.
> > > >
> > > > Sebastian
> > > >
> > > > --
> > > > Sebastian Wagner
> > > > https://twitter.com/#!/dead_lock
> > > > http://www.webbase-design.de
> > > > http://www.wagner-sebastian.com
> > > > seba.wagner@gmail.com
> > > >
> > >
> > >
> > >
> > > --
> > > WBR
> > > Maxim aka solomax
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: should we branch v2.1 ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Irina,
What do you think is the best way to handle it:
1) replace all String fields which value is "null" with null object
2) process only user emails so "null" email will be null object?
On Mon, Mar 18, 2013 at 5:59 PM, Irina Arkhipets
<ir...@gmail.com>wrote:
> Hi All,
>
> I believe that https://issues.apache.org/jira/browse/OPENMEETINGS-572 is a
> blocker for the release.
>
> The following problem appears here as a side effect of this issue:
>
> If user had an empty e-mail, after the import-export his e-mail is shown as
> 'null'.
> Now if some user data has been changed in the user parameters screen, it's
> impossible to save the changes - "Duplicated e-mail" error always appears
> in this case. This happens if there several users with such _null_ e-mail
> address in the database.
> At the same time, all is OK for the just created user. His e-mail is shown
> as an empty string, and even if there are several such users, making update
> is OK for him.
>
> Best regards,
> Irina.
>
> On Mon, Mar 18, 2013 at 12:32 PM, Maxim Solodovnik <solomax666@gmail.com
> >wrote:
>
> > Hello Sebastian,
> > I was hoping we can release today/tomorrow?
> > Maybe we can name our current blockers? (currently there is no unresolved
> > issues for 2.1)
> >
> > Separate branch means additional build target, double commits, etc.
> > I would release in nearest couple of days with no additional branch
> >
> > what do you think?
> >
> >
> > On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
> > seba.wagner@gmail.com> wrote:
> >
> > > Hi Maxim,
> > >
> > > I wonder if the release does lock you from committing improvements to
> > > trunk. For example the red5 update that you mentioned to be already
> > > somewhere in your pipe.
> > >
> > > Do you think it makes sense to create a branch for the 2.1 release?
> > > So that you can commit changes to trunk (that would not got into the
> 2.1
> > > branch anyway)
> > > I guess any kind of fixes that will be committed to branch 2.1 might
> be
> > > minor enhancements or security / bug fixes anyway. But I guess the
> > process
> > > will take several days. And creating a TAG in the SVN for the Vote does
> > not
> > > mean that trunk is available to commit new things again. Actually you
> > would
> > > need to wait until there is really a release approved and done.
> > > So by optimistic estimation might be next week, pessimistic estimation
> > > might be 2-3 weeks.
> > >
> > > Sebastian
> > >
> > > --
> > > Sebastian Wagner
> > > https://twitter.com/#!/dead_lock
> > > http://www.webbase-design.de
> > > http://www.wagner-sebastian.com
> > > seba.wagner@gmail.com
> > >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
> >
>
--
WBR
Maxim aka solomax
Re: should we branch v2.1 ?
Posted by Irina Arkhipets <ir...@gmail.com>.
Hi All,
I believe that https://issues.apache.org/jira/browse/OPENMEETINGS-572 is a
blocker for the release.
The following problem appears here as a side effect of this issue:
If user had an empty e-mail, after the import-export his e-mail is shown as
'null'.
Now if some user data has been changed in the user parameters screen, it's
impossible to save the changes - "Duplicated e-mail" error always appears
in this case. This happens if there several users with such _null_ e-mail
address in the database.
At the same time, all is OK for the just created user. His e-mail is shown
as an empty string, and even if there are several such users, making update
is OK for him.
Best regards,
Irina.
On Mon, Mar 18, 2013 at 12:32 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> Hello Sebastian,
> I was hoping we can release today/tomorrow?
> Maybe we can name our current blockers? (currently there is no unresolved
> issues for 2.1)
>
> Separate branch means additional build target, double commits, etc.
> I would release in nearest couple of days with no additional branch
>
> what do you think?
>
>
> On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
> > Hi Maxim,
> >
> > I wonder if the release does lock you from committing improvements to
> > trunk. For example the red5 update that you mentioned to be already
> > somewhere in your pipe.
> >
> > Do you think it makes sense to create a branch for the 2.1 release?
> > So that you can commit changes to trunk (that would not got into the 2.1
> > branch anyway)
> > I guess any kind of fixes that will be committed to branch 2.1 might be
> > minor enhancements or security / bug fixes anyway. But I guess the
> process
> > will take several days. And creating a TAG in the SVN for the Vote does
> not
> > mean that trunk is available to commit new things again. Actually you
> would
> > need to wait until there is really a release approved and done.
> > So by optimistic estimation might be next week, pessimistic estimation
> > might be 2-3 weeks.
> >
> > Sebastian
> >
> > --
> > Sebastian Wagner
> > https://twitter.com/#!/dead_lock
> > http://www.webbase-design.de
> > http://www.wagner-sebastian.com
> > seba.wagner@gmail.com
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: should we branch v2.1 ?
Posted by Maxim Solodovnik <so...@gmail.com>.
done
http://svn.apache.org/repos/asf/openmeetings/branches/2.1/
https://builds.apache.org/view/M-R/view/OpenMeetings/job/Openmeetings%202.1/
On Mon, Mar 18, 2013 at 1:10 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> That would be great!
> And if you need to branch, just do it.
>
> Thanks,
> Sebastian
> Am 18.03.2013 19:03 schrieb "Maxim Solodovnik" <so...@gmail.com>:
>
> You are right :(
>> I'll create the branch and set up the build.
>>
>> according to the logs demo is up for 10 hours so far (it is being used in
>> testing SIP so it is reloaded from time to time)
>> I'll ask others if we can deploy the next RC to it for the tests.
>>
>>
>> On Mon, Mar 18, 2013 at 12:47 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Even if you start the vote by today it takes 72 hours to vote.
>>> And even if that vote passes it will take another day to release.
>>> So the earliest day when its safe to commit new things to trunk will be
>>> Friday or Saturday.
>>>
>>> And I still think it would be worth doing some more tests.
>>> I have not been able to really test everything that I would like to test.
>>> I did not test yet:
>>> - backup feature / changes
>>> - Mail queue on a server that has some valid mail settings
>>> - Some basic server load, verification that the app runs stable for a
>>> while
>>>
>>> The last point could be possible verified by the demo server at dataved.
>>> Is there a report on that at dataved?
>>>
>>> The other things are also relatively new, but potential issues could be
>>> resolved by doing a 2.1.1 release. But basically the new device settings
>>> have been tested by only 3 users so far: Me, you, marius. And thats it.
>>>
>>> Can't we at least do the following:
>>> Set up exactly the potential RC somewhere and really ask everyone on the
>>> mailing list to test it before we start a new vote ?
>>> It would be really useful and a chance to get some more activity around
>>> our project.
>>>
>>> Sebastian
>>>
>>>
>>>
>>> 2013/3/18 Maxim Solodovnik <so...@gmail.com>
>>>
>>>> Hello Sebastian,
>>>> I was hoping we can release today/tomorrow?
>>>> Maybe we can name our current blockers? (currently there is no
>>>> unresolved issues for 2.1)
>>>>
>>>> Separate branch means additional build target, double commits, etc.
>>>> I would release in nearest couple of days with no additional branch
>>>>
>>>> what do you think?
>>>>
>>>>
>>>> On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
>>>> seba.wagner@gmail.com> wrote:
>>>>
>>>>> Hi Maxim,
>>>>>
>>>>> I wonder if the release does lock you from committing improvements to
>>>>> trunk. For example the red5 update that you mentioned to be already
>>>>> somewhere in your pipe.
>>>>>
>>>>> Do you think it makes sense to create a branch for the 2.1 release?
>>>>> So that you can commit changes to trunk (that would not got into the
>>>>> 2.1 branch anyway)
>>>>> I guess any kind of fixes that will be committed to branch 2.1 might
>>>>> be minor enhancements or security / bug fixes anyway. But I guess the
>>>>> process will take several days. And creating a TAG in the SVN for the Vote
>>>>> does not mean that trunk is available to commit new things again. Actually
>>>>> you would need to wait until there is really a release approved and done.
>>>>> So by optimistic estimation might be next week, pessimistic estimation
>>>>> might be 2-3 weeks.
>>>>>
>>>>> Sebastian
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
--
WBR
Maxim aka solomax
Re: should we branch v2.1 ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
That would be great!
And if you need to branch, just do it.
Thanks,
Sebastian
Am 18.03.2013 19:03 schrieb "Maxim Solodovnik" <so...@gmail.com>:
> You are right :(
> I'll create the branch and set up the build.
>
> according to the logs demo is up for 10 hours so far (it is being used in
> testing SIP so it is reloaded from time to time)
> I'll ask others if we can deploy the next RC to it for the tests.
>
>
> On Mon, Mar 18, 2013 at 12:47 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> Even if you start the vote by today it takes 72 hours to vote.
>> And even if that vote passes it will take another day to release.
>> So the earliest day when its safe to commit new things to trunk will be
>> Friday or Saturday.
>>
>> And I still think it would be worth doing some more tests.
>> I have not been able to really test everything that I would like to test.
>> I did not test yet:
>> - backup feature / changes
>> - Mail queue on a server that has some valid mail settings
>> - Some basic server load, verification that the app runs stable for a
>> while
>>
>> The last point could be possible verified by the demo server at dataved.
>> Is there a report on that at dataved?
>>
>> The other things are also relatively new, but potential issues could be
>> resolved by doing a 2.1.1 release. But basically the new device settings
>> have been tested by only 3 users so far: Me, you, marius. And thats it.
>>
>> Can't we at least do the following:
>> Set up exactly the potential RC somewhere and really ask everyone on the
>> mailing list to test it before we start a new vote ?
>> It would be really useful and a chance to get some more activity around
>> our project.
>>
>> Sebastian
>>
>>
>>
>> 2013/3/18 Maxim Solodovnik <so...@gmail.com>
>>
>>> Hello Sebastian,
>>> I was hoping we can release today/tomorrow?
>>> Maybe we can name our current blockers? (currently there is no
>>> unresolved issues for 2.1)
>>>
>>> Separate branch means additional build target, double commits, etc.
>>> I would release in nearest couple of days with no additional branch
>>>
>>> what do you think?
>>>
>>>
>>> On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
>>> seba.wagner@gmail.com> wrote:
>>>
>>>> Hi Maxim,
>>>>
>>>> I wonder if the release does lock you from committing improvements to
>>>> trunk. For example the red5 update that you mentioned to be already
>>>> somewhere in your pipe.
>>>>
>>>> Do you think it makes sense to create a branch for the 2.1 release?
>>>> So that you can commit changes to trunk (that would not got into the
>>>> 2.1 branch anyway)
>>>> I guess any kind of fixes that will be committed to branch 2.1 might
>>>> be minor enhancements or security / bug fixes anyway. But I guess the
>>>> process will take several days. And creating a TAG in the SVN for the Vote
>>>> does not mean that trunk is available to commit new things again. Actually
>>>> you would need to wait until there is really a release approved and done.
>>>> So by optimistic estimation might be next week, pessimistic estimation
>>>> might be 2-3 weeks.
>>>>
>>>> Sebastian
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: should we branch v2.1 ?
Posted by Maxim Solodovnik <so...@gmail.com>.
You are right :(
I'll create the branch and set up the build.
according to the logs demo is up for 10 hours so far (it is being used in
testing SIP so it is reloaded from time to time)
I'll ask others if we can deploy the next RC to it for the tests.
On Mon, Mar 18, 2013 at 12:47 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> Even if you start the vote by today it takes 72 hours to vote.
> And even if that vote passes it will take another day to release.
> So the earliest day when its safe to commit new things to trunk will be
> Friday or Saturday.
>
> And I still think it would be worth doing some more tests.
> I have not been able to really test everything that I would like to test.
> I did not test yet:
> - backup feature / changes
> - Mail queue on a server that has some valid mail settings
> - Some basic server load, verification that the app runs stable for a
> while
>
> The last point could be possible verified by the demo server at dataved.
> Is there a report on that at dataved?
>
> The other things are also relatively new, but potential issues could be
> resolved by doing a 2.1.1 release. But basically the new device settings
> have been tested by only 3 users so far: Me, you, marius. And thats it.
>
> Can't we at least do the following:
> Set up exactly the potential RC somewhere and really ask everyone on the
> mailing list to test it before we start a new vote ?
> It would be really useful and a chance to get some more activity around
> our project.
>
> Sebastian
>
>
>
> 2013/3/18 Maxim Solodovnik <so...@gmail.com>
>
>> Hello Sebastian,
>> I was hoping we can release today/tomorrow?
>> Maybe we can name our current blockers? (currently there is no unresolved
>> issues for 2.1)
>>
>> Separate branch means additional build target, double commits, etc.
>> I would release in nearest couple of days with no additional branch
>>
>> what do you think?
>>
>>
>> On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Hi Maxim,
>>>
>>> I wonder if the release does lock you from committing improvements to
>>> trunk. For example the red5 update that you mentioned to be already
>>> somewhere in your pipe.
>>>
>>> Do you think it makes sense to create a branch for the 2.1 release?
>>> So that you can commit changes to trunk (that would not got into the 2.1
>>> branch anyway)
>>> I guess any kind of fixes that will be committed to branch 2.1 might be
>>> minor enhancements or security / bug fixes anyway. But I guess the process
>>> will take several days. And creating a TAG in the SVN for the Vote does not
>>> mean that trunk is available to commit new things again. Actually you would
>>> need to wait until there is really a release approved and done.
>>> So by optimistic estimation might be next week, pessimistic estimation
>>> might be 2-3 weeks.
>>>
>>> Sebastian
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: should we branch v2.1 ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Even if you start the vote by today it takes 72 hours to vote.
And even if that vote passes it will take another day to release.
So the earliest day when its safe to commit new things to trunk will be
Friday or Saturday.
And I still think it would be worth doing some more tests.
I have not been able to really test everything that I would like to test.
I did not test yet:
- backup feature / changes
- Mail queue on a server that has some valid mail settings
- Some basic server load, verification that the app runs stable for a while
The last point could be possible verified by the demo server at dataved. Is
there a report on that at dataved?
The other things are also relatively new, but potential issues could be
resolved by doing a 2.1.1 release. But basically the new device settings
have been tested by only 3 users so far: Me, you, marius. And thats it.
Can't we at least do the following:
Set up exactly the potential RC somewhere and really ask everyone on the
mailing list to test it before we start a new vote ?
It would be really useful and a chance to get some more activity around our
project.
Sebastian
2013/3/18 Maxim Solodovnik <so...@gmail.com>
> Hello Sebastian,
> I was hoping we can release today/tomorrow?
> Maybe we can name our current blockers? (currently there is no unresolved
> issues for 2.1)
>
> Separate branch means additional build target, double commits, etc.
> I would release in nearest couple of days with no additional branch
>
> what do you think?
>
>
> On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> Hi Maxim,
>>
>> I wonder if the release does lock you from committing improvements to
>> trunk. For example the red5 update that you mentioned to be already
>> somewhere in your pipe.
>>
>> Do you think it makes sense to create a branch for the 2.1 release?
>> So that you can commit changes to trunk (that would not got into the 2.1
>> branch anyway)
>> I guess any kind of fixes that will be committed to branch 2.1 might be
>> minor enhancements or security / bug fixes anyway. But I guess the process
>> will take several days. And creating a TAG in the SVN for the Vote does not
>> mean that trunk is available to commit new things again. Actually you would
>> need to wait until there is really a release approved and done.
>> So by optimistic estimation might be next week, pessimistic estimation
>> might be 2-3 weeks.
>>
>> Sebastian
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: should we branch v2.1 ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sebastian,
I was hoping we can release today/tomorrow?
Maybe we can name our current blockers? (currently there is no unresolved
issues for 2.1)
Separate branch means additional build target, double commits, etc.
I would release in nearest couple of days with no additional branch
what do you think?
On Mon, Mar 18, 2013 at 12:28 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> Hi Maxim,
>
> I wonder if the release does lock you from committing improvements to
> trunk. For example the red5 update that you mentioned to be already
> somewhere in your pipe.
>
> Do you think it makes sense to create a branch for the 2.1 release?
> So that you can commit changes to trunk (that would not got into the 2.1
> branch anyway)
> I guess any kind of fixes that will be committed to branch 2.1 might be
> minor enhancements or security / bug fixes anyway. But I guess the process
> will take several days. And creating a TAG in the SVN for the Vote does not
> mean that trunk is available to commit new things again. Actually you would
> need to wait until there is really a release approved and done.
> So by optimistic estimation might be next week, pessimistic estimation
> might be 2-3 weeks.
>
> Sebastian
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax