[PATCH 1/2] bump published Ruby version requirement to 2.0

[PATCH 1/2] bump published Ruby version requirement to 2.0

[Eric Wong]

Note: technically we remain unofficially 1.9.3-compatible
outside of extras/try_gzip_static.rb, but we won't try very
hard to remain 1.9.3 compatibility in the future.

We'll also stop advertising Rubinius compatibility: I am no longer
willing to deal with proprietary bug trackers.

In the future, becoming 2.0.0+ only will allow us to drop the
close_on_exec=true assignments we do all over the place.
---
 README | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/README b/README
index 1db5284..3867ccc 100644
--- a/README
+++ b/README
@@ -48,8 +48,7 @@ We have experimental support kqueue on FreeBSD (and possibly OpenBSD and
 NetBSD).  Non-Free systems/dependencies will never be supported.
 
 Supported Ruby implementations:
-* (Matz) Ruby 1.9.3 and later (we develop (and host our website) on trunk)
-* Rubinius 2.0 or later (best-effort)
+* (Matz) Ruby 2.0.0 and later (we develop (and host our website) on trunk)
 
 Contact
 -------
-- 
EW

Re: [PATCH 1/2] bump published Ruby version requirement to 2.0

[Lin Jen-Shin (godfat)]

Hi, this is a bit off-topic, but I am wondering:

On Wed, Dec 17, 2014 at 6:54 AM, Eric Wong <e@80x24.org> wrote:
> We'll also stop advertising Rubinius compatibility: I am no longer
> willing to deal with proprietary bug trackers.

Is it because they are using GitHub's issue tracker?
Is there any freely hosted issue tracker you might be
suggesting?

Last time I tried to use freelists.org to replace Google Groups,
it works ok. I am all for free software, but don't really want to
bother any hosting :(

Re: [PATCH 1/2] bump published Ruby version requirement to 2.0

[Eric Wong]

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> Hi, this is a bit off-topic, but I am wondering:

Not off topic at all.

> On Wed, Dec 17, 2014 at 6:54 AM, Eric Wong <e@80x24.org> wrote:
> > We'll also stop advertising Rubinius compatibility: I am no longer
> > willing to deal with proprietary bug trackers.
> 
> Is it because they are using GitHub's issue tracker?

Yes, for rubinius and their rubysl-* stdlib

> Is there any freely hosted issue tracker you might be
> suggesting?

I can tolerate Redmine for mainline Ruby.  Unfortunately it still
requires login+registration (but no legal terms-of-service to accept).

Debian's email-based BTS is the best I've seen (no registration);
but I do not like "formal" things such as
classifying/prioritizing/assigning/organizing bugs: I just fix bugs.

For some projects, I'd rather file bug reports against the Debian
package and let the Debian maintainers deal with upstream trackers.

Having only a mailing list works best for me :)

> Last time I tried to use freelists.org to replace Google Groups,
> it works ok. I am all for free software, but don't really want to
> bother any hosting :(

savannah.nongnu.org offers ad-free hosting of mailing lists, bug
tracking, file hosting, etc.  They're rather picky of things like having
copyright notices on every single file (even more so than Debian), but
it's not limited to GNU projects or even GNU licenses.

I've only tried savannah's mailing list hosting and it seems fairly
spam-free (easy with Postgrey, but the delays can be annoying).

I still prefer public-inbox+mlmmj (what this list uses) to Mailman,
though: password-free workflow, good defaults in mlmmj,
git synchronization of archives, SpamAssassin+incrond integration...

I actually don't have a /huge/ problem with Google Groups mailing lists
because it's still SMTP (not a proprietary API), and it's subscribable
w/o a Google account (for now).  Of course, their spam filtering sucks
and as a result: every Google Group I'm on requires subscription to post
or even first-post-moderation.  I think their web-based archives also
require proprietary JS to browse.  mail-archive.com and gmane.org come
in handy there.

That said, running public-inbox+mlmmj has been easier than I expected it
to be the past 7 months (as far as dealing with spam + bounces go).

Re: [PATCH 1/2] bump published Ruby version requirement to 2.0

[Lin Jen-Shin (godfat)]

On Wed, Dec 17, 2014 at 8:01 PM, Eric Wong <e@80x24.org> wrote:
> "Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
>> Hi, this is a bit off-topic, but I am wondering:
>
> Not off topic at all.

Haha, great.

>> On Wed, Dec 17, 2014 at 6:54 AM, Eric Wong <e@80x24.org> wrote:
>> > We'll also stop advertising Rubinius compatibility: I am no longer
>> > willing to deal with proprietary bug trackers.
>>
>> Is it because they are using GitHub's issue tracker?
>
> Yes, for rubinius and their rubysl-* stdlib

Sadly I guess they are not going to change this any time soon.

>> Is there any freely hosted issue tracker you might be
>> suggesting?
>
> I can tolerate Redmine for mainline Ruby.  Unfortunately it still
> requires login+registration (but no legal terms-of-service to accept).

From what I've used so far, I like Redmine best, but there's no
free Redmine hosting.

> Debian's email-based BTS is the best I've seen (no registration);
> but I do not like "formal" things such as
> classifying/prioritizing/assigning/organizing bugs: I just fix bugs.
>
> For some projects, I'd rather file bug reports against the Debian
> package and let the Debian maintainers deal with upstream trackers.
>
> Having only a mailing list works best for me :)

