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

Re: release update: freeze, RC Bug count, python, toolchain


* Adam Borowski (kilobyte@angband.pl) [060809 12:19]:
> On Tue, Aug 08, 2006 at 11:45:46PM +0200, Andreas Barth wrote:
> > Full IPv6 support
> > =================
> > 
> > There has been some confusion about the Etch release goal about IPv6. Our
> > understanding of that release goal is that all network applications should be
> > able to work with both IPv4 and IPv6. Also stateful packet filtering should
> > work for both protocols. Please consider all bugs tagged "ipv6" to be
> > upgraded to at least important - or even better, fix them.
> How invasive ways are welcome/allowed?

That's a good question.

> For example, I use pound (a reverse proxy/URL redirector/SSL wrapper).
> * unstable has 2.0
> * I use 2.0.9 with my partial (listen-only) IPv6
> * upstream just released 2.1
> The maintainer seems to be MIA.  I didn't unload my patches (IPv6, WebDAV)
> into the BTS yet as upstream kept saying they'll release "tomorrow" or "in
> three days from now" for a few months.  The new stable upstream release got
> released on Saturday, but I've been sick so I didn't port my IPv6 patch to
> 2.1 yet; it should be done and tested soon, though.
> So, should I:
> a) make a backport to 2.0; or
> b) provide patches for the current upstream (2.1) only; or
> c) do a complete overhaul, including unrelated issues; giving the maintainer
>    a tarball and svn
> (Of course, asking the maintainer again is the first thing to do)

Well, what I would do is to:
1. speak with the maintainer;
2. if that fails, check if the maintainer is still active (see section
about MIA maintainers in the developers reference);
3. if the maintainer is no longer active, let the QA group orphan the
package, adopt it and fix it;
3a. if this takes too long, put a minimal-invasive new upstream version
into experimental and encourage people to use it (via planet, ...).

Of course, this are only some ideas from the top of my head; there might
be a more appropriate way to deal with the issues in a case.

BTW, IMHO there is never an issue with putting patches to the BTS, even
if they're intended for future releases (as long as they work). Why not?


Reply to: