Re: [LyX/2.3-staging] Make inset-select-all select all cells only in tables

[Guillaume Munch]

Le 18/04/2016 14:59, Jean-Marc Lasgouttes a écrit :

--- a/src/insets/Inset.h
+++ b/src/insets/Inset.h
@@ -347,6 +347,8 @@ public:
virtual bool clickable(BufferView const &, int, int) const { return 
false; }
/// Move one cell backwards
virtual bool allowsCaptionVariation(std::string const &) const { return 
false; }
+   // true for insets that have a table structure (InsetMathGrid, 
InsetTabular)
+   virtual bool isTable() const { return false; }

/// does this contain text that can be change track marked in DVI?
virtual bool canTrackChanges() const { return false; }



This turns InsetMathHull::isTable() into a redefinition of Inset::isTable().

* Is it intended that InsetMathGrid::isTable() gets overridden by
InsetMathHull::isTable()? This seems to make sense to me but I would be
reassured to know that this is intentional.

* Is it intended that InsetMathHull::isTable() itself can now be 
overridden, possibly changing the meaning of existing code? Again I 
believe that the change makes sense and does not break the existing use 
of isTable().


If not intended, this sort of situation could be avoided by enforcing 
the use of the override keyword (c++11) using -Wsuggest-override (gcc5).



Guillaume

Re: Staging Branches [REVISED]

[Pavel Sanda]

Peter Kümmel wrote:
> I also think these branches are overkill.

+1

Pavel

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/18/2016 05:07 PM, Vincent van Ravesteijn wrote:
>
>
> >
> > We should already be on 2.2 and not on master, which is the future: 2.3
> >
>
> Yes, that was also my proposal.
>
> However, people appear to be afraid to not have the 2.2.0 tag in master.
>
> But note that if the 2.2-branch in this scenario is merged back into
> master after the release, it is equivalent to merging 2.3-staging to
> master in the current proposal. In both ways the tag ends up in
> master, and there is not a real difference between merging A into B
> anhd  merging B into A.
>

2.2.x-staging won't get merged into master, only into 2.2.x.

> 2.2.1-staging is not necessary as all changes are so important that
> they can probably go to 2.2.0 as well.
>

There are already commits to 2.2.1-staging. Nothing goes to master
(=2.2.0) now except what is absolutely critical.

> Changes for 2.2.2 can be cherry-picked from 2.3-staging (or master)
> when 2.1.1 is released.
>

Yes, it would be possible to do it this way. It is more confusing for
me, though, and I worry that some important commit would be missed.

rh

Re: [RFC] Staging Branches and Trac

[Richard Heck]

On 04/18/2016 05:19 PM, Vincent van Ravesteijn wrote:
>
>
> Op 16 apr. 2016 21:50 schreef "Richard Heck"  >:
> >
> >
> > As Scott pointed out, my previous suggestions for how fixes committed to
> > the staging branches should be handled in trac was silly. We can't reuse
> > "fixedinmaster" for 2.3-staging. I'm also not sure that we want to
> > introduce a new status "fixedinstaging" for such a short time.
> >
>
> First of all, 2.3-staging should be master, and current master should
> be 2.2.x. (see another thread)
>

Yes, I know this is your view, and some people share it, but it's not
what we decided to do. Perhaps we should decide to do it next time. I
may well, for myself, decide to do something similar with 2.2.x, but I
need to think about it.

> Besides that, what is wrong with a keyword fixedinmaster and a
> milestone 2.3 for things in 2.3-staging ? It looks perfectly fine to
> me: the bug will be fixed in 2.3, but is not fixed for 2.2.x.
>

Something like this would work, I'm sure, but more keywords seem to sow
more confusion.

Richard

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/18/2016 05:02 PM, Peter Kümmel wrote:
> Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck :
>> On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
>> :
 I also think these branches are overkill.

 I would only use master and 2.2. No 2.3, it is so far away that it
>> could be in master. 
 2.2 should be always stable so that at any time a short living 2.2.x
>> could be branched until the release is done. After the tag 2.2.x will
>> be deleted then.
 Similar to 
 https://wiki.qt.io/Branch_Guidelines

 Peter
