Re: How far is 2.3.0?

[Tommaso Cucinotta]

On 16/04/2017 00:03, Tommaso Cucinotta wrote:

   findadv-08-in.txt: FAILED


e.g., this one is experiencing an assert

lyxfind.cpp (961): Searching in regexp mode: at_begin=1
Assertion triggered in typename boost::detail::sp_member_access::type boost::shared_ptr::operator->() const [with T = 
boost::regex_iterator_implementation<__gnu_cxx::__normal_iterator >, char, 
boost::regex_traits >; typename boost::detail::sp_member_access::type = 
boost::regex_iterator_implementation<__gnu_cxx::__normal_iterator >, char, 
boost::regex_traits >*] by failing check "px != 0" in file /usr/include/boost/smart_ptr/shared_ptr.hpp:693

that reproduces running manually the test. I'm on master [a8bb3171/lyxgit].

My config looks like

$ grep prefix config.status
ac_cs_config="'--prefix=/usr/local/lyx-trunk' '--with-version-suffix=-trunk' 
'--disable-qt5' '--disable-std-regex' '--without-included-boost' '--disable-stdlib-debug' 
'--enable-debug'"

How can I place myself into a config resembling as much as possible what is 
going to be released ? (with system boost vs own boost etc...)

Thanks,

T.

Re: How far is 2.3.0?

[Tommaso Cucinotta]

On 15/04/2017 23:48, Tommaso Cucinotta wrote:

Just
going to check now whether any critical one is failing.


Not as nice as one could expect [1], let me see whether it's simply changes in 
logging/debuggin (which these tests rely upon).

T.

[1]

Running test cases . . .
   findadv-01-in.txt: Ok
   findadv-02-in.txt: Ok
   findadv-03-in.txt: Ok
   findadv-04-in.txt: Ok
   findadv-05-in.txt: Ok
   findadv-06-in.txt: Ok
   findadv-07-in.txt: Ok
   findadv-08-in.txt: FAILED
   findadv-09-in.txt: Ok
   findadv-10-in.txt: Ok
   findadv-11-in.txt: Ok
   findadv-12-in.txt: Ok
   findadv-13-in.txt: Ok
   findadv-14-in.txt: Ok
   findadv-15-in.txt: FAILED
   findadv-16-in.txt: Ok
   findadv-17-in.txt: Ok
   findadv-18-in.txt: FAILED
   findadv-19-in.txt: FAILED
   findadv-20-in.txt: Ok
 findadv-logo-in.txt: Ok
findadv-re-01-in.txt: FAILED
findadv-re-02-in.txt: FAILED
findadv-re-03-in.txt: FAILED
findadv-re-04-in.txt: FAILED
findadv-re-05-in.txt: FAILED
findadv-re-06-in.txt: FAILED

There were 10 FAILED tests

Re: How far is 2.3.0?

[Tommaso Cucinotta]

On 24/02/2017 18:45, Jean-Marc Lasgouttes wrote:

A good subject before the week-end: what do we need to do before
declaring feature freeze for 2.3?


