Le 06/11/2015 21:42, Georg Baum a écrit :
I think there is general consensus about \justification and
\output_changes, so if this is OK with Scott you could move these to
preferences, but for \track_changes I do not see a consensus, so this
setting should not be changed so short before a release IMHO.
I think that there are still valid points to be discussed, before we
resort to democracy.
I think everything is on the table now and we can cut down the
discussion to this: can we reach a consensus around adding some form of
document setting that says "Always open this document with change
tracking enabled"?
My impression is that it satisfies both use cases of letting us treat
change tracking as a per-user-per-document setting, and providing us
with a way of distributing copies of change-tracking enabled documents.
It would do so better than what we have now in both cases IMO.
This does not seem inconsistent with what Libreoffice is doing, which
however is not entirely comparable: Libreoffice does indeed store change
tracking, but on the one hand they have the philosophy of storing user
settings in the file unlike LyX, and on the other hand they include two
provisions: 1) for playing nicely with git and 2) for not loading user
settings* if that's not wanted.
(*disclaimer: for the latter I did not check that change tracking
belongs to these non-loaded settings)
Democracy is not the point IMHO: The point is not to further delay the
release. Implementing a small and safe file format change where everybody
agrees that it is useful does not produce a significant delay. Discussing a
controversal change where no easy solution is in sight has the potential of
delaying the release (at least if the possibility of implementing the change
before the release is seriously considered). Therefore I think that it is
not the right time right now to have this discussion.
Yes, I fully understand this point and I agree that a decision has to
be taken somehow quickly, this is why I brought the subject to the list.
We are in the process of releasing alpha and this discussion is not
delaying alpha, so I believe it comes just in time for 2.2 given the
annoyance of the bug and the fact that it incurs a file format change.
The other factor is the schedule for the format freeze which I do not
request to be delayed. If the case above does not convince, or if there
is not enough time before the format freeze, then I am not spending time
on an half-baked feature and I will just make the most trivial change
there is to be made to avoid this particular merge conflict.
Guillaume
