Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-30 at 02:49am, Thomas Goirand wrote: > Jack Bates is supposed to maintain php-codesniffer, [snip] > this package last upload was from 2008-10-05, [snip] > we'd like to see the latest version in Wheezy [snip] > We sent a mail 5 days ago to Jack Bates, and he didn't reply. It's > currently obvious that there's very few chances that Jack Bates will > upload a new version of php-codesniffer before Wheezy freezes. > > So, we'd like to have php-codesniffer orphaned, then taken over by us > (eg: the PKG-PHP Pear team). Jack Bates would anyway be very welcome > to join the team, and continue to do his packaging (we can add him to > the Uploaders: list if he wishes), even after this procedure. > > 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. I strongly object to this as a general principle: Debian freezing is no excuse for hijacking! Seems you had several years of solving this issue, yet you waited until just before freeze, and the option you came up with was to kick a maintainer. Did you consider an NMU? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-30 at 11:30am, Thomas Goirand wrote: > We aren't kicking him, we want to have the package team maintained. > He's fine to come and join! You want to play by your rules (file), not his. That's kicking to me. > This doesn't really qualify for an NMU, nor does the upgrade to the > latest upstream version. *nothing* qualifies for a hijacking. With hijacking I mean disrespectful takeover. Either respect maintainership by only NMUing, or respectfully resolve with the Debian community that the current maintainer is unfit for the task. You do the latter but instead of the normal use of MIA tracking you use Debian freeze as argument for swift takeover. I find it not respectful to rush processing like that! I am not at all surprised that this is yet another sponsored package bit-rotting. Personally I never liked how we allow maintainer to be someone not in Debian: There is too great a risk of drive-by contributions :-( ...but we should not improve quality of packages by relaxing the respect of the maintainer. We should hold maintainers responsible to their actions - and that is only really possible to do with "social pride" which is lacking when maintainer is outside of Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-30 at 09:41pm, Thomas Goirand wrote: > On 05/30/2012 05:11 PM, Jonas Smedegaard wrote: > > you use Debian freeze as argument for swift takeover. I find it not > > respectful to rush processing like that! > > > > Again, no! That wasn't my point. My point was that it was left > unmaintained since the upload of 2008, which is 4 years ago. A package can go untouched for several years and still be in good shape. A package be messed with frequently and still be badly maintained. For judging quality of maintainance it is better to look at handling and severity of bugs. > So I will only do an NMU on the delayed queue, and leave one month > pass. Then if there's no reply, I'll ask for the package to be > orphaned. If you fix grave bugs by doing an NMU, then you are responsible for maintaining your changes to the package - which means that if you do an NMU now just before freeze, it is highly likely that you will end up nursing those changes for several years to come. ...but those changes only! An NMU is an indication of you helping out the maintainer, not (in itself) an indication that the maintainer is failing to maintain. Just sitting idle regarding this issue for a month doesn't sound sensible to me: Please consider checking our standard procedures for MIA handling. And please consider filing bugs for issues with the current packaging. NB! The fact that code has not been updated to newest upstream release is in itself only of severity wishlist, but if newer upstream releases fix actual bugs it helps filing separate bugs about those. Makes sense to revisit this discussion if, severe bugs have been reported, learning they are left unresolved. > By the way, do other think that, even in this case, I should keep the > changes as minimum as possible? Or is it ok, considering that all of > our toolsets have changed since the last upload (eg: we now have > pkg-php-tools and dh 8 sequencer), that we do a bit more changes in > the package than just the new upstream release? (I am not others, but...) An essential point when NMU'ing is that you are *guest* maintainer. Respect your host when visiting as a guest: Work in same style in expectation of your host having sane reasoning for the chosen style of maintainance. Also, new tools do not necessarily mean better tools. My couch is from IKEA. I highly appreciate visitors to my home, but don't change the furniture - that's rude. I use CDBS for my packaging. I highly appreciate help with my packaging, both ongoing as teamwork and drive-by as NMUs, but don't change packaging style - that's rude. So yes, I think you should always keep changes minimal when doing NMUs. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 09:22am, Bernd Zeimetz wrote: > On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > It is better to have a well maintained package than to ait for > somebody who collected a number of NMUs and doesn't react to bug > reports for years. I perfectly agree. But it is better to have responsibly maintained packages having newest upstream code packaged at any cost. ...and I find both of our comparisons above too simplistic! On 12-05-31 at 09:22am, Bernd Zeimetz wrote: > On 05/30/2012 11:11 AM, Jonas Smedegaard wrote: > > I am not at all surprised that this is yet another sponsored package > > bit-rotting. Personally I never liked how we allow maintainer to be > > someone not in Debian: There is too great a risk of drive-by > > contributions :-( > > You and a lot of others fail to realize that the *SPONSOR* is > responsible for the package. Huh?!? What does "Maintainer:" mean if not the entity being responsible for, well, maintaining?!? > If the maintainer fails to keep the package in a useful shape it is > the sponsor's responsibility to do so. And last but not least it > should be the sponsor's decision to orphan a package if the maintainer > is MIA or not doing his job properly. It is also the sponsors > responsibility to try to figure out if a maintainer is willing to do > his job longer than one upload before sponsoring a package at all. I have heard before the argument of the sponsor having responsibility, but in reality I have *never* heard of sponsors actually being held responsible for anything but the concrete upload of a specific packaging release. ...which leads to my concern for high risk of drive-by contributions! > > ...but we should not improve quality of packages by relaxing the > > respect of the maintainer. We should hold maintainers responsible to > > their actions - and that is only really possible to do with "social > > pride" which is lacking when maintainer is outside of Debian. > > Yet another job for the sponsor. How can sponsor help create social pride (or social pressure if doing a lousy job)? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
[dropping PHP Pear team as cc] On 12-05-31 at 03:16pm, George Danchev wrote: > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > You and a lot of others fail to realize that the *SPONSOR* is > > > responsible for the package. > > > > Huh?!? > > > > What does "Maintainer:" mean if not the entity being responsible > > for, well, maintaining?!? > > Who is responsible for the package maintenance in the case where a > non-DD is listed in "Maintainer:", and the package is obviosuly signed > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > reasonable to expect that DD, being in the role of sponsor, is > responsible for the package quality and further maintenance. Sponsors > are full-fledged DDs, and trying to claim that they are not > responsible, or are somehow less responsible than any other > non-sponsoring DDs, for the uploads they have done, is obviously plain > wrong. You avoided my question, it seems: What does "Maintainer:" mean, then? Seems to me that for sponsored packages the Maintainer field is a joke! Seems to me that for sponsored packages we need access to ftp logfiles to resolve who is responsible for maintaining the package. I find both of those plain wrong. Possibly obviously and maybe even hilariously simple, but wrong nonetheless. - Jonas Who appreciate non-DM contributions, just not common hinting of them -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team
On 12-05-31 at 04:43pm, George Danchev wrote: > On Thursday 31 May 2012 16:15:31 Jonas Smedegaard wrote: > > [dropping PHP Pear team as cc] > > > > On 12-05-31 at 03:16pm, George Danchev wrote: > > > On Thursday 31 May 2012 11:47:21 Jonas Smedegaard wrote: > > > > > You and a lot of others fail to realize that the *SPONSOR* is > > > > > responsible for the package. > > > > > > > > Huh?!? > > > > > > > > What does "Maintainer:" mean if not the entity being responsible > > > > for, well, maintaining?!? > > > > > > Who is responsible for the package maintenance in the case where a > > > non-DD is listed in "Maintainer:", and the package is obviosuly signed > > > and uploaded (effectively sponsored) by a DD? I guess it is perfectly > > > reasonable to expect that DD, being in the role of sponsor, is > > > responsible for the package quality and further maintenance. Sponsors > > > are full-fledged DDs, and trying to claim that they are not > > > responsible, or are somehow less responsible than any other > > > non-sponsoring DDs, for the uploads they have done, is obviously plain > > > wrong. > > > > You avoided my question, it seems: What does "Maintainer:" mean, then? > > What does "Uploaders:" field mean? You still avoid my question: What does "Maintainer:" mean? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Maintainer responsible for or only doing maintenance?
On 12-05-31 at 06:08pm, Holger Levsen wrote: > On Donnerstag, 31. Mai 2012, Jonas Smedegaard wrote: > > You still avoid my question: What does "Maintainer:" mean? > > why do you ask rhetoric questions? It's defined in policy and you know > it. So whats the point? Context of my question is Bernd arguing that responsibility lies at the uploader, not only for the contents of the upload but also for its future maintenance. My point is that either we are all wasting our time declaring a meaningless "Maintainer:" control field, or Bernd is wrong and the uploader responsibility is for the contents of the upload - which includes stating who is then to be held responsible for the maintainance. In my interpretation, maintainer is expected to act responsibly. Uploader is expected to act responsibly too: The act of uploading covers ensuring the vailidy of statements in the packaging (which is especially tricky for sponsoring of work outside our Web of Trust). The act of uploading does *not* IMO cover ongoing maintenance of the package. But you are right, let's simply look at Policy. I found this at §3.3: > The maintainer is responsible for maintaining the Debian packaging > files, evaluating and responding appropriately to reported bugs, > uploading new versions of the package (either directly or through a > sponsor), ensuring that the package is placed in the appropriate > archive area and included in Debian releases as appropriate for the > stability and utility of the package, and requesting removal of the > package from the Debian distribution if it is no longer useful or > maintainable. Enrico told me (discretely, possibly assuming it was common knowledge to the rest of the community) that "Maintainer:" is often a mailinglist which cannot be in our WoT and therefore cannot be held responsible. And that therefore the uploader really is the responsible party. Let's see what is said about "Uploaders:" control field (again §3.3): > If the maintainer of the package is a team of people with a shared > email address, the `Uploaders' control field must be present and must > contain at least one human with their personal email address. See > Section 5.6.3, ``Uploaders'' for the syntax of that field. Hmm. Did you see that? According to Policy, maintainer is responsible - even for the tasks done by uploaders - and uploaders are not defined as responsible. I might be missing something, but searching all of Policy I found only tools, scripts, authors (of the Policy document) and maintainers to be described as responsible. My point here is not to be nitpicking with Policy and claiming that noone but maintainers are responsible - but I do find it quite hard to fathom that maintainers are *not* responsible. Did I miss something? Did Bernd perhaps simply mean that in *addition* to maintainers, uploaders also have a bit of responsibility for some things (but not maintenance which is what this thread is about)? Could have helped me to understand what Bernd meant if he had simply answered my direct question instead of talking around it answering question with a counter-question, Is my point clear now (even if is may disagree with my reasoning)? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Maintainer responsible for or only doing maintenance?
On 12-06-01 at 11:21am, Petter Reinholdtsen wrote: > > [Jonas Smedegaard] > > Is my point clear now (even if is may disagree with my reasoning)? > > I find your point quite clear, but suspect you misunderstood those > claiming the sponsor have responsibilities regarding package > maintenance. > > To me it is obvious that the sponsor is also responsible for a > package, when the maintainer become unresponsive or missing. When the > maintainer is active and available, the sponsor do not have to step in > and the responsibility is "sleeping". :) > > The maintainer is responsible in the day to day maintenance, but when > I sponsor packages I also keep in mind that I might end up having to > care about the package some time in the future if the listed > maintainer looses interest or disappears for other reasons. > > You seem to argue that this should not be the case. Is this because > of your current sponsor practice, or is there some other experience > behind your view on the responsibilities of a package sponsor in > Debian? I do not mean to say that sponsors should not be held responsible for maintenance, just that such responsibility *currently* isn't obvious - as e.g. Bernd seems to argue - and that I find that problematic. I read Policy as defining Maintainer as _socially_ responsible entity, and Uploader as optional _sub-entity_ when Maintainer cannot also hold _technical_ responsibility. Sponsoring breaks that logic, but I believe we can restore it by treating sponsoring exactly the same as we do teamwork. Let me try to explain...: Once upon a time we had maintainers that maintained and was held responsible for that. Back then I found it sensible that the "Maintainer:" field was prominent throughout our tools - it was hardcoded into each source and binary package (not resolved through network queries via e.g. PTS web pages or who-uploads), and appears in e.g. aptitude. Today I find the Maintainer field a joke. In the future I would like Debian to again use the Maintainer field to indicate who is *responsible* for maintenance. So yes, this is tied to my sponsor practice: I don't do sponsoring (in the common sense of the term), but (when we cannot find a suitable existing team to join) form a two-person team with me as Maintainer and the non-Debian-member as Uploader. That makes only the Uploader field somewhat a joke, similar to how it commonly is for teamwork nowadays. In my opinion a person outside of the Debian WoT does not make sense as a Maintainer, exactly because failures go unnoticed: Sponsors ought to take responsibility but are not on display so if they forget (or even worse, don't care) then we may only discover it much later in frustrated threads like this one. Debian is not a company. We don't pay the work done in money, and don't fire people not performing well. Instead, Debian is a social organism where work is "paid" or "punished by your name being prominently tied to your work. Problem is, if you are not hanging out in Debian social circles you don't feel the encouragement/pressure of your name on Debian billboards. And even if you do, others in Debian have trouble locating you, because you are not tied to our WoT. Please note that the reliability of the WoT is not the issue here - only the practicality of those email addresses being uniquely identifiable and cross-referenced in our structures so who is who is easily identifiable. Some may argue that I steal fame from the person doing the actual work on the package. I feel that I take fame (or shitstorm) of _responsibility_ of the package maintenance, and whoever doing the underlying _changes_ are documented in changelog. If my fellow unofficial maintainer later wants to apply for becoming DM or DD, proof of her/his actual contributions and skills in packaging is clearly tracked. I find sponsoring to be a hack, causing responsibility of maintenance to get blurred, with the consequence of packages going unmaintained too silently too easily. Also, I find that sonsoring is not needed: Anything done in sponsoring can be done by teamwork instead. Sure, for those sponsoring today feeling that their only responsibility is to _upload_ will feel that teaming up with the sponsoree instead is more responsibility - and that is exactly the point: sponsoring *is* more responsibility than just uploading, and today it is not clear, because we tag our sponsorees as maintainers even if in reality they (in my optic) cannot truly carry that role. I truly and sincerely hope that I am not stepping on the toes of non-Debian folks doing packaging work. That is absolutely not my intent - on the contrary I would want to make it more clear who is doing what and with which responsibility attached. - Jonas -- * Jonas Smedegaard - idealist &
Re: Maintainer responsible for or only doing maintenance?
On 12-06-02 at 04:59pm, Paul Wise wrote: > On Sat, Jun 2, 2012 at 1:33 AM, Jonas Smedegaard wrote: > > > Today I find the Maintainer field a joke. > > Both the Maintainer and Uploaders fields are less than useful for a > number of reasons: > > They are tied to the source package, this is bad because people's > commitment to and responsiblity for packages changes over time > independent of source package uploads. > > They are not sufficient to represent reality. While we have some > definition in, there are many different styles of maintainership and > different levels of commitment. > > I would like to see Debian get rid of the Maintainer and Uploaders > fields and instead implement something like DEP-2 where we have a list > of people, what they are willing to work on and the things they are > willing to do. [snip] > In this way we will get a much more realistic picture of the > commitment of the Debian community to the software that we are > shipping. Registering this level of detail might not be something > individuals are willing to do though. So because the classic fields are insufficient, you want to drop them. Even if you already ahead notice that replacement is probably too complex for simple uses. I have not followed DEP-2, so unaware if I am totally off here, but seems more sensible to me to keep classic hints as defaults. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: license of http://udd.debian.org/ data collection?
Quoting Stefano Zacchiroli (2012-12-16 10:08:56) > [ Note: I think -qa would be a better place where to discuss this, as it > is the list where UDD development is happening. Setting M-F-T > accordingly. ] > > On Sun, Dec 16, 2012 at 12:27:29PM +0800, Paul Wise wrote: > > On Sat, Dec 15, 2012 at 7:03 PM, Jonas Smedegaard wrote:' > > > What is the license of the collection of data? > > > > > > Not the script to collect it (I do notice the GPL in the header of > > > above referenced script), but the *database* of knowledge that is > > > composed. > > > > Most of the stuff is from packages themselves. Debian packages are > > under a number of different licenses, so the answer is "a collection > > of various free (and or non-free) licenses, depending on the > > package". > > If I understand correctly what Jonas is aiming at, that's not (yet) a > satisfactory answer. The license of a collection of a data might very > well be different than the license of the individual pieces of data > itself. I'm not expert on database licensing, but the underlying > intuition here is that there might be a creative effort in assemblying > the data, and that _that_ creative act might be copyrightable and > hence have a license in itself. You are spot on. And as usual (always?) you have this wonderful skill of expressing amazingly clear - thanks! > In the UDD case, the data collection is destroyed and recreated (with > some minor exception, for the historical tables) at each database > updated pulse. Hence the creativity is mostly captured by the scripts > that do this job. > > Still, it is likely that in the future more and more people interested > in UDD will ask "what is the license of the collection as opposed > to...", as it is a topic of increasing interest together with the "big > data" movement. > > It would be wise hence to have a proper data collection license > associated to the UDD database. A popular one is ODBL > http://opendatacommons.org/licenses/odbl/ . I suggest we license the > _collection_ that way, also pointing to the sources creating the > database, which will be under their own license. I fully agree. My previous reference (earlier in the thread than represented above) indeed is part of that "big data" movement: > It is now listed at > http://datahub.io/dataset/debian-package-tracking-system - but > annoyingly it is marked as " License Not Specified". Perhaps the question to ask is more who can decide on a license - the project or those harvesting (i.e. the person(s) writing the actual script)? Regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#703402: PTS: link to the blends website for packages involved in blends
Quoting Paul Wise (2013-03-19 09:33:41) > For packages that are involved in a Debian Pure Blend, it would be good > if the PTS were to link to the blends site from the links on the right. Good idea! I suggest to do it for _all_ Debian Blends, not only pure¹ ones, similar to how QA pages also include tracking of derivatives. - Jonas ¹ For distinction between "Debian Pure Blends" please see <https://wiki.debian.org/DebianPureBlends>, specifically the recent update: <https://wiki.debian.org/DebianPureBlends?action=recall&rev=35> -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
vcswatch seems not up-to-date for pandoc
Hi, Cool addition of vcswatch to the QA page! I noticed what seems to be a bug - not biggie, but thought you might want to know about it anyway: http://qa.debian.org/cgi-bin/vcswatch?package=pandoc&poke=Scan+now reports pandoc as having "UNRELEASED" as changelog, but both I and git browser at https://anonscm.debian.org/gitweb/?p=collab-maint/pandoc.git disagree with that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: vcswatch seems not up-to-date for pandoc
Quoting Christoph Berg (2014-06-30 11:00:33) > Re: Jonas Smedegaard 2014-06-24 > <20140624164126.21806.49...@bastian.jones.dk> >> Cool addition of vcswatch to the QA page! >> >> I noticed what seems to be a bug - not biggie, but thought you might >> want to know about it anyway: >> >> http://qa.debian.org/cgi-bin/vcswatch?package=pandoc&poke=Scan+now >> reports pandoc as having "UNRELEASED" as changelog, but both I and >> git browser at >> https://anonscm.debian.org/gitweb/?p=collab-maint/pandoc.git disagree >> with that. > > As said in the other mail, that was me believing "git clone --bare" > and "git fetch" would work, while git wants at least clone --mirror. What other email? Could you please re-send, as I seem to not have received that one. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
package in NEW not listed as pending upload
Hi, The package libmoox-cmd-perl is in the NEW queue: https://ftp-master.debian.org/new/libmoox-cmd-perl_0.009-1.html ...but still - after several days - lists as "Owned WNPP bugs", not "Pending uploads" at my DDPO page: https://qa.debian.org/developer.php?login=d...@jones.dk&comaint=yes Is there a bug, or have I missed some logic to it? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#825624: Raspbian not mentioned in bug categories :-(
Quoting Geert Stappers (2016-05-28 14:27:48) > Control: reopen -1 > Control: reassign -1 tracker.debian.org > Control: severity -1 wishlist > > On Sat, May 28, 2016 at 11:57:19AM +, Debian Bug Tracking System wrote: > > Your message dated Sat, 28 May 2016 13:24:33 +0200 > > with message-id <20160528112433.GB4474@bashton004> > > and subject line > > has caused the Debian Bug report #825624, > > regarding general: Raspbian not mentioned in bug categories :-( > > to be marked as done. > > Reopened > > > > Rasbian is not mentioned in reportbug cause it's not Debian. > > > > It is a derivative maintained outside of Debian, so if you want to file a > > bug > > against it please have a look at this website 1st: > > https://www.raspbian.org/RaspbianBugs > > > IMO should the gap between Raspbian and Debian not exist. > > My wish is that https://tracker.debian.org/pkg/PACKAGENAME > gets a Raspbian section like the Ubuntu section. I second that: I find it peculiar how Ubuntu is being special-cased and would appreciate if instead all derivatives were treated equally. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#838065: qa.debian.org: UDD dashboard: show recent contributors
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Would be nice if the UDD dashboard showed recent contributors. Even an inflexible implementation with just the amount (not listing each individual contributor nor whether they committed to git or released a package) and hardcoded range( e.g. past 12 months), this could be useful as a vector for estimating health of individual packages and of teams. For aiding in team health, it would be helpful to list not only the amount for each package, but also the amount across packages. - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJX3O7HAAoJECx8MUbBoAEhEb8P/iW/rYoxl/y/oqynb3aPJ1E7 x36uc8rkgO+OeAHwxdXx+gzxovQm5Gpd1DMwAN8DFH/fZ/OKLGNjHXd/hlclEvYj 61tFl5yGir6NPI99InRF+I4FMBOeFwSiiUfZDBVhUeGcjYtJnFbkyYyYPLFZkHOo nFnv+mrAqjFyfwr37A59EzkVt1syWAMTcX2vPJ/zY6hShe9+XoHqrQqCT9cNWq1W mf2NY6m40auDL70mkfkzqbyPMY2J8ik3XoUNd6zA5572qWyZwHnrwDy5086n+FpU eJxnLZao3PKWNoOaSBtdGvRIJrkevFZZD0SzrDW9QojVwJLqaG39gTSW/RwDcWLI cCDW50AbAreQTvNorLXatZbHdasXtBERwUUy4Mxwf6mQp8l9Nniycj61tvGGoDWU 4Qh8hMDB3jU5MhNykO/M6JZNRB/gViQgvro3O6FrPe1e0uPpCzVfRSbEI0I4VNfj NFMcuW7SkTfkBjzouzqmaVvaRcVDsu3K16Tk/vBnjBHFdNRaN4/Lih24bn0tI7oa F4Vn5h39GjwGuh54xwuzytLV4nk/gkImf3lrMA2TamYbSjkcDRGNZ+I8faIDKwwz zAZGLdbJXBQK9MM2HN1j1jalXWtdbz5ZHSrvkp12VuriCCPaI4n3liaddR/eKEqV a+wFZB8LXr9KRhutFusa =K//2 -END PGP SIGNATURE-
Bug#838067: qa.debian.org: UDD dashboard: show recent contributors
Package: qa.debian.org Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Would be nice if the UDD dashboard showed recent contributors. Even an inflexible implementation with just the amount (not listing each individual contributor nor whether they committed to git or released a package) and hardcoded range( e.g. past 12 months), this could be useful as a vector for estimating health of individual packages and of teams. For aiding in team health, it would be helpful to list not only the amount for each package, but also the amount across packages. - Jonas -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJX3PjjAAoJECx8MUbBoAEhlH0P/1vrxr151dWhZUxdK0gmTodj Cg7+eUPIGoKkR+9d3kNa08r3aaQiWRH6jNusZMCqm1ym/mCTGQ0BKnoyAzbQ3ySc JkcNJOVEnkzDMI8ayjdvjuEGo28u6AY6MbTHoO+GLNuzmax+ABgQuIIpaqFKOccb DWlHIqxOEPCFWY/R0uGK4cEm164f0iowyXUv+Cy9pdFFIr6HHBVLyYqmowMFnqMI Q8Lz7gYvbRQXsuki2hwamoaz4DiZwp4Wy1NzkbugpfkoeZRS1qJDpiXuA+6/0cgl 08NwI4HvBcPR8+qTcAZUJcAzqtPAycT01k4BFAh744pxUNXK52CZpoCg+PDtiNHV DAVNYBQuYaGC7tly24wNs/RE07hEV6wco+NNeOpwjJzGamVMmuC98DPT8of9hG/A p0LVMedz0VumIM06wK1Q3EyJTasxVQ8K6ZmBtqCFrQ9Lg0UMNVBL/YNyZQBYBPsx ePtGV6MvwVnq0G/GWSSfzNPvWrdG18d2cYDq8M5MSXOYwXWfO5gSS8JLTwd4BxLo aL/4R81gwbxFUDeLyFiAHAVeU+Hkph66DvMiUWrrWSqW5om5zFKSZZ8AecqEtbQ0 zCSHLwdfYhXfr9/+90ugocbBR35SVP/xRmnPtgTH4CnjSnJuppCUywpC6Q/fi9V3 c3Pu47wVYNNPQcKVxDNI =hbwd -END PGP SIGNATURE-
Bug#959762: tracker.debian.org: fails to load large page
Package: tracker.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Since some days this page failes to render: https://udd.debian.org/dmd.cgi?email1=dr%40jones.dk Maybe some threshold at the UDD backend have changed recently, the page loads ~600 packages. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl6wwesACgkQLHwxRsGg ASHGFA//aEkksX41m7KOEiLvEpEwMO5FW1AKuuMnuvSUpd/EAFZBvYPnsrkg5GUe Pf53M/MeQrwi7uFLiZONF3MOmVDYXa3wvLT38wU3CtbebbvLZvO5VABikQHC+du2 1AYDmQN0AZZjhnzxQMCpGsKGXc67rSVLVXZ92CN/3sIgj6x88wtx0O2aiq+LGt62 SEGXt0OrqqsC+GGmX7iRV9YugzvlNO99DlJ3eEUpbz/U4BbibuUwpBL9DUBuUhHk YZ+WbpDg1NgkCXGvV3h4uYcT5AgUvNuO2RKhi2ynC8+vWZj3AZF/NOx2x8fROB/H CdDoK39DjwOjgfMCKmhEHf9uY9a+FScj1Eks8lrDTc1KpVrXAVRNMNhyGy8gjKuD BwijvHsDuqIoG3bmYrchV/ulFETs2yqJsDR6s6nF8Y0oG20YtJZfSCAz0SDpLuze /IVU5ASv6Hk7WhgM4ILJoQu2H1jgpTljj0jCRXyb6T1d64irp5yz1COdlhfRfLuh ozvgv5WGCyaF83EBhRhwf9W3k8Ln5iRWfI/hoPhNx08ljaHwkh+cSVPvGpJSS5yy VhYVwCLPof96jweX0iUrrxTP4GvY1iPS8th0OBesGyPXDfx/qdJC/nwnjOD3uYkd wWF010aTERtrLTXH30kjfUxCq6YTq0CThxQ31g78S9zrwWW9LFw= =w9bR -END PGP SIGNATURE-
Bug#959762: UDD/dmd: fails to load when debci data is missing
Quoting Rebecca N. Palmer (2020-05-25 10:57:02) > Control: retitle -1 UDD/dmd: fails to load when debci data is missing > > The problem isn't the number of packages, but some specific packages > that can't be displayed even when they are the only package requested: > https://udd.debian.org/dmd/?email1=&email2=&email3=&packages=node-file-entry-cache&ignpackages=&format=html#todo > > These packages appear to be the ones that have a debci result (any > result) in testing but no debci data in unstable: > https://ci.debian.net/packages/n/node-file-entry-cache/ > > Known examples: > acpi-call node-housekeeping node-chainsaw node-file-entry-cache > > As a workaround, you can exclude packages like this: > > https://udd.debian.org/dmd/?email1=dr%40jones.dk&email2=&email3=&packages=&ignpackages=eyes.js+node-eslint-plugin-node+node-eslint-plugin-requirejs++node-eslint-utils+node-esquery+node-ignore+node-leche+node-file-entry-cache+node-proxyquire+python-asynctest+pd-zexy+python-m2r+&format=html#todo > > These packages can be identified from the CI column of DDPO, which does > work for such package sets: > > https://qa.debian.org/developer.php?email=dr%40jones.dk ThanksyouThankyouThankyou! I hereby owe you a /virtual/real beverage of your choosing. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Removing diskless?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 11 Sep 2005 23:02:49 +0200 Matej Vela <[EMAIL PROTECTED]> wrote: > I think it's time to remove diskless. I know we usually don't remove > packages marked as being adopted, but this one looks hopeless: > Jonas, as the maintainer of lessdisks, do you think it can serve as an > adequate replacement? Lessdisks is more powerful than diskless, so in most aspects it is adequate. One aspect is simplicity - here I think diskless wins, but not if poorly maintained and not if depending on custom kernels. IMHO. So I recommend dropping diskless as well. Regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDJLoZn7DbMsAkQLgRAlAeAJ0YoLepzXntyBKev7Bc91nqagdq/gCdHrRk H/deAdwFy6U6krldavnGjFw= =p/Cf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should we remove icecast-client?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 21 Nov 2005 06:44:47 +0100 Matej Vela <[EMAIL PROTECTED]> wrote: > icecast-client has been orphaned for a year, and seems to have been > superseded upstream by libshout and ices2. Are there any reasons to > keep it in the archive? I would have no problems with that package dropped, but it streams MP3 files while ices2 stream Ogg/Vorbis files. So the package may still be interesting for some users. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgayqn7DbMsAkQLgRAp/8AJ9BAVKg25rrLNz2KpBNFOWrjD7WVQCfasn7 VzsXrivkwQZzsN65fxCC92U= =XS3/ -END PGP SIGNATURE-
Re: Custom Debian powerpc cd last yaboot 1.3.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Dec 25, 2008 at 11:18:14PM +0900, Paul Wise wrote: >On Thu, Dec 25, 2008 at 11:12 PM, Vincent Bernat wrote: > >> Is there any other way to boot on PPC without yaboot? > >quik, grub-ieee1275 seem to support some section of powerpc machines. Correct. But quik is for so-called "old-world" machines whereas yaboot is for "newworld" ones, and grub-ieee1275 is still pretty new: I have played with GRUB for some years but have so far failed to make GRUB2 (that the ieee1275 variant is part of) work on Apple PowerPCs. >The point is that yaboot needs to be better maintained, not that >Debian would remove yaboot without also removing powerpc (which seems >unlikely at this point). I still need yaboot on some of my machines. I'll have a look at the package and consider adopting it. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklU3b0ACgkQn7DbMsAkQLgWZwCfTBinG1wd5Xk5Nd0/PaLru3uh rIAAn3GOZHmViLzdbFcrOn80s4C/zHZ/ =NjY/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debootloaders-yaboot] Custom Debian powerpc cd last yaboot 1.3.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Dec 29, 2008 at 09:43:49PM +0100, Aurélien GÉRÔME wrote: >On Fri, Dec 26, 2008 at 02:35:58PM +0100, Jonas Smedegaard wrote: >> I still need yaboot on some of my machines. I'll have a look at the >> package and consider adopting it. > >Feel free to join the team and to take the responsibility for the >upload of the new upstream release if you have access to pSeries >machines. For my part, I will not do an upload to fix bugs which I >cannot verify due to a lack of hardware. Thanks for the heads up. This is above my head, however. My "machines" are just simple G4 and G5 Machintoshes, so I stand down :-P - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklZUzQACgkQn7DbMsAkQLgSIQCfQ9wNrqgbGsBrBIqPwoPvr7U2 OK0AnikDqD51VrYmsvJnBWs7OE2lAI5M =p1F4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
