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

["D Bera" <dbera web gmail com>]

Hi Joe,

> Indeed.  All new code really needs to go onto a branch and made
> working before being merged back onto the trunk.

Note the "new code ... made working before being merged ..." and read
on further.

> I've not been particularly happy with two fairly large chunks of code
> that are half-finished sitting on the trunk (network searches and the
> web interface).  The former in particular is the largest thing holding
> up a 0.3.0 release, IMO.  The latter is more easily disabled, but I'd
> still prefer not to ship it (in source) if it's not considered ready.

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.
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.

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.

BTW, the number of new features (without the uninstalled web-ui) in
trunk is overwhelming:
- thunderbird backend
- firefox (extension) backend
- network searches
- different way of indexing attachments and archives
- LaTeX filter
- beagle-search IO polish
- snowball analyzer
- XMP metadata (this is the one which I actually consider as the
blocker; I have to think about the whole external metadata stuff
considering how to handle nautilus/xmp/tags-store but I keep finding
excuse to not to do it :( )
- features I am pretty sure I missed

And to give a sneak peek on the features coming:
- better web interface, including showing snippets, showing emails
directly in the browser and showing full cached text
- extensible local/global configuration + client API to deal with
configuration. + web-ui interface to change settings
- better textcache storage to reduce wasted space created by lots of small files
- textcat support for language determination and using language
specific stemmer (depending on performance)
- BasKet backend
- don't remember

Some of the changes will be incremental change and will go in the
trunk. Some of them are large changes, will require longer time to get
it ready to be usable and may not the final implementation that will
get into trunk, so those will go into a branch.

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!".

- dBera

-- 
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user