>>> We should already be on 2.2 and not on master, which is the future:
>> 2.3 
>>
>> We discussed this sort of option: Branch 2.2.x now and continue
>> development towards 2.2.0 there. Then development targeted at 2.3 can
>> continue in master. But most people didn't like this option. Most
>> importantly, Scott didn't like it, or didn't feel comfortable with it,
>> and it's his call.
>>
>> So master is still what will become 2.2.0, and it is closed except for
>> absolutely essential fixes. But people wanted to be able to continue
>> development, so that's why we have 2.3-staging.
>>
>> The other two 2.2.x-staging branches are entirely for book-keeping
>> purposes. It is just easier for me to have the various fixes that are
>> intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>> track of them via milestones or keywords or whatever in trac. It's also
>> easier for people to backport these fixes around the same time they did
>> them than to do it weeks or months later.
>>
>> We're not really "think[ing] about four stable releases in parallel", and 
>> certainly I do not expect that the staging branches are going to get any 
>> kind of testing. Once 2.2.x is created, it will get testing, and at that 
>> point 2.2.1-staging will be merged into it, and then will politely 
>> disappear. Same, eventually, for 2.2.2-staging.
>>
>> Richard
> But why are there fixes which should go only into 2.2.2 and not into an 
> unreleased 2.2.1? 

Because the plan (discussed in another thread) is currently to reserve
2.2.1, for the time being, only for serious bugs that emerge shortly
after release, if any do. I.e., 2.2.1 may be released very shortly after
2.2.0, and too soon for anything to get much testing. There are bugs for
which we now have fixes that aren't appropriate for 2.2.1, under that
plan, but will go into 2.2.x eventually, i.e., into 2.2.2. If things go
better than expected, and we don't need to do a "quick" release of
2.2.1, then we can merge 2.2.2-staging into 2.2.x as well and release
all that as 2.2.1.

Richard

Re: [RFC] Staging Branches and Trac

[Vincent van Ravesteijn]

Op 16 apr. 2016 21:50 schreef "Richard Heck" :
>
>
> As Scott pointed out, my previous suggestions for how fixes committed to
> the staging branches should be handled in trac was silly. We can't reuse
> "fixedinmaster" for 2.3-staging. I'm also not sure that we want to
> introduce a new status "fixedinstaging" for such a short time.
>

First of all, 2.3-staging should be master, and current master should be
2.2.x. (see another thread)

Besides that, what is wrong with a keyword fixedinmaster and a milestone
2.3 for things in 2.3-staging ? It looks perfectly fine to me: the bug will
be fixed in 2.3, but is not fixed for 2.2.x.

Vincent

Re: Staging Branches [REVISED]

[Vincent van Ravesteijn]

>
> We should already be on 2.2 and not on master, which is the future: 2.3
>

Yes, that was also my proposal.

However, people appear to be afraid to not have the 2.2.0 tag in master.

But note that if the 2.2-branch in this scenario is merged back into master
after the release, it is equivalent to merging 2.3-staging to master in the
current proposal. In both ways the tag ends up in master, and there is not
a real difference between merging A into B anhd  merging B into A.

2.2.1-staging is not necessary as all changes are so important that they
can probably go to 2.2.0 as well. Changes for 2.2.2 can be cherry-picked
from 2.3-staging (or master) when 2.1.1 is released.

Vincent

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:56:06 MESZ, schrieb Richard Heck :
>On 04/18/2016 04:32 PM, Peter Kümmel wrote:
>> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel"
>:
>>> I also think these branches are overkill.
>>>
>>> I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>>>
>>> 2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>>>
>>> Similar to 
>>> https://wiki.qt.io/Branch_Guidelines
>>>
>>> Peter
>> We should already be on 2.2 and not on master, which is the future:
>2.3 
>
>We discussed this sort of option: Branch 2.2.x now and continue
>development towards 2.2.0 there. Then development targeted at 2.3 can
>continue in master. But most people didn't like this option. Most
>importantly, Scott didn't like it, or didn't feel comfortable with it,
>and it's his call.
>
>So master is still what will become 2.2.0, and it is closed except for
>absolutely essential fixes. But people wanted to be able to continue
>development, so that's why we have 2.3-staging.
>
>The other two 2.2.x-staging branches are entirely for book-keeping
>purposes. It is just easier for me to have the various fixes that are
>intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
>track of them via milestones or keywords or whatever in trac. It's also
>easier for people to backport these fixes around the same time they did
>them than to do it weeks or months later.
>
>We're not really "think[ing] about four stable releases in parallel",
>and certainly I do not expect that the staging branches are going to
>get
>any kind of testing. Once 2.2.x is created, it will get testing, and at
>that point 2.2.1-staging will be merged into it, and then will politely
>disappear. Same, eventually, for 2.2.2-staging.
>
>Richard

