[haiku-development] Re: Haiku git migration status?
- From: pulkomandy@xxxxxxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 03 Aug 2011 20:34:07 +0200
On 2011-08-03 at 19:28:21 [+0200], Ryan Leavengood <leavengood@xxxxxxxxx>
wrote:
> On Wed, Aug 3, 2011 at 12:34 PM, Brecht Machiels <brecht@xxxxxxxxxxx> wrote:
> >
> > Understandably, as Haiku is the *only* project tagging each and every
> > changeset. This is clearly not the intended use for tags. But I don't
> > suppose
> > the few people in favor of the tags have changed their mind about it yet?
> > :)
>
> I really, really, really hope we can move away from this crutch once
> most developers have gotten used to using Git. We will need to start
> learning to use the SHA1 hashes when referring to particular Haiku
> revisions. These tags will never be as convenient as the old SVN
> revision numbers.
Well we'll get over it. The tags are mostly interesting as a way to refer to
older chnagesets for now. We have a huge ticket base in trac referring to the
revisions that way, so we need to keep some easy way to map these numbers to
something. Maybe we don't need to keep all of them, but only the 1000 mor
erecent or so ? Though numbers can move pretty fast in alpha preparation mode.
>
> Using a Haiku revision string in AboutSystem which includes the date
> and SHA1 hash of the commit the system was built from can serve the
> same purpose as SVN revision numbers (and is better since the date can
> be read directly.)
This was discussed a lot already, they'll never be as information-dense as
the 5-digit revision numbers, but we can live with it, as something a bit
more verbose.
>
> I also think we should start tagging known stable commits with a real
> version number (0.1.1.8 or whatever) which also shows up in
> AboutSystem and do the "alpha release preparation" type tasks more
> often.
Well, I did manage the alpha3 release and I'd rather not do that often. It's
a painful and boring task. That's why we needed almost one year before
someone stepped up to do it, because the outcome was big enough. Doing it
more often is going to spend more energy on work that doesn't really bring
much features in by itself (it has other good effects for the project).
I really hope that managing a release branch will be less trouble in git than
svn. But it will still need someone to take care of it and make sure
everything gets packaged, QA process, and ensure distribution to mirrors
before an official release date and press release annoucement.
--
Adrien.
Other related posts:
