Add alignment in graphics option

[edu Gpl]

Dear lyx team
Thank you for all.

Now, when after i added any gaphics in my book:
- click right on the image, then setting, then i sellected width and ... ,
closed.
- then paragraph setting/ alignment/center.

I hope you can make it easy, by add alignment in the graphics setting, to
let us adding width and alignment in one step (one window).

Best regards

Re: [LyX/master] Win installer: prepare for a new 2.3 release (hopefully a beta)

[Uwe Stöhr]

El 03.08.2017 a las 00:03, Scott Kostyshak escribió:


Should this be beta1?


This depends on you, either alpha2 or beta 1.

regards Uwe

Re: What kinds of "code" can be embedded in a LyX document and "run" from LyX?

[Andrew Parsloe]

On 3/08/2017 8:45 a.m., Scott Kostyshak wrote:

On Tue, Aug 01, 2017 at 09:50:47PM +0200, Christian Ridderström wrote:


* Execution occurs at preview or when  related to exporting a document.


I agree it is a good idea to discuss specifically what can happen during preview
and what can only happen during export.

Scott

I don't know if it is relevant but a year or two ago in response to my 
nagging, Enrico made the document name available to preview (as 
\jobname). Before that \jobname contained only the name of the preview. 
But \jobname does not contain the path (or extension).


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [LyX/master] Win installer: prepare for a new 2.3 release (hopefully a beta)

[Scott Kostyshak]

On Mon, Jul 24, 2017 at 09:27:53PM -0400, Scott Kostyshak wrote:
> On Tue, Jul 25, 2017 at 12:31:50AM +0200, Uwe Stöhr wrote:
> > commit 52025d5c9b5857ae9a0df67d78cd75f8e955e288
> > Author: Uwe Stöhr 
> > Date:   Tue Jul 25 00:31:45 2017 +0200
> > 
> > Win installer: prepare for a new 2.3 release (hopefully a beta)
> > ---
> >  .../Win32/packaging/installer/ChangeLog.txt|9 -
> >  development/Win32/packaging/installer/settings.nsh |6 +++---
> >  2 files changed, 11 insertions(+), 4 deletions(-)
> > 
> > diff --git a/development/Win32/packaging/installer/ChangeLog.txt 
> > b/development/Win32/packaging/installer/ChangeLog.txt
> > index 1e56edf..d7836a3 100644
> > --- a/development/Win32/packaging/installer/ChangeLog.txt
> > +++ b/development/Win32/packaging/installer/ChangeLog.txt
> > @@ -1,4 +1,11 @@
> > -Changelog for LyX-230-alpha1:
> > +Changelog for LyX-230-alpha2:
> 
> Should this be beta1?

I forgot to CC Uwe.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Preferences shows current zoom instead of preference's default zoom (#10455)

[Scott Kostyshak]

On Tue, Jul 25, 2017 at 08:23:39AM +1000, racoon wrote:
> On 25.07.2017 07:49, Scott Kostyshak wrote:
> > On Sat, Jul 22, 2017 at 07:41:32PM +1000, racoon wrote:
> > > On 22.07.2017 08:38, Scott Kostyshak wrote:
> > 
> > > No, sorry. Most importantly, I do not understand what the debug messages
> > > mean. Unfortunately, I also do not have much time at my hands at the 
> > > moment
> > > either. I am happy to help though, if something in my code is unclear.
> > 
> > No problem, Daniel. Thanks for the reply. I'll take a look at it
> > hopefully within the next week.
> 
> Thanks Scott.

