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

Re: Status of resolutions about TC tweaks



* Anthony Towns (aj@azure.humbug.org.au) [060302 12:11]:
> On Thu, Mar 02, 2006 at 08:51:10AM +0100, Andreas Barth wrote:
> > > >   ]  So I propose we establish a rule that we won't make decisions on
> > > >   ]  issues that aren't ready for an immediate NMU when we make that
> > > >   ]  decision.
> > BTW, I think something similar should be done, but not as strict as in
> > this resolution draft. But let's discuss about that seperate from voting
> > details.

> So, we're considering whether ndiswrapper should be moved to contrib atm.
> We don't actually have a package that we could upload to do that though --
> should we decline to consider the issue without it? If we were to vote in
> favour of moving to contrib, and had a package we could upload it immediately,
> and request ftpmaster (eg, me) to process it straight away, and we'd be done.
> OTOH, without it, we'd either have to do it ourselves, or hope the maintainer
> was willing to.

In the case of ndiswrapper, I think we want such a package, yes. But
consider e.g. a similar case where the maintainer of a new package asks
us "please decide where the package should go to" - in that case, there
is nothing to NMU (another problem occurs if we are asked to
decide/overrule in a case where the tech ctte doesn't have direct
possibilities to commit a change - in that case, I think we should
require "a patch exists").

So, I think the resolution should rather run like:
We establish a rule that we won't make decisions on issues that are
ready. This means,
- for overruling a package maintainer's decision, an appropriate package
  for an NMU exists, and if we overrule, we upload that NMU;
- for other overrulings, an appropriate patch exists, and if we overrule
  and someone from the tech ctte can apply that patch, we apply it;
- for other decisions, we make sure a similar state of readiness exists.


(Just a draft.)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/



Reply to: