[re-adding bugreport to list of recipients] On 12-01-31 at 10:17pm, Mike Gabriel wrote: > Hi Andreas, hi Jonas, hi all, > > thanks for the reply!!! > > On Fr 27 Jan 2012 11:44:02 CET Andreas Tille wrote: > > >On Thu, Jan 26, 2012 at 04:27:40PM +0100, Jonas Smedegaard wrote: > > >>[...] > > >[...] > > >I also would like to add the following: Mike's suggestion needs some > >dpkg/apt/whatever coding first. It does not help to make good > >suggestions if you will not come up with patches which you tested for > >some time and than make the maintainers of this core functionality > >accepting these patches. This is not an easy job and according to my > >experience this takes ages. > > I am aware of this. Before starting to code comes enrolling people, > discussing possibilities, listening to what's already there, > listening to other people's ideas, etc. It does not really make > sense to start coding into the dark and finding out that it is not > at all the way to go. > > >I'm comparing with how long it took to make > >apt aware about description translations - and translations is a feature > >about 50% of all Debian users might really *want*. Unfortunately we > >need to realise that Blends is - like it or not - a quite unknown topic > >in the Debian universe even if I try my best to talk about it at any > >DebConf and other events. I like to quote Peter Eisentraut: "You are > >talking about something which does not exist." Well, it is not that > >drastical, but changing the Debian infrastructure on behalf of the needs > >of Blends is at current state not realistic. > > ACK. > > >However, if we are talking about #311188 I think what we could try to > >approach is making config issues of Blends RC critical and thus making > >the bugs we filed against those packages RC critical which in turn would > >enable us NMUing packages of maintainers which are not willing to help > >us otherwise. I know that's also not very nice but would solve the > >problem we are facing and is way more realistic to be solved until June > >(suggested freeze time). > > :-) /me likes this... However, I am rather not thinking about > wheezy, this is a short period. For wheezy the Debian Edu goal has > to be to release D-E wheezy with the first or second point release > of D-E wheezy. Apart from that I hear voices that want to change > over to using Git for D-E development (I am one of that voices). > > >>I am pretty sure that anyone interested in blending would be excited if > >>you invent/refine needed mechanisms for above two needs. ...if done > >>Policy compliant - which does *not* mean weaken Policy but (understand > >>reasons for and) obey Policy. > >> > >>I am less sure that anyone else will volunteer to do the work for you, > >>if that's what you are asking. Personally I would not, because I cannot > >>imagine such work bear fruit - i.e. become Debian Policy compliant. > > > >Perfectly correct. You just will not manage to convince somebody else > >to do the work for you. That's why I would suggest to find a way were > >you can do the work yourself more easy (just do an NMU). > > Should we not address this approach (blend bugs = RC critical bugs > -> make NMUing possible) on debian-devel ML? If you mean raise severity of bug#311188, then that bugreport belongs to Skolelinux, so if feel representative for Skolelinux and you consider the issue more severe than currently tagged then go ahead and change it. I've argued strongly in the past that is was more severe, but have been overruled by Debian release managers, and Petter Reinholdtsen also disagrees (see approx. 30min. into Debconf11 Skolelinux meeting video). If you mean raise severity of bugs underlying bug#311188 then feel free to try, but beware that they package maintainers of those packages have the last say. If you want to force raise severity despite the judgement of respective owners of bugreports, then you should contact the Technical Committee, not raise it at d-devel@ (but going down that route is not recommended). Having said all that, you need not raise severity in order to make NMUs. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature