bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] Near future for Wget, and bug-tracker changes


From: Micah Cowan
Subject: [Bug-wget] Near future for Wget, and bug-tracker changes
Date: Fri, 02 Oct 2009 15:14:12 -0700
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Announcement: Savannah bug queries that had previously been for "1.13",
will now show results for "1.14", and similarly "1.14" has become
"1.15". A few of you may need to rename your bookmarks.

A new "1.13" item has been inserted, with just a handful of bugs against it.

The current primary goals for a patch-level 1.12.x release are:
 . Get officially-supported Wget builds on Windows again, ideally
including IRI support.
 . Handle too-long filenames (bug 21714).
 . Send cookie values containing backslashes properly (bug 27449).
 . Handle the Subject Alternate Name from SSL certs the way we're
supposed to (20421).

The (new) 1.13 release is currently very narrowly-focused: in a
nutshell, all I'm planning is to get the recently-discussed regex
support, along with the --traverse-links feature, in. While I'm at it,
I'd like to fix some brokenness in our built-in fnmatch (for the current
accept/reject lists feature), and maybe adding a "**" token that also
matches slashes in paths. I want to keep the focus narrow, because
ideally I'd like this feature out in the wild sometime in first-quarter
2010, or as close to that as I can get.

In addition to these things, I've made it my current top priority to
triage the set of bugs that have patches associated with them; I've made
a bad habit of letting other priorities steal momentum from other issues
that may already have been solved by helpful contributors, and what's
worse is I steal the creative energy and momentum of these contributors
by forcing their changes to sit and wait indefinitely, and when I
finally get to them there's the FSF copyright paperwork to do... from
here on out, I want to give patches top priority, all the time, until
they're either sitting back in the author's plate for additional work,
or waiting on paperwork, to minimize these delays.

Any such patches that happen to be ready (and appropriate for the
release) will most likely go into whichever release is upcoming. If
they're big changes they won't go into a patch-level release like
1.12.x; for instance, libproxy support would fall under minor-release
material (it's not a big change to code, but it represents a significant
change in behavior).

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrGezQACgkQ7M8hyUobTrGK9gCfavcm1XD9uMrT4QUjdbxTSBUZ
9ZgAmwYq6xiWyBq6pyyvDJ47h1kL928v
=+au3
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]