Re: New code and branches (was Re: ITagProvider)

["Joe Shaw" <joe joeshaw org>]

Hi,

On 9/28/07, D Bera <dbera web gmail com> wrote:
> This is how I look at branches. When features are at a nascent stage
> i.e. things dont quite work, some _basic_ features are not quite
> complete, it is essentially unusable and the ongoing work could take
> at least a few weeks, I consider it necessary to have a branch. For
> such small dev groups. As long as the trunk builds and runs ok after
> each commit, I think it OK.
>
> Accordingly, both the network-search and web-ui (which depends on the
> former) met the above criteria and so they are available in the trunk.

I certainly disagree in the case of the network search code.  The code
that landed in the trunk is significantly different than the code
which lived in the branch, and it's not particularly stable.  With
Avahi support at least, I've not had a network enabled daemon survive
the night.

Also recall that all of the tools were broken for a bit on the trunk
because messages weren't attached to the Unix domain socket handler by
default.  That's the sort of thing that should probably have been
caught and fixed on a branch.

Now, I think the design changes Lukas went for are the right ones, and
I've been supportive of his work on this.  But I think a number of the
TODO items in his original mail are still outstanding:

    http://mail.gnome.org/archives/dashboard-hackers/2007-August/msg00029.html

I know that he hasn't had the time to dedicate to the code that he'd
like.  This happens to all of us, and it's a reality of life, but it's
also something that operating on a branch insulates us from.

The web UI, I agree that it's more separate from the core and that its
impact on stability, etc. are lowered.

> They both work, has the basic features working and its important it to
> be there because then people who install the trunk can report bugs.
> Its quite hard to get any QA done on branches.

I think it's hard to get people to QA SVN entirely.  I'm not sure that
QAing a branch is any worse than the trunk, honestly.  Especially if
the branches are kept in sync with the trunk and things like index
format changes are minimized.

> As for the 0.3.0, since you released 0.2.18 a few weeks ago, I was
> under the feeling that it will be at least a month before 0.3.0.
> Nirbheek (bheekling) is working hard on the web-ui and I think he can
> get it look and function much better in the next few weeks (not that
> it is unsable now). But if you have intention of making a release, you
> gotta let us know.

My general feeling is that the trunk should always be (more or less)
in a releasable state.  We can branch off "stable" branches and make
releases on those as we did with 0.2.16 and later, but keeping those
up-to-date with bug fixes is a pain, and one which we've not done a
great job doing.  (Bug fix branches end up being a lot more work
because so many fixes on the trunk make sense and need to be
backported; this happens a lot more often than you'd need to, for
example, update a feature branch to bring it in line with the trunk.)

> I hope that gives you a better picture of whats happening in the trunk
> right now (and also in IRC) and helps you in deciding when to call it
> "freeze!".

Yeah, the trunk is formidable and a nice step forward, and I don't
want to minimize the awesome work you and others have done, but it
feels more like the "old" way Linux kernels were released: once the
unstable branch was opened, everything broke, people added all these
new features, and it took forever for it to stablize again.  The "new"
way, which is somewhat similar to how GNOME does it, is to do much
more incremental development.

Of course, they also use git, which would help this situation a lot
too, but I don't foresee us doing that any time soon.

Joe