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] master
Date: Tue, 28 Jan 2014 16:41:56 +0000	[thread overview]
Message-ID: <20140128164156.GB7404@toaster.adamthompson.me.uk> (raw)
In-Reply-To: <20140028062012.eklhad@comcast.net>

On Tue, Jan 28, 2014 at 06:20:12AM -0500, Karl Dahlke wrote:
> Yes I think it would be easier if all this was moved into master,
> if Adam then had permission to push into masster, as I do,
> if that's ok with you chris, and it's ok with me of course.

Ok, looks like I've been added.  I guess it's ok if I start pushing changes?

> A piece of my brain thinks there should be some backward compatibility,
> like a flag to makefile to build the old way against 185,
> for those who don't have 24 yet,
> but then a larger piece of my brain thinks about the linux kernel,
> where they really discourage that sort of thing.
> Youre just expected to keep up!
> Linux has a means of conditional compilation
> #if version <= 3.2.7
> That kind of thing, but I tell you, you hardly ever see it in the kernel code,
> because if you ever started your code would be full of #if versions
> maybe all the way back to 2.4, and impossible to read,
> so they just tell you generically not to do it.
> So I have come to understand the practical point of view of
> marching forward, and if you want the latest of this you better get
> the latest of that.
Yeah, I think in this case the changes are too large to sustain any sort of
backward compatibility and it'd just make debugging that bit harder.

> Anyways I digress; I think master would be fine,
> the only thing we really have to stop nad pause and well test is the threshold
> of version 3.4.11.
> I think we all have to say yea before we do that.

Yes, definitely. There're a few bugs I know about and think need squashing
before 3.4.11 happens, but the list is thankfully shrinking slowly.
Do we have some form of issue tracker which works with edbrowse (I'm not sure
how edbrowse-friendly the github setup is)?

On the subject of 3.4.11, apart from the js lib change and other bug fixes,
are there any other features or major changes we want to make before it
happens, or do we want to get out the js update and then start pushing
features etc in the next release?

Cheers,
Adam.

  parent reply	other threads:[~2014-01-28 16:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-28 11:20 Karl Dahlke
2014-01-28 16:41 ` Chris Brannon
2014-01-28 16:49   ` Adam Thompson
2014-01-28 16:41 ` Adam Thompson [this message]
2014-01-28 17:16   ` Chris Brannon
2014-01-28 17:31     ` Cleverson Casarin Uliana
2014-01-29 10:54       ` Adam Thompson
2014-01-28 17:35 Karl Dahlke
2014-01-28 21:31 ` Adam Thompson
2014-01-28 21:45 Karl Dahlke
2014-01-28 22:16 ` Chris Brannon
2014-01-29 10:48 ` Adam Thompson

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=20140128164156.GB7404@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).