Haha. Sounds like distribution maintainers really have a lot to do.

>> Last time I tried to use freelists.org to replace Google Groups,
>> it works ok. I am all for free software, but don't really want to
>> bother any hosting :(
>
> savannah.nongnu.org offers ad-free hosting of mailing lists, bug
> tracking, file hosting, etc.  They're rather picky of things like having
> copyright notices on every single file (even more so than Debian), but
> it's not limited to GNU projects or even GNU licenses.

I guess that won't work for me then. It would be great if we could have
something built on top of Git so that hosting won't be an issue.
Unfortunately all projects from what I know doing that all stopped
developing.

> I've only tried savannah's mailing list hosting and it seems fairly
> spam-free (easy with Postgrey, but the delays can be annoying).
>
> I still prefer public-inbox+mlmmj (what this list uses) to Mailman,
> though: password-free workflow, good defaults in mlmmj,
> git synchronization of archives, SpamAssassin+incrond integration...

My first impression is that so much I need to learn to host one :o

> I actually don't have a /huge/ problem with Google Groups mailing lists
> because it's still SMTP (not a proprietary API), and it's subscribable
> w/o a Google account (for now).  Of course, their spam filtering sucks
> and as a result: every Google Group I'm on requires subscription to post
> or even first-post-moderation.  I think their web-based archives also
> require proprietary JS to browse.  mail-archive.com and gmane.org come
> in handy there.

Oh, that's a bit surprising to me. The problem I have with Google Groups
is that their web-based archives is too annoying to me. Yes I could just use
email to read/post or setup some other archives (actually I didn't think of
this before, but I should probably do), but I want to take this chance to find
some other alternatives.

> That said, running public-inbox+mlmmj has been easier than I expected it
> to be the past 7 months (as far as dealing with spam + bounces go).

Is it possible to have a single script to set this up soon? If it's really that
easy to maintain, I should probably try it out.

TAN: public-inbox + mlmmj [was: bump published Ruby ...]

[Eric Wong]

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> On Wed, Dec 17, 2014 at 8:01 PM, Eric Wong <e@80x24.org> wrote:
> > That said, running public-inbox+mlmmj has been easier than I expected it
> > to be the past 7 months (as far as dealing with spam + bounces go).
> 
> Is it possible to have a single script to set this up soon? If it's really that
> easy to maintain, I should probably try it out.

I'm not a fan of telling people to run things without understanding
(take the scary disclaimer for yahns, for example :)
Instead, I've been meaning to streamline installation/setup and work on
better public-inbox docs+howtos over the holidays when I get the chance.

The goal for public-inbox is it can be run by anybody, even with just an
IMAP account (or even POP3) hosted by somebody else.  mlmmj (or
Mailman/smartlist...) delivery can be handled by somebody else on a
completely different machine.

mlmmj itself is already a well-established project and already in
Debian-based distros.  The main weakness (to me) is the lack of
a good archive retrieval system.