But why are there fixes which should go only into 2.2.2 and not into an 
unreleased 2.2.1? 
Peter

Re: Staging Branches [REVISED]

[Richard Heck]

On 04/18/2016 04:32 PM, Peter Kümmel wrote:
> Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>> I also think these branches are overkill.
>>
>> I would only use master and 2.2. No 2.3, it is so far away that it could be 
>> in master. 
>>
>> 2.2 should be always stable so that at any time a short living 2.2.x could 
>> be branched until the release is done. After the tag 2.2.x will be deleted 
>> then.
>>
>> Similar to 
>> https://wiki.qt.io/Branch_Guidelines
>>
>> Peter
> We should already be on 2.2 and not on master, which is the future: 2.3 

We discussed this sort of option: Branch 2.2.x now and continue
development towards 2.2.0 there. Then development targeted at 2.3 can
continue in master. But most people didn't like this option. Most
importantly, Scott didn't like it, or didn't feel comfortable with it,
and it's his call.

So master is still what will become 2.2.0, and it is closed except for
absolutely essential fixes. But people wanted to be able to continue
development, so that's why we have 2.3-staging.

The other two 2.2.x-staging branches are entirely for book-keeping
purposes. It is just easier for me to have the various fixes that are
intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep
track of them via milestones or keywords or whatever in trac. It's also
easier for people to backport these fixes around the same time they did
them than to do it weeks or months later.

We're not really "think[ing] about four stable releases in parallel",
and certainly I do not expect that the staging branches are going to get
any kind of testing. Once 2.2.x is created, it will get testing, and at
that point 2.2.1-staging will be merged into it, and then will politely
disappear. Same, eventually, for 2.2.2-staging.

Richard

Re: [LyX/2.3-staging] Change mouse cursor on tabular selection zones

[Richard Heck]

On 04/18/2016 09:06 AM, Jean-Marc Lasgouttes wrote:
> Le 18/04/2016 14:56, Jean-Marc Lasgouttes a écrit :
>> commit 5b7be5eb61d68466f808099ea3524cb2966333f9
>> Author: Jean-Marc Lasgouttes 
>> Date:   Tue Feb 2 17:07:29 2016 +0100
>>
>>  Change mouse cursor on tabular selection zones
>>
>>  This is done by implementing the clickable method. It is not
>> possible yet to have the usual left and down arrows, because Qt does
>> not implement them as far as I can see.
>>
>>  Factor the code that triggers row/column selection and fix the
>> logic. Now it is possible to select also at the right of the tabular
>> inset.
>
> This is candidate for 2.2.2 (it relies on the first patch of ticket
> #9756).

OK.

rh

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>> 
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood 
>>something):
>>
>>2.1.x  => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging  => will become 2.2.1
>>2.2.2-staging  => will become 2.2.2
>>2.3-staging=> will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a 
>>lot of additional book keeping work that eats from our valuable
>>resources. 
>>In addition, there are the trac keyword problems. Currently it is not 
>>possible to map these branches to trac, if we wanted to do that we'd
>>need 
>>three additional keywords for the staging branches. If we do not add
>>these 
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need 
>>manual work to find out from trac whether a particular bug will be
>>fixed 
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for 
>>such a small group of part time developers like us IMHO. We do not
>have
>>the 
>>resources to think about four stable releases in parallel. IMHO we
>>should 
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain 
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out 
>>all these different 2.2 branches, so these fixes won't get additional 
>>testing. In the contrary, I believe that they would get more testing
>if
>>they 
>>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>>for 
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to 
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3 
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that 
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to 
>https://wiki.qt.io/Branch_Guidelines
>
>Peter

