edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] wordexp again
Date: Sat, 18 Apr 2015 14:09:10 +0100	[thread overview]
Message-ID: <20150418130910.GM5949@toaster.adamthompson.me.uk> (raw)
In-Reply-To: <20150318073435.eklhad@comcast.net>

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-04-18 13:10 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 21:40 Karl Dahlke
2015-04-17  7:12 ` Adam Thompson
2015-04-17 12:50   ` Adam Thompson
2015-04-17 13:33     ` Karl Dahlke
2015-04-17 17:59       ` Adam Thompson
2015-04-17 13:47     ` Karl Dahlke
2015-04-17 18:01     ` Karl Dahlke
2015-04-17 21:34       ` Adam Thompson
2015-04-17 21:58         ` Adam Thompson
2015-04-17 22:25           ` Karl Dahlke
2015-04-17 22:43             ` Adam Thompson
2015-04-17 23:14               ` Karl Dahlke
2015-04-17 22:28           ` Adam Thompson
2015-04-17 22:39             ` Karl Dahlke
2015-04-18 10:53               ` Adam Thompson
2015-04-18  4:18     ` Karl Dahlke
2015-04-18 10:49       ` Adam Thompson
2015-04-18 11:34         ` Karl Dahlke
2015-04-18 13:09           ` Adam Thompson [this message]
2015-04-18 19:33             ` Chris Brannon
2015-04-18 20:05               ` Adam Thompson
2015-04-18 23:03                 ` Chris Brannon
2015-04-18 12:36         ` Karl Dahlke
2015-04-18 12:54           ` Adam Thompson
2015-04-18 13:09             ` Karl Dahlke
2015-04-18 13:24               ` Adam Thompson
2015-04-18 13:45                 ` Karl Dahlke
2015-04-18 17:44                   ` Adam Thompson
2015-04-18 19:48                     ` Karl Dahlke
  -- strict thread matches above, loose matches on Subject: below --
2015-01-09 22:44 Karl Dahlke
2015-01-09 22:19 Karl Dahlke
2015-01-09 22:29 ` Chris Brannon
2015-01-09 21:16 Chris Brannon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150418130910.GM5949@toaster.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).