Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Le mardi, 23 octobre 2012 19.19:37, Sune Vuorela a écrit : > 1) report a bug 'should this package be orphaned?' against the package > with a more or less defalut templated text and a serious severity Make it 'affects qa.debian.org', with an eventual usertag, eventually X- Debbugs-CC debian-qa@ldo, so that people who care can get warned, and I'm with you. > 2) sleep 4*7*24*3600 That should be enough time for anyone interested in the package to comment, either way. > 3) if bug silent, orphan it (and maybe adopt it) > > For a quite common thing to do, this is just drowning it in bureaucracy. Yes. We should aim to more simplicity. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201210241136.33442.o...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek writes: > On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote: >> > 4. When/if consensus has been reached, the package can be orphaned by >> >retitling and reassigning the ITO bug accordingly. > >> I fear a bit the situation "nobody care enough to comment", being >> interpreted as lack of consensus. But I do think in that case we should >> _eventually_ allow the orphaning to happen (after all 1/0 > 3/1 ACK/NACK >> ). >> Any suggestion on how to word that properly, without adding yet another >> timeout rule carved in stone? > > I disagree on this point. If you can't get anyone to ack that you should go > ahead with the orphaning, then the system is not working as designed and > consensus has not been achieved. It's then incumbent on the person looking > to orphan the package to rattle the cage and get developers to pay > attention. On the other hand, it is already hard to find people willing to review other peoples work. Mandating acks means trusting that there will be enough manpower to review something potentially unknown. I can't see that happening reliably. It also makes the process a whole lot more complicated than it needs to be, which in turn allows the package to suffer unmaintainance longer, decreasing the distributions overall quality. As said elsewhere in the thread, the process needs to be easy and efficient. Hunting ACKs is neither easy, nor efficient. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zk3caxpj.fsf@algernon.balabit
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Andreas Tille wrote: >On Tue, Oct 23, 2012 at 05:32:25PM -0400, Scott Kitterman wrote: >> I don't object to ACKs, but the requirement to get a certain ACK/NACK >ratio. I see risk of this devolving into a popularity contest. >> >> I think it should either be unanimous or there is a dispute that the >tech ctte needs to resolve. >> >> Sune's proposal certainly seems simpler (and I see simplicity as a >virtue), but modulo the voting issue, I think either would be fine. > >I do not think that the packages we are talking about here in this >thread might frequently trigger some voting / popularity contest. If >really more than one NACK would be rised we most probably do not see >such an salvage candidate as we actually have in mind here. If more >than two people would really NACK we probably have awaken some people >who might start caring about the package again - so it might serve to >salvage it by the original maintainers which is fine as well. > >I would suggest to apply the proposed rules because I do see more >danger >in getting no salvaging process at all because of endless discusion >about this process and I would bear the risk that the rules will not >work in some exceptional cases (as for all rules). That could work either way. If you're in such a rush to build consensus you could change 3/1 ACK/NACK ratio to without objection (objections result in disputes resolved by the tech ctte) and have a +1 from me. The problem is that once in place these rules are rather harder to change. While you have in mind a certain set of packages this rule should be applied to, there's nothing preventing it from being applied in incorrect cases. The popularity contest aspect of the current rule creates a risk that maintainers that make unpopular, but technically correct, choices will have their packages orphaned out from under them. This is not what Debian is about and we should not institutionalize such a thing. I'm firmly -1 as long as there a popular vote in this proposal. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84db0545-3e47-4f6c-9571-66e24209c...@email.android.com
Bug#691349: ITP: libopencm3 -- firmware library for ARM Cortex-M3 and similar microcontrollers
Package: wnpp
Severity: wishlist
Owner: chrysn
* Package name: libopencm3
Version : not released yet
Upstream Author : Uwe Hermann , Piotr Esden-Tempski
and others
* URL : http://libopencm3.org/
* License : LGPL-3+
Programming Lang: C
Description : firmware library for ARM Cortex-M3 and similar
microcontrollers
libopencm3 (formerly libopenstm32) provides the basic library functions
for programming ARM Cortex M-3 microcontrollers. These tend to have
around up to 128k RAM and 1024k flash ROM, and onoboard peripherials
like SPI, UARTs, USB and general purpose IO (GPIO) pins. The library
contains drivers for the common core chip functionality (turning on and
off interrupts, managing the systick timer) and for the individual
chips.
* * *
the debian branch i'm keeping in the upstream git repo at [1] is
functional in the sense that libopencm3 can be used from the installed
package, but has several shortcomings:
* it depends on something to provide arm-none-eabi-gcc and an
appropriate libc (eg newlibc).
currently, i'm using a popular script to download, compile and install
the required toolchain: summon-arm-toolchain[2] (by the libopencm3
authors), for which i wrote a little debian directory[3] -- in that
form, it's pretty inacceptable as a debian package, though.
* it feels strange to have compiled binaries (statically linked
libraries) in an "architecture: all" package -- but seems technically
correct. (things were different if there was a debian port to those
chips, but only few of them support running linux at all).
* loads of lintian warnings, many about files at strange locations.
upstream installs to /usr/arm-none-eabi/{lib,include}, which is in
line with what the gcc used is expecting.
* some essential packaging stuff is missing (copyright and watch file,
the latter for lack of a release process, which is just being
discussed on the project mailing list) -- can fix that myself, it's
just lower priority than getting everything to build in the first
place
* examples are not installed yet -- can fix that myself too
so what i'd need in order to complete that package is:
* an idea of how to create an arm-none-eabi-gcc package properly.
my gut feeling says that the gcc-4.[67] packages should build another
binary package called gcc-4.[67]-arm-none-eabi, similar to
gcc-4.6-hppa64. i'm not familiar with how gcc actually works, so i
wonder whether we could have a gcc-4.7-multiarch just like we have
binutils-multiarch (which works well for libopencm3). same goes for
gdb (not depended on, but more "essential" than "useful" to
developers)
* a packaged newlibc; given how libstdc++ is integrated with gcc, i
don't know whether that's separate from the above or not.
* a statement on where things should actually go. /usr/share feels just
as wrong as "architecture: any" feels, and lintian complains about
/usr/arm-none-eabi/.
i'd like to emphasise that (from my understanding) this is neither
related to multiarch nor to emdebian, both of which are dealing with
cross compilation to other debian architectures, and this is about bare
metal programming.
[1] https://github.com/libopencm3/libopencm3/tree/debian
[2] https://github.com/esden/summon-arm-toolchain
[3] https://github.com/chrysn/summon-arm-toolchain
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
signature.asc
Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, Oct 24, 2012 at 02:59:09PM +0800, Thomas Goirand wrote: > On 10/24/2012 11:55 AM, Bart Martens wrote: > >On Tue, Oct 23, 2012 at 01:40:16PM -0700, Steve Langasek wrote: > >>>I fear a bit the situation "nobody care enough to comment", being > >>>interpreted as lack of consensus. But I do think in that case we should > >>>_eventually_ allow the orphaning to happen (after all 1/0> 3/1 ACK/NACK > >>>). > >>>Any suggestion on how to word that properly, without adding yet another > >>>timeout rule carved in stone? > >>I disagree on this point. If you can't get anyone to ack that you should go > >>ahead with the orphaning, then the system is not working as designed and > >>consensus has not been achieved. It's then incumbent on the person looking > >>to orphan the package to rattle the cage and get developers to pay > >>attention. > >I agree with Steve on this. > >Regards, > >Bart Martens > So, what will you do if: > - previous maintainer goes MIA > - Somebody wants to hija^W salvage the package and starts the procedure > - Nobody votes for this to happen... > Should we then leave the package forever unmaintained? > I don't think this is reasonable... And I don't think this is a realistic scenario. Why can't you find N other DDs who agree with you that the package should be taken over? This is not a high bar. I don't really have any sympathy for the argument that the entire Debian project might decide not to care about the package you're concerned about and therefore you need to take matters into your own hands and take it over. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, Oct 24, 2012 at 02:59:09PM +0800, Thomas Goirand wrote: > On 10/24/2012 11:55 AM, Bart Martens wrote: > >On Tue, Oct 23, 2012 at 01:40:16PM -0700, Steve Langasek wrote: > >>>I fear a bit the situation "nobody care enough to comment", being > >>>interpreted as lack of consensus. But I do think in that case we should > >>>_eventually_ allow the orphaning to happen (after all 1/0> 3/1 ACK/NACK > >>>). > >>>Any suggestion on how to word that properly, without adding yet another > >>>timeout rule carved in stone? > >>I disagree on this point. If you can't get anyone to ack that you should go > >>ahead with the orphaning, then the system is not working as designed and > >>consensus has not been achieved. It's then incumbent on the person looking > >>to orphan the package to rattle the cage and get developers to pay > >>attention. > >I agree with Steve on this. > > > So, what will you do if: > - previous maintainer goes MIA > - Somebody wants to hija^W salvage the package and starts the procedure > - Nobody votes for this to happen... > > Should we then leave the package forever unmaintained? > I don't think this is reasonable... Steve explained that, see above. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121024161745.gb21...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote: > > I disagree on this point. If you can't get anyone to ack that you should go > > ahead with the orphaning, then the system is not working as designed and > > consensus has not been achieved. It's then incumbent on the person looking > > to orphan the package to rattle the cage and get developers to pay > > attention. > On the other hand, it is already hard to find people willing to review > other peoples work. Mandating acks means trusting that there will be > enough manpower to review something potentially unknown. I can't see > that happening reliably. It also makes the process a whole lot more > complicated than it needs to be, No, it makes the process based on *consensus*, which is a minimum requirement. > which in turn allows the package to suffer unmaintainance longer, > decreasing the distributions overall quality. > As said elsewhere in the thread, the process needs to be easy and > efficient. Hunting ACKs is neither easy, nor efficient. The debian-qa list served this purpose fine for *years*. It's not acceptable to use handwavy assertions about manpower to justify an antisocial process. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
> Steve Langasek writes:
>
> > On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
> >> > 4. When/if consensus has been reached, the package can be orphaned by
> >> >retitling and reassigning the ITO bug accordingly.
> >
> >> I fear a bit the situation "nobody care enough to comment", being
> >> interpreted as lack of consensus. But I do think in that case we should
> >> _eventually_ allow the orphaning to happen (after all 1/0 > 3/1 ACK/NACK
> >> ).
> >> Any suggestion on how to word that properly, without adding yet another
> >> timeout rule carved in stone?
> >
> > I disagree on this point. If you can't get anyone to ack that you should go
> > ahead with the orphaning, then the system is not working as designed and
> > consensus has not been achieved. It's then incumbent on the person looking
> > to orphan the package to rattle the cage and get developers to pay
> > attention.
>
> On the other hand, it is already hard to find people willing to review
> other peoples work. Mandating acks means trusting that there will be
> enough manpower to review something potentially unknown. I can't see
> that happening reliably.
I think that sufficient DDs will review the ITOs. Note that most work is
already done by the ITO submitter. Sponsoring a package at mentors ("review
other peoples work") is, in my opinion, much more work than reading an ITO and
sending an ACK.
> It also makes the process a whole lot more
> complicated than it needs to be, which in turn allows the package to
> suffer unmaintainance longer, decreasing the distributions overall
> quality.
It's not so complicated to find three DDs to agree with the ITO.
>
> As said elsewhere in the thread, the process needs to be easy and
> efficient. Hunting ACKs is neither easy, nor efficient.
The proposed text is quite easy, in my opinion.
Regards,
Bart Martens
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121024162732.gc21...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On 10/25/2012 12:11 AM, Steve Langasek wrote: And I don't think this is a realistic scenario. Why can't you find N other DDs who agree with you that the package should be taken over? Hum ... and what makes you think that it will always be easy to find people to ACK? Making sure that a package is left unmaintained does take some time. At the end, some DDs might just send ACK on some hijacking/salvage bugs in the BTS just because they trust their friends, without doing any checks, which would defeat the purpose of such ACK. Some other DDs might decide to just never send ACK because they don't want to be in the middle of a package "ownership" battle. In some other cases, we will see bugs being opened, nobody sending ACK, and the person willing to become the new maintainer not doing anything because not motivated by this. For the case of someone not being a DD, and willing to take over the maintainership, and not knowing a lot of people in the Debian community, this process of ACK / NACK might simply not work at all. I remember when I started a thread about 6 months ago, willing to take over maintainership of a clearly unmaintained package (since then, all other packages of this maintainer have been orphaned...). It (unwillingly) created a huge thread about when and when not taking over a maintainer, with some of the thread participant having no clue what so ever if the old maintainer was still alive or not. All this for what? Avoiding that someone hijacks a package? Does this happen often? If yes, please point to the relevant recent cases, because I must have missed them. I'd be also glad to read what kind of consequences we are facing with more relaxed rules. The rules are already too tight for no reason now, so of course I don't think adding even more paper work for taking over someone who's anyway MIA would be a good thing. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50882bf8.1080...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On 10/25/2012 12:15 AM, Steve Langasek wrote: No, it makes the process based on *consensus*, which is a minimum requirement. How many people should send ACKs in this system? - If it's a lot of people, then it's hard to hunt for so many. - If it's not a lot of people, then it hardly can be called a consensus. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50882cd1.9060...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, 2012-10-24 at 14:59:09 +0800, Thomas Goirand wrote: > So, what will you do if: > - previous maintainer goes MIA > - Somebody wants to hija^W salvage the package and starts the procedure > - Nobody votes for this to happen... They should use the already existing MIA process instead... regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121024185215.ga25...@gaara.hadrons.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote: > I remember when I started a thread about 6 months ago, > willing to take over maintainership of a clearly unmaintained > package (since then, all other packages of this maintainer > have been orphaned...). It (unwillingly) created a huge thread > about when and when not taking over a maintainer, with some > of the thread participant having no clue what so ever if the old > maintainer was still alive or not. Do you also remember WHY it created a huge thread? It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS ASSENT. Silence is not assent. That thread blew up because you proposed a *broken* process for trying to orphan a package that didn't require you to establish a consensus, which is the exact same thing you are now arguing. Establishing consensus about whether a package should be orphaned isn't hard, if you're following the right process in the first place! > All this for what? Avoiding that someone hijacks a package? > Does this happen often? If yes, please point to the relevant > recent cases, because I must have missed them. I'd be also > glad to read what kind of consequences we are facing with > more relaxed rules. > The rules are already too tight for no reason now, so of course > I don't think adding even more paper work for taking over > someone who's anyway MIA would be a good thing. Fine, if getting a consensus is too much work for you, feel free to refer all maintainer change requests directly to the Technical Committee instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Second BSP in Dublin + Ireland DUG announcement
Bug Squashing Party in Dublin = http://wiki.debian.org/BSP/2012/11/ie/Dublin Come and help get Wheezy released, a second time! After the success of the first Irish Debian BSP, we're holding a second one in November. We will gather to collectively fix bugs and help each other while having some fun. Visits to the pub are assured after a day of hard work! Everybody is invited, even newcomers! We will assist people who has never done this before, and the whole point of getting together is to help each other! There is no need to be a programmer to help, there are plenty of tasks for everyone! See http://people.debian.org/~vorlon/rc-bugsquashing.html for what exciting opportunities there are! Over [http://bugs.debian.org/release-critical/] of them! :-) Ireland Debian User Group created - Since I am already spamming all of you, I want to announce that the Ireland DUG can be considered founded after the Debian listmasters created our mailing list! You can subscribe here: https://lists.debian.org/debian-dug-ie/ When Saturday 3rd November, 2012. 11:00-19:00 Where = Google Ireland 1 Grand Canal Plaza Dublin 4 Ireland http://osm.org/go/es~TUCk1U-- (Dunno how to mark a point in the map!) We'll get a nice conference room in the ground floor with good Wi-Fi access, free snacks, and pizza! Who === Please add yourself to the list in the wiki page (http://wiki.debian.org/BSP/2012/11/ie/Dublin), I'll need to provide a list of people attending the event. Where to stay = If you do not live in Dublin and don't know where to stay, but would like to come, then please contact debian-dug...@lists.debian.org and we'll try to host you. -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL60Pd9QbdK24T-3D135fDWQAQn9iPV+Y=_5qwtjx2lb6ke...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Wed, Oct 24, 2012 at 11:48:12AM -0700, Steve Langasek wrote: > Silence is not assent. That thread blew up because you proposed a *broken* No, silence is an indication that you don't deserve any decision-making power. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121024214608.ga3...@scru.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Le Wed, Oct 24, 2012 at 09:46:08PM +, Clint Adams a écrit : > On Wed, Oct 24, 2012 at 11:48:12AM -0700, Steve Langasek wrote: > > Silence is not assent. That thread blew up because you proposed a *broken* > > No, silence is an indication that you don't deserve any decision-making > power. Hi all, while in general one can not make interpretation for silence, in this particular case, I think that the absence of any reaction to the proposition to orphan a package is actualy a clear demonstration that the package is orphan. It is not a question of who has power or not, it is about correcting a package's metadata to reflect a fact. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121024233819.ga31...@falafel.plessy.net
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thu, Oct 25, 2012 at 08:38:19AM +0900, Charles Plessy wrote: > Le Wed, Oct 24, 2012 at 09:46:08PM +, Clint Adams a écrit : > > On Wed, Oct 24, 2012 at 11:48:12AM -0700, Steve Langasek wrote: > > > Silence is not assent. That thread blew up because you proposed a > > > *broken* > > No, silence is an indication that you don't deserve any decision-making > > power. > while in general one can not make interpretation for silence, in this > particular case, I think that the absence of any reaction to the > proposition to orphan a package is actualy a clear demonstration that the > package is orphan. No. We're talking here about silence *from the entire Debian developer community* in response to a call for orphaning. That says nothing about whether the package is orphaned. It may just mean you've managed to send your request to the wrong place (or gotten it stuck in a mail queue somewhere). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121024235113.ga22...@virgil.dodds.net
