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

  • From: Alex Wilson <yourpalal2@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 2 Nov 2011 12:01:48 -0600

On Wed, Nov 2, 2011 at 5:11 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> Alex Wilson wrote:
>> Replying to 3 emails in one:
>> The sequential revision numbers really aren't that comparable. They're
>> comparable in that a - b gives you the amount of changesets that one
>> build is missing, but you don't know much beyond that.
>>
>> Suppose a-b = 100. With 100 medium-large changesets, you can
>> fix/introduce many bugs. However, with 100 changesets in graphics and
>> network drivers, the code being discussed might not have been changed
>> at all. Yes, developers will likely know about modifications they have
>> made, but I don't read every commit that I pull, most people probably
>> don't.
>
> You seem to have a wrong idea how the revision number are usually used in 
> practice. A not too uncommon bug report is like "bug in rXXX, used to work 
> fine in rYYY". Usually that already helps to suspect a recent revision that 
> changed something on the component in question. If you follow the ticket 
> mailing list, you'll frequently see a ticket in which an early comment 
> suggests a certain revision as the culprit on that basis (often being 
> correct). Conversely, revisions can quickly be ruled out on that basis (if 
> their number is greater than the tested one). That's all pretty helpful to 
> narrow things down and it's a very simple mechanism at that same time.

It seems that semantic tags would serve this purpose nicely as well.
Eg. for a bug report like "bug in a3.15.3, used to work in a3.14.7",
you start by grepping the annotations for the intermediary tags, which
will likely let you reduce your search to a set of changes between
a3.X.Y and a3.X.(Y - 1). or a few such sets. At that point, you can
use whatever method you want to search the remaining revisions
(probably start be reading the commit messages), but you already have
fewer to search than XXX - YYY. It makes getting to that initial
suggestion of which revision is a likely culprit easier.

It's also worth noting that once we switch to a distributed workflow,
changes will likely end up in the main repo in chunks, ie. it will be
less common to have changesets for 2 or 3 unrelated things comingling
in the project history.

>> With more semantic versioning, you can quickly find out the sum
>> of all changes that have happened between a and b, by reading the
>> annotations of the version tags. There is definitely a convenience to
>> numeric, monotonically increasing version numbers, but I think we can
>> have that and more with 'real' versions. We get just a little bit more
>> information directly from the version string, and it's easier to do a
>> detailed comparison of two versions.
>
> "Real" version numbers certainly wouldn't harm. On the other hand I also 
> don't see any advantages of having those for the interesting use cases, 
> though. Moreover generating those version numbers seems to be more 
> complicated to me and probably needs to be done manually (in your example 
> version numbers the "a3" component would be automatically available, but I 
> don't know where you'd get the other ones from). At any rate, I don't see 
> particularly good reasons to replace the sequential revision numbers.

These version strings would be managed as annotated tags. (Similar to
the current solution, but way less tags.). Yes, the tags would be
generated manually, but it basically comes down to whoever pushes to
the main repo adding a tag when they think their work is significant
enough to warrant it.

The main reason to replace the sequential revision numbers is to be
able to provide meaningful versions that give you a better estimate of
the difference between two versions. a3.20.3 is not that different
from a3.20.15, but a3.21.3 is significantly different from a3.20.3.
This also makes it easier to see if you should update your build, for
instance. 200 svn revisions might look like you are very out of date,
but that could be the difference between a3.20.3 and a3.20.15, where
it is probably not worth your time to update.


--Alex

Other related posts:

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