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

  • From: Alex Wilson <yourpalal2@xxxxxxxxx>
  • To: haiku-development <haiku-development@xxxxxxxxxxxxx>
  • Date: Fri, 28 Oct 2011 13:54:43 -0600

Hi all, since I'm not going to be at Begeistert, but I have opinions
to share on some of the topics that will be discussed, I figured I'd
let them out on the mailing list now, so that those fortunate enough
to get to Begeistert to hash things out IRL can consider my input too.
Anyone who wants to can of course reply here on the mailing list.

Recently I made a fork of haiku/haiku on github, and that is where
I've been doing my work lately. I decided to try this out because I
find git to be much nicer than svn, and I was eager to see how this
would all work with Haiku.

Unfortunately, my experiences have been a bit of a mixed bag. Git and
github are great, but I already knew that. What's not so great is the
how either of them handle our 40k 'lightweight' tags. Unfortunately,
even after executing git pack-refs --all, things go *really* slowly
for me. Granted, I don't have a powerful processor (it's an atom) but
I don't think one should need a powerful processor to run 'git
status'. Git simply isn't built to handle this many tags.
Incidentally, neither is github, and the repository view hangs in Web+
when trying to view my repo.

What frustrates me the most about these tags is that they are
basically useless. With Haiku, we basically have 3 types of users.
Users running a nightly, users running a release image and developers
running their own builds. The first two types of users will never have
any modifications to their source, so to some extent, the tags might
be useful in determining what fixes/bugs/features they have. Do we
need 40k tags to do that? no. It would be sufficient to tag only those
builds released on haiku-files, for instance.

The third type of user, developers, may have all sorts of
modifications to their build. They may cherry pick changes from the
main haiku repo, and they may modify any piece of Haiku they as they
see fit. For these users, a version string in AboutSystem saying
'hrev4****' is useless. Luckily, these are the same users who will be
able to run git commands and post detailed information about their
build/modifications when they file a ticket. We can also ask these
people to rebuild with a minimal set of modifications and test again.

While I was trying to figure out how to delete all those tags from my
repo, I asked a github support guy for a soundbyte on our current
tagging system, and what he essentially said is this: we shouldn't be
letting our revision control system dictate our versioning.

I think he's got a good point here. What is the semantic difference
between hrev41234 and hrev41334? Only that 100 things have been done.
Maybe it's 100 changes to the copyright info in the headers, maybe the
kernel was rewritten in 100 changesets, the only thing you know is
that something happened. The guy I talked to suggested we use semantic
versioning as defined on semver.org (Major.Minor.Patch-level), which
would work pretty well, but I don't think it is a great fit for Haiku.

What I suggest (and this ties into release management as well) is that
we do monthly 'stable' builds. For example, 3 weeks a month, any
change at all could  be merged into the main Haiku repo, but during
the last week, only bugfixes would be merged. Developers would also be
asked to hold off on big changes that are unlikely to be stabilized in
time for the monthly build. For users who are accustomed to
downloading nightlies, we would suggest downloading monthly stable
images. For developers who want to test an older build, nightlies
could still be available. Managing this process may sound like a
horrendous chore, but with a DVCS, where developers work in their own
forks, and then merge upstream as they see fit, this would really be
as simple as holding off on your merges once in a while.

Okay, back to git now... Since users would generally only be using
monthly images, we could simply tag those monthly builds. It would be
nice to also include some sort of semantic versioning as well, maybe
the version string could look like 'Haiku stable 11/10
a3.big_changes.fixes' where big_changes and fixes are somehow related
to the number of significant improvements and bugfixes since alpha3.

I think something like what I have outlined above strikes a good
balance between developer productivity, git's competencies, and user
experience. Of course, I'd love to hear what others have to say,
particularily anyone else who has already been using git to work on
Haiku.

--Alex

Other related posts:

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