We should already be on 2.2 and not on master, which is the future: 2.3 

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 22:29:51 MESZ, schrieb "Peter Kümmel" :
>Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum
>:
>>Richard Heck wrote:
>>
>>> We now have three staging branches. These are:
>>> 
>>> 2.3-staging
>>> 2.2.1-staging
>>> 2.2.2-staging
>>
>>That makes 5 active branches in total (please correct me if I
>>misunderstood 
>>something):
>>
>>2.1.x  => will become 2.1.5
>>master => will become 2.2.0
>>2.2.1-staging  => will become 2.2.1
>>2.2.2-staging  => will become 2.2.2
>>2.3-staging=> will become 2.3.0
>>
>>Am I the only one who thinks that this is too much? IMHO this results
>>in a 
>>lot of additional book keeping work that eats from our valuable
>>resources. 
>>In addition, there are the trac keyword problems. Currently it is not 
>>possible to map these branches to trac, if we wanted to do that we'd
>>need 
>>three additional keywords for the staging branches. If we do not add
>>these 
>>keywords then bugs might be closed for the wrong milestone and/or we
>>need 
>>manual work to find out from trac whether a particular bug will be
>>fixed 
>>e.g. for 2.2.1 or not.
>>
>>Such a structure is good for large organizations. It does not make
>>sense for 
>>such a small group of part time developers like us IMHO. We do not
>have
>>the 
>>resources to think about four stable releases in parallel. IMHO we
>>should 
>>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>>refrain 
>>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>>try out 
>>all these different 2.2 branches, so these fixes won't get additional 
>>testing. In the contrary, I believe that they would get more testing
>if
>>they 
>>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>>for 
>>2.2.2, these plans are likely to become obsolete. We have a simple
>tool
>>to 
>>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>>2.3 
>>branch and set the bug milestones it is easy to get a list of all
>fixes
>>that 
>>need backporting.
>>
>>
>>Georg
>
>I also think these branches are overkill.
>
>I would only use master and 2.2. No 2.3, it is so far away that it
>could be in master. 
>
>2.2 should be always stable so that at any time a short living 2.2.x
>could be branched until the release is done. After the tag 2.2.x will
>be deleted then.
>
>Similar to 
>https://wiki.qt.io/Branch_Guidelines
>
>Peter

We should already be on 2.2 and not on master, which is the future: 2.3 

Re: Staging Branches [REVISED]

[Peter Kümmel]

Am 18. April 2016 21:28:04 MESZ, schrieb Georg Baum 
:
>Richard Heck wrote:
>
>> We now have three staging branches. These are:
>> 
>> 2.3-staging
>> 2.2.1-staging
>> 2.2.2-staging
>
>That makes 5 active branches in total (please correct me if I
>misunderstood 
>something):
>
>2.1.x  => will become 2.1.5
>master => will become 2.2.0
>2.2.1-staging  => will become 2.2.1
>2.2.2-staging  => will become 2.2.2
>2.3-staging=> will become 2.3.0
>
>Am I the only one who thinks that this is too much? IMHO this results
>in a 
>lot of additional book keeping work that eats from our valuable
>resources. 
>In addition, there are the trac keyword problems. Currently it is not 
>possible to map these branches to trac, if we wanted to do that we'd
>need 
>three additional keywords for the staging branches. If we do not add
>these 
>keywords then bugs might be closed for the wrong milestone and/or we
>need 
>manual work to find out from trac whether a particular bug will be
>fixed 
>e.g. for 2.2.1 or not.
>
>Such a structure is good for large organizations. It does not make
>sense for 
>such a small group of part time developers like us IMHO. We do not have
>the 
>resources to think about four stable releases in parallel. IMHO we
>should 
>concentrate on one branch for 2.2.0 and one for 2.3 development, and
>refrain 
>from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will
>try out 
>all these different 2.2 branches, so these fixes won't get additional 
>testing. In the contrary, I believe that they would get more testing if
>they 
>were all in one 2.3 branch.  Also, I doubt that we can now plan ahead
>for 
>2.2.2, these plans are likely to become obsolete. We have a simple tool
>to 
>schedule bug fixes: Milestones in trac. If we put all bug fixes in the
>2.3 
>branch and set the bug milestones it is easy to get a list of all fixes
>that 
>need backporting.
>
>
>Georg

I also think these branches are overkill.

I would only use master and 2.2. No 2.3, it is so far away that it could be in 
master. 

2.2 should be always stable so that at any time a short living 2.2.x could be 
branched until the release is done. After the tag 2.2.x will be deleted then.

Similar to 
https://wiki.qt.io/Branch_Guidelines

Peter

Re: master is locked for 2.2.0rc1 preparation