I just pushed a fix of development/autotests/*.py et al., that allowed
me to recover a working autotests machinery for Advanced F Just
going to check now whether any critical one is failing.

T.

Re: How far is 2.3.0?

[Joel Kulesza]

On Fri, Apr 14, 2017 at 2:43 AM, Pavel Sanda  wrote:

> José Abílio Matos wrote:
> > FWIW, IMHO it all comes to:
> >
> > What is the event that we think is relevant to jump to the 3.x series?
> >
> > If none then the first number in the 2.x.y moniker is irrelevant and it
> should
> > be dropped.
>
> You can take the first number just as a buffer for the case the second
> number becomes
> way too big and becomes impractical to remember it, and you cam make the
> same trick
> which kernel devs did when they switch to 3.x series.
>
> True, there was no real reason why to jump from 1.6 to 2.0 and not simply
> continue
> e.g. to 1.9. If I remember it was actually you who strongly pushed forward
> for 2.0
> for reasons I never really understood; perhaps that marketing thing? :)
> Not that I see who we are competing with, unlike firefox there's no real
> competitor
> unless you count SWP :)
>
> In other words, I think our numbering is just fine :)


While I agree with Pavel that the current version number approach taken is
fine, I disagree with the comment "You can take the first number just as a
buffer for the case the second number becomes
way too big and becomes impractical to remember it".  That seems entirely
too arbitrary and would suggest basing version number changes on concrete
criteria such as a semantic system .

Incidentally, humans can (or at least, could) remember 10+ digit phone
numbers, so I suspect the second place can have quite a few digits before
one would need to arbitrarily increment the first place.  Would this ever
occur in practice?

Re: How far is 2.3.0?

[Pavel Sanda]

José Abílio Matos wrote:
> FWIW, IMHO it all comes to:
> 
> What is the event that we think is relevant to jump to the 3.x series?
> 
> If none then the first number in the 2.x.y moniker is irrelevant and it 
> should 
> be dropped.

You can take the first number just as a buffer for the case the second number 
becomes
way too big and becomes impractical to remember it, and you cam make the same 
trick
which kernel devs did when they switch to 3.x series.

True, there was no real reason why to jump from 1.6 to 2.0 and not simply 
continue
e.g. to 1.9. If I remember it was actually you who strongly pushed forward for 
2.0
for reasons I never really understood; perhaps that marketing thing? :)
Not that I see who we are competing with, unlike firefox there's no real 
competitor
unless you count SWP :)

In other words, I think our numbering is just fine :)

Pavel

Re: How far is 2.3.0?

[Jean-Marc Lasgouttes]

Le 10/04/2017 à 11:49, José Abílio Matos a écrit :

FWIW, IMHO it all comes to:

What is the event that we think is relevant to jump to the 3.x series?

If none then the first number in the 2.x.y moniker is irrelevant and it should
be dropped.


I agree with what you write, but it does not seem important enough to me 
to actually act on it :)


Either way, I do not really care. The only numbering that makes a real 
difference to me is Year.Month, but it is not adapted to our workflow.


JMarc

Re: How far is 2.3.0?

[José Abílio Matos]

On Monday, 10 April 2017 08.50.32 WEST Jean-Marc Lasgouttes wrote:
> Version numbers are just version numbers, I do not think that they make
> as much of a difference than getting versions out fast. In the case of
> firefox and gcc, the important part of the new release scheme was speed.
> The rest is just marketing.
> 
> JMarc

My rationale is always the same we have basically major and minor versions. 
For major versions we introduce changes that are incompatible with older 
versions, in the sense that older versions can not read the new file formats 
(lyx file, layouts, etc).

Minor versions are strictly compatible and represent incremental improvements 
in the same stable series.

So if our development only has two types of releases we should use two 
numbers, the major and the minor.

I remember this type of discussion that we had to jump to the 1.0 release, to 
jump to the 2.0 release and so on. :-)

In the case of gcc btw the idea was not to get faster versions, since the 
release cycle was kept at one year, but to convey the message that each new 
major version is really a major version.
The marketing even in free software projects is also important, as you know. 
:-)

Also as a developer that has to type the version number often when comparing 
previous formats I would appreciate to have to type less meaningless numbers. 
This is a very objective argument.


FWIW, IMHO it all comes to:

What is the event that we think is relevant to jump to the 3.x series?

If none then the first number in the 2.x.y moniker is irrelevant and it should 
be dropped.
-- 
José Abílio

Re: How far is 2.3.0?

[Jean-Marc Lasgouttes]

Le 10/04/2017 à 05:36, Scott Kostyshak a écrit :

First the obvious conclusion, those number are completely arbitrary. Each of
those versions has been a major version on its own. And as usual I propose to
go the way of gcc (not necessarily dropping the first .0 ;-) ). And use simply
a major number and a minor number for the version.

An yearly version on the other hand seems a good compromise. Again gcc is a
good model.


I don't have a strong opinion on this. Does anyone else?


Well, everybody is doing that. It looks like a good reason for _not_ 
doing it :)


Version numbers are just version numbers, I do not think that they make 
as much of a difference than getting versions out fast. In the case of 
firefox and gcc, the important part of the new release scheme was speed. 
The rest is just marketing.


JMarc

Re: How far is 2.3.0?

[Scott Kostyshak]

On Sat, Mar 04, 2017 at 07:06:51PM +, José Abílio Matos wrote:

> Now regarding the other issue at hand and looking into history we have that:
> 
> 2.2.0 -> 2016.05
> 2.1.0 -> 2014.04
> 2.0.0 -> 2011.04
> 1.6.0 -> 2008.11
> 1.5.0 -> 2007.07
> 1.4.0 -> 2006.03
> 
> First the obvious conclusion, those number are completely arbitrary. Each of 
> those versions has been a major version on its own. And as usual I propose to 
> go the way of gcc (not necessarily dropping the first .0 ;-) ). And use 
> simply 
> a major number and a minor number for the version.
> 
> An yearly version on the other hand seems a good compromise. Again gcc is a 
> good model.

I don't have a strong opinion on this. Does anyone else?

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Scott Kostyshak]

On Sat, Mar 11, 2017 at 10:53:30PM +, José Abílio Matos wrote:
> On Saturday, 11 March 2017 20.48.02 WET Richard Heck wrote:
> > And I'll second that. You did an excellent job last time, which is why
> > we all want you to do it again.
> 
> +1

Thanks for all of your encouragement. I will propose for discussion some
dates by next week for moving forward.

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[José Abílio Matos]

On Saturday, 11 March 2017 20.48.02 WET Richard Heck wrote:
> And I'll second that. You did an excellent job last time, which is why
> we all want you to do it again.

+1

-- 
José Abílio

Re: How far is 2.3.0?

[Richard Heck]

On 03/11/2017 03:14 PM, Scott Kostyshak wrote:
> On Sat, Mar 11, 2017 at 08:56:01PM +0100, Jean-Marc Lasgouttes wrote:
>> Le 08/03/2017 à 01:26, Scott Kostyshak a écrit :
>>> So yes, I am willing to be the release manager, but I am also willing to
>>> have a more knowledgeable developer as the release manager if one
>>> volunteers.
>> FWIW, I think you will do (again) a good release maintainer.
> Thanks, to me it is worth a lot!

And I'll second that. You did an excellent job last time, which is why
we all want you to do it again.

>> And Pavel is right that you are not supposed to know everything, but to lean 
>> on the right people.
> I am learning that this is indeed the most important. But I would lean 
> (fall?) on people more than others.

I wouldn't be so sure. Many of us know the bits of code we know, and we
fake it about the rest.

Richard

Re: How far is 2.3.0?

[Scott Kostyshak]

On Sat, Mar 11, 2017 at 08:56:01PM +0100, Jean-Marc Lasgouttes wrote:
> Le 08/03/2017 à 01:26, Scott Kostyshak a écrit :
> > So yes, I am willing to be the release manager, but I am also willing to
> > have a more knowledgeable developer as the release manager if one
> > volunteers.
> 
> FWIW, I think you will do (again) a good release maintainer.

Thanks, to me it is worth a lot!

> And Pavel is
> right that you are not supposed to know everything, but to lean on the right
> people.

I am learning that this is indeed the most important. But I would lean
(fall?) on people more than others.

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Jean-Marc Lasgouttes]

Le 08/03/2017 à 01:26, Scott Kostyshak a écrit :

So yes, I am willing to be the release manager, but I am also willing to
have a more knowledgeable developer as the release manager if one
volunteers.


FWIW, I think you will do (again) a good release maintainer. And Pavel 
is right that you are not supposed to know everything, but to lean on 
the right people.


JMarc

Re: How far is 2.3.0?

[José Abílio Matos]

On Wednesday, 8 March 2017 01.33.03 WET Pavel Sanda wrote:
> My take on this is that release manager responsibility is to set and publish
> deadlines and push people who are responsible for their area of expertise
> to fix or stabilize that in reasonable time. So it's more of understanding
> whom to trust in which area rather than understanding the code.

I (wholeheartedly) agree with Pavel in this point. It is more important this 
managerial trait than the technical aspect. We are in the developers mailing 
list and the mean field technical knowledge is here. :-)

> > So yes, I am willing to be the release manager, but I am also willing to
> > have a more knowledgeable developer as the release manager if one
> > volunteers.
> 
> Easy. Is any other dev thinking about trying the release managment for 2.3?
> We can wait couple days and see whether someone has feeling of doing it.
> 
> Pavel

Honestly I would like to suggest that if no one is stepping until say Tuesday 
the job is yours. :-)

The purpose of this is just to establish an explicit deadline and it is not to 
exclude anyone from the release manager role.

So if anyone has something to say about this speak now or forever hold your 
peace. ;-)

Regards,
-- 
José Abílio

Re: How far is 2.3.0?

[José Abílio Matos]

On Wednesday, 8 March 2017 00.17.33 WET Scott Kostyshak wrote:
> Makes sense. I guess in the end this is the decision of the branch
> maintainer.
> 
> Scott

Agreed. :-)

-- 
José Abílio

Re: How far is 2.3.0?

[Scott Kostyshak]

On Tue, Mar 07, 2017 at 05:33:03PM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > On Tue, Mar 07, 2017 at 12:42:10PM -0800, Pavel Sanda wrote:
> > > Scott Kostyshak wrote:
> > > > When we branch 2.3, this branch would be named "2.3.x", right? The
> > > > slightly weird thing would be that the release manager would be in
> > > > charge of the 2.3.x branch until 2.3.0 and then the stable branch
> > > 
> > > 2.3.x is good for devs and less good for 2.3 because it gets less 
> > > attention.
> > 
> > I don't understand what you mean here. Can you give more details? Do you
> > mean that if there is a "2.3.x" branch, devs might commit patches that
> > could be a little risky for 2.3.0, where if there is instead a "2.3.0"
> > branch, the name makes us be more careful about such patches?
> 
> My understanding was that you propose to have master and 2.3.x which will
> later become 2.3.0. People generally like more to develop new stuff rather
> than focus on stabilizing the code, so having both master and 2.3.x
> will divide attention and perhaps more to the favor of 2.3.x.
> So if I was responsible for 2.3.0 I would try to fix 2.3.x==master as
> long as possible ;) But not really my call now...

Ah I understand what you mean now. Thanks for explaining.

> > > OTOH if the manager is sloppy with deadlines people get very frustrated 
> > > about
> > > the freeze and that is not good either.
> > 
> > +1
> > 
> > > Anyway I think that the manager should have major word in decisions like 
> > > this
> > > because he will have the burden/responsibility for whatever decision is 
> > > taken.
> > > 
> > > So let's get to the point: Are you willing to be release manager for 2.3?
> > 
> > Yes.
> > 
> > My main hesitation is that there are several parts of LyX's code where I
> > am completely lost, and that's not a good quality of a release manager.
> > And when we get to the stage where every commit requires careful review,
> > I would need more help from others than a more experienced developer. I
> 
> My take on this is that release manager responsibility is to set and publish
> deadlines and push people who are responsible for their area of expertise
> to fix or stabilize that in reasonable time. So it's more of understanding
> whom to trust in which area rather than understanding the code.

I see, that makes sense.

> > So yes, I am willing to be the release manager, but I am also willing to
> > have a more knowledgeable developer as the release manager if one
> > volunteers.
> 
> Easy. Is any other dev thinking about trying the release managment for 2.3?
> We can wait couple days and see whether someone has feeling of doing it.

Perfect.

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Pavel Sanda]

Scott Kostyshak wrote:
> On Tue, Mar 07, 2017 at 12:42:10PM -0800, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> > > When we branch 2.3, this branch would be named "2.3.x", right? The
> > > slightly weird thing would be that the release manager would be in
> > > charge of the 2.3.x branch until 2.3.0 and then the stable branch
> > 
> > 2.3.x is good for devs and less good for 2.3 because it gets less attention.
> 
> I don't understand what you mean here. Can you give more details? Do you
> mean that if there is a "2.3.x" branch, devs might commit patches that
> could be a little risky for 2.3.0, where if there is instead a "2.3.0"
> branch, the name makes us be more careful about such patches?

My understanding was that you propose to have master and 2.3.x which will
later become 2.3.0. People generally like more to develop new stuff rather
than focus on stabilizing the code, so having both master and 2.3.x
will divide attention and perhaps more to the favor of 2.3.x.
So if I was responsible for 2.3.0 I would try to fix 2.3.x==master as
long as possible ;) But not really my call now...

> > OTOH if the manager is sloppy with deadlines people get very frustrated 
> > about
> > the freeze and that is not good either.
> 
> +1
> 
> > Anyway I think that the manager should have major word in decisions like 
> > this
> > because he will have the burden/responsibility for whatever decision is 
> > taken.
> > 
> > So let's get to the point: Are you willing to be release manager for 2.3?
> 
> Yes.
> 
> My main hesitation is that there are several parts of LyX's code where I
> am completely lost, and that's not a good quality of a release manager.
> And when we get to the stage where every commit requires careful review,
> I would need more help from others than a more experienced developer. I

My take on this is that release manager responsibility is to set and publish
deadlines and push people who are responsible for their area of expertise
to fix or stabilize that in reasonable time. So it's more of understanding
whom to trust in which area rather than understanding the code.

> So yes, I am willing to be the release manager, but I am also willing to
> have a more knowledgeable developer as the release manager if one
> volunteers.

Easy. Is any other dev thinking about trying the release managment for 2.3?
We can wait couple days and see whether someone has feeling of doing it.

Pavel

Re: How far is 2.3.0?

[Scott Kostyshak]

On Tue, Mar 07, 2017 at 12:42:10PM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > When we branch 2.3, this branch would be named "2.3.x", right? The
> > slightly weird thing would be that the release manager would be in
> > charge of the 2.3.x branch until 2.3.0 and then the stable branch
> 
> 2.3.x is good for devs and less good for 2.3 because it gets less attention.

I don't understand what you mean here. Can you give more details? Do you
mean that if there is a "2.3.x" branch, devs might commit patches that
could be a little risky for 2.3.0, where if there is instead a "2.3.0"
branch, the name makes us be more careful about such patches?

> OTOH if the manager is sloppy with deadlines people get very frustrated about
> the freeze and that is not good either.

+1

> Anyway I think that the manager should have major word in decisions like this
> because he will have the burden/responsibility for whatever decision is taken.
> 
> So let's get to the point: Are you willing to be release manager for 2.3?

Yes.

My main hesitation is that there are several parts of LyX's code where I
am completely lost, and that's not a good quality of a release manager.
And when we get to the stage where every commit requires careful review,
I would need more help from others than a more experienced developer. I
will not give a +1 for a patch that I don't understand, even in some
cases where the patch if just a few line changes. I think this is a
disadvantage, and I think it could slow down the release and cause some
frustration (even taking into consideration that everyone will of course
help with reviewing).

The advantage of having a more experienced developer as the release
manager is that they could:

 1. Review every patch.
 2. If there is a critical bug that is holding up a release, they can
 just put in the time and fix it.

I'm not saying that the experienced developer *would* actually review
every patch and fix every critical bug. My point is that if there is a
deadline, it is nice if the release manager at least has the knowledge
to *potentially* do it.

So yes, I am willing to be the release manager, but I am also willing to
have a more knowledgeable developer as the release manager if one
volunteers.

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Scott Kostyshak]

On Tue, Mar 07, 2017 at 11:03:13AM +0100, Jean-Marc Lasgouttes wrote:
> Le 07/03/2017 à 01:06, Scott Kostyshak a écrit :
> > When we branch 2.3, this branch would be named "2.3.x", right? The
> > slightly weird thing would be that the release manager would be in
> > charge of the 2.3.x branch until 2.3.0 and then the stable branch
> > maintainer would be in charge of the branch after 2.3.0.
> 
> As you say, it is only slightly weird, and the easiest is probably to get
> over it :)
> 
> > For
> > the sake of argument, what would be the disadvantage to branching even
> > before the feature freeze?
> 
> I would say that backporting features is more work than backporting fixes...

Makes sense.

> > This discussion gets more complex once we talk about our opinions
> > regarding 2.3.1 and 2.3.2 releases. When we get close to releasing
> > 2.3.0, there will be bug fixes that might be viewed as desirable for
> > eventual inclusion in 2.3.x, but too risky for 2.3.0.
> 
> We might want to put some pressure here by setting dates and trying to stick
> to them.
> We have to accept to drop some things from a release and keep them for the
> next, especially if these releases come somewhat quicker (we can always
> dream!).

> It _might_ happen that our shiny CI infrastructure will actually
> help in this regard.

This is indeed nice.

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Scott Kostyshak]

On Tue, Mar 07, 2017 at 09:23:13AM +, José Abílio Matos wrote:
> On Tuesday, 7 March 2017 00.06.24 WET Scott Kostyshak wrote:
> [...]
> 
> Thank you Scott for all distilling your experience as release manager, as 
> this 
> is important to improve the development process. :-)
> 
> I will left the other issues that you have raised for others.
> 
> > In case someone is craving wants more complexity, we can also discuss
> > our view for the last point release of 2.2.x. For example, should all
> > commits to the 2.3.x branch be backported to the 2.2.x branch? Or only
> > critical patches and the lyx2lyx patch?
> 
> Here I think that we should prioritize our efforts by going with the later 
> option, that is, the last 2.2.x should consist only of critical patches and 
> the lyx2lyx patch. This reduce the testing required and minimizes the need 
> for 
> an extra release if something slips under our radar, because by then we will 
> have three branches opened: 2.2.x; 2.3.x and 2.4.dev.

Makes sense. I guess in the end this is the decision of the branch
maintainer.

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Richard Heck]

On 03/06/2017 07:06 PM, Scott Kostyshak wrote:
> On Sat, Mar 04, 2017 at 09:53:08PM +0100, Guillaume Munch wrote:
>> If you create a 2.4 milestone then I can already re-target the bugs that
>> I care about so as to have a better picture of 2.3.
> +1

I've created 2.4.0 and 2.4.x milestones.

Richard

Re: How far is 2.3.0?

[Richard Heck]

On 03/04/2017 03:53 PM, Guillaume Munch wrote:
> Le 24/02/2017 à 18:45, Jean-Marc Lasgouttes a écrit :
>> Hi there,
>>
>> A good subject before the week-end: what do we need to do before
>> declaring feature freeze for 2.3? Personally I have finished a cycle or
>> breaking/fixing the math editor and would like to refrain from doing new
>> big architectural changes. I only have two or three patches pending,
>> plus of course all the bugs that Guillaume keeps finding.
>>
>> Who has Work In Progress that should go to 2.3? How long do we need?
>>
>
>
> I have finished a front-end to QFileSystemWatcher and fixed
> http://www.lyx.org/trac/ticket/10072. The UI still requires some
> polishing but it is nearly there.
>
> There is the u32string patch that is almost complete. But I need to get
> back to it.
>
> I think Richard has a few pending patches I am interested in:
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195246.html
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195204.html

Yes, I'll try to get back to those.

Richard

Re: How far is 2.3.0?

[Pavel Sanda]

Scott Kostyshak wrote:
> When we branch 2.3, this branch would be named "2.3.x", right? The
> slightly weird thing would be that the release manager would be in
> charge of the 2.3.x branch until 2.3.0 and then the stable branch

2.3.x is good for devs and less good for 2.3 because it gets less attention.
OTOH if the manager is sloppy with deadlines people get very frustrated about
the freeze and that is not good either.

Anyway I think that the manager should have major word in decisions like this
because he will have the burden/responsibility for whatever decision is taken.

So let's get to the point: Are you willing to be release manager for 2.3?

Pavel

Re: How far is 2.3.0?

[Jean-Marc Lasgouttes]

Le 07/03/2017 à 01:06, Scott Kostyshak a écrit :

When we branch 2.3, this branch would be named "2.3.x", right? The
slightly weird thing would be that the release manager would be in
charge of the 2.3.x branch until 2.3.0 and then the stable branch
maintainer would be in charge of the branch after 2.3.0.


As you say, it is only slightly weird, and the easiest is probably to 
get over it :)



For
the sake of argument, what would be the disadvantage to branching even
before the feature freeze?


I would say that backporting features is more work than backporting fixes...


This discussion gets more complex once we talk about our opinions
regarding 2.3.1 and 2.3.2 releases. When we get close to releasing
2.3.0, there will be bug fixes that might be viewed as desirable for
eventual inclusion in 2.3.x, but too risky for 2.3.0.


We might want to put some pressure here by setting dates and trying to 
stick to them.
We have to accept to drop some things from a release and keep them for 
the next, especially if these releases come somewhat quicker (we can 
always dream!). It _might_ happen that our shiny CI infrastructure will 
actually help in this regard.



Actually, now that I think about it, it seems that we could reduce the
number of branches by one by not having 2.3.1-staging. I wonder if the
following would be a clean way of proceeding: [...]


I do not have strong feelings here. We shall do whatever the maintainer 
is more comfortable with. Use the simplest scheme that serves us well.


JMarc

Re: How far is 2.3.0?

[José Abílio Matos]

On Tuesday, 7 March 2017 00.06.24 WET Scott Kostyshak wrote:
[...]

Thank you Scott for all distilling your experience as release manager, as this 
is important to improve the development process. :-)

I will left the other issues that you have raised for others.

> In case someone is craving wants more complexity, we can also discuss
> our view for the last point release of 2.2.x. For example, should all
> commits to the 2.3.x branch be backported to the 2.2.x branch? Or only
> critical patches and the lyx2lyx patch?

Here I think that we should prioritize our efforts by going with the later 
option, that is, the last 2.2.x should consist only of critical patches and 
the lyx2lyx patch. This reduce the testing required and minimizes the need for 
an extra release if something slips under our radar, because by then we will 
have three branches opened: 2.2.x; 2.3.x and 2.4.dev.

All of this IMHO, of course.

Regards,
-- 
José Abílio

Re: How far is 2.3.0?

[Scott Kostyshak]

On Sat, Mar 04, 2017 at 09:53:08PM +0100, Guillaume Munch wrote:

> But the most important to me is if 2.3 could please be branched at
> feature freeze so that I don't have a backlog of patches to rebase six
> months later.

This is a good discussion to have early. My poor decision regarding
branching for the 2.2.0 cycle caused a lot of frustration for everyone.

When we branch 2.3, this branch would be named "2.3.x", right? The
slightly weird thing would be that the release manager would be in
charge of the 2.3.x branch until 2.3.0 and then the stable branch
maintainer would be in charge of the branch after 2.3.0. Before, it was
more clear because the stable branch maintainer was always in charge of
2.y.x branches because they were branched on release. Did I get that
difference correct? I suppose an alternative would be to call the branch
"2.3.0" and then after 2.3.0 is released, branch 2.3.x from 2.3.0. But I
think that is more complicated.

From what I understand, the only reason not to branch early is to avoid
work duplication (e.g. if automatic merge is not correct) on master
branch and 2.3.x branch. Are there any other disadvantages to branching
early? Perhaps there is a small probability that we forget a backport
(because we have to backport from master to both 2.3.x anad 2.2.x). For
the sake of argument, what would be the disadvantage to branching even
before the feature freeze?

This discussion gets more complex once we talk about our opinions
regarding 2.3.1 and 2.3.2 releases. When we get close to releasing
2.3.0, there will be bug fixes that might be viewed as desirable for
eventual inclusion in 2.3.x, but too risky for 2.3.0. If I remember
correctly, this was a point of debate. On the one hand, I think some
people thought "if a patch fixes a bug, and if it is viewed to be safe
enough to consider for stable branch, it should be included in 2.3.0 if
2.3.0 has not been released." On the other hand, some (including me)
thought "even if a patch fixes a bug and even if it looks safe, if the
bug is not important and if the patch didn't get testing, it might be
viewed as too risky to include the patch in 2.3.0 a week before
release". Note that "too risky" here does not mean risky on an absolute
level, it just means that the benefit-to-risk ratio is low.

Depending on which argument one prefers in the above paragraph, that is
what decides whether we should have e.g. 2.3.1-staging and 2.3.2-staging
branches or not. Why both 2.3.1-staging and 2.3.2-staging? Because 2.3.1
might be released very quickly after 2.3.0 is released, so it should not
be expected that a patch in there will get much additional testing. I
think there is a view that we should keep the possibility of doing a 2.3.1
release soon after the 2.3.0 release. The alternative might be to do a
2.3.0.1 release if there is real urgency, and otherwise proceed with
2.3.1 as a normal minor release.

Actually, now that I think about it, it seems that we could reduce the
number of branches by one by not having 2.3.1-staging. I wonder if the
following would be a clean way of proceeding: instead of 2.3.1-staging
and 2.3.2-staging, we just have 2.3.x-staging, and once 2.3.0 is tagged
(which is on the 2.3.x branch), 2.3.x-staging is immediately merged into
2.3.x. In the case that we need to do a quick release (e.g. a couple of
weeks after 2.3.0 is released), we branch 2.3.1 (or 2.3.0.1 if
preferred) from 2.3.0 (which will be behind 2.3.x at this point), and
just include the critical patches.  For the case where we do not need to
do an emergency release, we branch 2.3.1 from 2.3.x, as normal.

In case anyone is curious, here are some relevant discussions regarding
branching for the 2.2.0 cycle. If I understand correctly, most of the
problems and confusion would have been solved if I had branched 2.2.0
early.

https://www.mail-archive.com/search?l=mid=20160411230555.GA9496%40OptiPlex-9020.ad.ufl.edu
https://www.mail-archive.com/search?l=mid=57123167.2040904%40lyx.org
https://www.mail-archive.com/search?l=mid=57129605.6090806%40lyx.org

In case someone is craving wants more complexity, we can also discuss
our view for the last point release of 2.2.x. For example, should all
commits to the 2.3.x branch be backported to the 2.2.x branch? Or only
critical patches and the lyx2lyx patch?

> If you create a 2.4 milestone then I can already re-target the bugs that
> I care about so as to have a better picture of 2.3.

+1

We should also perhaps discuss how trac should be handled more
generally, but I think it makes sense to figure out our git branching
strategy first. For a disucssion on how we handled trac for the 2.2.0
cycle, see:
https://www.mail-archive.com/search?l=mid=57129763.9060007%40lyx.org

Scott


signature.asc
Description: PGP signature

Re: How far is 2.3.0?

[Guillaume Munch]

Le 24/02/2017 à 18:45, Jean-Marc Lasgouttes a écrit :

Hi there,

A good subject before the week-end: what do we need to do before
declaring feature freeze for 2.3? Personally I have finished a cycle or
breaking/fixing the math editor and would like to refrain from doing new
big architectural changes. I only have two or three patches pending,
plus of course all the bugs that Guillaume keeps finding.

Who has Work In Progress that should go to 2.3? How long do we need?




I have finished a front-end to QFileSystemWatcher and fixed
http://www.lyx.org/trac/ticket/10072. The UI still requires some
polishing but it is nearly there.

There is the u32string patch that is almost complete. But I need to get
back to it.

I think Richard has a few pending patches I am interested in:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195246.html
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg195204.html

But the most important to me is if 2.3 could please be branched at
feature freeze so that I don't have a backlog of patches to rebase six
months later.

If you create a 2.4 milestone then I can already re-target the bugs that
I care about so as to have a better picture of 2.3.

Guillaume

Re: How far is 2.3.0?

[José Abílio Matos]

On Friday, 24 February 2017 17.45.28 WET Jean-Marc Lasgouttes wrote:
> Hi there,
> 
> A good subject before the week-end: what do we need to do before
> declaring feature freeze for 2.3? Personally I have finished a cycle or
> breaking/fixing the math editor and would like to refrain from doing new
> big architectural changes. I only have two or three patches pending,
> plus of course all the bugs that Guillaume keeps finding.
> 
> Who has Work In Progress that should go to 2.3? How long do we need?
> 
> JMarc

The only obvious itch that I would like to scratch is the xdg-open patch that 
I have to redo on each version to configure.py.

A possible solution is to have specific component that is loaded for each 
platform for the programs that read and edit the supported document formats.
That would allow me to have a simply file that configures the checkViewer 
without needing to patch it in a tedious and error prone process.

Now regarding the other issue at hand and looking into history we have that:

2.2.0 -> 2016.05
2.1.0 -> 2014.04
2.0.0 -> 2011.04
1.6.0 -> 2008.11
1.5.0 -> 2007.07
1.4.0 -> 2006.03

First the obvious conclusion, those number are completely arbitrary. Each of 
those versions has been a major version on its own. And as usual I propose to 
go the way of gcc (not necessarily dropping the first .0 ;-) ). And use simply 
a major number and a minor number for the version.

An yearly version on the other hand seems a good compromise. Again gcc is a 
good model.

The next obvious question is who is the voluntary for the release manager 
role.

A good/nice weekend for everyone, :-)
-- 
José Abílio

Re: How far is 2.3.0?

[Scott Kostyshak]

On Fri, Feb 24, 2017 at 06:45:28PM +0100, Jean-Marc Lasgouttes wrote:

> Who has Work In Progress that should go to 2.3? How long do we need?

I don't have anything big I'm working on for 2.3.

Scott


signature.asc
Description: PGP signature