> No, my idea was to put the above text in the about box, to replace our
> current 4f11d0a-adcf6d5-... string.
Oh, I see! But then it would be easier to use the "pretty printing
date" instead of having 2 strings to compare for each repository. That
would be a nice improvement.
What I was proposin
On Sat, Dec 03, 2011 at 11:40:01PM +, Pedro Lino wrote:
>> Git commit IDs as identifiers have the huge problem that they are not
>> comparable (one cannot say which one is "greater") without referring
>> to the repository. How about we also put the *commit* (not author)
>> timestamp (in UTC) o
On Sat, Dec 3, 2011 at 7:24 PM, Pedro Lino wrote:
> Hi guys
>
> I was copying cells between two open spreadsheets, one in 3.4.4 final
> and another on LibO-dev 3.5.0 ( a286353-090bcba-3bf3b94) aka
> master~2011-12-02_22.36.35_libodev35 from Win-x86@6
>
> When I pasted a cell containing a formula,
Hi guys
I was copying cells between two open spreadsheets, one in 3.4.4 final
and another on LibO-dev 3.5.0 ( a286353-090bcba-3bf3b94) aka
master~2011-12-02_22.36.35_libodev35 from Win-x86@6
When I pasted a cell containing a formula, it got pasted as the
resulting value. This happens both ways.
Hi Lionel
> Git commit IDs as identifiers have the huge problem that they are not
> comparable (one cannot say which one is "greater") without referring
> to the repository. How about we also put the *commit* (not author)
> timestamp (in UTC) of the top node (commit), and maybe the branch?
That w
On Sat, Dec 03, 2011 at 01:06:18PM +0100, Andras Timar wrote:
> 2011/12/3 Pedro Lino :
>> Another situation: I download a master build from a tinderbox. How do
>> I know the build included? How do I know if the source it was
>> generated from is newer or older than the one I already have? Easy.
>>
Hi,
currently I have much trouble using existing user profiles with Master
or 3.5.0 Beta. The trouble vanishes when I switch to a blank new user
profile for.
I believe that might cause heavy trouble when users update from 3.4 8or
3.3), but on the other hand my suspect might be complete nonse
On 12/3/11 6:27 PM, Cor Nouws wrote:
> Will be something that marketing is going to praise us for, isn't it?
If the change of code name is not a problem, it would make thing easier
for everyone.
--
Italo Vignoli - [email protected]
mob +39.348.5653829 - VoIP [email protected]
skype it
Michael Meeks wrote (03-12-11 15:49)
Well - we've fixed a number of the most obvious packaging bugs,
parallel installability etc. etc. in master - so (without further new
problems - of which we expect some up to the freeze) Beta1 will be
rather better.
It's more realistic to expect tha
Michael Meeks wrote (03-12-11 15:50)
Yes ! we have not branched yet; master will branch at the
feature-freeze before B1 so we have:
master Beta0 ---\--- crazy stuff ...
\
\- Beta1 --- stabilisation -
Pedro Lino wrote (03-12-11 11:23)
I hope that _at least_ they make DAMN sure that Beta1 doesn't
overwrite the stable build...
To be honest: I have no idea. I just install zillions (well, little less
;-) ) without system integration.
But your question is relevant indeed.
Anyone else?
Thanks,
> No need to know. It is just a random (or not so random) sequence of
> hex digits. If nothing documents it to have some significance, don't
> assume it to have any significance.
Thank you for the clarification. It does have some significance.
>> Anyway, even if this was a combination of the GIT
> I thought Andras was referring to the single 8 letter/number code
> added to the Windows install folder name.
> Where does that come from?
No need to know. It is just a random (or not so random) sequence of
hex digits. If nothing documents it to have some significance, don't
assume it to have an
Le 03/12/2011 14:28, Pedro Lino a écrit :
>> On my build of the master (Build ID:
>> 2c09f50-43e9388-090bcba-3bf3b94-05891e7 on Ubuntu 10.04 x86_64) the
>> button "Close" in the dialog Insert -> Fields -> Other... (Ctrl+F2) does
>> nothing. Other buttons (Insert and Help) work as expected. The only
Hi Pedro,
On Sat, 2011-12-03 at 12:25 +, Pedro Lino wrote:
> Is it reasonable to admit that the all current changes in master will
> be in Beta1? If so, using master~2011-12-02_22.36.35_libodev35 from
> Win-x86@6-fast as a replacement for Beta0 is acceptable?
Yes ! we have not branche
Hi Rainer,
On Sat, 2011-12-03 at 08:42 +0100, Rainer Bielefeld wrote:
> it's a disaster, completely unusable ! Quality of Beta0 is far behind
> quality of Master during the last weeks, it seems that we were not lucky
> with the time where the tag has been created
Quite quite :-) so Beta
Hi Korrawit
> That is, if your 4f11d0a is the first group of IDs in About box, it's
> the core repository's commit ID.
Yes, obviously. Sorry for the confusion.
I thought Andras was referring to the single 8 letter/number code
added to the Windows install folder name.
Where does that come from?
E
Hello Pedro, Andras, *
On Sat, Dec 3, 2011 at 20:16, Pedro Lino wrote:
> So, 4f11d0a is a global commit ID calculated from the partial 5 git
> commit IDs?
No, it isn't. It's like what you've explained:
> So the About box says a286353-090bcba-3bf3b94
> which I just realized are the 7 first lette
> On my build of the master (Build ID:
> 2c09f50-43e9388-090bcba-3bf3b94-05891e7 on Ubuntu 10.04 x86_64) the
> button "Close" in the dialog Insert -> Fields -> Other... (Ctrl+F2) does
> nothing. Other buttons (Insert and Help) work as expected. The only way
> to close the dialog is to click the cro
Hi again Andras
> We have 5 repositories now: core, binfilter, dictionaries, help, and
> translations. Therefore there are 5 git commit IDs in the About box
> separated by dashes. These are good identifiers of the build, at least
> these uniquely identify the source code that the build was made fr
Hi,
On my build of the master (Build ID:
2c09f50-43e9388-090bcba-3bf3b94-05891e7 on Ubuntu 10.04 x86_64) the
button "Close" in the dialog Insert -> Fields -> Other... (Ctrl+F2) does
nothing. Other buttons (Insert and Help) work as expected. The only way
to close the dialog is to click the cross bu
Le 30/11/2011 20:59, Cor Nouws a écrit :
> Hi Petr,
>
> Petr Mladek wrote (25-11-11 18:07)
>>
>> It should get fixed by
>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=1221e6a9e44f080b8e5fc5d3fdf3a708b6e382ab
>>
>>
>> The wrong libobasis-dev3.5-core01 was not empty. It included the Latv
Hi Pedro
2011/12/3 Pedro Lino :
> Hi Andras
>
> Thank you for your quick and enlightening reply!
>
>> LibreOffice 3.5 will not unpack anything to desktop. But we can't
>> change the past... :)
>
> Fair enough :)
>
>> You can check what's included and what's not, when you visit
>> for example
>> h
> I think the latest Master builds before Beta has been splitted were
> in an acceptable shape for a Beta.
I have just uninstalled Beta0 because I need my 3.4.4 functional. Not
only because I actually use it to WORK but I also need some comparison
to check for regressions...
Is it reasonable to a
Hi Andras
Thank you for your quick and enlightening reply!
> LibreOffice 3.5 will not unpack anything to desktop. But we can't
> change the past... :)
Fair enough :)
> You can check what's included and what's not, when you visit
> for example
> http://cgit.freedesktop.org/libreoffice/core/log/
Hi Pedro,
2011/12/3 Pedro Lino :
> Hi all
>
> This is my final request about this subject.
>
> Can you please make some sense out of the version naming convention?
>
> I was about to reinstall version 3.4.4 (after it was overwritten by
> 3.5.0 Beta0) and I already had an unpacked install folder on
Hi all
This is my final request about this subject.
Can you please make some sense out of the version naming convention?
I was about to reinstall version 3.4.4 (after it was overwritten by
3.5.0 Beta0) and I already had an unpacked install folder on my
desktop. The only way I could verify that i
Pedro Lino schrieb:
So what do we (QA) do now? Is there some protocol? Are there tasks to
split? By how many?
Hi,
we should see how many and severe bugs really are "Beta only", that
means to correct Version if the bug is from a more early version. If we
are lucky only few bugs will remain
> As posted already yesterday, it is not unlikely that beta1 will have about
> the same troubles. If so, those will be fixed before beta2, which will make
> that version fine for larger testing.
Really??? Not _unlikely_?
The Devs are actually going to release a Public Beta in this state?
I hope
Hi Rainer,
Rainer Bielefeld wrote (03-12-11 08:42)
Shit happens, now the question is how we will go on.
As posted already yesterday, it is not unlikely that beta1 will have
about the same troubles. If so, those will be fixed before beta2, which
will make that version fine for larger testing
30 matches
Mail list logo