[Vincent van Ravesteijn]

On Wed, Apr 13, 2016 at 11:20 AM, Pavel Sanda  wrote:
> Scott Kostyshak wrote:
>> B) Branch 2.2.x from master and continue "unstable" development on
>> master.
>>
>> To me it does not feel right that the commits in-between 2.2.0rc1 and
>> 2.2.0 final would not *necessarily* be in master's commit history. I
>
> I would prefer to see 2.2.0 final commit in master, reason being
> history searches via git log etc.
>

git log $(git merge-base HEAD 2.2.0)..HEAD

Vincent

Re: master is locked for 2.2.0rc1 preparation

[Georg Baum]

Scott Kostyshak wrote:

> On Thu, Apr 14, 2016 at 09:08:50PM +0200, Georg Baum wrote:
> 
>> PS: Since RC is "Release candidate" we should IMHO only allow really
>> critical bug fixes between RC1 and 2.2.0 final. In particular I think we
>> should not do a RC2.
> 
> I think I mostly agree, although I would take off the qualifier "really"
> for critical bugs. Also I think patches that fix regressions, even if
> they are not critical regressions, should also be allowed in. What are
> your thoughts on patches that fix non-critical regressions? (or perhaps
> a regression falls under your category of "really critical" by
> definition?)

No, not all regressions are critical (e.g. if a workaround exists and the 
regression is not in an important feature.) My rule of thumb would be to 
allow patches that do only local code changes (i.e. could only break the 
feature that has the regression anyway), and patches that change more 
central code only if the regression is important.


Georg

Re: Staging Branches [REVISED]

[Georg Baum]

Richard Heck wrote:

> We now have three staging branches. These are:
> 
> 2.3-staging
> 2.2.1-staging
> 2.2.2-staging

That makes 5 active branches in total (please correct me if I misunderstood 
something):

2.1.x  => will become 2.1.5
master => will become 2.2.0
2.2.1-staging  => will become 2.2.1
2.2.2-staging  => will become 2.2.2
2.3-staging=> will become 2.3.0

Am I the only one who thinks that this is too much? IMHO this results in a 
lot of additional book keeping work that eats from our valuable resources. 
In addition, there are the trac keyword problems. Currently it is not 
possible to map these branches to trac, if we wanted to do that we'd need 
three additional keywords for the staging branches. If we do not add these 
keywords then bugs might be closed for the wrong milestone and/or we need 
manual work to find out from trac whether a particular bug will be fixed 
e.g. for 2.2.1 or not.

Such a structure is good for large organizations. It does not make sense for 
such a small group of part time developers like us IMHO. We do not have the 
resources to think about four stable releases in parallel. IMHO we should 
concentrate on one branch for 2.2.0 and one for 2.3 development, and refrain 
from big refactoring projects in 2.3 until 2.2.1 is out. Nobody will try out 
all these different 2.2 branches, so these fixes won't get additional 
testing. In the contrary, I believe that they would get more testing if they 
were all in one 2.3 branch.  Also, I doubt that we can now plan ahead for 
2.2.2, these plans are likely to become obsolete. We have a simple tool to 
schedule bug fixes: Milestones in trac. If we put all bug fixes in the 2.3 
branch and set the bug milestones it is easy to get a list of all fixes that 
need backporting.


Georg

Re: Lyx-rc1 feedback

[Jean-Marc Lasgouttes]

Le 17/04/2016 22:55, mn a écrit :

