Le 09/06/2016 à 04:03, Richard Heck a écrit :
On 06/08/2016 03:57 PM, Georg Baum wrote:
Guillaume Munch wrote:
Le 07/06/2016 00:00, Richard Heck a écrit :
Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.
Thi
Le 15/06/2016 00:51, Enrico Forestieri a écrit :
On Fri, Jun 10, 2016 at 10:20:32PM +0100, Guillaume Munch wrote:
As for lyx2lyx, I gave one example of a commit which explicitly said
that it would not be made round-trip, and another example where it had
to be fixed afterwards because a special c
On Fri, Jun 10, 2016 at 10:20:32PM +0100, Guillaume Munch wrote:
> As for lyx2lyx, I gave one example of a commit which explicitly said
> that it would not be made round-trip, and another example where it had
> to be fixed afterwards because a special case was not taken into
> accountn because it i
Le 08/06/2016 22:36, Liviu Andronic a écrit :
On Wed, Jun 8, 2016 at 10:14 PM, Guillaume Munch wrote:
Le 08/06/2016 20:48, Pavel Sanda a écrit :
Guillaume Munch wrote:
Here's what I suggest. Let's do, on a trial basis for the
duration of 2.3dev, a branch that mirrors master but inserts
pat
On 06/08/2016 03:57 PM, Georg Baum wrote:
> Guillaume Munch wrote:
>
>> Le 07/06/2016 00:00, Richard Heck a écrit :
>>> Our use of git would make it very easy for us to have a branch in which
>>> new features not requiring format changes could also be put.
>>>
>> This solution would be fine by me t
On Wed, Jun 8, 2016 at 10:14 PM, Guillaume Munch wrote:
>
> Le 08/06/2016 20:48, Pavel Sanda a écrit :
>>
>> Guillaume Munch wrote:
>>>
>>> Here's what I suggest. Let's do, on a trial basis for the duration of
>>> 2.3dev, a branch that mirrors master but inserts patches to disable the
>>> input an
Le 08/06/16 à 22:14, Guillaume Munch a écrit :
As long as I am allowed to ignore the third branch completely I am
fine with that.
I think this is the idea.
So why not, indeed.
JMarc
Le 08/06/2016 20:57, Georg Baum a écrit :
Guillaume Munch wrote:
Le 07/06/2016 00:00, Richard Heck a écrit :
Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.
This solution would be fine by me too, if people
Le 08/06/2016 20:48, Pavel Sanda a écrit :
Guillaume Munch wrote:
Here's what I suggest. Let's do, on a trial basis for the duration of
2.3dev, a branch that mirrors master but inserts patches to disable the
input and output of new file-format features (as well as layout changes,
etc.) after eac
Guillaume Munch wrote:
> Le 07/06/2016 00:00, Richard Heck a écrit :
>>
>> Our use of git would make it very easy for us to have a branch in which
>> new features not requiring format changes could also be put.
>>
>
> This solution would be fine by me too, if people agree to have three
> branches
Guillaume Munch wrote:
> Here's what I suggest. Let's do, on a trial basis for the duration of
> 2.3dev, a branch that mirrors master but inserts patches to disable the
> input and output of new file-format features (as well as layout changes,
> etc.) after each file-format change. We would see if
Le 07/06/2016 00:35, Guillaume Munch a écrit :
Le 07/06/2016 00:00, Richard Heck a écrit :
On 06/06/2016 06:40 PM, Guillaume Munch wrote:
The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format chang
On Tue, Jun 7, 2016 at 12:10 AM, Andrew Parsloe wrote:
> On 7/06/2016 9:50 a.m., Richard Heck wrote:
>>
>> On 06/06/2016 03:33 PM, Georg Baum wrote:
>>>
>>> Jean-Marc Lasgouttes wrote:
>>>
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>
> Yet, most of the file format changes are ve
Le 07/06/2016 00:00, Richard Heck a écrit :
On 06/06/2016 06:40 PM, Guillaume Munch wrote:
The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format changes remain to be fully tested.
This assumes the
On 06/06/2016 06:40 PM, Guillaume Munch wrote:
>
> The point of the proposal is to enabling the early testing and release
> of *non-file-format* changes. Then for a proper master release only
> file-format changes remain to be fully tested.
This assumes these aspects do not interact. Oftentimes, t
On 06/06/2016 06:10 PM, Andrew Parsloe wrote:
> On 7/06/2016 9:50 a.m., Richard Heck wrote:
>> On 06/06/2016 03:33 PM, Georg Baum wrote:
>>> Jean-Marc Lasgouttes wrote:
>>>
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
> Yet, most of the file format changes are very simple. I wonder
>>>
Le 06/06/2016 22:47, Richard Heck a écrit :
On 06/06/2016 04:27 PM, Guillaume Munch wrote:
Le 06/06/2016 20:33, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
Yet, most of the file format changes are very simple. I wonder
whether one could i
On 7/06/2016 9:50 a.m., Richard Heck wrote:
On 06/06/2016 03:33 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
Yet, most of the file format changes are very simple. I wonder whether
one could introduce a single compilation variable to disabl
On 06/06/2016 03:33 PM, Georg Baum wrote:
> Jean-Marc Lasgouttes wrote:
>
>> Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>>> Yet, most of the file format changes are very simple. I wonder whether
>>> one could introduce a single compilation variable to disable them,
>>> and ask developers to e
On 06/06/2016 04:27 PM, Guillaume Munch wrote:
> Le 06/06/2016 20:33, Georg Baum a écrit :
>> Jean-Marc Lasgouttes wrote:
>>
>>> Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
Yet, most of the file format changes are very simple. I wonder
whether one could introduce a single compilation
Le 06/06/2016 20:33, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
Yet, most of the file format changes are very simple. I wonder
whether one could introduce a single compilation variable to
disable them, and ask developers to enclose file-fo
Jean-Marc Lasgouttes wrote:
> Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>> Yet, most of the file format changes are very simple. I wonder whether
>> one could introduce a single compilation variable to disable them,
>> and ask developers to enclose file-format-specific code between the
>> c
Liviu Andronic wrote:
> We already have nightly builds for Ubuntu Linux:
> https://launchpad.net/~lyx-devel/+archive/ubuntu/daily
>
> It's been running for couple of years (probably all through the 2.2
> development cycle), though I'm not sure it's made much of an impact in
> terms of testing and
Sorry for the late reply, I somehow missed this message.
Jean-Marc Lasgouttes wrote:
> Le 31/05/2016 à 22:26, Georg Baum a écrit :
>> We need to decide: Either have a fixed schedule, and an unknown feature
>> set of the next release, or a fixed feature set, and an unknown schedule.
>> We do not
Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
Yet, most of the file format changes are very simple. I wonder whether
one could introduce a single compilation variable to disable them,
and ask developers to enclose file-format-specific code between the
corresponding #ifdefs. (For instance in my
Le 03/06/2016 13:02, Jean-Marc Lasgouttes a écrit :
Le 31/05/2016 à 22:26, Georg Baum a écrit :
In addition I would suggest the following: (Officially) allow new
features that do not require a file format change into minor
releases.
The main reason is again that this allows testing more
regular
On Friday, June 3, 2016 2:02:15 PM WEST Jean-Marc Lasgouttes wrote:
> I prefer the fixed schedule. We never know exactly when starting a
> release cycle what features will happen or not. But we can enforce when
> the release will happen.
+1
--
José Abílio
Le 03/06/2016 à 15:03, Liviu Andronic a écrit :
We already have nightly builds for Ubuntu Linux:
https://launchpad.net/~lyx-devel/+archive/ubuntu/daily
It's been running for couple of years (probably all through the 2.2
development cycle), though I'm not sure it's made much of an impact in
terms
On Fri, Jun 3, 2016 at 2:02 PM, Jean-Marc Lasgouttes wrote:
> Le 31/05/2016 à 22:26, Georg Baum a écrit :
>>
>> We need to decide: Either have a fixed schedule, and an unknown feature
>> set
>> of the next release, or a fixed feature set, and an unknown schedule. We
>> do
>> not have enough man po
Le 31/05/2016 à 22:26, Georg Baum a écrit :
We need to decide: Either have a fixed schedule, and an unknown feature set
of the next release, or a fixed feature set, and an unknown schedule. We do
not have enough man power for defining both a fixed feature set and a fixed
release schedule.
I pre
On Tue, May 31, 2016 at 10:26:57PM +0200, Georg Baum wrote:
> Guillaume Munch wrote:
> - Have a build server that does automatic builds on a regular basis for all
> three platforms (Linux, OS X, windows) and makes binary packages and build
> logs available.
This would be a great way to get feed
On Thu, Jun 02, 2016 at 02:00:20AM +0200, Uwe Stöhr wrote:
> There are 2 large security holes in ImageMagick (and also GraphicsMagick)
> that have been fixed:
> (article in German:
> http://www.heise.de/newsticker/meldung/Luecke-in-ImageMagick-und-GraphicsMagick-ermoeglicht-erneute-Angriffe-322381
There are 2 large security holes in ImageMagick (and also
GraphicsMagick) that have been fixed:
(article in German:
http://www.heise.de/newsticker/meldung/Luecke-in-ImageMagick-und-GraphicsMagick-ermoeglicht-erneute-Angriffe-3223811.html)
I therefore decided to release a new installer for LyX 2
On Tue, May 31, 2016 at 10:26:57PM +0200, Georg Baum wrote:
> Guillaume Munch wrote:
>
> > Le 26/05/2016 07:45, Jean-Marc Lasgouttes a écrit :
> >
> >> Time to think about the release date of 2.3.0 now ;)
> >>
> >
> > Yes, let's have this discussion :)
> >
> > I find the interval between featur
Guillaume Munch wrote:
> Le 26/05/2016 07:45, Jean-Marc Lasgouttes a écrit :
>
>> Time to think about the release date of 2.3.0 now ;)
>>
>
> Yes, let's have this discussion :)
>
> I find the interval between feature releases too high. Having an
> interval longer than one year (more than two fo
Guillaume Munch wrote:
> The schedule could be decided in advance, and be on the website for
> clarity.
This is more or less decision of release manager and his style. Some
releases had that and some did not.
> In addition I would suggest the following: (Officially) allow new
> features that do
Le 26/05/2016 07:45, Jean-Marc Lasgouttes a écrit :
Le 25/05/2016 19:11, Jürgen Spitzmüller a écrit :
Thanks to everyone for all the help with the final steps in the
release
process.
Congratulations. And thanks for the excellent management job, Scott.
Indeed. You did it much more thoroughly
On Sat, May 28, 2016 at 03:36:28AM +0200, Uwe Stöhr wrote:
> Am 27.05.2016 um 09:20 schrieb Scott Kostyshak:
>
> > > It was more tricky than I thought. However, I solved the problems and
> > > uploaded a new version:
> > >
> > > http://ftp.lyx.de/LyX%202.2.0/
>
> Just for information: Today I te
Am 27.05.2016 um 09:20 schrieb Scott Kostyshak:
It was more tricky than I thought. However, I solved the problems and
uploaded a new version:
http://ftp.lyx.de/LyX%202.2.0/
Just for information: Today I tested a lot more and despite minir issues
(e.g. 2 residues after uninstalling LyX) they
Scott Kostyshak wrote:
> The tarballs for LyX 2.2.0 can be found at
>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0/
>
quickly tested on ubuntu 12.04 & gentoo x86 and seemed ok. p
On Fri, May 27, 2016 at 03:09:59AM +0200, Uwe Stöhr wrote:
> Am 27.05.2016 um 01:03 schrieb Scott Kostyshak:
>
> > > I will try to release a new version withing 2 hours or so.
>
> It was more tricky than I thought. However, I solved the problems and
> uploaded a new version:
>
> http://ftp.lyx.d
Am 27.05.2016 um 01:03 schrieb Scott Kostyshak:
I will try to release a new version withing 2 hours or so.
It was more tricky than I thought. However, I solved the problems and
uploaded a new version:
http://ftp.lyx.de/LyX%202.2.0/
sorry and regards
Uwe
On Thu, May 26, 2016 at 11:30:03PM +0200, Uwe Stöhr wrote:
> Am 26.05.2016 um 16:05 schrieb Uwe Stöhr:
>
> > Here it is:
> > http://ftp.lyx.de/LyX%202.2.0/
>
> As always a release without testing is very bad. I only had an hour but
> fortunately have now time to test it and there are some errors
Am 26.05.2016 um 16:05 schrieb Uwe Stöhr:
Here it is:
http://ftp.lyx.de/LyX%202.2.0/
As always a release without testing is very bad. I only had an hour but
fortunately have now time to test it and there are some errors and
mistakes if Lyx is installed the first time and without admin
privi
On Thu, May 26, 2016 at 04:05:24PM +0200, Uwe Stöhr wrote:
> Am 25.05.2016 um 00:29 schrieb Uwe Stöhr:
>
> > Despite of the warning the compilation run fine and I have an installer
> > ready.
>
> Here it is:
> http://ftp.lyx.de/LyX%202.2.0/
Thanks they are uploaded.
> It contains the fresh MiKT
Uwe Stöhr wrote:
> Am 25.05.2016 um 00:37 schrieb Richard Heck:
>
>> We have lots of warnings like this. They are usually fixed by doing the
>> conversion explicitly, so probably nothing really needs to be done for
>> the release.
>
> This is suspicious to me because usually MSVC has good reason
Le 26/05/2016 15:12, Uwe Stöhr a écrit :
Am 25.05.2016 um 00:37 schrieb Richard Heck:
We have lots of warnings like this. They are usually fixed by doing the
conversion explicitly, so probably nothing really needs to be done for
the release.
This is suspicious to me because usually MSVC has g
Am 25.05.2016 um 00:37 schrieb Richard Heck:
We have lots of warnings like this. They are usually fixed by doing the
conversion explicitly, so probably nothing really needs to be done for
the release.
This is suspicious to me because usually MSVC has good reasons for
issuing a dataloss warnin
Am 25.05.2016 um 00:29 schrieb Uwe Stöhr:
Despite of the warning the compilation run fine and I have an installer
ready.
Here it is:
http://ftp.lyx.de/LyX%202.2.0/
It contains the fresh MiKTeX release from yesterday. However, I did not
yet have the time to test new installation of LyX/MiKTeX
On Wednesday, May 25, 2016 7:11:14 PM WEST Jürgen Spitzmüller wrote:
> Congratulations. And thanks for the excellent management job, Scott.
>
> Jürgen
I agree. :-)
Well done.
--
José Abílio
Le 25/05/2016 19:11, Jürgen Spitzmüller a écrit :
Thanks to everyone for all the help with the final steps in the
release
process.
Congratulations. And thanks for the excellent management job, Scott.
Indeed. You did it much more thoroughly than I would have been able to.
Time to think about
On Tue, May 24, 2016 at 08:50:14PM -0400, Scott Kostyshak wrote:
> On Wed, May 25, 2016 at 12:29:04AM +0200, Uwe Stöhr wrote:
> > Am 24.05.2016 um 04:32 schrieb Scott Kostyshak:
> >
> > > As usual I'll wait before announcing the release until after uploading
> > > the binaries and providing some t
Am Montag, den 23.05.2016, 22:32 -0400 schrieb Scott Kostyshak:
> Hi all,
>
> The tarballs for LyX 2.2.0 can be found at
>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0/
>
> As usual I'll wait before announcing the release until after
> uploading
> the binaries and providing some time for
Am Dienstag, 24. Mai 2016 um 21:16:33, schrieb Georg Baum
> Scott Kostyshak wrote:
>
> > Hi all,
> >
> > The tarballs for LyX 2.2.0 can be found at
> >
> > ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0/
>
> Builds and runs fine on debian 8.1, except when configuring with version
> suffix
On Wed, May 25, 2016 at 12:29:04AM +0200, Uwe Stöhr wrote:
> Am 24.05.2016 um 04:32 schrieb Scott Kostyshak:
>
> > As usual I'll wait before announcing the release until after uploading
> > the binaries and providing some time for the mirrors.
>
> Great job Scott! Many thanks for all your patient
On 05/24/2016 06:29 PM, Uwe Stöhr wrote:
> Am 24.05.2016 um 04:32 schrieb Scott Kostyshak:
>
>> As usual I'll wait before announcing the release until after uploading
>> the binaries and providing some time for the mirrors.
>
> Great job Scott! Many thanks for all your patient work.
>
> I built it
Am 24.05.2016 um 04:32 schrieb Scott Kostyshak:
As usual I'll wait before announcing the release until after uploading
the binaries and providing some time for the mirrors.
Great job Scott! Many thanks for all your patient work.
I built it now and noticed 2 things:
- There is a dataloss warn
Scott Kostyshak wrote:
> Hi all,
>
> The tarballs for LyX 2.2.0 can be found at
>
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0/
Builds and runs fine on debian 8.1, except when configuring with version
suffix: http://www.lyx.org/trac/ticket/10159. Since this also happens with
2.1.4 it i
Hi all,
The tarballs for LyX 2.2.0 can be found at
ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0/
As usual I'll wait before announcing the release until after uploading
the binaries and providing some time for the mirrors.
Thanks to everyone for all the help with the final steps in the rele
59 matches
Mail list logo
