Le 08/06/2016 22:36, Liviu Andronic a écrit :
On Wed, Jun 8, 2016 at 10:14 PM, Guillaume Munch <g...@lyx.org> 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 and output of new file-format
features (as well as layout changes, etc.) after each
file-format change. We would see if the idea works out.
I was going to do something like this anyway for myself, so I
propose to take care of it until it gains some momentum. At
first we could just make nightlies out of it for Ubuntu.
One roadblock that I am expecting is that the author of the
original file format change knows better than me how to block
it, but in case of trouble I can ask for advice. I plan to
include the patches responsible for file format changes and
patch them afterwards, because otherwise I expect the code to
diverge too much. If at some point it no longer works then I
will stop.
I will call the branch “unstable”.
Agreement? Suggestions?
So what is the goal here. Jut to get aditional testing from
interested parties or to make release from this branch at the
end?
In a first time the goal would be to have nightlies, if Liviu
agrees that we reuse his infrastructure.
Generally I'm not convinced that spreading testing over two types of
master builds is a good idea, especially since we do not have such
testing manpower anyway. The problem with bleeding edge master is
not confined to fileformat changes (and in any case as it had been
suggested you can still export to 2.prev anyway) --- master will
always contain regressions and other nastiness, which is more likely
to keep testers at bay, at least those who use LyX for production.
And, for me at least, it feels strange to test neutered bleeding
edge code --- seems like a way to keep testers from trying out
latest fileformat changes and associated complications. (Imagine for
instance if the radical 2.2.0dev beamer modifications hadn't gotten
the attention they deserved...)
The target demographics are people who currently would use stable
dailies, but who would be fine getting a little more cuts. I do not
think that it would take testers away from master dailies, who are
already fine with the file format changes.
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 is developped on a trial-and-error basis. Moreover
people may be asked to export by hand a few times, but not constantly.
For many people, it would not be sensible to rely on lyx2lyx. I know for
me it isn't.
We can of course set up daily builds using this third branch, but I
wouldn't put them in the lyx-devel PPAs. Given that the packaging
arrangements are already ready for daily builds (though I still have
to prepare the 2.3 builds, probably towards the end of the month),
setting up a new recipe/PPA should be very easy and I'll gladly walk
you through it.
Thank you very much for your kind offer of assistance. I will likely
take you up on it.
Regarding the PPA, my condition is to do something (experimental yet)
official. Therefore I would prefer to use the official PPA, and the
unstable dailies would also be advertised on the web site. My point
being that I would not be asking for the consent of the community of LyX
developers, and agreement over what is allowed to go in it, if it was a
little thing that I was going to do on the side.
Guillaume