1. LyX is supposed to be faster now. After a while of having the app
open, from 2 hours to some days, editing slows down to a crawl. After
restarting LyX speed is back to normal (which is still too slow, btw) so
it’s not my documents. (And I mean really glacial, while CPU-usage for
LyX or other processes weren't out of the ordinary.)


OK, a few questions in order:
1/ what kind of machine do you have?
2/ when starting LyX 2.2, is it faster than 2.1.x?
3/ when you say that after a while it slows down to glacial, is it 
gradual, or brutal? Are there messages shown by Console.app?
4/ do you have Xcode (programmer tools) installed? If Stephan is able to 
produce a binary with debug info, it would be nice if you could run LyX 
with a profiler running so that we can see what is wrong.



The second time I noticed that, it was in this situation with rc1:
Cursor alone on a new line, standard-environment, after the newly
inserted table, trying to insert another table:

As you correctly understood, it was the whole section, everything greyed
out from Table to Preview.


Do you think you can reproduce reliably?

JMarc

Re: [RFC] Staging Branches and Trac

[Richard Heck]

On 04/18/2016 12:21 PM, Jean-Marc Lasgouttes wrote:
> Le 18/04/2016 18:08, Richard Heck a écrit :
>> On 04/18/2016 06:13 AM, Jean-Marc Lasgouttes wrote:
>>> Le 16/04/2016 21:49, Richard Heck a écrit :

 As Scott pointed out, my previous suggestions for how fixes
 committed to
 the staging branches should be handled in trac was silly. We can't
 reuse
 "fixedinmaster" for 2.3-staging. I'm also not sure that we want to
 introduce a new status "fixedinstaging" for such a short time.

 Here, then, is a simple proposal: Any bug that is fixed in one of the
 staging branches should get the *keyword* "fixedinstaging", and the
 milestone should be set to reflect the appropriate branch. So fixes
 committed to 2.3-staging should be tagged "fixedinstaging", with the
 milestone set to 2.3.0. Fixes committed to 2.2.2-staging should be
 tagged "fixedinstaging", with the milestone set to 2.2.2. Etc. This
 will
 restore the /status quo ante/ briefly, which was workable if not
 perfect. The only difference is that the keyword will not distinguish
 what has happened where, but we can tell this from the milestone and
 comments in the bug itself. There won't be so many of these that that
 becomes a problem.
>>>
>>> What if the fix is applied to 2.1.5 too? (for example bug 10063).
>>
>> Then it can be marked "fixedinstable". So nothing changes there.
>
> And do you want the fixedinstaging tag? I ask because I am not sure of
> what you plan to do with it.

No. I will be assuming that what is in 2.1.5 is also in 2.2.2-staging.
I.e., I will try to make sure it happens that way.

Richard

Re: [RFC] Staging Branches and Trac

[Jean-Marc Lasgouttes]

Le 18/04/2016 18:08, Richard Heck a écrit :

On 04/18/2016 06:13 AM, Jean-Marc Lasgouttes wrote:

Le 16/04/2016 21:49, Richard Heck a écrit :


As Scott pointed out, my previous suggestions for how fixes committed to
the staging branches should be handled in trac was silly. We can't reuse
"fixedinmaster" for 2.3-staging. I'm also not sure that we want to
introduce a new status "fixedinstaging" for such a short time.

Here, then, is a simple proposal: Any bug that is fixed in one of the
staging branches should get the *keyword* "fixedinstaging", and the
milestone should be set to reflect the appropriate branch. So fixes
committed to 2.3-staging should be tagged "fixedinstaging", with the
milestone set to 2.3.0. Fixes committed to 2.2.2-staging should be
tagged "fixedinstaging", with the milestone set to 2.2.2. Etc. This will
restore the /status quo ante/ briefly, which was workable if not
perfect. The only difference is that the keyword will not distinguish
what has happened where, but we can tell this from the milestone and
comments in the bug itself. There won't be so many of these that that
becomes a problem.


What if the fix is applied to 2.1.5 too? (for example bug 10063).


Then it can be marked "fixedinstable". So nothing changes there.


And do you want the fixedinstaging tag? I ask because I am not sure of 
what you plan to do with it.


JMarc

Re: Is "make distcheck" failure a blocker?

[Jean-Marc Lasgouttes]

Le 18/04/2016 18:09, Richard Heck a écrit :

On 04/18/2016 08:12 AM, Jean-Marc Lasgouttes wrote:

Le 16/04/2016 06:19, Stephan Witt a écrit :

<0001-Make-monolithic-build-code-portable-to-Mac-OS.patch>


Sorry for the late response: yes, it works here on my Mac.


I put it in 2.3-staging.

Richard, is it OK for 2.2.2?


Yes.


Thanks, done.

JMarc

Re: Is "make distcheck" failure a blocker?

[Richard Heck]

On 04/18/2016 08:12 AM, Jean-Marc Lasgouttes wrote:
> Le 16/04/2016 06:19, Stephan Witt a écrit :
>>> <0001-Make-monolithic-build-code-portable-to-Mac-OS.patch>
>>
>> Sorry for the late response: yes, it works here on my Mac.
>
> I put it in 2.3-staging.
>
> Richard, is it OK for 2.2.2?

Yes.

rh

Re: [RFC] Staging Branches and Trac

[Richard Heck]

On 04/18/2016 06:13 AM, Jean-Marc Lasgouttes wrote:
> Le 16/04/2016 21:49, Richard Heck a écrit :
>>
>> As Scott pointed out, my previous suggestions for how fixes committed to
>> the staging branches should be handled in trac was silly. We can't reuse
>> "fixedinmaster" for 2.3-staging. I'm also not sure that we want to
>> introduce a new status "fixedinstaging" for such a short time.
>>
>> Here, then, is a simple proposal: Any bug that is fixed in one of the
>> staging branches should get the *keyword* "fixedinstaging", and the
>> milestone should be set to reflect the appropriate branch. So fixes
>> committed to 2.3-staging should be tagged "fixedinstaging", with the
>> milestone set to 2.3.0. Fixes committed to 2.2.2-staging should be
>> tagged "fixedinstaging", with the milestone set to 2.2.2. Etc. This will
>> restore the /status quo ante/ briefly, which was workable if not
>> perfect. The only difference is that the keyword will not distinguish
>> what has happened where, but we can tell this from the milestone and
>> comments in the bug itself. There won't be so many of these that that
>> becomes a problem.
>
> What if the fix is applied to 2.1.5 too? (for example bug 10063).

Then it can be marked "fixedinstable". So nothing changes there.

rh

Re: CRASH 2.2.0dev with XeLaTeX and Utopia font

[Helge Hafting]

Den 15. april 2016 19:10, skrev PhilipPirrip:

Don't ask me how I find these...
I'm at 744f6e3cd802 now, compiled with Qt 5.6.0 on Linux Fedora 24. I 
get the same behavior with an older binary compiled with Qt 4.8.7.

Before filing a bug report, I need someone to confirm:

Start LyX 2.2
New Document
Type something in, say, abcd
Document Settings > Fonts >  Use non-TeX fonts
Roman: Utopia
View [PDF (XeTeX)]
LyX crashes


This only seems to happen when I choose Utopia, tried at least 20 others.

Confirmed with 2.2.0rc1 on arch linux (64 bit):
Looking for python v2.x ...
Examining /usr/bin/python
Examining /usr/bin/python-config
Examining /usr/bin/python2
Found Python 2.7.11

This is XeTeX, Version 3.14159265-2.6-0.2 (TeX Live 2015/Arch Linux) 
(preloaded format=xelatex)

 restricted \write18 enabled.
entering extended mode
(./ny_fil1.tex
LaTeX2e <2015/10/01> patch level 2
Babel <3.9m> and hyphenation patterns for 79 languages loaded.


xdvipdfmx:fatal: Cannot proceed without the font: 
/usr/share/fonts/Type1/UTB_.pfa


Output file removed.
This is XeTeX, Version 3.14159265-2.6-0.2 (TeX Live 2015/Arch Linux) 
(preloaded format=xelatex)

 restricted \write18 enabled.
entering extended mode
(./ny_fil1.tex
LaTeX2e <2015/10/01> patch level 2
Babel <3.9m> and hyphenation patterns for 79 languages loaded.


xdvipdfmx:fatal: Cannot proceed without the font: 
/usr/share/fonts/Type1/UTRG.pfa


Output file removed.
lassert.cpp (51): ASSERTION status != ExportSuccess VIOLATED IN 
Buffer.cpp:4323

(  1) lyx-2.2.0dev: lyx-2.2.0dev() [0xadf5e0]
(  2) lyx-2.2.0dev: lyx-2.2.0dev() [0x4dd43c]
(  3) lyx-2.2.0dev: lyx-2.2.0dev() [0x8e3b09]
(  4) lyx-2.2.0dev: lyx-2.2.0dev() [0x8fb52b]
(  5) /usr/lib/libQt5Core.so.5: /usr/lib/libQt5Core.so.5(+0xa70d3) 
[0x7fe78cdff0d3]
(  6) /usr/lib/libQt5Core.so.5: /usr/lib/libQt5Core.so.5(+0xaade8) 
[0x7fe78ce02de8]
(  7) /usr/lib/libpthread.so.0: /usr/lib/libpthread.so.0(+0x7424) 
[0x7fe78c2a5424]

(  8) /usr/lib/libc.so.6: /usr/lib/libc.so.6(clone+0x6d) [0x7fe78bfe4cbd]
Assertion triggered in void lyx::doAssertWithCallstack(bool) by failing 
check "false" in file lassert.cpp:44

 /home/helgehaf/ny fil1.lyx.emergency
QSocketNotifier: Socket notifiers cannot be enabled or disabled from 
another thread

Avbrutt (SIGABRT) (core dumped)

Re: Is "make distcheck" failure a blocker?

[Jean-Marc Lasgouttes]

Le 16/04/2016 06:19, Stephan Witt a écrit :

<0001-Make-monolithic-build-code-portable-to-Mac-OS.patch>


Sorry for the late response: yes, it works here on my Mac.


I put it in 2.3-staging.

Richard, is it OK for 2.2.2?

JMarc

Re: [PATCH] move doc changelogs out of attic

[Jean-Marc Lasgouttes]

Le 16/04/2016 14:37, Richard Heck a écrit :

Scott, I am not sure when we want to apply this.

I prefer not for 2.2.0.


It can now go to 2.3-staging. Is this something we want in 2.2.x? If so,
it's fine to go to 2.2.1-staging, as it doesn't actually affect anything
in the code.


I did both.

JMarc

Re: [RFC] Staging Branches and Trac

[Jean-Marc Lasgouttes]

Le 16/04/2016 21:49, Richard Heck a écrit :


As Scott pointed out, my previous suggestions for how fixes committed to
the staging branches should be handled in trac was silly. We can't reuse
"fixedinmaster" for 2.3-staging. I'm also not sure that we want to
introduce a new status "fixedinstaging" for such a short time.

Here, then, is a simple proposal: Any bug that is fixed in one of the
staging branches should get the *keyword* "fixedinstaging", and the
milestone should be set to reflect the appropriate branch. So fixes
committed to 2.3-staging should be tagged "fixedinstaging", with the
milestone set to 2.3.0. Fixes committed to 2.2.2-staging should be
tagged "fixedinstaging", with the milestone set to 2.2.2. Etc. This will
restore the /status quo ante/ briefly, which was workable if not
perfect. The only difference is that the keyword will not distinguish
what has happened where, but we can tell this from the milestone and
comments in the bug itself. There won't be so many of these that that
becomes a problem.


What if the fix is applied to 2.1.5 too? (for example bug 10063).

JMarc

Re: 2.2.0rc1 tar balls are available

[Jean-Marc Lasgouttes]

Le 15/04/2016 21:56, Scott Kostyshak a écrit :

On Fri, Apr 15, 2016 at 09:48:38PM +0200, Jean-Marc Lasgouttes wrote:

Le 15/04/16 21:45, Scott Kostyshak a écrit :

On Fri, Apr 15, 2016 at 04:19:20PM +0200, Jean-Marc Lasgouttes wrote:

Le 13/04/2016 21:27, Jean-Marc Lasgouttes a écrit :

It is indeed in SOURCEFILES, and it had been there all the time. I guess
it should be removed, but with care.

Do you build before doing "make dist"?


I'd say that this patch is all we need.


If "I'd say" means you are confident, then go ahead. Let me know if you
want me to test something (e.g. apply your patch and make the tar file
and check).


I am confident, but then the makefile was like that from the start in 2007,
so that makes me more nervous. But then, what could possibly go wrong? ;)


Normally I probably wouldn't want to change something at this point, but
on 2.2.0rc1 that file takes up 24MB in the extracted tar ball so it
would be nice to get rid of it.


Is this a +1 for 2.2.0?

JMarc

Re: [PATCH] compilation fix for libc++ in C++11 mode

[Jean-Marc Lasgouttes]

Le 17/04/2016 01:03, Guillaume Munch a écrit :

Le 10/01/2016 21:38, Jean-Marc Lasgouttes a écrit :

Le 10/01/16 22:33, Guillaume Munch a écrit :

I imagine that Toc and other classes are being forward-declared in some
headers probably for the same speed reason. Toc.h is there to provide an
alternative to the forward declarations without sacrificing speed (or
maybe my Toc.h already includes too much?). But I'd be happy to learn
about any reasons behind the current header organisation.


I am not completely sure today. What I know is that the cpp files have
been grouped for speed.



Is there still an objection to creating a new header Toc.h?


I do not really remember what the discussion was. Do what you think is best.

JMarc