On Sat, Nov 21, 2015 at 10:37:18AM -0500, Richard Heck wrote:
> On 11/21/2015 12:02 AM, Scott Kostyshak wrote:
> > On Fri, Nov 20, 2015 at 08:06:16PM -0800, Pavel Sanda wrote: >> Richard
> > Heck wrote: Did Guillaume's regex patch fix the crash
> you are talking about? >>> >>> Yes, it did. Yo
On 11/21/2015 12:02 AM, Scott Kostyshak wrote:
> On Fri, Nov 20, 2015 at 08:06:16PM -0800, Pavel Sanda wrote: >> Richard Heck
> wrote: Did Guillaume's regex patch fix the crash
you are talking about? >>> >>> Yes, it did. You actually could just
release a sort of alpha1.1 tarball >>> with just
Scott Kostyshak wrote:
> OK, but I got the feeling that one week would be too long. Richard are
> you OK with that?
In case it was unclear from my other message: Current master has a very
similar regex problem as alpha1, but with swapped compilers and without
crash: alpha1 is broken for C++11 m
On Fri, Nov 20, 2015 at 08:06:16PM -0800, Pavel Sanda wrote:
> Richard Heck wrote:
> > > Did Guillaume's regex patch fix the crash you are talking about?
> >
> > Yes, it did. You actually could just release a sort of alpha1.1 tarball
> > with just that one patch applied. It'd save some problems fo
Richard Heck wrote:
> > Did Guillaume's regex patch fix the crash you are talking about?
>
> Yes, it did. You actually could just release a sort of alpha1.1 tarball
> with just that one patch applied. It'd save some problems for some
No please, release the other updates as well, esp. monolithic b
On Fri, Nov 20, 2015 at 02:14:41PM -0500, Richard Heck wrote:
> > OK how soon? Should we wait a few days to get feedback on alpha1 to
> see if we can make some other quick corrections for alpha2? Or would you
> suggest going forward with alpha2 as soon as possible?
>
> I guess we can wait a bit,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/20/2015 01:32 PM, Scott Kostyshak wrote:
> On Fri, Nov 20, 2015 at 12:04:15PM -0500, Richard Heck wrote:
>> On 11/20/2015 04:02 AM, Scott Kostyshak wrote:
>>> Dear all, > > Binaries for 2.2.0alpha1 have been uploaded and the
pre release has
>>
On Fri, Nov 20, 2015 at 12:04:15PM -0500, Richard Heck wrote:
> On 11/20/2015 04:02 AM, Scott Kostyshak wrote:
> > Dear all, > > Binaries for 2.2.0alpha1 have been uploaded and the pre
> > release has
> been > announced on lyx-users and twitter. If anyone has a twitter
> account, > please consider
On 11/20/2015 04:02 AM, Scott Kostyshak wrote:
> Dear all, > > Binaries for 2.2.0alpha1 have been uploaded and the pre release
> has
been > announced on lyx-users and twitter. If anyone has a twitter
account, > please consider retweeting to get the word out. > > I propose
that we wait a week to se
Dear all,
Binaries for 2.2.0alpha1 have been uploaded and the pre release has been
announced on lyx-users and twitter. If anyone has a twitter account,
please consider retweeting to get the word out.
I propose that we wait a week to see what kind of feedback we get (from
users that are testing as
Jean-Marc Lasgouttes wrote:
> I thought my apathy would be enough to have Juergen do it, but he won.
I'm making progress, you know ...
Jürgen
Le 29 mars 10 à 00:58, Pavel Sanda a écrit :
Pavel Sanda wrote:
I'll go through the enh bugs with 2.0 target and leave only those
which are
really to be included. For this I need somebody create two new
milestones in
trac for postponing - 2.1.0 & 2.0.1.
ding ding dong dong ;)
Done.
I t
Pavel Sanda wrote:
> I'll go through the enh bugs with 2.0 target and leave only those which are
> really to be included. For this I need somebody create two new milestones in
> trac for postponing - 2.1.0 & 2.0.1.
ding ding dong dong ;)
pavel
Le 10/03/2010 23:39, Abdelrazak Younes a écrit :
The problem is that it modifies stuff outside of the cell itself.
Such as?
Vincent made the same argument but I fail to see where this is true. For
longtable, we iterate through the rows and the collumns to see if header
of firstheader is set. F
On 10/03/2010 23:27, Jean-Marc Lasgouttes wrote:
Le 10/03/2010 23:20, Abdelrazak Younes a écrit :
Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and
inset-params-modify. Basically inset-modify should be about modifying
the con
Le 10/03/2010 23:20, Abdelrazak Younes a écrit :
Well, it does modify the inset so it's OK to have it in there.
But I agree about the distinction beween inset-modify and
inset-params-modify. Basically inset-modify should be about modifying
the content (and can depend on the Cursor position) and
i
On 10/03/2010 23:09, Jean-Marc Lasgouttes wrote:
Le 10/03/2010 09:00, Abdelrazak Younes a écrit :
Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to
create a new LFUN for each and every inset. Also because when
Le 10/03/2010 23:15, Abdelrazak Younes a écrit :
But this one is fixed now, isn't it? I mean, we worked around it :)
Yes, Edwin did. And I also did something similar in InsetMathGrid IIRC.
OK, thanks.
JMarc
On 10/03/2010 23:14, Jean-Marc Lasgouttes wrote:
Le 10/03/2010 13:52, Vincent van Ravesteijn - TNW a écrit :
The one below:
other bug you would like to see killed?
Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.
But this one is fixed
Le 10/03/2010 13:52, Vincent van Ravesteijn - TNW a écrit :
The one below:
other bug you would like to see killed?
Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.
But this one is fixed now, isn't it? I mean, we worked around it :)
JMa
Le 10/03/2010 09:00, Abdelrazak Younes a écrit :
Well this whole issue is because I made the opposite change...
I still think this is a good move because I really don't like to have to
create a new LFUN for each and every inset. Also because when the use of
user defined insets can be generalized
>> If the issue is that InsetTabular thinks it has to have the cursor
>> inside it to apply the LFUN, can't we change how that works? I.e.,
>> can't we move the cursor in there, or re-write the routine so it
>> doesn't need to assume that?
>
>Hmm, what is the particular bug we want to fix here?
Le 10/03/2010 13:33, rgheck a écrit :
On 03/10/2010 03:00 AM, Abdelrazak Younes wrote:
I still think this is a good move because I really don't like to have
to create a new LFUN for each and every inset. Also because when the
use of user defined insets can be generalized then inset-modify could
On 03/10/2010 03:00 AM, Abdelrazak Younes wrote:
On 03/09/2010 10:47 PM, Jean-Marc Lasgouttes wrote:
Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there
seems to be no
easy fix right now.
Just cerate inset-type change to replace the uses
On 03/09/2010 10:47 PM, Jean-Marc Lasgouttes wrote:
Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there seems
to be no
easy fix right now.
Just cerate inset-type change to replace the uses of inset-modify...
Well this whole issue is bec
Le 09/03/2010 20:11, Pavel Sanda a écrit :
ah, thats part of the AtPoint discussion... unfortunately there seems to be no
easy fix right now.
Just cerate inset-type change to replace the uses of inset-modify... For
some reason I do not manage to get svn access here. It is a pity
since otherwis
On 03/09/2010 02:12 PM, Edwin Leuven wrote:
rgheck wrote:
Do we need then to remove the AtPoint feature from whatever LFUN this
is?
i think we can't because it is LFUN_INSET_MODIFY
Ah, yes. That issue.
rh
rgheck wrote:
Do we need then to remove the AtPoint feature from whatever LFUN this
is?
i think we can't because it is LFUN_INSET_MODIFY
What that means is precisely: You can apply this LFUN when not in
the inset but in front of it.
but for tabular functions the cursor need to be in the tab
Edwin Leuven wrote:
> Pavel Sanda wrote:
>> Vincent van Ravesteijn - TNW wrote:
other bug you would like to see killed?
>>> Insert a table, put the cursor in front of the table, press set all
>>> lines on the table toolbar.. Crash.
>> table guys? Ed, Uwe?
>
> because with the cursor in front o
On 03/09/2010 01:59 PM, Edwin Leuven wrote:
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
other bug you would like to see killed?
Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.
table guys? Ed, Uwe?
because with the cursor in
Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
other bug you would like to see killed?
Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.
table guys? Ed, Uwe?
because with the cursor in front of a tabular, 'inset' in the code belo
On 03/09/2010 10:07 AM, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
The error dialog is currently completely broken (it doesn't show at
all). I think this is a pretty nasty bug.
any news about this one?
No. But I think this one is also due to the buffer cloning.
Pro
Vincent van Ravesteijn - TNW wrote:
> >other bug you would like to see killed?
>
> Insert a table, put the cursor in front of the table, press set all
> lines on the table toolbar.. Crash.
table guys? Ed, Uwe?
pavel
Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Pavel Sanda wrote:
> > > other bug you would like to see killed?
> >
> > The error dialog is currently completely broken (it doesn't show at all). I
> > think this is a pretty nasty bug.
any news about this one?
pavel
On 03/09/2010 04:11 PM, rgheck wrote:
On 03/09/2010 10:07 AM, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
The error dialog is currently completely broken (it doesn't show at
all). I think this is a pretty nasty bug.
any news about this one?
No. But I think this one is also due to the buffer
Pavel Sanda wrote:
> > > The error dialog is currently completely broken (it doesn't show at
> > > all). I think this is a pretty nasty bug.
>
> any news about this one?
No. But I think this one is also due to the buffer cloning.
Jürgen
Le 06/03/2010 19:04, Abdelrazak Younes a écrit :
* There has been some work on dispatch results, but I have no idea
whats the
current status. JMarc? There are already filled bugs around dispatch.
Concerning the DispatchResult stuff, I have to admit I do not know what
the status is :) I think i
On 03/08/2010 08:18 AM, Vincent van Ravesteijn - TNW wrote:
other bug you would like to see killed?
The outline doesn't work anymore.
That's due to my "fix" for the outliner crash. Now it doesn't crash but
doesn't work, either.
See also the "Export Crash" thread. There are serious
> other bug you would like to see killed?
The outline doesn't work anymore.
Vincent
>other bug you would like to see killed?
Insert a table, put the cursor in front of the table, press set all
lines on the table toolbar.. Crash.
Vincent
On 03/08/2010 01:19 AM, Pavel Sanda wrote:
Pavel Sanda wrote:
tarball creation is already fixed, monolithic builds checked, short
work with trunk didn't revealed any drastic problems and currently
i monitor two ugly bugs:
- Richard fixed crash #6522, but the price is that outliner doesn't
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > other bug you would like to see killed?
>
> The error dialog is currently completely broken (it doesn't show at all). I
> think this is a pretty nasty bug.
ok
pavel
Pavel Sanda wrote:
> other bug you would like to see killed?
The error dialog is currently completely broken (it doesn't show at all). I
think this is a pretty nasty bug.
Jürgen
Pavel Sanda wrote:
> Alpha - next week if possible
tarball creation is already fixed, monolithic builds checked, short
work with trunk didn't revealed any drastic problems and currently
i monitor two ugly bugs:
- crashes in #6516, there are already some hinst from Peter in trac
- Richard fixed cr
Pavel Sanda wrote:
* Advanced Search - as far as I can see all wanted features finished, Tommaso?
at least the simple usage scenarios are ok . . .
I expect lot of bug reports here though, we need to wait on users testing.
. . . though, I expect bugs to come up when you try all the thing
Abdelrazak Younes wrote:
>> Is there some cost to leaving the old code in until e.g. #6516 is fixed?
>>
>
> No, we can leave it if this is a blocker of course.
actually it would fine if you could look before alpha on this particular one.
pavel
Jürgen Spitzmüller wrote:
> > Jürgen has much better writing skills than me :-P
>
> Very transparent trial. But I'll do it.
Done. Please check if everything is correct.
Jürgen
Abdelrazak Younes wrote:
> >>For the packagers we need some summary what are the recommended
> >>dependencies. Haven't been closely following this stuff - could somebody
> >>write some summary of all those spellcheck (a/i/hun/spell) and thesaurus
> >>deps into RELEASE-NOTES? Juergen, Abdel?
> >
On 06/03/2010 20:32, John McCabe-Dansted wrote:
On Sun, Mar 7, 2010 at 2:10 AM, Abdelrazak Younes wrote:
On 06/03/2010 14:43, Vincent van Ravesteijn wrote:
John McCabe-Dansted schreef:
On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
wrote:
Did we l
John McCabe-Dansted wrote:
> > the dialog which would make me interested is the one which produce
> > backtrace after each crash, so user can put it in our bugzilla.
> > but thats not easy to do i guess.
>
> Maybe something like the following?
> char buffer[512];
> sprintf(buffer,
On Sun, Mar 7, 2010 at 2:10 AM, Abdelrazak Younes wrote:
> On 06/03/2010 14:43, Vincent van Ravesteijn wrote:
>>
>> John McCabe-Dansted schreef:
>>>
>>> On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
>>> wrote:
Did we leave the instability period that was expected due to:
On Sun, Mar 7, 2010 at 12:52 AM, Pavel Sanda wrote:
> John McCabe-Dansted wrote:
>> It seems that a dialog box allowing the user to choose what to do on a
>> case by case basis would be nicer than the LyX window disappearing
>> without any warning. Is there a disadvantage?
>
> over engineering. p
On 06/03/2010 14:43, Vincent van Ravesteijn wrote:
John McCabe-Dansted schreef:
On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
wrote:
Did we leave the instability period that was expected due to:
- threaded export,
IMHO we should
#define EXPORT_in_THREAD 0
No, we should have
On 06/03/2010 18:45, Pavel Sanda wrote:
Pavel Sanda wrote:
stage. The current version can be always reached at
http://wiki.lyx.org/Devel/LyX20Road
and I fill it once this thread is finished.
did this now. still waiting on replies from the French wing Abdel and JMarc.
Not sure wh
Pavel Sanda wrote:
> stage. The current version can be always reached at
> http://wiki.lyx.org/Devel/LyX20Road
> and I fill it once this thread is finished.
did this now. still waiting on replies from the French wing Abdel and JMarc.
one more idea - if you feel some particular bug should be fixed
John McCabe-Dansted wrote:
> >> #6427. On my machine each threaded export has a roughly 50% chance of
> >> crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
> >> broken. We already know it is.
>
> Actually, I think I am hitting #6516 more often than #6427.
i see. the master chil
On Sat, Mar 6, 2010 at 10:17 PM, Pavel Sanda wrote:
> John McCabe-Dansted wrote:
>> IMHO we should
>> #define EXPORT_in_THREAD 0
>
> no we should collect as many bugs as possible for new features.
But we need some exciting new feature to announce with the second Alpha! :P
>> #6427. On my machin
John McCabe-Dansted wrote:
> IMHO we should
> #define EXPORT_in_THREAD 0
no we should collect as many bugs as possible for new features.
> #6427. On my machine each threaded export has a roughly 50% chance of
> crashing LyX. We don't need users tell us that EXPORT_in_THREAD is
> broken. We alrea
John McCabe-Dansted schreef:
On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
wrote:
Did we leave the instability period that was expected due to:
- threaded export,
IMHO we should
#define EXPORT_in_THREAD 0
No, we should have this.
I have done this in keytest sinc
On Fri, Mar 5, 2010 at 10:48 PM, Vincent van Ravesteijn - TNW
wrote:
> Did we leave the instability period that was expected due to:
> - threaded export,
IMHO we should
#define EXPORT_in_THREAD 0
I have done this in keytest since otherwise keytest would do almost
nothing but generate reports abo
Bo Peng wrote:
> >>Other entries?
> >
> > The "Export as ZIP" feature. I'll try to come up with a prototype asap.
> >
> > Vincent
>
> Is this the final consensus of the embedding/zip/folder/whatever
> feature of lyx?
there was no discussion about this proposal and as i understood
its not embeddin
i'm not sure who is this "we"; from the last discussions about release
plans it looked like that more devs thought we are already late and
particularly can't remember anybody claiming we should wait little bit
longer. if its not the case then sorry and lets discuss the stages
a little bit more.
On 03/05/2010 01:58 PM, Pavel Sanda wrote:
Vincent van Ravesteijn - TNW wrote:
lets start landing towards 2.0.
That's what we call a "flying start"...
i'm not sure who is this "we"; from the last discussions about release
plans it looked like that more devs thought we are alr
Vincent van Ravesteijn - TNW wrote:
> >Anybody want to have something before alpha in trunk?
>
> I've one worthy unfinished feature left. Export to dir/zip including all
> dependent files. Don't know what the advantage of being in alpha release
> would be.
i have feeling that we do not understand
Vincent van Ravesteijn - TNW wrote:
> >lets start landing towards 2.0.
>
> That's what we call a "flying start"...
i'm not sure who is this "we"; from the last discussions about release
plans it looked like that more devs thought we are already late and
particularly can't remember anybody claimin
>>Other entries?
>
> The "Export as ZIP" feature. I'll try to come up with a prototype asap.
>
> Vincent
Is this the final consensus of the embedding/zip/folder/whatever
feature of lyx? I have been forced to use MS Word more and more
because of increased collaboration activities. It becomes clear
On Friday 05 March 2010 14:10:47 Pavel Sanda wrote:
> * rc2rc conversion scripts for converting older preferences into new ones.
> Jose promised to come with something. I have worried what happen with
> users which run lyx beta to test and get prefs overwritten for their
> stable 1.6.x?
I propos
On 03/05/2010 09:48 AM, Vincent van Ravesteijn - TNW wrote:
Anybody want to have something before alpha in trunk?
I've one worthy unfinished feature left. Export to dir/zip including all
dependent files. Don't know what the advantage of being in alpha release
would be.
Excellent.
On 03/05/2010 09:10 AM, Pavel Sanda wrote:
* HTML export. I remember Richard asked for help with images. Anybody around?
Some plans to add instant preview snapshots for equations, or external insets
using preview? Some other plans Richard? NewInLyx2.0 entry is missing.
I do need help h
>> Alpha 1: I don't have any special requirement, from my POV the most
>> serious bug in OS X has been "fixed" by Abdel and I don't see any
other showstopper.
>> Anybody want to have something before alpha in trunk?
>
>Things are looking reasonably good on Mac. It needs some polish, and I
think
On Fri, Mar 5, 2010 at 9:10 AM, Pavel Sanda wrote:
> Alpha 1: I don't have any special requirement, from my POV the most serious
> bug in OS X has been "fixed" by Abdel and I don't see any other showstopper.
> Anybody want to have something before alpha in trunk?
Things are looking reasonably goo
>lets start landing towards 2.0.
That's what we call a "flying start"...
>Preliminary dates for the stage beginning:
>Alpha - next week if possible
Did we leave the instability period that was expected due to:
- threaded export,
- movements of code in the dispatch machinery,
- insetdialog change
Pavel Sanda wrote:
> Any comments/objections?
Looks reasonable, AFAICT.
> * Multiple viewers/converters. Juergen asked for some help; how this
> evolved, what is to be done in this area? Juergen, Richard?
I still did not yet find the time to re-address this. I need to clean up the
tree with my
Hi LyXers,
lets start landing towards 2.0.
I respect Jose's choice so the upcoming version is fixed to 2.0 from now on.
Maybe you are not aware, but on autumn we celebrate 15 years of LyX (from the
first releases), so we can join releasing of 2.0 with some public advertisement
and looking back, w
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Jean-Marc Lasgouttes wrote:
José Matos <[EMAIL PROTECTED]> writes:
Now I am just waiting from André to add the missing file. :-)
If it blocks you, do like me: use -
#define LASSERT(a,b)
as stub file.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> José Matos <[EMAIL PROTECTED]> writes:
>>
>>> Now I am just waiting from André to add the missing file. :-)
>>
>> If it blocks you, do like me: use -
>> #define LASSERT(a,b)
>>
>> as stub file. It seems
Jean-Marc Lasgouttes wrote:
José Matos <[EMAIL PROTECTED]> writes:
Now I am just waiting from André to add the missing file. :-)
If it blocks you, do like me: use
-
#define LASSERT(a,b)
as stub file. It seems to work.
Then I suggest to commit this temporarily until Andre
José Matos <[EMAIL PROTECTED]> writes:
> Now I am just waiting from André to add the missing file. :-)
If it blocks you, do like me: use
-
#define LASSERT(a,b)
as stub file. It seems to work.
JMarc
On Friday 11 April 2008 08:08:27 Abdelrazak Younes wrote:
> alpha2: today :-)
> beta1: 01/05/2008
> beta2: 15/05/2008
> RC1 or beta3: 01/06/2008
> RC2 or beta4: 15/06/2008
> 1.6.0 or RC3: 01/07/2008
>
> So I think we can even do faster ;-)
It is a good schedule. :-)
Now I am just waiting from And
Uwe Stöhr wrote:
> These things do not need to be discussed. They should be imposed ;-)
But our release dictator doesn't impose but tests out democracy ;-).
> Temptative schedule:
> alpha2: today :-)
> beta1: 01/06/2008
> beta2: 15/06/2008
> RC1 or beta3: 01/07/2008
> RC2 or beta4: 15/07
> These things do not need to be discussed. They should be imposed ;-)
But our release dictator doesn't impose but tests out democracy ;-).
> Temptative schedule:
> alpha2: today :-)
> beta1: 01/06/2008
> beta2: 15/06/2008
> RC1 or beta3: 01/07/2008
> RC2 or beta4: 15/07/2008
> 1.6.0 or RC3: 01/
Uwe Stöhr wrote:
> OTHO, surely I agree with you that we should start discussing the
schedule for
> the first beta and rc releases.
Ping.
These things do not need to be discussed. They should be imposed ;-)
Temptative schedule:
alpha2: today :-)
beta1: 01/06/2008
beta2: 15/06/2008
RC1 or b
> OTHO, surely I agree with you that we should start discussing the schedule for
> the first beta and rc releases.
Ping.
regards Uwe
> I think we are feature complete for the next release,
i think this is very much dependent on the result of the current embedding
feature discussions.
pavel
On Monday 07 April 2008 19:22:24 Uwe Stöhr wrote:
> I read today that José plans to release it in about 5 months which is too
> long away.
Please read again, what I said was that if we take the 1.5 as an example it
would take five months to have a stable release.
This is not a matter of opinion,
Hello everybody,
I think it is time to define now a fixed release schedule towards LyX 1.6.
I read today that José plans to release it in about 5 months which is too long away. LyX 1.6svn is
in principle in a good shape, although there are enough bugs to fix. I think we are feature complete
fo
Basically, everything is ready (the recent performance fixes have been a very
valuable last-minute contribution, IMHO). So branch is frozen, except for
urgent fixes (crashes, building, etc.), documentation and l10n.
However, I have to modify the original plan, which was to prepare the release
t
On Fri, Aug 24, 2007 at 04:17:10PM +0300, Martin Vermeer wrote:
> On Fri, 24 Aug 2007 14:41:27 +0200
> Andre Poenitz <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Aug 24, 2007 at 12:11:49PM +0200, Abdelrazak Younes wrote:
> > > Well, we need to express opinions to reach consensus, don't we? I know
> >
On Fri, 24 Aug 2007 14:41:27 +0200
Andre Poenitz <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 24, 2007 at 12:11:49PM +0200, Abdelrazak Younes wrote:
> > Well, we need to express opinions to reach consensus, don't we? I know
> > that my opinions are in general not shared with old devs but this is my
On Fri, Aug 24, 2007 at 12:11:49PM +0200, Abdelrazak Younes wrote:
> Well, we need to express opinions to reach consensus, don't we? I know
> that my opinions are in general not shared with old devs but this is my
> opinion :-)
> I want more frequent releases, this is the only way IMHO to avoid b
Abdelrazak Younes wrote:
> Well, we need to express opinions to reach consensus, don't we?
Of course. I simply think that this consensus is still quite a bit away.
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
I have learned my lesson. If I will fix a bug in my branch I will no more
bring it to lyx-devel, since it only results in frustration.
Why that? The two subjects are unrelated AFAIS.
No. This thread would not exist if I had not
92 matches
Mail list logo