The issue comes from the call to dispatch, in the following part of your commit:

 bool GuiView::restoreLayout()
 {
QSettings settings;
+   lyxrc.currentZoom = settings.value("zoom", lyxrc.zoom).toInt();
+   lyx::dispatch(FuncRequest(LFUN_BUFFER_ZOOM, 
convert(lyxrc.currentZoom)));
settings.beginGroup("views");
settings.beginGroup(QString::number(id_));
QString const icon_key = "icon_size";

The reason the message is shown on startup for me is that there is no buffer
open. What is the purpose of having the dispatch there? Isn't the zoom
automatically set (via some other mechanism) when a buffer is opened?

Scott


signature.asc
Description: PGP signature

Safety/security: I've received some good advice

[Christian Ridderström]

Hi,

I've consulted about LyX with someone who's an IT security professional.
I'll later post that stuff separately to developers list, and/or add it to
the wiki page.
This post is just to make sure you guys can remind if I manage to forget as
I'm tired and won't do it tonight.
/Christian

Re: What kinds of "code" can be embedded in a LyX document and "run" from LyX?

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 09:50:47PM +0200, Christian Ridderström wrote:

> * Execution occurs at preview or when  related to exporting a document.

I agree it is a good idea to discuss specifically what can happen during preview
and what can only happen during export.

Scott

Re: [LyX/master] Cmake build: Ignore boost settings if we are using std-regex

[Scott Kostyshak]

On Mon, Jul 31, 2017 at 08:48:42AM +0200, Kornel Benko wrote:
> Am Montag, 31. Juli 2017 um 01:09:09, schrieb Scott Kostyshak 
> 
> > On Sun, Jul 30, 2017 at 07:41:02AM +0200, Kornel Benko wrote:
> > > Am Samstag, 29. Juli 2017 um 19:14:01, schrieb Scott Kostyshak 
> > > 
> > > > On Thu, Jul 27, 2017 at 11:32:06PM +0200, Kornel Benko wrote:
> > > > > commit 2fe59adbc89f56e7e192b57c90eb5e2a8338721c
> > > > > Author: Kornel Benko 
> > > > > Date:   Thu Jul 27 23:29:29 2017 +0200
> > > > > 
> > > > > Cmake build: Ignore boost settings if we are using std-regex
> > > > > 
> > > > > External/included boost is only used for the component regex
> > > > 
> > > > With this commit, I get the following message:
> > > > 
> > > > Unable to determine the system directory having searched
> > > > /home/scott/lyxbuilds/master/CMakeBuild/share/lyx/
> > > > Use the '-sysdir' command line parameter or set the environment 
> > > > variable
> > > > LYX_DIR_23x to the LyX system directory containing the file 
> > > > `chkconfig.ltx'.
> > > > 
> > > > Scott
> > > 
> > > Totally unexpected. What should boost have to do with system dir?
> > > Could you please test with clean build?
> > 
> > I tested with clean builds of 2fe59adb and 2fe59adb^, and see the same
> > difference.
> > 
> > The only difference in the output of the cmake commands is
> > 
> > "Using std regex"
> > 
> > The difference in the CMakeCache.txt files is:
> > 
> > $ diff CMakeCache_before.txt CMakeCache_after.txt 
> > 639,644d638
> > <
> > 
> > boost_BINARY_DIR:STATIC=/home/scott/lyxbuilds/master/CMakeBuild/3rdparty/boost/libs
> > < 
> > < //Value Computed by CMake
> > <
> > 
> > boost_SOURCE_DIR:STATIC=/home/scott/lyxbuilds/master/repo/3rdparty/boost/libs
> > < 
> > < //Value Computed by CMake
> > 871c865
> > < CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=26
> > ---
> > > CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=24
> > $ 
> > 
> > Are those changes expected?
> > 
> > With 2fe59adb, compilcation succeeds and I get the same error under the
> > following three cases:
> > 1. I omit -DLYX_EXTERNAL_BOOST
> > 2. I set it to -DLYX_EXTERNAL_BOOST=ON
> > 3. I set it to -DLYX_EXTERNAL_BOOST=OFF
> > 
> > With 2fe59adb^, if I set it to -DLYX_EXTERNAL_BOOST=ON, the CMake call
> > gives me:
> > 
> > -- Searching for boost
> > CMake Error at CMakeLists.txt:814 (message):
> >   Boost not found
> > 
> > Are those clues useful at all? If not, don't spend time on it. I will
> > take a deeper look when I have time.
> 
> Yes, they do. Looks like a very old CMakeLists.txt. The committed one has 
> this message
> on line 821. The mentioned commit 2fe59adb is later amended by b5c2e02e.

For archival purposes, this issue was fixed at b5a4e797.

Thanks, Kornel.

Scott

Re: Solved: lyx executable built with cmake will not run

[Scott Kostyshak]

On Wed, Aug 02, 2017 at 06:52:05PM +0200, Kornel Benko wrote:
> Am Dienstag, 1. August 2017 um 15:11:03, schrieb Kornel Benko 
> > Am Dienstag, 1. August 2017 um 14:47:36, schrieb Jean-Pierre Chrétien 
> > 
> > > Le 01/08/2017 à 10:57, Scott Kostyshak a écrit :
> > > > On Mon, Jul 31, 2017 at 06:23:07PM +0200, Jean-Pierre Chrétien wrote:
> > > >> Le 31/07/2017 à 18:09, Kornel Benko a écrit :
> > > >>
> 
> ...
> 
> > > Might be due to 2fe59adbc;
> 
> Yes. Corrected at b5a4e79736513aee6c8ef4da6eb05bee0e6ce17e

Thanks, this fixed my issue as well.

Scott

Re: Solved: lyx executable built with cmake will not run

[Kornel Benko]

Am Dienstag, 1. August 2017 um 15:11:03, schrieb Kornel Benko 
> Am Dienstag, 1. August 2017 um 14:47:36, schrieb Jean-Pierre Chrétien 
> 
> > Le 01/08/2017 à 10:57, Scott Kostyshak a écrit :
> > > On Mon, Jul 31, 2017 at 06:23:07PM +0200, Jean-Pierre Chrétien wrote:
> > >> Le 31/07/2017 à 18:09, Kornel Benko a écrit :
> > >>

...

> > Might be due to 2fe59adbc;

Yes. Corrected at b5a4e79736513aee6c8ef4da6eb05bee0e6ce17e

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Options for resolving the minted + shell-escape issue

[Richard Heck]

On 08/02/2017 10:11 AM, Guillaume MM wrote:
>  Please do not let Enrico's new attacks affect you.

Can we please put an end to this kind of public comment? If you want to
make
such remarks privately, that is totally reasonable. But this sort of
snark is totally
uncalled for, and it is not helping right now.

Richard

Re: Options for resolving the minted + shell-escape issue

[Richard Heck]

On 08/02/2017 07:25 AM, Enrico Forestieri wrote:
> On Wed, Aug 02, 2017 at 06:05:19AM -0400, Scott Kostyshak wrote:
>> [[So the situation is as Richard described it:]] we can of course decide to 
>> remove something before the final release.
> Moreover, this last sentence means that you still want a sword of Damocles 
> hanging on a feature that would have not been added without your interest for 
> it.

I don't think that is entirely fair. Scott was simply echoing a remark
*I* had made (I've restored something clipped), which is totally banal:
We can ALWAYS decide to remove something if we feel we have to do so. I
don't think that either Scott or I see any reason to do that now or
expect that there will be any such reason later. I, at least, just meant
to point out that deciding not to take a second vote doesn't mean we
can't act later if we feel we have to do so. Obviously.

And just to be clear, the kind of reason that could possibly lead to
removal of needauth, say, would NOT lie in the sorts of abstact
considerations that have dominated recent discussion. Rather, it would
emerge from testing, i.e., from problems encountered by users. So there
is no suggestion here, either, that we should re-litigate the issue.

Richard

Re: Options for resolving the minted + shell-escape issue

[Richard Heck]

On 08/01/2017 07:13 PM, Christian Ridderström wrote:
> On 1 August 2017 at 21:24, Richard Heck  > wrote:
>
> Hi Richard,
>
> It sounds like you complain about the time spent on discussing what I
> assume is not just the minted patch but safety/security in general.
> However, regarding spending to much time discussing safety, I can't
> help but think about LyX 2.2 where something was obviously missing in
> terms of safety.
> That leads me to conclude that something was missing, or went awry, in
> the development process of LyX 2.2. This, combined with you advocating
>
>  "... spend our time figuring how to make the needauth
> and shell-escape stuff as secure
>   as we can make it, given the present framework" 
>
> makes me a little concerned.
>
> It sounds like you argue for a release of 2.3 regardless of the
> absolute achieved level of safety, because:
> a) we've anyway done all that can be done using the needauth framework.
> b) it's anyway better than LyX 2.2.
>
> Would you mind clarifying your point of view?

No, I don't mean to complain about our discussing this in such detail.
Such discussions are tremendously important, since security issues are
tremendously important. I simply meant to point out that we *have*
discussed this in great detail. At some point we have to make a
decision. We could continue discussing the general issue---and the wiki
page, etc, that you've created are a good step in that direction---but
the overall view recently has been that the present discussion was not
changing anyone's mind. It was just getting people upset.

Since we have had to take a vote, we know it's a decision with which not
everyone will be happy. But once a decision has been made, we need to do
our best, *as a team*, to implement the decision that was made as best
we can. Continuing to discuss the question that's already been decided,
by rare vote, is not productive.

That said, it does matter to me that the needauth framework, so far as I
can see, makes things *better* than they were in LyX 2.2. LyX 2.3, in my
opinion, will be *more secure* than LyX 2.2 was. If I thought that
security was being *reduced*, that would be an entirely different matter.

I'm sure it's true that we could, in principle, do even better. That is
why it's not unreasonable to continue this discussion on a somewhat
different level. People who have the expertise to design a new solution,
and then to implement it, whether via AppArmor or whatever, should feel
free to make it a priority for 2.4 and create a feature branch for it.
(I'm guessing this would involve format changes.) Maybe that would even
be a reason to do an early release of 2.4. I don't mean to be
pre-judging that.

Richard

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Wed, Aug 02, 2017 at 04:11:42PM +0200, Guillaume MM wrote:
> 
> The first thing we will remember about your handling of this discussion
> is your commitment of rationality. Please do not let Enrico's new
> attacks affect you.

I have really no words able to correctly describe you.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Guillaume MM]

Le 01/08/2017 à 10:50, Scott Kostyshak a écrit :

On Mon, Jul 31, 2017 at 09:07:11PM +0200, Guillaume MM wrote:


I am sure that Scott meant to include in some way the option that I have
been advocating constantly from the beginning, which I understand is
probably 1. (Otherwise, I do not see what the option 1. refers to nor
who proposed it, and I would opt for not taking part in the vote.)


Yes my intention was to represent your opinion in a simplified way. I'm
sorry to have failed that. You will have an opportunity to write your
own option for the next vote (see separate email).



Hi Scott,

That's alright, I think my opinion was represented well enough. Patch
0002 was disabling minted as per 1., and patches 0001 and 0003 at

answer your more general question "how can we make LyX the most secure
for 2.3?". One can see it like that. 0001 takes various comments that
have been made about Enrico's patch by various people into account and
0003 fixes a small display issue. It just misses for now the enabling of
shell-escape via the improved needauth mechanism but this looks simple
enough to do, and after that it can be proposed as an improvement to
Enrico's mechanism.

The first thing we will remember about your handling of this discussion
is your commitment of rationality. Please do not let Enrico's new
attacks affect you.

Guillaume

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Wed, Aug 02, 2017 at 06:05:19AM -0400, Scott Kostyshak wrote:

> I expected the point about a second vote being unfair, but since I did not
> consider the first vote fair (due to my poor structuring of the options), I
> chose to do a second vote.

I must add that your fairness was lacking well before, trying to treat
differently dangerous converters and minted. But maybe you were skilfully
deceived to remove minted support but not the needauth one.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Jean-Marc Lasgouttes]

Agreed too. I will add that we should not neglect the harm we are inflicting to 
our smallish team by making people increasingly pissed off at each other. 
Security is important, but bikeshedding has a cost, and I am not sure that we 
can afford it.

We have to take into account that the minted problem is supposed to eventually 
fix itself, meaning that none of our choices will paint us in a corner. 
Therefore we can afford to be wrong, instead of looking for an elusive perfect 
solution.

JMarc

Le 2 août 2017 13:17:55 GMT+02:00, "Jürgen Spitzmüller"  a écrit 
>
>I agree.

Re: Options for resolving the minted + shell-escape issue

[Enrico Forestieri]

On Wed, Aug 02, 2017 at 06:05:19AM -0400, Scott Kostyshak wrote:
> 
> I am going to take the advice of the senior developers and to cancel the
> second vote.

Dear Scott, you can try to remove the nail but the hole remains.

> we can of course decide to remove something before the final release.

Moreover, this last sentence means that you still want a sword of Damocles
hanging on a feature that would have not been added without your interest
for it.

I am trying to analyze your behavior in this matter in order to take
a decision about what to do with my future involvement with LyX.

-- 
Enrico

Re: Options for resolving the minted + shell-escape issue

[Jürgen Spitzmüller]

Am 01.08.2017 9:24 nachm. schrieb "Richard post-beta1 vote, we may decide
to remove it.


It's obviously up to you, Scott, as release manager, but I agree with
Enrico, to some extent,
that this isn't the best policy. We have spent an enormous amount of
time on this and finally
have come to some kind of resolution. It really would be best to close
that part of the debate
and spend our time figuring out how to make the needauth and
shell-escape stuff as secure as
we can make it, given the present framework. Time spent re-litigating
the questions about the
framework is going to be wasted time.


I agree.

Jürgen


.

Richard

Re: [patch] update PDF viewers in configure.py

[Guenter Milde]

On 2017-08-02, Uwe Stöhr wrote:


Master PDF is a PDF editor, not viewer. 
-> it should be added to PDF editors

I an not sure PDF editors are already supported by configure.py, but they
can be set via Tools>Preferences.

+ no interference with PDF viewers
- it is not clear how to use this entry.

> Meanwhile I contacted the Master PDF devs and indeed the responded 
> quickly. I reported the problem that an executable name 
> "masterpdfeditor4" is a problem for use and that we won't spend time to 
> check the different version numbers. Moreover, on Windows the name of 
> the executable is just "masterpdfeditor". The will discuss this.

> So unless the name of the executable is not uniform on all OSes, I won't 
> support it. Thus I retract my patch.

Fine.

> I still think however that we should remove KPDF and KGhostscript. 
> However as we are in a feature freeze, I would postpone this to LyX 2.4.

Fine.

Günter

Re: Options for resolving the minted + shell-escape issue

[Pavel Sanda]

Christian Ridderström wrote:
> On 1 August 2017 at 01:25, Pavel Sanda  wrote:
> 
> Would you mind pointing me to that post?  I don't know if I simply missed it
> or was unable to read/consider/reply at the time.

I can, but would you mind start using some reasonable technical solution rather
than gmail if you want to participate in more complex threads on this email 
list?

Pavel

Re: Options for resolving the minted + shell-escape issue

[Scott Kostyshak]

On Wed, Aug 02, 2017 at 11:15:23AM +0200, Pavel Sanda wrote:
> Richard Heck wrote:
> > It's obviously up to you, Scott, as release manager, but I agree with 
> > Enrico,
> > to some extent, that this isn't the best policy. We have spent an enormous
> > amount of time on this and finally have come to some kind of resolution. It
> > really would be best to close that part of the debate and spend our time
> > figuring out how to make the needauth and shell-escape stuff as secure as we
> > can make it, given the present framework. Time spent re-litigating the
> > questions about the framework is going to be wasted time.
> 
> +1

I did not expect such strong opinions against a second vote. I expected the
point about a second vote being unfair, but since I did not consider the first
vote fair (due to my poor structuring of the options), I chose to do a second
vote. But it seems I did not correctly estimate the cost of a second vote, not
just in terms of time, but I think in other dimensions as well. I am going to
take the advice of the senior developers and to cancel the second vote.

In this decision to cancel the second vote, in addition to experience of the
developers who gave their opinions (on the list as well as through private
email), it also made a difference that Pavel, who did not vote for option 3, and
who was part of the reason I decided to have a second vote (because his was one
of the opinions not represented as an option), also supports canceling the
second vote.

Further, I do remember asking for one final cognitive spurt. And I really
appreciate those who gave it.

So the situation is as Richard described it: we can of course decide to remove
something before the final release. But as of now, there is no future vote
planned on this issue.

Thanks to everyone for your help and advice,

Scott


signature.asc
Description: PGP signature

Re: Long threads? / list etiquette? (Was: Options for resolving the minted + shell-escape issue)

[Pavel Sanda]

Scott Kostyshak wrote:
> Ah I did not realize you did that on purpose. I actually found it annoying 
> when
> I wanted to go up the discussion and couldn't because it was cut off

+1

Pavel

Re: Options for resolving the minted + shell-escape issue

[Pavel Sanda]

Richard Heck wrote:
> It's obviously up to you, Scott, as release manager, but I agree with Enrico,
> to some extent, that this isn't the best policy. We have spent an enormous
> amount of time on this and finally have come to some kind of resolution. It
> really would be best to close that part of the debate and spend our time
> figuring out how to make the needauth and shell-escape stuff as secure as we
> can make it, given the present framework. Time spent re-litigating the
> questions about the framework is going to be wasted time.

+1

Pavel

Re: Discussing minted/safety/etc (Was: Options for resolving the minted + shell-escape issue)

[Scott Kostyshak]

On Wed, Aug 02, 2017 at 01:00:47AM +0200, Christian Ridderström wrote:

> Hmm, and perhaps in case of votes, Scott should (be allowed to) weigh them
> differently depending on the persons knowledge. E.g., since I don't
> know/understand the (intended) safety design, why should my vote count as
> much as a potential safety "guru".

I will not be assigning weights to votes. We can restrict who votes (e.g. those
who participate in a discussion), but assigning subjective weights does not seem
like a good idea to me. There are ways to improve the vote for next time, and I
will write some ideas down and ask for feedback on them.

From what I see, you have great knowledge and experience with security. If the
above comment is because I did not reference you when I counted the votes, all I
can say is that it was a mistake.

> On a more practical level:
> Hindsight is 20-20, but regarding e.g. Enrico's patch, perhaps we should
> have created a branch representing that alternative?   This would have
> allowed that branch to always represent the latest improvement, thus
> avoiding people testing out an older patch accidentally.
> So we should keep the possibility of using branches in mind for future
> discussions.

This is a good idea, I think. We do have a features repository. I think part of
it is that I did not expect it to be such a long discussion. It snowballed.

> Perhaps there's other more practical things we could've done to make life
> easier.

Thanks for starting this discussion. I would like to spend more time on
reflection, but I also want to spend time on addressing issues needed to get
beta1 out.

> [*] Regarding SW design descriptions and actually being able to understand
> and review an intended design in advance, I'm probably a bit "damaged" from
> when I worked with satellite software (AOCS), e.g. as SW verification and
> validation manager.
> 
> In that field, lots of documentation was required which often was annoying,
> but for complicated stuff like FDIR (making the SW/satellite be able to
> cope with equipment failures), it really was essential to have the overall
> picture. The reason being that a tiny change in one area of the system
> could easily cause big problems in other areas, i.e. it's about unintended
> consequences.
> 
> Here I see several similarities between FDIR and the safety/security for
> LyX, e.g. that adding a neat feature like previews of Gnuplot figures
> could've led to a big security hole.
> 
> Another similarity is that you can't do FDIR only at a low level, you need
> a system perspective.
> I think it's the same with safety/security for LyX: If we only consider
> each feature separately, we're going to screw up. Two features in isolation
> might be safe, but when available together it might "leak".
> 
> Another similarity is needing to define our objectives, and what we
> consider "good enough" safety. If we don't understand what we're trying to
> achieve, it's e.g. not possible to review a design to see if it achieves
> the objectives.

I'm glad you bring this experience to the discussion. You can provide a unique
view that the rest of us might not see.

Scott


signature.asc
Description: PGP signature

Re: Long threads? / list etiquette? (Was: Options for resolving the minted + shell-escape issue)

[Scott Kostyshak]

On Wed, Aug 02, 2017 at 12:20:24AM +0200, Christian Ridderström wrote:
> Richard wrote:
> 
> > We have spent an enormous amount of time on this ...
> >
> 
> HI,
> 
> Regarding the discussion of LyX's safety I'd like to make a few remarks
> related to ... ?list etiquette? Not sure what the correct term should be,
> but it ought to be clear below.
> 
> Really long threads:
> Are we really ok with threads containing upwards a hundred posts?
> Perhaps at some point it's necessary to simply start the thread over?
> 
> Thread splitting:
> I've tried to break off topics into separate threads, but it _seems_ like
> it's mainly me doing that.

Ah I did not realize you did that on purpose. I actually found it annoying when
I wanted to go up the discussion and couldn't because it was cut off, but that's
probably because I don't have much experience with thread-splitting. I'd be
happy to change my workflow if others preferred it.

> Or maybe it's how the gmail interface presents the thread to me?
> 
> Is it something we're not doing anymore.
> Should thread splitting be avoided, or should we try to do it more?

It might be useful to know what other mailing lists do and if they have related
policies.

> 
> I'm using gmail's web interface these days. This might be why I'm finding
> it difficult to efficiently follow threads that are so long.
> - The gmail labs thing I used for replying to parts of an e-mail is no
> longer working.
> - Sometimes the replies don't go to the list. *sigh*
> - I haven't figured out how to mark a single e-mail as unread,
>   e.g. when I feel I need to reply to it later, and instead have to mark
> the entire thread.
>   This does _not_ work well for long threads.
> 

I find mutt to be very helpful with emails, but it takes a long time to get used
to, and I'm not sure it would solve the particular issues you reference.

> Are there other things we could've done to do the discussion more
> efficiently?
> 
> Using a wiki page for security topics didn't seem like it's (so far) helped
> anything.
> Would a LyX document in git have been better?
> Or a plain text file?

Good questions, I don't know the answer.

Scott


signature.asc
Description: PGP signature

Re: Options for resolving the minted + shell-escape issue

[Scott Kostyshak]

On Wed, Aug 02, 2017 at 01:13:14AM +0200, Christian Ridderström wrote:
> On 1 August 2017 at 21:24, Richard Heck  wrote:
> 
> > On 08/01/2017 04:54 AM, Scott Kostyshak wrote:
> > > On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
> > >> Pavel Sanda wrote:
> > >>> I did not hear your reaction to it either.
> > >> I see you just did that, sorry... P
> > > I believe that except for Enrico and I, everyone who participated in
> > > this conversation has voted.
> 
> 
> Hi Scott,
> 
> For the record, I'm not sure why I'm not included in people who particpated
> but haven't voted.

I meant to mention you and just did not. I'm sorry about that. I really do
appreciate your participation in the discussion.

> Anyway, you're the release manager so your decisions goes.

No, thanks for pointing that out.

Scott

Re: Options for resolving the minted + shell-escape issue

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 03:24:48PM -0400, Richard Heck wrote:
> On 08/01/2017 04:54 AM, Scott Kostyshak wrote:
> > On Tue, Aug 01, 2017 at 02:35:27AM +0200, Pavel Sanda wrote:
> >> Pavel Sanda wrote:
> >>> I did not hear your reaction to it either.
> >> I see you just did that, sorry... P
> > I believe that except for Enrico and I, everyone who participated in
> > this conversation has voted. Uwe was interested in voting, but as the
> > vote stands currently, his vote would not change the outcome. I don't
> > have indication that any other LyX developer is interested in voting.
> >
> > The results are the following:
> >
> > 1: Guillaume (hesitantly [1]), .5 Pavel
> > 2: .5 Pavel
> > 3: Kornel, JMarc, Jürgen, Richard
> >
> > Option 3 wins the vote. My decision is to go forward with Enrico's
> > latest patch for beta1.
> >
> > Because the vote was not a blowout, and because I did not represent the
> > opinions of at least Guillaume and Pavel in the options, we will have
> > another vote two weeks after beta1 is released. Each developer may
> > propose one option that will be included in the vote.
> >
> > So to be clear: although we are going to release beta1 with minted
> > support, depending on the post-beta1 vote, we may decide to remove it.
> 
> It's obviously up to you, Scott, as release manager, but I agree with
> Enrico, to some extent,
> that this isn't the best policy. We have spent an enormous amount of
> time on this and finally
> have come to some kind of resolution.

I understand your points and took a long time to make that decision. And since I
have so much respect for Enrico and you, especially given your long experience
as the stable release manager, I will reflect on the decision I made much more
(probably long past the 2.3.0 release).

> It really would be best to close
> that part of the debate
> and spend our time figuring out how to make the needauth and
> shell-escape stuff as secure as
> we can make it, given the present framework. Time spent re-litigating
> the questions about the
> framework is going to be wasted time.
> We can always decide to remove things, especially before a major
> release. If there are serious
> problems or concerns that arise during testing, then those can be raised
> at that point. Or if one
> or more of us who preferred the present course has doubts, we can raise
> those.

> But simply
> having another vote (a rare enough occurrence around here) just because
> people weren't
> entirely happy with how the options were presented doesn't strike me as
> a good idea. There
> is no indication I can see that the people who voted (3) might, let
> alone would, have voted
> differently had the other options been differently described. I think we
> all understood well
> enough what the broad issue was.

If you feel that further discussion is a waste of time, then just don't
participate in the discussion and keep your vote the same. Others who feel
similarly can do the same. That way there is not much time lost for those who
choose to do that. If those who voted in favor of the patch just decide that
they are sure that is the right way forward and no other points or alternatives
would change their mind, then you can all keep your vote there.

This way, we at least move on towards beta1.

Scott

Re: [LyX/master] UserGuide.lyx: accept and distribute description of inverted branches

[Scott Kostyshak]

On Tue, Aug 01, 2017 at 01:52:14PM +0200, Uwe Stöhr wrote:
> 
>   Original Message  
> From: Scott Kostyshak
> Sent: Dienstag, 1. August 2017 10:57
> 
> >  So I guess that for Additional, I will create a
> > Changelog-Additional-LyX_23x.txt retaining only what is to be done once I've
> > done the copy to es|fr[ja.
> > CC'ing Uwe since I think he does not follow all conversations on the‎ list.
> 
> Sorry, I forgot to announce what we agreed to: I will take care for the 
> UserGuide and JP for Additional and Customization. Math and EmbeddedObjects 
> should be ready for 2.3.
> JP will decide what suits best fir the files he is working on.

Nice. Thanks for the update.

Scott

Re: Ad a section in the wiki page about LaTeX safety

[Jean-Pierre Chrétien]

Le 02/08/2017 à 09:30, Jean-Pierre Chrétien a écrit :

Hello,

Following Christian's suggestion, I've added a section about the subject

http://wiki.lyx.org/Devel/SafetyAndSecurity#toc2


I've been unable to approve the last link, none of the passwords would work.

--
Jean-Pierre

Ad a section in the wiki page about LaTeX safety

[Jean-Pierre Chrétien]

Hello,

Following Christian's suggestion, I've added a section about the subject

http://wiki.lyx.org/Devel/SafetyAndSecurity#toc2

Is it useful/appropriate?

There is also in the Customization manual a section (6.4) about security and 
safety for externel material. Should this be rewritten in the light of the new 
framework?


--
Jean-Pierre