[haiku-development] Re: Begeistert warmup: Git migration, releases

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 29 Oct 2011 10:15:53 +0200

Alex Wilson wrote:
> > Well, there's code in the build system
> > (build/scripts/determine_haiku_revision)
> > that is supposed to determine the hrev that a certain haiku built from a git
> > repo
> > is based on and describe any additional changes (plus a dirty marker for a
> > checkout
> > with local changes). I dunno if this works currently, but it should give a
> > pretty
> > decent description of the code's state. That description is shown in
> > AboutSystem, so
> > it's available to users for reports.
> 
> This string will only really be useful when there are little to no
> modifications (most likely from a user on a nightly). If there are
> significant modifications, they can't be reflected in this string, but
> we can simply ask for the user (who probably has built their own
> image) to run a few git commands for very detailed information on
> their build. If a user has problems using some weird build that they
> can't tell us anything about, and we can't replicate, then there is no
> reason we should try to fix their bug.

Those users with modifications are likely developers, i.e. us. If e.g. you work 
on the layout code, the Haiku revision number of your build will be perfectly 
fine for reporting kernel issues. The person looking into the bug might have 
changes as well, but if they are in an unrelated area -- and Haiku is a big 
project with a lot of components -- his revision number will be comparable to 
yours. "Running a few git commands" on both sides to determine that the 
versions are comparable does certainly work, but you'll have to admit that 
comparing a simple revision number that is built into Haiku (and shown in 
AboutSystem and printed to the syslog etc.) is *significantly* more convenient.

> It comes down to users with a standard build, which we know everything
> about, and users with a non-standard build, which we know only what
> they'll tell us. If it's that important, we could add a file at build
> time somewhere with detailed info on exactly what their build
> contains.

The nightlies or builds from unmodified sources are really not the interesting 
cases. We, the developers, are the ones who'll need to determine versions most 
of the time and we very often have modifications.

> >> Essentially, these tags only do their jobs on
> >> nightly builds, which means that having a tag on every single revision
> >> is overkill.
> >
> > Hm, I'm never using nightly builds, when I'm working on a bug, I usually
> > switch my
> > checkout to the mentioned revision (or a later one) and rebuild. So those
> > tags certainly
> > do a fine job for me.
> 
> Right, but you could do the exact same thing with a git sha-1 id, so
> in this case, there is no benefit to having these tags.

They are not, if either side has modifications. The sequential revision number 
provide direct comparability as long as possible modification are in unrelated 
areas (which the the people involved will certainly know).

CU, Ingo

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 10-2011