On Sat, Apr 18, 2015 at 07:34:35AM -0400, Karl Dahlke wrote:
> > What the last couple of days have shown is that making undiscussed changes is
> > just going to get circular due to differing user requirements and opinions.
> 
> Yes and we all did that, when initially my intent was just to fix a bug.
> But instead we changed the user interface, things expanded when they didn't before,
> and conversely, changing the meaning of ` etc,
> and some of the edbrowse users, who are not on this list
> contacted me and were confused.
> So now it works all as it did before, except the bug is fixed,
> and the code is much cleaner inside.
> Of course there's nothing wrong with cleaning up code,
> but we do have to talk more and plan more
> before changing the user interface.

I think this also comes back to release management as well, i.e.
users really shouldn't be pulling the latest git and expecting everything to be
fully working, that's not what version control's for in a collaberative project.
If people are running the latest, bleeding edge,
code then things will break like this.
Obviously I hope some users do keep doing this since user feedback is always
welcome, but we're a development team now and we need to be kept in the loop if
this kind of thing is happening.

One thing that's on my mind at the moment is that,
when I seriously get stuck into the DOM stuff,
I'll need people to work with me on that and I'd rather not do it with a gun to my head i.e.
users pulling git changes and expecting the same browsing experience etc.
That just won't happen due to the amount of changes.
I appreciate not everyone's on this list,
but I'd personally change the github page to point to this list rather than the
commandline list since git is our development environment.
We post released code (at least I hope we do) and binaries,
if users want a stable browser they should probably use that.
Of course this also means we need to be better at getting features out,
thus preventing users from having to use our git repo to get anything close to
the latest code.
I'd like to head towards more of a monthly or 2 monthly release cycle if we
can, with small point releases for features.
For example the plugin changes warrent a point release.
Obviously if there're no new features then there's no new release but we should
be aiming to get features out as soon as they're stable really.
That'll also have the nice side effect of keeping the project moving,
which is always a good thing.
That being said, I accept that the build process is rather involved at the
minute, so we may need to work to automate some of that.

Cheers,
Adam.