[haiku-development] Re: UI discussion (was "WebPositive misleading tool tip on new tab")
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 28 Feb 2013 14:58:18 +0100
On 02/28/2013 03:16 AM, Clemens wrote:
I haven't said I want to stop using git and thus I assumed that it is
clear that there are local (github) branches!
Something what Ryan posted:
http://nvie.com/posts/a-successful-git-branching-model/
What I'm saying is: at the moment there is no post R1 feature "develop"
branch (R2 branch) that is needed for a "A successful Git branching
model" (see link).
Our "master" branch is actually what would be the "develop" branch in
that model. While we should mainly concentrate on the features that are
considered mandatory or at least "nice to have" for R1, I think there's
generally no opposition to incorporating other new features. So
essentially you can merge any feature that is complete and stable (!).
I.e. if you implement session management and get it into a solid shape,
it will be included in the next release -- which ATM is R1.
One caveat though: Since session management will require API changes and
extensions, care must be taken to retain compatibility. And the new API
will have to be experimental first.
On 02/27/2013 07:08 PM, Jessica Hamilton wrote
> On 02/27/2013 04:32 PM, Ryan Leavengood wrote:
>
> > In an ideal world, you could release the main tree any day.
> >
> > The fact that we'll anticipate a lot of API changes during that
> > time surely
> > won't make this easier, but being able to do intermediate
> > releases will be
> > crucial for the project.
>
> > On this topic, there is a methodology called git-flow that I
started
> > using at work, and it might be worth investigating for Haiku. I
> > haven't used it long enough to say all the benefits or lack
thereof,
> > but I just figured I would mention it:
>
> > https://github.com/nvie/gitflow
I find the model a bit weird. The only purpose of the "master" branch
seems to be as an alias for the latest release. I'd rather keep the
release branches around and use a moving tag (e.g. "current-release") to
mark the latest. Consequently "master" could be used for the purposes of
the "develop" branch (i.e. integrating new features) and the latter
could be omitted. Similarly the hotfix branches could simply be
continuations of the release branches with the actual release points
being marked via tags.
> I actually find http://scottchacon.com/2011/08/31/github-flow.html to be
> a better approach... and fits with the idea of being able to release the
> main tree any day.
I'm rather skeptical regarding such an approach for Haiku. I think
releases with a preceding focused testing and bug-fixing period are the
best way to reach a good level of quality.
> I also find topic/feature branches make it easier to
> track changes within haiku in more manageable chunks given how massive
> the codebase is. And this in turn enables other people to look at the
> more focused changes and maybe even contribute to them.
I agree that (especially larger) features should be developed in
dedicated feature branches (outside the main repository). I believe we
already have started to switch to that practice, though we could work on
doing that even more consequently. Having the commit mailing list as a
central means of following all the work in separate repositories is a
pretty cool feature for that purpose IMO.
CU, Ingo
Other related posts:
