Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - sponsoring
On Thu, Oct 25, 2012 at 10:05:40PM +, Jean-Michel Vourgère wrote: > When fixing non important bugs, or improving the package quality, like > switching to format 3 source, arranging the rules file, and so on, I fear > it will be very difficult to find a sponsor for these nmus. > > Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these > cases. After it's done, one can work on more radical changes, that are more > likely to get sponsored. > > I find it sad to see patches hanging for years in the bug tracker. I fully agree with the above. I occasionally sponsor packages. I don't sponsor NMU packages when they contain changes that don't conform to the NMU procedure. I understand that it is difficult for non-DDs to salvage packages via NMUs. I prefer that an unmaintained package is simply orphaned, so that the non-DD can adopt the package with full maintainership. Much easier to sponsor. 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/20121026071211.gm10...@master.debian.org
Re: non-developer packages depending on gettext?
On Fri, 19 Oct 2012 23:20:39 +0700 Ivan Shmakov wrote: > > Neil Williams writes: > > […] > > > Check if the package contains a shell script which supports > > translated output strings — such packages should Depend: gettext-base > > rather than drop the dependency entirely. > > > I've had a quick look at gnas and it does seem that this is a case > > where gettext-base is required, but not gettext. > > ACK, thanks for the information. > > To note is that Source: gnunet has contrib/report.sh, which > calls gettext(1), but it doesn't seem to be propagated to any of > the binaries currently depending on gettext. You've misunderstood the gettext packaging. $ dpkg -S `which gettext` gettext-base: /usr/bin/gettext So packages/scripts which call gettext should not depend on gettext but on gettext-base instead - that's the point. This little wrinkle (an executable not being packaged in the binary package of the same name) is probably the entire reason for why packages end up with the wrong dependency. It doesn't get picked up because, in most cases, it simply doesn't matter enough. Having gettext and gettext-base installed is rarely going to be an actual problem, it's merely an inconsistency. > > gettext should only be necessary for packages or tasks which > > *manipulate* PO files directly, rather than use the processed .mo > > files to generate translated output. So, Build-Depends: yes, > > Depends: probably a bug. gettext-base is only really needed when the > > package provides shell scripts with translated output because those > > evaluate the gettext process at runtime but that only requires > > gettext-base, not gettext. .. and that evaluation in shell scripts uses /usr/bin/gettext in an eval or similar but that still means a dependency on gettext-base *not* gettext. > > Could be worth filing a wishlist bug against lintian because it > > should be quite easy to spot. > > ? I see no easy way to discern between these three cases (the > dependency is valid, depend on gettext-base instead, drop the > dependency altogether.) 0: Manipulating PO files directly should only happen during package builds, so either the package is itself a build tool (like po4a) or the dependency goes into Build-Depends. 1: Depend on gettext-base but not gettext when the package calls /usr/bin/gettext, dgettext and/or ngettext directly (all from gettext-base) rather than the other executables in the gettext binary package which do stuff like manipulating or reporting on PO files. 2: Drop any dependency when no calls to gettext can be found in the source and it isn't a build tool. Languages other than shell have in-built ways of using the .mo file prepared through PO and gettext to output translated text at runtime. This has nothing to do with running gettext itself. Languages may also have their own packaging support for this, e.g. liblocale-gettext-perl (which itself uses the libc support, not gettext-base). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp0CrZvfDsdj.pgp Description: PGP signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek writes: >> > > No, it makes the process based on *consensus*, which is a minimum >> > > requirement. > >> > It also means that the salvager has to do more work. > >> I expect the cc to debian-qa to draw sufficient DD's attention. And the >> ACKs are about agreeing on marking a package as orphaned. That's the easy >> part. > >> The salvaging part goes via the existing ITA procedure. That's the hard >> part. > > Exactly. Anyone who can't be bothered to find N other DDs to agree with him > that a package should be orphaned (for some value of N <= 3 - as far as I'm > concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering > themselves a candidate for maintaining the package anyway. I am then unfit to maintain any package, since I would not be willing to do more than CC -qa@ by the time it comes to an ITO, to draw attention. If I get no answer to that, no acks, no nothing (and similar things did happen in the past, perhaps not on -qa, but I have mails on -devel@ and -release@ unanswered, or complained about months later after the fact), I would not want to go out of my way to find consensus. I take no replies (within a reasonable timeframe) as not caring, as silent agreement. By the time -qa@ is mailed, the salvager had to do enough visible work to draw attention to the eventual ITO, so mailing -qa@ should be enough, whether that gets the salvager any acks or not. In case of no acks, it is *NOT* the salvagers fault that noone cares, and therefore it is not the salvager who should be punished with more gruntwork, either. I don't really see the point of requiring consensus if there are *zero* replies to an ITO CC'd to -qa@ for, say, 2-3 weeks. On a similar note, the original proposal did not mention how much time needs to pass before the salvager can proceed, after getting a majority. THAT too, needs a timeout, and if it does, why would it hurt to bake in a worst-case scenario with no acks or nacks? (I can accept defaulting to no too, after a timeout, as long as there's one. I would find the result pointless and silly, but at least it puts an end to it, which the current proposal doesn't.) -- |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/87haphy8ql@luthien.mhp
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On 10/26/2012 01:09 PM, Bart Martens wrote: I expect the cc to debian-qa to draw sufficient DD's attention. And the ACKs are about agreeing on marking a package as orphaned. That's the easy part. The salvaging part goes via the existing ITA procedure. That's the hard part. Regards, Bart Martens Could anyone explain what broken thing we are trying to fix? - Is the current process of orphaning broken? (if so: why?) - Is there too many hijacks? - Not enough salvage? And more importantly: - What do you expect the new procedure will do? What's the goal? I have re-read Lucas Nussbaum original post, and I didn't find any information about the above. 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/508a45d3.8070...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Bart Martens writes:
>> > 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.
>>
>> On the other hand, ACKing an ITO is much more responsibility, becasue
>> it's not only about a package, but about taking over a package too.
>
> No, it is not. See the "two activities" explained here:
> http://lists.debian.org/debian-devel/2012/10/msg00261.html
It is still more responsibility than sponsoring, whether you orphan or
take over the package, because you're not just introducing a new package
or a new version as with sponsoring, you're not just doing an NMU, but
you're taking away something from someone. This latter part is what - in
my opinion - makes ACKing an ITO a much bigger thing than sponsoring or
NMUs.
>> An
>> ITO will also contain quite a lot of info about previous attempts at
>> updating the package - that's not simple to review either. It is less
>> technical too, which can be off-putting to some.
>
> No, an ITO should just enumerate the reasons why the package should be marked
> as orphaned.
And the reasons why the package should be orphaned overlaps quite a bit
with previous attempts at getting the package fixed/updated/whatever by
other means.
If there were no previous attempts, then the package should not be
considered for 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.
>>
>> Indeed, it is. Partly because as far as I understand it, it only
>> recommends a 3/1 majority, and does not demand it. That's perfectly
>> fine.
>
> I guess it's a recommendation because it would go in developers-reference.
> That doesn't mean that it would be OK to randomly orphan packages ignoring the
> recommended procedure in developers-reference.
I never said ignoring the recommended procedure. CC-ing -qa@ is a must,
I never said otherwise. I merely said that *waiting* for ACK/NACK
replies should have a timeout, and if no response arrives within a
reasonable amount of time, we should default to allowing the salvager to
proceed.
That is all. Without the timeout, we have a hole in the system: how long
do you have to wait for replies? When is majority reached? As soon as
3/0? What if that happens within 10 minutes, and a NACK would come on
the 15th? If waiting for majority does have a timeout, what happens if
there are no replies for one reason or the other?
These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,
and default to yes in case of no replies, on the grounds that mistakes
can be corrected, and we should be civilised enough to not flame the
salvager to crisp if that happens (since it was us who failed to give
him feedback in the first place - punishment shall be on us, not the
salvager).
--
|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/87d305y88b@luthien.mhp
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - goal
On Fri, Oct 26, 2012 at 04:12:03PM +0800, Thomas Goirand wrote: > On 10/26/2012 01:09 PM, Bart Martens wrote: > >I expect the cc to debian-qa to draw sufficient DD's attention. > >And the ACKs are about agreeing on marking a package as orphaned. > >That's the easy part. The salvaging part goes via the existing ITA > >procedure. That's the hard part. > > Could anyone explain what broken thing we are trying to fix? > > - Is the current process of orphaning broken? (if so: why?) > - Is there too many hijacks? > - Not enough salvage? > > And more importantly: > - What do you expect the new procedure will do? What's the goal? People interested in salvaging an unmaintained package are discouraged by the current procedures. The new procedure is meant to add a lightweight procedure to mark unmaintained packages as orphaned, so that anyone interested can adopt them without needless delay. Basically the goal is to increase speed in getting packages salvaged. > I have re-read Lucas Nussbaum original post, and I didn't find > any information about the above. Some aspects were discussed earlier in different threads than this one. 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/20121026090720.ga23...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - need for ACKs, default no orphaning
On Fri, Oct 26, 2012 at 09:59:16AM +0200, Gergely Nagy wrote:
> Bart Martens writes:
>
> >> > 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.
> >>
> >> On the other hand, ACKing an ITO is much more responsibility, becasue
> >> it's not only about a package, but about taking over a package too.
> >
> > No, it is not. See the "two activities" explained here:
> > http://lists.debian.org/debian-devel/2012/10/msg00261.html
>
> It is still more responsibility than sponsoring, whether you orphan or
> take over the package, because you're not just introducing a new package
> or a new version as with sponsoring, you're not just doing an NMU, but
> you're taking away something from someone. This latter part is what - in
> my opinion - makes ACKing an ITO a much bigger thing than sponsoring or
> NMUs.
When a package has clearly not been maintained for years, then marking it as
orphaned doesn't take "away something from someone".
I agree that there is some responsibility involved. But the work is easy. In
obvious cases sufficient ACKs will be collected in no time. When there is
doubt, a NACK is appropriate. I trust DDs to be responsible with this.
>
> >> An
> >> ITO will also contain quite a lot of info about previous attempts at
> >> updating the package - that's not simple to review either. It is less
> >> technical too, which can be off-putting to some.
> >
> > No, an ITO should just enumerate the reasons why the package should be
> > marked
> > as orphaned.
>
> And the reasons why the package should be orphaned overlaps quite a bit
> with previous attempts at getting the package fixed/updated/whatever by
> other means.
>
> If there were no previous attempts, then the package should not be
> considered for ITO.
Marking a clearly unmaintained package as orphaned is useful regardless of
previous attempts to update it.
>
> >> >> 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.
> >>
> >> Indeed, it is. Partly because as far as I understand it, it only
> >> recommends a 3/1 majority, and does not demand it. That's perfectly
> >> fine.
> >
> > I guess it's a recommendation because it would go in developers-reference.
> > That doesn't mean that it would be OK to randomly orphan packages ignoring
> > the
> > recommended procedure in developers-reference.
>
> I never said ignoring the recommended procedure. CC-ing -qa@ is a must,
> I never said otherwise. I merely said that *waiting* for ACK/NACK
> replies should have a timeout, and if no response arrives within a
> reasonable amount of time, we should default to allowing the salvager to
> proceed.
>
> That is all.
I'm with Steve L. on this. Without sufficient ACKs, no orphaning.
> Without the timeout, we have a hole in the system: how long
> do you have to wait for replies? When is majority reached? As soon as
> 3/0? What if that happens within 10 minutes, and a NACK would come on
> the 15th? If waiting for majority does have a timeout, what happens if
> there are no replies for one reason or the other?
Collecting ACKs is useful to avoid needless delay to wait for possible
objections. It is, in my opinion, OK to conclude the ITO with three ACKs,
without further delay. If nobody sends ACKs nor NACKs then something went
probably wrong with the cc to debian-qa.
> These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,
I prefer no delay in the text, but I have no strong opinion on this.
> and default to yes in case of no replies,
Without sufficient ACKs, no orphaning. My opinion on that is quite strong.
> on the grounds that mistakes
> can be corrected, and we should be civilised enough to not flame the
> salvager to crisp if that happens (since it was us who failed to give
> him feedback in the first place - punishment shall be on us, not the
> salvager).
Of course, the maintainer can re-adopt his/her package during the time it is
orphaned. But if someone else already has retitled the O to ITA, then in
general that person should be allowed to continue. Of course, all involved
parties can still talk and agree on something else.
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/20121026093548.gb23...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - no ACKs nor NACKs, timeout, defaulting to no
On Fri, Oct 26, 2012 at 09:48:18AM +0200, Gergely Nagy wrote: > why would it hurt > to bake in a worst-case scenario with no acks or nacks? (I can accept > defaulting to no too, after a timeout, as long as there's one. I would > find the result pointless and silly, but at least it puts an end to it, > which the current proposal doesn't.) I would not object against including this in the text. 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/20121026094407.gc23...@master.debian.org
Re: Candidates for removal from testing (results)
On 2012-10-18 10:32, Niels Thykier wrote: > > Hi, > > [...] > > If the relevant RC bugs in the affected packages are not dealt with > /before/ Friday the 26th of Oct., the packages will be removed from > testing. Note that "dealt with" may also include downgrading a > severity-inflated bug or fixing affected versions in the BTS. > Britney has just finished removing the following 21 packages: ax25-apps, fabric, firmware-crystalhd, icewm-themes, ilisp, inguma, lustre, mingw-ocaml, noflushd, openvas-plugins-dfsg, php-crypt-gpg, phpgacl, python-django-piston, smbind, sorl-thumbnail, spatialite-gui, sugar-chat-activity-0.86, sugar-log-activity-0.86, sugar-moon-activity, twidge, venkman The removed packages accounted for about 4.4% of all RC bugs left in testing[0]. > [...] > > Should you need a bit more time than given, please do not hesitate to > contact us. It is also easier for us if we can avoid having to > reintroduce a removed package. > > [...] We got about 3 or 4, who took advantage of this offer. I also noticed two bug reports with a promise of a (N)MU in the report, which I left for now[1]. By my count 5 RC bugs got downgraded and about packages 14 got an upload to unstable (most of which have already been unblocked). ~Niels [0] According to [BTS-RC], there were 479 RC bugs concerning testing at 6 am UTC. Assume that each package only had 1 RC each, 21/479 ~~ 4.4% [BTS-RC] http://bugs.debian.org/release-critical/ [1] But I intend check up on them. -- 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/508a67f2.7010...@thykier.net
Re: Bug#691479: ITP: pcalendar -- application to track women menstrual cycles
Dmitry Smirnov writes: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org > >Package name: pcalendar > Version: 3.3.0 > Upstream Author: Mar'yan Rachynskyy > URL: http://linuxorg.sourceforge.net/ > License: GPL-3+ > Description: application to track women menstrual cycles > > Periodic Calendar is a GUI application which assists in women menstrual > cycles tracking and fertility periods prediction. This information can > be used as. supportive either for conception or contraception planning. > . > Periodic Calendar provides support for sympto-thermal method which has > the highest reliability in fertility periods prediction. User can > choose any subset of the. features to be used or even fall to the > generic calendar method (which if used. alone is very unreliable)... > . > Periodic Calendar is not an equal substitute to the fertility planning > consultants or doctors. Before using this application please talk to > your doctor or read a good book on the subject. > . > THIS PROGRAM PREDICTIONS IN NO WAY CAN BE USED AS THE FINAL. > THERE ARE NO PREDICTION METHODS WHICH PROVIDE 100% RELIABILITY. Hi, this software is already packaged, (http://packages.qa.debian.org/p/pcalendar.html) -- Alberto -- 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/87haph5wif@eps142.cdf.udc.es
Re: Bug#691479: ITP: pcalendar -- application to track women menstrual cycles
Hi Alberto, Thanks for your reply. On Fri, 26 Oct 2012 21:59:52 Alberto Luaces wrote: > Hi, this software is already packaged, > (http://packages.qa.debian.org/p/pcalendar.html) Indeed it is, sorry for the noise. It was already revealed to me so I closed the ITP. I've searched for "ovulation" and "menstruation" using "apt-cache search": that returned "cycle" and "mencal" but not "pcalendar" which I would have found if I could spell "menstrual"... Regards, Dmitry. -- 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/201210262217.10128.only...@member.fsf.org
GR: Orphaning another maintainer's packages
Hi, while Lucas did his best to summarize the outcome from the last thread in a fairly constructive and consensual way, it turned out that too many people have too many opinions here on this matter. Having clearly in mind, that seeking consensus by way of a General Resolution for something ending up in Developer's Reference is like breaking a fly on the wheel, I believe this is the only way out of this impasse which yields to any working solution. As it looks to me, I observe: *) we have consensus that we are in need of such a rule set - which ever it may be *) we have three orthogonally different ideas: a) Bart's approach which was reformulated and proposed by Lucas in this thread [1] b) Mine - which was based on timeout arithmetics [2] c) Michael Gilbert's approach to merge the concept of NMUs with orphaning packages [3] Among these, alternative a) seems to attract most responses and opinions, most agreeing in spirit and procedures, but disagreeing about one detail ... *) ... within approach a) the most heat seems to deal with the necessity to seek ACKs/NACKs for an intent to orphan of a package by peers. If we would exclude the paragraph about DD seconding we are also roughly there, what Sune proposed in [4] and - in spirit - seems to be most attractive alternative to the original proposal. Therefore, I consider seeking resolution by means of a GR proposing Lucas alternative [with minor formulation tweaks and after discussion of the actual text] (that is, proposal a).) without the DD seconding part, because I do not like that much, personally. Moreover, if we decided to go this way, I endorse anyone liking the DD seconding to formulate an amendment adding this or another requirement to the resolution statement. What do you think? Does this sound like a fair compromise everyone could live with? [1] https://lists.debian.org/debian-devel/2012/10/msg00469.html [2] https://lists.debian.org/debian-devel/2012/09/msg00654.html [3] https://lists.debian.org/debian-devel/2012/10/msg00524.html [4] https://lists.debian.org/debian-devel/2012/10/msg00473.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 01:46:41PM +0200, Arno Töll wrote: > What do you think? Does this sound like a fair compromise everyone > could live with? Voting is almost never a way to reach consensus. Rather, it acknowledges that consensus has not been reached and side-steps further constructive attempts to reach it. I'm positive we can have consensus on this issue. In fact, I think we're pretty close to it. I'm traveling, so can't elaborate in more detail on this matter. But I urge you to reconsider proposing a GR. It is a heavy weight tool, that should be used as a last resort. I don't think we're nowhere near the need of it in this specific case. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 01:54:19PM +0200, Stefano Zacchiroli wrote: > I don't think we're nowhere near the need of it in this specific case. s/don't// obviously :) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- 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/20121026115516.ga10...@upsilon.cc
Re: GR: Orphaning another maintainer's packages
On 26.10.2012 13:54, Stefano Zacchiroli wrote: > But I urge you to reconsider proposing a GR. It is a heavy > weight tool, that should be used as a last resort. So far I agree. I didn't say I'll propose on - JFTR. I said I'll consider that and asked for opinions - like yours :) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Discarding uploaded binary packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 02:13, Peter Miller a écrit : > It may be possible to address both concerns in a different way. > > 1. Implement PPAs. The code is open source, get it working first, > and enhance it later. > > 2. DDs and DMs upload source-only to their individual PPA(s). The > PPA build farm builds the package on all the architectures Debian > cares about. > > 3. When a DD or DM wants to place a package to testing or > experimental, it is done as a *copy* from a PPA (no upload > required). If the package in the PPA didn't build, no copy > happens. > > This means folks who pay $$$ for uploads don't have to upload the > binary package that is discarded. But it also means the package is > known to build (on all architectures) before being copied into > testing or experimental. The autobuilders will still see many failing builds. Perhaps even more, if you openly advertise them as a way to perform test builds. I don't see what you gain from it. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQinjwAAoJEJOUU0jg3ChAUwUQAJCrR+y1wb8EebuJgW89DHAN PJkIGdB1w3M7opk+oYNybGa+vEM5/4KITDLJ1/ie/l5bauEJQHoJMEog0UoILK2H TLEO1xlbc89hK6NWwEmGnrH68yxytMJNcJszdlxAX+94S1WvDzuu8H9e3P/cVKlU xg7ZOYnI/G4CjFkRJExTdgJaQF9pz/l7MffztIAt/rDrmsowXStwlqyGAbeYlydL JBHMeM/CB0V+gIFjMmK/n34uv9oPxGU4H7hzsJaKW+A0j9anvf3n+SkW8bzvBk6f VvCmAnk8XDzdSCw7llqE0dt1M5ffnIAGUfSHbzdhplMGPYeuPpu/aB3/H4r30fpk 8jir2YWJholoG8ngk+Xr8Y+eTW26YJuutwlN3bKTETuUW9EOSsiYXnXlO0UNOEGu C4Y6xJKFbCOWStLjYj+lT843tY53xqNukTBBhfnWFd+SkajMQsJTElyiW1VvRBot lSaXtQ6pjMiPZp7oBgKHOvYZrCV7jikcqbBOojx8f8dQywpKiWmvJZyQCLY3UgSN rCS39TdSTPHDlW22KNW9F4AoQQdGxUcWC+Rw5PjQ+7G+ilKDC+7mMl1w6DXT49Af YB43+B1eZzoseQhbMQylWq2LmoYJWSgURlzzJtXalTPwyRg8qaO0qrjo2Wevu1jg +N7K43qPk3MMN8h/w0NA =N717 -END PGP SIGNATURE- -- 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/508a7938.7070...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 08:35, vangelis mouhtsis a écrit : > Hi, I'm wondering, before a package will be orphaned is it > possible/ needful the owner to ask for help or to express the > reasons? > > Regards gnugr http://www.debian.org/devel/wnpp/ Look for "RFH" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQinm/AAoJEJOUU0jg3ChA09wQAIsS1aQf81ela8jA73azBwrN DoDxzYGyNQQBtv1X5h3S7lYvLk4mXLs+JnkDfrI4gzdsE/3j8yw8wA6c9YjLMnMo qqPZwZ6Pv1Cvv7CQ02qAJujbqjoftwOn6vCtIPPKLJ7gzJrFIDoAqhRfCjdLPwB3 hpR9wvi3P9kCvCWKZgCZTwOymFIM7Oeie07bVhI55MSC925msG5Bg5Iy77EjppIl LmwW3WWY+x7ut1nkwNjkhs6dHWGOKjPh1louetEmqEng97FXUCFS/WiTUEz3QN7D qxSIA4QkTnSHpbwY8zvt4jBOHT+PCfc8yQ2omjwoFK4YvgUiuFRSHFP1rueHSjSZ LSvM/n+Oaxw9wgpcmeDedTabk1bO9Dy2NcP+rQsICV0OimioxMqTeHT8wXW4mAAt mSbMuu393CxJ2xs2kBTRFCmWxqYJu6vTUEyZstc9W7ZdISBGGnYHMghcixtQejEM 5Zlv/oN6BQKMP9h0fk/Rmfx9HEaobqzvrXktd3vlLZOwdihyD38ZwaHB/YoTya7d Zaq8kcb1PRTDqM3j4hZE9ZmNzyB3JUuEWDiaBT/LOmIydXbPug3UBzvBb5ecJ0LG cYhnxLNPAExPXGwsAx6yid1YVnz44CquW4ou5Wdcs7qw1PRYPqCkXtvDA1kBopH+ jG1s2GLVU9UPgBE+VZiv =x9xl -END PGP SIGNATURE- -- 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/508a79bf.7080...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 08:46, Bart Martens a écrit : > On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: >> Gergely Nagy wrote: AIUI, with the current >> proposal, as long as three DDs think it should be orphaned, the >> maintainer's objection is irrelevant. > > I would send a "NACK because the maintainer objects", and I trust > other DDs subscribed to debian-qa to do the same. The ITO > procedure is not meant to replace the TC handling conflicts. > So why not agree now that the maintainer can veto the process? Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQinr/AAoJEJOUU0jg3ChAJ74P/3i8/IHIS1HN/IRdldsQUEa8 sJvW/hRd2iXrPmwLCkxP0ng0XmiG8GZ8JjYo7esYWbU2omgJhZ/XxlOKeePHQJfA RQ5ifYq1kZFZT+5xpkwqlhtQ+MBbTuMSRYmDsEgyjnwoEQGLrjCld/+Q4SJA5EQo DvGgFOd3gvz0SpJa8Tp9wDfr8bXezEJs8iTBiGCnihs4n+Qfhjc7aHrAEUenOzuh ZWnEmpbByF79jHYuor403Lu9TPwrCklVxZ69qKhSHJlDVTUDoC2H8MxZcLyJwYqJ KmmwQMYFi8mf210WPw/OpJ9mDYR+VbCWA4zFaoq91rFoxsmIVn0Z8upFFQVyr4fZ DnxKBxeOjBC25hb5301v67cZOYC6x+izfHY9oPHuzPCPkinybk1ak0KpsIX5vXTU jCy4xCt3Uu1RnJBl0f215RpyKxcGx8Nh67t0GjjyfP72ZrfM9LluwzZRGXyixCJU ujnZZZ5+VSzqsXGYAQW9UU1ME9ap4yLJ6jXYsX0AEuzF0y6XT7iHLQ2c3nHGWlgv fk7Gl7+23lxOs1VbWgbiHwhyRLp/F0BAD+eUjtnAYWGPFpFrp/FV6JkOosTmL4kM yUfBjTIhGlp9uPcYO9hikyRXkvp0P1lDE1GMe0Ng8gCUfymBFu6r5O3ENkZ2q2Ii B2UFYpy1as6N4BykeEr5 =2BdK -END PGP SIGNATURE- -- 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/508a7aff.3020...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - without objection versus requiring ACKs
Bart Martens wrote: >On Thu, Oct 25, 2012 at 09:06:34AM -0400, Scott Kitterman wrote: >> Why not start with a "without objection" standard and see how it >works? > >The "without objection" approach would require a reasonable delay for >people to >raise objections (some say two months). The ACK/NACK approach allows >to reach >a consensus in a shorter time, so that for obvious cases the salvaging >can >proceed without pointless delay. No. Changing 3:1 ACK/NACK to 3 (or some other number) ACKS and no objections imposes no such constraint. 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/89ce141c-80d9-4e5f-b73b-2089677f2...@email.android.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
Bart Martens wrote: >On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: >> Gergely Nagy wrote: >> >Ian Jackson writes: >> >> Whether a package is in need of greater attention is not a hard >and >> >> fast objective thing. It's to a large part subjective. Perhaps >the >> >> maintainer thinks it's more or less fine, or at least low enough >> >> priority that the problems are tolerable. >> > >> >Then the maintainer has many options, including but not limited to >> >NACK-ing the ITO. One has a lot of possibilities even before it >comes >> >to >> >filing an ITO. >> >> AIUI, with the current proposal, as long as three DDs think it should >be >> orphaned, the maintainer's objection is irrelevant. > >I would send a "NACK because the maintainer objects", and I trust other >DDs >subscribed to debian-qa to do the same. The ITO procedure is not meant >to >replace the TC handling conflicts. But as written, it does. It should be changed. 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/99822e4d-662e-4589-ae72-5a017906b...@email.android.com
Re: Discarding uploaded binary packages
On 26.10.2012 01:13, Peter Miller wrote: It may be possible to address both concerns in a different way. 1. Implement PPAs. The code is open source, get it working first, and enhance it later. 2. DDs and DMs upload source-only to their individual PPA(s). The PPA build farm builds the package on all the architectures Debian cares about. 3. When a DD or DM wants to place a package to testing or experimental, it is done as a *copy* from a PPA (no upload required). If the package in the PPA didn't build, no copy happens. s/testing/unstable/, presumably? "It builds everywhere" is only one criterion involved in testing migration; for all of the others, migration to testing from anywhere other than unstable doesn't really make sense. Regards, Adam -- 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/8713c24579dac159d4024ca710485...@mail.adsl.funky-badger.org
Bugs filed in unexpected places
Hi all, The discussion about ITO made me think: wouldn't it make more sense to also have RFH, RFA, and O filled against the package itself and not wnpp? One has to be quite familiar with Debian to check wnpp for RFH, RFA or O. Maybe having these bugs "in the face" of people interested in the package (i.e. on the package's bug page) can help attract contributions. Additionally for some packages it might make sense to remove them from testing and raise the severity of the O bug to serious to signal that the package should not be included in the next release unless someone is willing to commit to maintain it. An immediate solution would probably be to 'affects ' so the bugs at least shows up on the package's bug page. Maybe the BTS could/should do this automatically? One a somewhat related note, I also notice confusion is created by the removal bugs being filed against ftp.debian.org. When people not familiar with Debian are looking into why a package has been removed they look at the (archived) package's bugs. Not a biggie, but might help users or prospective ITPers (e.g. if the removal reasons still apply). Not sure if 'affects' can help here. I'm guessing the current procedures were created because at the time the BTS did not have the 'affects ' feature. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Russ Allbery writes: > Michael Gilbert writes: >> On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote: > >>> Okay, well, I guess I return to my previous statement, then. I don't >>> think your proposed solution will work for the more common cases. > >> I respect your opinion, so I'm just curious which part do you believe >> won't work in common cases? It's just applying existing NMU rules with >> a little more liberalism to increase activity in under-maintained >> packages, so I personally can't see where it would break down. > > Well, that's what I was trying to get at: I think your method puts too > many barriers in the way of someone who wants to take over an effectively > abandoned package. It also requires *more* skill than adopting the > package would otherwise, since you have to be good enough at Debian > packaging to make minimal chnages within some arbitrary packaging scheme. > In other words, it requires as much or more skill than doing NMUs, whereas > adopting a traditionally orphaned package is much easier. Very much agree. I am much more likely to work on a neglected package if I can use the tools that I'm familiar with from my own packages. The prospect of having to reverse engineer the packaging before I can make any useful changes is very discouraging. I am *not* a DD, so I think I'm qualified to say that if the goal of the proposal is to attract new contributors to help with existing packages, being allowed to change the packaging style is crucial. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/871uglcqzq@inspiron.ap.columbia.edu
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Fri, Oct 26, 2012 at 01:58:55PM +0200, Thibaut Paumard wrote: > Le 26/10/2012 08:46, Bart Martens a écrit : > > On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: > >> Gergely Nagy wrote: AIUI, with the current > >> proposal, as long as three DDs think it should be orphaned, the > >> maintainer's objection is irrelevant. > > > > I would send a "NACK because the maintainer objects", and I trust > > other DDs subscribed to debian-qa to do the same. The ITO > > procedure is not meant to replace the TC handling conflicts. > > > > So why not agree now that the maintainer can veto the process? Because this would raise the question "how long should we wait for the maintainer to object or to remain silent". In obvious cases, for example when the package has clearly not been maintained for years, then three ACKs from DDs should be sufficient to orphan the package, so that the package can be salvaged quickly, without pointless delay. In less obvious cases, for example when the maintainer objects, I trust the DDs to send NACKs to the ITO, so that the package is not orphaned forcibly. 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/20121026134025.ga17...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Friday, October 26, 2012 01:40:26 PM Bart Martens wrote: > On Fri, Oct 26, 2012 at 01:58:55PM +0200, Thibaut Paumard wrote: > > Le 26/10/2012 08:46, Bart Martens a écrit : > > > On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote: > > >> Gergely Nagy wrote: AIUI, with the current > > >> proposal, as long as three DDs think it should be orphaned, the > > >> maintainer's objection is irrelevant. > > > > > > I would send a "NACK because the maintainer objects", and I trust > > > other DDs subscribed to debian-qa to do the same. The ITO > > > procedure is not meant to replace the TC handling conflicts. > > > > So why not agree now that the maintainer can veto the process? > > Because this would raise the question "how long should we wait for the > maintainer to object or to remain silent". In obvious cases, for example > when the package has clearly not been maintained for years, then three ACKs > from DDs should be sufficient to orphan the package, so that the package > can be salvaged quickly, without pointless delay. In less obvious cases, > for example when the maintainer objects, I trust the DDs to send NACKs to > the ITO, so that the package is not orphaned forcibly. It seems like an obvious bug in the proposal that I don't understand the resistance to fixing. Rather than trust is won't be a problem, why not fix the bug and change it to if there are NACKs, it's a dispute for the tech ctte? 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/5609089.6aMmCRQnhL@scott-latitude-e6320
Re: Bugs filed in unexpected places
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 26/10/2012 15:24, Andrei POPESCU a écrit : > Hi all, > > The discussion about ITO made me think: wouldn't it make more sense > to also have RFH, RFA, and O filled against the package itself and > not wnpp? One has to be quite familiar with Debian to check wnpp > for RFH, RFA or O. Maybe having these bugs "in the face" of people > interested in the package (i.e. on the package's bug page) can help > attract contributions. Hi, it is currently showed in the PTS: e.g. http://packages.qa.debian.org/a/alevt.html: "problems The current maintainer is looking for someone who can take over maintenance of this package. If you are interested in this package, please consider taking it over. Alternatively you may want to be co-maintainer in order to help the actual maintainer. Please see bug number #532093 for more information." I don't see a reason to move it away from wnpp: its great to have a central place for that information, but I agree it is useful to have the info forwarded to other places (such as the PTS, and perhaps the package's own bug page). Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQipI7AAoJEJOUU0jg3ChA5O8P/iu9wJ6hZneEmuW9wHBckxpe 3LdgUnWmjQNM/ZDmgtwnGZa1MW8aoHyx6lQIRJl18whiDlLSIWESX2iNdn2jiw/j 7/3DAhTevEeYDVmuItXxWj43GLit/dogSKNP4K4Qwx0/OpGoG4oQ4MxI7DQPJiM9 /JdgeW2yKh8K0D4HbsZ+9pC9Y/3c8yzAZHhNepmYFtQLK3IvQ1WPey9UdMTiO57Z hboowwrN0CAn6aBcRDtqZPDMwuupH6r82+0N12KxGEP1PoGsA1+peQekObVN1OTN jqzq5Ns4aaSeZBHo5PdYfCv0TiLjFFu/6w6cgZm/0AGlHmL/retDBG3nS/52OC4J zM8Y9L8h3g4/2dL8C6cr0aTyZ94AWpFUNDGZl5VB4+E0GY3woIFoGkgrbrGwYycr iTjOTJhrFgzqA+z2rQix1Wt9bFkgwpi5/VzsEytkzBEfEDWN70OzdbGTvBTRqU0/ IraAzshSH660aNlaSbMpv1McyNij6sy7OcVLXJbahXrNvGnnrTWup2AC81LVYhuk MLLt+36mWTgH+e/aolfc/C+amisHrXLweU/ScBctJYgYLoPPN0eWA0G7zxzxoe+b a+8LzY4lctfHiMbUQZhPeMX0K184QFsYL9werx9qoIQxWohqHmi5Vknu8usm+CNF Sr81+OAxieG4CnaQa93S =6H/Q -END PGP SIGNATURE- -- 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/508a923b.5020...@debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - full maintainer without restrictions
On Fri, Oct 26, 2012 at 09:17:13AM -0400, Nikolaus Rath wrote: > Russ Allbery writes: > > Well, that's what I was trying to get at: I think your method puts too > > many barriers in the way of someone who wants to take over an effectively > > abandoned package. It also requires *more* skill than adopting the > > package would otherwise, since you have to be good enough at Debian > > packaging to make minimal chnages within some arbitrary packaging scheme. > > In other words, it requires as much or more skill than doing NMUs, whereas > > adopting a traditionally orphaned package is much easier. > > Very much agree. I am much more likely to work on a neglected package if > I can use the tools that I'm familiar with from my own packages. The > prospect of having to reverse engineer the packaging before I can make > any useful changes is very discouraging. > > I am *not* a DD, so I think I'm qualified to say that if the goal of the > proposal is to attract new contributors to help with existing packages, > being allowed to change the packaging style is crucial. I strongly agree with what Russ Allbery and Nikolaus Rath wrote above. When a package is clearly not maintained, then it should be orphaned, so that a new contributor can become full package maintainer without any restrictions on the allowed changes. 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/20121026135454.gb17...@master.debian.org
Re: non-developer packages depending on gettext?
> Neil Williams writes: > Ivan Shmakov wrote: > Neil Williams writes: […] >> To note is that Source: gnunet has contrib/report.sh, which calls >> gettext(1), but it doesn't seem to be propagated to any of the >> binaries currently depending on gettext. > You've misunderstood the gettext packaging. > $ dpkg -S `which gettext` > gettext-base: /usr/bin/gettext > So packages/scripts which call gettext should not depend on gettext > but on gettext-base instead — that's the point. The point is that I haven't checked for gettext(1) the first time I've examined the gnunet source package. So, even though I was sure that the dependency on gettext was unwarranted, I didn't actually rule out gettext-base. […] >>> Could be worth filing a wishlist bug against lintian because it >>> should be quite easy to spot. >> ? I see no easy way to discern between these three cases (the >> dependency is valid, depend on gettext-base instead, drop the >> dependency altogether.) > 0: Manipulating PO files directly should only happen during package > builds, so either the package is itself a build tool (like po4a) or > the dependency goes into Build-Depends. I understand the logic. What I can't understand is how to implement it as a lintian check. (There isn't really a “this package is a build tool” flag. There're Tags:, but they may be misleading; consider, e. g., gnuplot bearing suite::gnu.) > 1: Depend on gettext-base but not gettext when the package calls > /usr/bin/gettext, dgettext and/or ngettext directly (all from > gettext-base) rather than the other executables in the gettext binary > package which do stuff like manipulating or reporting on PO files. I don't see an easy way to check for calls to gettext(1), etc., either. Certainly, we can grep the source, but how reliably (and specific) would that be for a lintian check? > 2: Drop any dependency when no calls to gettext can be found in the > source and it isn't a build tool. Languages other than shell have > in-built ways of using the .mo file prepared through PO and gettext > to output translated text at runtime. This has nothing to do with > running gettext itself. Languages may also have their own packaging > support for this, e. g. liblocale-gettext-perl (which itself uses the > libc support, not gettext-base). So, at least we could safely warn about a dependency on gettext-base for a package containing no Shell scripts. Still, it doesn't seem to rule out a dependency on gettext. -- FSF associate member #7257 -- 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/86sj91z3vg@gray.siamics.net
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Russ Allbery writes ("Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's
packages"):
> I think orphaned packages are one of our best opportunities to attract new
> developers, rather than serving as an additional obligation for existing
> developers. [etc.]
Thanks for that excellent analysis. You have convinced me that the
salvaging process should countenance orphaning packages, as well as
(or perhaps instead of) allowing a different maintainer to take them
over.
I still think that the right standard is "no objection" rather than
collecting some explicit number of acks. In particular I don't think
any number of acks ought to override a nack from the existing
maintainer.
And if we're allowing any single nack to stop it, then I don't see
what requiring ack(s) buys us. It would force the salvager to make
explicit their criticisms of the package and hence the maintainer.
Ian.
--
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/20618.41869.34617.514...@chiark.greenend.org.uk
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay
Bart Martens writes ("Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's
packages - skipping pointless delay"):
> On Thu, Oct 25, 2012 at 02:50:46PM +0100, Ian Jackson wrote:
> > 3. Wait for objections
>
> For how long ? The proposal includes collecting ACKs so that any pointless
> delay can be skipped, resulting in the package being salvaged sooner.
I was thinking some weeks.
I do think this delay is essential, not pointless. It is there to
allow a maintainer who wishes to resist the orphaning to do so.
Ian.
--
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/20618.42165.454144.292...@chiark.greenend.org.uk
Re: Bugs filed in unexpected places
* Thibaut Paumard [121026 15:54]: > I don't see a reason to move it away from wnpp: its great to have a > central place for that information, but I agree it is useful to have > the info forwarded to other places (such as the PTS, and perhaps the > package's own bug page). Having a central page to show all of them is nice. Having them in one pseudo page is not really the optimal solution for that. (I usually only look for http://www.debian.org/devel/wnpp/work_needing instead because https://bugs.debian.org/wnpp is just too slow.) Putting it to the package's data is a much more logical place, easier to find, harder to miss. Better collect the data to show them in some central place also instead. Bernhard R. Link -- 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/20121026160646.ga29...@client.brlink.eu
Re: Candidates for removal from testing (results)
Great stuff, thanks! -- 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/20121026160652.GC20294@debian
Re: Bugs filed in unexpected places
On Vi, 26 oct 12, 15:38:03, Thibaut Paumard wrote: > > it is currently showed in the PTS: e.g. > http://packages.qa.debian.org/a/alevt.html: > "problems How many non-DDs/DMs do you think are aware of the PTS? My guess is: not that many. IMVHO the BTS is much more visible, especially to users who do take the time to report bugs. Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Bugs filed in unexpected places
On Fri, Oct 26, 2012 at 07:39:52PM +0300, Andrei POPESCU wrote: > On Vi, 26 oct 12, 15:38:03, Thibaut Paumard wrote: > > > > it is currently showed in the PTS: e.g. > > http://packages.qa.debian.org/a/alevt.html: > > "problems > > How many non-DDs/DMs do you think are aware of the PTS? My guess is: not > that many. IMVHO the BTS is much more visible, especially to users who > do take the time to report bugs. How about how many non-DDs/DMs are aware of wnpp, versus the processed result of it (http://www.debian.org/devel/wnpp - which is not the same as b.d.o/wnpp, and could be auto-generated from e.g. a usertag or top-level tag just as easily as from b.d.o/wnpp) -- 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/20121026175244.GA22021@debian
Re: Bugs filed in unexpected places
On Fri, Oct 26, 2012 at 03:38:03PM +0200, Thibaut Paumard wrote: > Le 26/10/2012 15:24, Andrei POPESCU a écrit : > > The discussion about ITO made me think: wouldn't it make more sense > > to also have RFH, RFA, and O filled against the package itself and > > not wnpp? One has to be quite familiar with Debian to check wnpp > > for RFH, RFA or O. Maybe having these bugs "in the face" of people > > interested in the package (i.e. on the package's bug page) can help > > attract contributions. > > it is currently showed in the PTS: e.g. > http://packages.qa.debian.org/a/alevt.html: > "problems > > The current maintainer is looking for someone who can take over > maintenance of this package. If you are interested in this package, > please consider taking it over. Alternatively you may want to be > co-maintainer in order to help the actual maintainer. Please see bug > number #532093 for more information." > > I don't see a reason to move it away from wnpp: its great to have a > central place for that information, but I agree it is useful to have > the info forwarded to other places (such as the PTS, and perhaps the > package's own bug page). Instead of parsing a wnpp bug title, with potential errors, have a more formal data model and tag RFH/RFA/O.. with a dedicated wnpp tag ? This way, you can : - easily get the list of wnpp bugs - easily see a package has a wnpp bugs - get rid of all the parsing needed by PTS, wnpp-alert, UDD, etc. -- Simon Paillard -- 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/20121026180527.ga30...@glenfiddich.mraw.org
Re: Bugs filed in unexpected places
On Fri, 26 Oct 2012, Andrei POPESCU wrote: > An immediate solution would probably be to 'affects ' so > the bugs at least shows up on the package's bug page. Maybe the BTS > could/should do this automatically? Doing affects automatically isn't really something that the BTS itself should do,[1] but it's trivial for anyone to script something to do this. wnpp bugs should be filed against wnpp or debian-mentors and marked as affecting the package they are involved with. Don Armstrong -- 6: I'm human. I have a thousand flaws. I break down. I get up or I don't get up. I get lost. I make the same mistakes over and over. I have scars and wounds. Sometimes when I can't bear them anymore, I drink. You can't fix me. You can't fix any of us. You can't make us perfect. -- "The Prisoner (2009 Miniseries)" _Checkmate_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20121026181216.gl11...@rzlab.ucr.edu
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote: > On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote: >> I think this is where language is important. In my opinion, the term >> "adoption" will continue to mean taking on full responsibility for a >> package as its new maintainer. The term "salvage", in my opinion, we >> can define as a process for becoming a co-maintainer on a package with >> a long-term possibility of becoming its maintainer. > > This is an unhelpful redefinition of the term. The term "salvage" was > introduced to *mean* orphaning/adopting a package when the maintainer is no > longer fulfilling their responsibilities. Why do we need two different terms defined as the exact same thing? In other words, if both salvaging and orphaning mean the same thing, then what's the point of salvaging? In my opinion salvaging (under the above definition) is something that would be able to happen a lot sooner than orphaning because it is initial a co-mainainter process, rather than a maintainer replacement process. Best wishes, Mike -- 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/CANTw=MNYTDBqy6do+=flacn+srnvzfhosbbj3inou4qdad5...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - goal
On 10/26/2012 05:07 PM, Bart Martens wrote: People interested in salvaging an unmaintained package are discouraged by the current procedures. The new procedure is meant to add a lightweight procedure to mark unmaintained packages as orphaned, so that anyone interested can adopt them without needless delay. Basically the goal is to increase speed in getting packages salvaged. Thanks, this is much more clear now. After more thoughts, I probably agree such a proposal. Probably, Steve Langasek is right in that it shouldn't be such a big deal to find few DDs to vote for the salvaging... And if I understand well, this procedure is *on top* of what we have currently for orphaning anyway (eg: QA team orphaning MIA maintainers, and the tech. commity), right? 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/508ae1de.4080...@debian.org
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 7:46 AM, Arno Töll wrote: > *) we have consensus that we are in need of such a rule set - which ever > it may be > > *) we have three orthogonally different ideas: >a) Bart's approach which was reformulated and proposed by Lucas in > this thread [1] >b) Mine - which was based on timeout arithmetics [2] >c) Michael Gilbert's approach to merge the concept of NMUs with > orphaning packages [3] My proposal has nothing to say about orphaning itself, and explicitly leaves it untouched. Mine can be considered a more flexible co-maintainer process that importantly can be started far before orphaning becomes a package's last resort. It also seeks to handle the "hard" cases whereas a) and b) explicitly state that they're avoiding that problem altogether. Anyway, I and seemingly many others don't like the bureaucracy of a) and b), especially since there is already a common-law 4*7*24*3600 rule in existence that would probably get applied more often if it were actual devref-law. Finally, if a) and b) aren't meant to do something about the original issue, the "hard" maintainership questions, then what's the point? Why do we need more bureaucracy when we already have a common-law solution? Best wishes, Mike -- 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/CANTw=MNx1O0d0uQ9pLNgA=4z7ljslbssoqgcsolxjsg_4sr...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react
On Fri, 26 Oct 2012 16:56:02 Bart Martens wrote: > On Fri, Oct 26, 2012 at 08:06:57AM +1100, Dmitry Smirnov wrote: > > If bug was unanswered for let's say two months the package is free to > > orphan > > Some prefer no delay, some prefer one month, some prefer two months. I > originally wanted one month, but I got convinced by others to drop the > delay. For merely orphaning minimising delay is not too important because if there is an active maintainer ready to adopt the package it is a "salvaging" procedure. For example if package is not maintained for years we can certainly wait for a month or two before orphaning even though there may be no need to wait that long. > Now my opinion is that I trust the DDs reviewing the ITO to judge > the package's situation before sending an ACK or NACK. One possible > judgement on an ITO can be "NACK until 2 months have passed or the > maintainer has agreed to orphan the package". Another possible judgement > on an ITO can be "ACK because this package has clearly not been maintained > for years, so please proceed without further delay". I'm convinced that acknowledging is ambiguous and unnecessary. First, what do you expect DDs to acknowledge -- the fact that package needs attention (this should be obvious already) or their approval of salvager? Assuming they're not familiar with salvager's work getting and acknowledgement might be as hard as finding a sponsor. Also this will rely on developers constantly reviewing ITA requests in other people's packages. Most certainly this will increase delay and the complexity of the procedure which might work only for popular packages with high visibility. I think in usual case we can expect no response for salvaging requests. Also without timed delay acknowledgements may be very unfair if few DDs voted for salvaging and therefore salvager got a green light without waiting for possible objections. Michael Gilbert's proposal to start salvaging with NMUs makes more sense as it allows to proceed gently and demonstrate motivation and willingness to work on the package. From non-DD prospective couple of successful NMUs will confirm salvaging intent and capacity better than random ACKs. Regards, Dmitry. -- 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/201210270747.48293.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection
On Sat, 27 Oct 2012 00:40:26 Bart Martens wrote: > > So why not agree now that the maintainer can veto the process? > > Because this would raise the question "how long should we wait for the > maintainer to object or to remain silent". In obvious cases, for example > when the package has clearly not been maintained for years, then three > ACKs from DDs should be sufficient to orphan the package, so that the > package can be salvaged quickly, without pointless delay. In less obvious > cases, for example when the maintainer objects, I trust the DDs to send > NACKs to the ITO, so that the package is not orphaned forcibly. I recognise fundamental injustice here. If you expect ACKs then objections should be allowed as well but there might be unlikely situation when salvaging proceed after few ACKs without waiting for any further objections. I fear of conflicts it may create. Any form of agreement require fair amount of time for all parties to respond. If the matter cannot wait one can use NMU during transition of package ownership. This is in harmony with what Michael Gilbert proposed. In clear case when waiting is impossible without hurting the package state, DDs can take over without delays and take responsibility for future issues with maintainer. In any case we want salvaging to be documented in corresponding bug report. Regards, Dmitry. -- 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/201210270800.17329.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Sat, 27 Oct 2012 01:51:57 Ian Jackson wrote: > I still think that the right standard is "no objection" rather than > collecting some explicit number of acks. In particular I don't think > any number of acks ought to override a nack from the existing > maintainer. > Indeed. I think lack of enough acknowledgements can make process even slower. Acknowledgements will require developers to judge on other developer's intentions and I'm not sure wherever ACKs meant to approve the fact that salvaging is needed or to approve salvager and express trust to her/his capacities as maintainer. Probably not many people will find this role attractive so we can expect a lack of acknowledgements. > And if we're allowing any single nack to stop it, then I don't see > what requiring ack(s) buys us. It would force the salvager to make > explicit their criticisms of the package and hence the maintainer. I'm sure salvaging intent can be neutral or positive. It is merely a declaration of intent to help maintaining a package. When original maintainer is responding it is effectively a co-maintainership offer. Only when maintainer is not responding it becomes de-facto a declaration of adoption intent (ITA) so perhaps word "savlaging" is not perfect to express the idea. There is nothing to suggest that salvager has to express any criticism. As far as I can remember some adoption experiences of mine I was sincerely grateful to previous maintainers for their work. Regards, Dmitry. -- 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/201210270839.54287.only...@member.fsf.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote: > On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote: > > On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote: > >> I think this is where language is important. In my opinion, the term > >> "adoption" will continue to mean taking on full responsibility for a > >> package as its new maintainer. The term "salvage", in my opinion, we > >> can define as a process for becoming a co-maintainer on a package with > >> a long-term possibility of becoming its maintainer. > > This is an unhelpful redefinition of the term. The term "salvage" was > > introduced to *mean* orphaning/adopting a package when the maintainer is no > > longer fulfilling their responsibilities. > Why do we need two different terms defined as the exact same thing? > In other words, if both salvaging and orphaning mean the same thing, > then what's the point of salvaging? They don't mean the same thing. Maintainers orphan their own packages; adopters adopt orphaned (or RFAed) packages. Salvaging is the process of identifying packages that *should* be orphaned in the *absence* of the maintainer. > In my opinion salvaging (under the above definition) is something that > would be able to happen a lot sooner than orphaning because it is > initial a co-mainainter process, rather than a maintainer replacement > process. Comaintenance is irrelevant to the question at hand. -- 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 Fri, Oct 26, 2012 at 6:06 PM, Steve Langasek wrote: > On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote: >> On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote: >> > On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote: >> >> I think this is where language is important. In my opinion, the term >> >> "adoption" will continue to mean taking on full responsibility for a >> >> package as its new maintainer. The term "salvage", in my opinion, we >> >> can define as a process for becoming a co-maintainer on a package with >> >> a long-term possibility of becoming its maintainer. > >> > This is an unhelpful redefinition of the term. The term "salvage" was >> > introduced to *mean* orphaning/adopting a package when the maintainer is no >> > longer fulfilling their responsibilities. > >> Why do we need two different terms defined as the exact same thing? >> In other words, if both salvaging and orphaning mean the same thing, >> then what's the point of salvaging? > > They don't mean the same thing. Maintainers orphan their own packages; > adopters adopt orphaned (or RFAed) packages. Salvaging is the process of > identifying packages that *should* be orphaned in the *absence* of the > maintainer. We already orphan packages without the maintainer's consent, and it's already called "orphaning". Salvaging is still undefined; until we come to consensus on its definition. Some vague notion of the idea was started at debconf, and we should be willing to be open to discussing the best definition that achieves the most optimum result. If we limit the scope of our thinking, then we box ourselves into a much smaller and likely less optimum set of solutions. So let's keep the term's definition open for debate. >> In my opinion salvaging (under the above definition) is something that >> would be able to happen a lot sooner than orphaning because it is >> initial a co-mainainter process, rather than a maintainer replacement >> process. > > Comaintenance is irrelevant to the question at hand. Again, co-maintenance is a proposed solution to the question at hand, so it is quite apropos to the discussion. There is now vast evidence within the archive that co-maintained packages tend to be much healthier than strongly maintained ones. This adds an additional avenue for becoming a co-maintainer while injecting health into often neglected parts of the archive. Wrapping up, I'd like to state my concern about how we continue to allow a certain culture of strong voices to effectively limit the scope of discussions. This isn't how a meritocracy should work. I've developed a solution, shown that it works, and now I would like to document it to make it available to help others as a guide in similar situations. Criticism from those that haven't demonstrated their own solutions should fail in a real meritocracy. Best wishes, Mike -- 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/CANTw=MN+uaGrAsSvPjs5bMt_ty4FBr=fsh+6++03jo-wnrr...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote: > We already orphan packages without the maintainer's consent, and it's > already called "orphaning". > Salvaging is still undefined No, it is not. The definition was clear from the first use of the term. Stop trying to redefine it. > So let's keep the term's definition open for debate. Or, find something useful to do with yourself 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
suggestion
When will there be in debian installer for Debian and wubi as Ubuntu? Attentively Ricardo Obando, from Chile.
Re: suggestion
Take a look: http://goodbye-microsoft.com/ Cheers! On Fri, Oct 26, 2012 at 7:29 PM, Ricardo Obando wrote: > When will there be in debian installer for Debian and wubi as Ubuntu? > > Attentively Ricardo Obando, from Chile. > -- William Vera | bi...@billy.mx Systems Engineer / Consultant IT / Sysadmin PGP Key: 1024D/F5CC22A4 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 8:19 PM, Steve Langasek wrote: > On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote: > >> We already orphan packages without the maintainer's consent, and it's >> already called "orphaning". > >> Salvaging is still undefined > > No, it is not. The definition was clear from the first use of the term. > Stop trying to redefine it. > >> So let's keep the term's definition open for debate. > > Or, find something useful to do with yourself instead. This is an unkind insult. I am defending my dissertation on Monday, so I have more than enough to do right now. That's something quite important to me, and I am taking time away from that to make a passionate case for something else that I believe in. I've also spent a reasonable amount of time on Debian over the past few weeks, but I prefer humility, so I won't drone on about that. Anyway, deployment of an abusive ad hominem is generally seen as a concession of the argument to the opposing side of the discussion, so I think that puts a rather sour note and an end to this particularly unproductive sub-thread. Best wishes, Mike -- 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/CANTw=MM+SgEwoJ2frbt7N=6vpffkxrto84o8st822oxx3p-...@mail.gmail.com
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Hi Zack, On Tue, Oct 23, 2012 at 11:19:34PM +0200, Stefano Zacchiroli wrote: > On Tue, Oct 23, 2012 at 05:19:37PM +, Sune Vuorela wrote: > > 1) report a bug 'should this package be orphaned?' against the package > > with a more or less defalut templated text and a serious severity > > 2) sleep 4*7*24*3600 > > 3) if bug silent, orphan it (and maybe adopt it) > According to the interpretation I suggested in [1], this is actually the > degenerate case of the proposal that is being discusses. If no-one ACKs > --- which IMHO is what would happen by default anyhow in quite a number > of cases --- and if the interested person chooses to sleep 4*7*24*3600, > your point (3) will be the natural conclusion. > [1]: https://lists.debian.org/debian-devel/2012/10/msg00471.html > Otherwise stated, the proposal is *exactly* what you're proposing, plus > some consensus-based best practice to deal with the missing "else" > branch of your point (3). > I'm convinced that "else" branch will be quite uncommon (unless > mandated, see below), and that ACKs/NACKs are just a different way of > putting what already happens when we discuss on a mailing list the > salvation of a package. > But you could either have the unsupervised "if" branch, or what Steve > suggests in https://lists.debian.org/debian-devel/2012/10/msg00475.html > i.e. maintainers explicitly looking for ACKs to support their action as > a requirement to complete the procedure. It has its merits (e.g. a > surefire extra review layer). But if you consider ACKs as "votes", as > Scott put it, and you see that as bad, you won't accept this. > So, can people comment on Steve's proposal? > Similarly, Steve: can you comment on the criticism of "voting" on > packages, why don't you see it as a problem? "Voting" implies that the majority rules. I am certainly not in favor of any sort of voting mechanism where we tally those in favor and those against orphaning the package. The standard I expect to see applied here is *consensus*, not voting. A lone voice in the wilderness, with no one saying either yay or nay, is not a consensus. 20 DDs saying the package should be orphaned, and the maintainer saying it shouldn't (or some other DD saying it shouldn't), is not a consensus. We should not need a heavyweight process here at all. It seems that some of the participants in this discussion are unaware that some of us are subscribed to debian-qa specifically *for* dealing with questions of unmaintained packages (MIA, salvaging, or coordination of QA uploads). The only real requirements for such a process are: - Make an appropriate effort to notify the maintainer of your concern - Make the rest of Debian aware of your plans in the designated public forum - Get some (small) number of your peers to agree via public review that this is the correct course of action for the package in question - Wait a reasonable amount of time for objections - If consensus is not reached, refer to the TC And if my frustration is showing through in this thread, it's because *I am not proposing a new process*. This was the process that was used for *years* via debian-qa. But, evidently because this process was never adequately codified in the developer's reference, here we are now having a long, drawn-out discussion not only about reinventing the wheel but also about what we should define a wheel to be, and entertaining solutions in search of a problem from people who have never used that existing and proven process. It is not going to be hard to get the necessary handful of acks when following an appropriate process, nor is it hard to wait a fixed period to give time for any nacks to arrive before taking action on a package to be salvaged. A package salvage is NOT an urgent matter, ever. Urgent matters should be dealt with by NMU. Salvaging is for longer-term questions of maintainership, and where maintainership is concerned we should be duly respectful of the existing maintainer's committment to Debian instead of enacting a buggy process that allows for a maintainer to come back from a vacation/hospital stay/computer outage to find her package has been rewritten without so much as a thank you. If you really intend to commit to maintaining the package for the foreseeable future, you can bloody well sit on your hands for a month and wait for the maintainer to react first. So in sum, I'm broadly in favor of Lucas's patch, except: - A single nack is evidence of a lack of consensus. If consensus can't be achieved, it should be referred to the TC instead of making a political mess of things for the rest of the project. - There does need to be a mandatory minimum waiting period. This process is going to be seen as "blessed" via the devref; we should not be blessing a process with an obvious bug that permits abuse by a DD and three of her friends pulling off a hostile takeover of a package before anybody has a chance to say no. Even though such an a
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Thu, Oct 25, 2012 at 09:58:54PM +0100, Ben Hutchings wrote: > On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote: > [...] > > All the pings in the world won't help if you are sending them via > > a path that discards them. I know several large US ISPs that automatically > > reject what they consider SPAM without the customer's knowledge. If > > the sender of the ping is on a SPAM list for one of them, the ping > > will never get to the maintainer, and *no one* will know. > > (From personal experience I can tell you mail from the Debian list addresses > > does get "caught" in these SPAM "filters" and no, the ISPs won't change the > > policy.) > Given that Debian lists are 'open' and haven't always had good spam > filtering, it is not too surprising that they are sometimes treated > as spam sources. > In general, anything that needs to reach the maintainer(s) of a > specific package should not be sent to the maintainer address, not to > some general mailing list. (The maintainer address may itself be a > mailing list, but if the maintainer(s) no longer read mail sent to it > then that's a further reason to orphan/salvage the package!) I strongly recommend that such mails always be sent via the BTS. This ensures that the mail follows the same path as bug mail, and avoids getting tripped up on filtering bugs that don't actually impact the maintainers ability to carry out their responsibilities as maintainer. I.e.: maintainers don't have a responsibility to reply to private mails. They do have a responsibility to act on bug reports. So if you send it via the BTS, and the maintainer claims afterwards that they didn't receive the mail, it's clear where the responsibility lies. -- 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 Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote: > On 10/25/2012 02:48 AM, Steve Langasek wrote: > >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. > What? Could you explain what I did? Silence from who? The old maintainer? > Other DDs reading the list? "So, if nobody objects within the next following 2 or 3 days, and if Jack doesn't show up and oppose to this procedure, we'll do that." https://lists.debian.org/debian-devel/2012/05/msg01362.html That's equating silence with assent. Perhaps that wasn't what you intended, but that is what you said, and that was a factor in the resulting blow-up. -- 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 Fri, Oct 26, 2012 at 06:24:24PM -0700, Steve Langasek wrote: > So in sum, I'm broadly in favor of Lucas's patch, except: > > - A single nack is evidence of a lack of consensus. If consensus can't be >achieved, it should be referred to the TC instead of making a political >mess of things for the rest of the project. I fully agree with that. > - There does need to be a mandatory minimum waiting period. This process >is going to be seen as "blessed" via the devref; we should not be >blessing a process with an obvious bug that permits abuse by a DD and >three of her friends pulling off a hostile takeover of a package before >anybody has a chance to say no. Even though such an act *can* be >appealed to the TC, we shouldn't put ourselves in the situation that it >has to be. I won't object to adding a mandatory minimum waiting period, although in some obvious cases it will lead to a pointless delay. 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/20121027041826.ga5...@master.debian.org
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
Steve Langasek wrote: > On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote: > > On 10/25/2012 02:48 AM, Steve Langasek wrote: > > >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. This claim seems to be false. > > What? Could you explain what I did? Silence from who? The old maintainer? > > Other DDs reading the list? > > "So, if nobody objects within the next following 2 or 3 days, and if Jack > doesn't show up and oppose to this procedure, we'll do that." > > https://lists.debian.org/debian-devel/2012/05/msg01362.html > > That's equating silence with assent. > > Perhaps that wasn't what you intended, but that is what you said, and that > was a factor in the resulting blow-up. The mail also talked about "we" and "us (eg: the PKG-PHP Pear team)". That implies he already had the support of someone else, and they could have sent ACKs if needed (but there was no need to, as he wanted to know whether anyone opposed; the number of "me too"s didn't matter). None of the mails starting the discussion questioned whether the number of people in favor was sufficient. -- 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/1351312739.10719.19.camel@glyph.nonexistent.invalid
Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages
On Sat, Oct 27, 2012 at 04:18:26AM +, Bart Martens wrote: > On Fri, Oct 26, 2012 at 06:24:24PM -0700, Steve Langasek wrote: > > - There does need to be a mandatory minimum waiting period. This process > >is going to be seen as "blessed" via the devref; we should not be > >blessing a process with an obvious bug that permits abuse by a DD and > >three of her friends pulling off a hostile takeover of a package before > >anybody has a chance to say no. Even though such an act *can* be > >appealed to the TC, we shouldn't put ourselves in the situation that it > >has to be. > I won't object to adding a mandatory minimum waiting period, although in > some obvious cases it will lead to a pointless delay. What cases do you consider obvious? For me, the only obvious cases are the ones where the MIA team has declared the maintainer no longer active and orphaned all of their packages, in which case this entire process is redundant. In all other cases, I think the maintainer should have a reasonable opportunity to respond. -- 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 Friday, October 26, 2012 11:09:18 PM Steve Langasek wrote: > On Sat, Oct 27, 2012 at 04:18:26AM +, Bart Martens wrote: > > On Fri, Oct 26, 2012 at 06:24:24PM -0700, Steve Langasek wrote: > > > - There does need to be a mandatory minimum waiting period. This > > > process > > > > > >is going to be seen as "blessed" via the devref; we should not be > > >blessing a process with an obvious bug that permits abuse by a DD and > > >three of her friends pulling off a hostile takeover of a package > > >before > > >anybody has a chance to say no. Even though such an act *can* be > > >appealed to the TC, we shouldn't put ourselves in the situation that > > >it > > >has to be. > > > > I won't object to adding a mandatory minimum waiting period, although in > > some obvious cases it will lead to a pointless delay. > > What cases do you consider obvious? For me, the only obvious cases are the > ones where the MIA team has declared the maintainer no longer active and > orphaned all of their packages, in which case this entire process is > redundant. In all other cases, I think the maintainer should have a > reasonable opportunity to respond. If the maintainer never responds, then (it turns out) there was no need for the delay. So there are cases where delay is pointless, the problem is that you can't tell in advance if you're in one of those cases or not. Scott K signature.asc Description: This is a digitally signed message part.
