[Libreoffice-qa] daily vs. 4.-0+ bibisect repos [was: Trouble bibisecting - 'com::sun::star::uno::RuntimeException']

[Mirosław Zalewski]

Hi all

I spent afternoon with git manual and repeatedly removing/unpacking
bibisect archives and I think I understand a little more now.

Dnia 2013-10-24, o godz. 11:29:42
dk122 at torfree.net napisał(a):

> I am confused about the names "daily" and "4.0+" for bibisect
> repositoriies.  Does it make sense now to say "daily" at all?
> 
> I gather vaguely from messages on the dev list that the maintenance
> process for the bibisect repository or repositories has not settled
> down to its final state.  But if my confusion has led Mirosław
> into confusion, I should correct HowToBibisect
> <https://wiki.documentfoundation.org/QA/HowToBibisect> promptly, even
> if only as an interim measure.
> 
> But first, somebody please tell me what is what.

As far as I am concerned, "daily" and "4.0+" were the smallest source of
my confusion. But there are many other problems with instructions.

First and foremost, we have two repositories from two men. These not
only serve different purpose, but also are set up differently, which
means that user must perform different steps depending on which one he
has. Unfortunately, these differences are never laid out
systematically. I learned them by trial and error.
I think that "versions" table could use another column with name of man
who created archive in question. Then we can reference to them as
"Bjoern archive" and "Jean archive".

If one is to seriously bibisect, he has to download two packages:
1. Bjoern 4.0, which covers everything from 2011-08-06 (about midway
between branching 3.4 and 3.5 from master) to 2012-12-08 (around
branching 4.0 from master).

2. Either Bjoern 2013-10-12 or Jean 4.0+. They both cover roughly the
same area, since 2012-12-08 to 2013-09-17 (later date is subject to
change). The difference between them is density of builds - Jean
archive is far denser, which means that each build covers fewer
commits, which means that finding patch that introduced regression is
easier for developer with bisect log. But we pay for this with almost 4
times bigger package.
Also, Jean package was supposed to be updated daily, while Bjoern
apparently never made such commitment. But at the moment they both are
not updated for a month and they both stop at about the same moment in
time.

Of course second package is more important, as we are mainly interested
in newer regressions. But there are still bugs that can be bibisected
only with older package.

When we download and unpack archive, we must set up working
environment. And that depends which package we have used.

In Bjoern packages (well, "4.0" that is; I did not checked
"2012-10-12", but assume it is set up the same way) our main concern is
HEAD set up at oldest commit. This way `git rev-parse HEAD` will
produce ID of oldest commit. If we blindly follow instructions at wiki,
we will end up assigning "latest" tag to oldest possible commit.
Our second problem is that we have empty git working tree.
Both of them can be fixed by issuing:
    git checkout master

We are ready to go. We can assign "latest" tag to ID returned by git
rev-parse and "oldest" tag to 65fd30f5cb4. Then we can issue bibisect
command.

In Jean package, on the other hand, HEAD is set up to latest commit.
But since our git working tree is empty, git thinks that we have one
uncommitted change (the one that removes everything...). 
We can assign tags to commits, but then bibisect command will bring
working tree to messed state.
This command, mentioned at very beginning of "Bibisecting" section at
wiki:
    git checkout latest
will not refresh working directory content, because git IS already at
latest tree version. Wiki says that we should execute `soffice`
command, but this will not be possible.
The second command, `git checkout oldest`, will leave us with broken
git tree. My assumptions why it happens are outlined below.

We can fix all these problems and go ahead with wiki instructions by
forcing git to restore working tree content to state it was supposed to
be at current revision:
    git checkout-index -a
Then we can tag latest and oldest commits (commands are already on the
wiki), checkout any commit and start bisecting.

BTW: git bisect will pick up commit in the middle between known good
and bad version and bring working tree to state of that revision.
Therefore, `git checkout {oldest,latest}` are needed only to verify
that bug was introduced in one of builds that we have access to.
Actually, we can check only oldest commit. If we are on "4.0+" or
"2012-10-12" and the bug is present, then we must check Bjoern "4.0"
archive; if we are on Bjoern "4.0" and bug is present in oldest
revision, then we must set whiteboard to "prebibisect", because it was
introduced somewhere before August of 2011.

Finally, there is that thing why `git checkout oldest` does not work in
Jean archive (it leaves with broken LO due to renamed libraries).
I suppose that `git checkout` does not use full restore, but
differential/incremental one. That is: if we want to switch from
revision X to revision Y, git will create diff between these two
revisions and apply it at working tree. So switching revisions will be
instant in only few files has actually changed.
But this assumes that content of working tree was exactly as in
revision X when we started. And as we know now, this is not a case in
Jean archive.
As I learned right now, there is a command line switch that suppress
this behavior: -f (as in --force).
So, after unpacking Jean archive, we can either:
 - `git checkout-index -a` to restore tree content expected by git
 - `git checkout -f oldest` to sync tree content with git expectations
   AND check whether our bug was introduced after December of 2012.

If we are talking about Wiki, then:
- entire section about OVA images could be removed. They are not
  updated anymore and perhaps are not useful that much.
- "Versions" table could use another column with bibisect archive name,
  as I stated above; also, we could remove "Bugs need bibisecting" and
  "Whiteboard posting for success" columns. These instructions are
  repeated in "Bibisecting" and "Finding bugs" sections, and honestly -
  they belong there.
- Paragraph above "Versions" table says that bibisect-3.5 and
  bibisect-3.6 are not needed anymore; well, if they are not needed,
  why ever mention them? People will most likely just click link in
  "Download link" column.
- it might be good idea to encourage people to invoke bibisected LO
  like that:
    /opt/program/soffice -env:UserInstallation=file:///tmp/lo-bisect/
  This way bibisect will take place at it's own user profile
  directory and we will not mess up our working profile with untested
  version. Since this directory in /tmp/, it will be removed during
  next machine boot.

If anyone can update wiki page with information provided in this
message, please do. 

Also, if I have made mistake somewhere, do not hesitate to shout ;) .
-- 
Best regards
Mirosław Zalewski