Re: Four days
Hi Michael! Just a few responses... I think the thread that followed answered a lot of your general questions, but I wanted to be sure you understood where I am coming from. On Sun, 3 Oct 2010, Michael Tautschnig wrote: - As a mentor, as far as RFS are concerned, I can only work on packages where I have some proper background. That is, I should be using those packages or work on related packages. - As a mentor, I cannot look at each and every RFS, I'll have to be able to spot interesting packages quickly. I therefore ignore all RFS with package names where I cannot deduce that they could be relevant for me. Hint: it might be useful to add the short description of the main binary package to the subject (I have no idea what, e.g., vavoom is about). Indeed! I don't do a lot of sponsoring myself, though I have bit by bit. The subject line change is a good idea! - Although debian-mentors is a default destination for RFS, it would probably better to contact one of the teams that works on related packages. Again, the vavoom package (I now looked at the RFS): Why wasn't pkg-games-de...@lists.a.d.o contacted? Yup -- that's the kind of feedback people deserve in their RFSs, and if we find ourselves saying it a lot on the list, someone can come up with a FAQ and work on integrating changes to the mentors.debian.net software. In effect, I want to expose the process problems we have so loudly that more people see them, and then they can help come up with solutions. So I was thinking it would be nice if every email thread got a public reply within four days. That's a goal that Niels and I have set, and we hope maybe some of you help too. Even if we reply, Eek, I'm swamped. Try again later, I figure that is nicer than hearing nothing back. Would you mind to elaborate on the expected benefit of such a step? *Whom* would you expect to be doing such replies? Is that more than an ACK, your message made it to the list (you can check that by looking at the list archives as well)? I think you are only curing some symptoms, but fail to tackle the underlying root cause (some of which might be the points I mentioned above). I expect that Niels and I will do it, as I tried to say in my email. We will hold the line at 4 days, and hopefully others will reply. Even if the ACK, your message made it to the list is all people get, to many people it means more than that -- it's a human read it, and sympathizes with your lack of sponsorship. Also, the four-days thing helps people say, Well, if this list isn't working for getting a sponsor, maybe I should try a different strategy. Just like how you can set a timeout on a socket, and if the socket appears to be dead, code can take a different action. I say that because I remember sending out RFS emails to this list and getting no answer and feeling less excited about contributing to Debian. I see excitement and dedication to Debian as scarce resources. Eventually I got that excitement back when a friend of a friend (Mako) took interest in sponsoring my packages. If I had reached out to him sooner, then I would have become a DD sooner! In general, I encourage mentees and mentors to consider 4 days the timeout on your debian-mentors conversations. So if you email your usual sponsor and don't hear an answer within 4 days, try once more. I'm not sure how mentees usually handle the situation where a package has already been sponsored once. I'd expect mentors to be ready to handle further uploads, and IMHO such RFS shouldn't even pop up on the list. After a few rounds, people should be both ready and willing to apply for Debian-Maintainer status. And yet they do! I find it pretty odd, too. There's perhaps some process problem that we don't know about, and I want to help people figure that out. So when the (updated package) emails come to the list, and we look at those people weird, we can let them know that they should reach back to their usual sponsor. Or we can just know that and not tell them. After another four days, email the list asking for a sponsor (explaining that you have a normal sponsor). Should the mentor indeed be non-responsive, this should be *clearly* indicated in the subject of an RFS email to debian-mentors. Agreed. I'm hoping to take some of the uncertainty out of the process. What do you guys think? And what other cultural improvements can we make to debian-mentors? What else can we do to make this place supportive and helpful for the progress of y'all mentees into sparkly Debian contributors and developers? IMHO one of the most important steps would be for mentees to look for appropriate teams already working on similar packages. It would actually be beneficial if people first subscribed to their respective lists to see what's going on there and then try to get in touch with them about a new package. Hope this helps (mentees and mentors alike), Thanks -- it was helpful! You wrote
Re: Four days
Hi, (order of quotes changed to make things clearer.) On Montag, 4. Oktober 2010, Asheesh Laroia wrote: Even if the ACK, your message made it to the list is all people get, to many people it means more than that -- it's a human read it, and sympathizes with your lack of sponsorship. Also, the four-days thing helps people say, Well, if this list isn't working for getting a sponsor, maybe I should try a different strategy. Just like how you can set a timeout on a socket, and if the socket appears to be dead, code can take a different action. I'm ready to applaud your efforts, I think it's a good idea. I expect that Niels and I will do it, as I tried to say in my email. We will hold the line at 4 days, and hopefully others will reply. Especially as *you* plan to do it, and don't ask others to! :-) I say that because I remember sending out RFS emails to this list and getting no answer and feeling less excited about contributing to Debian. I see excitement and dedication to Debian as scarce resources. Absolutly. I also sympathise with Michaels concerns, but dont think those invalid yours. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Four days
Asheesh Laroia ashe...@asheesh.org writes: Since we agree on that general point, can you be the watchdog -- that is, if we try removing pain points that are necessary or useful, can you specifically identify them and remind us why they're worth keeping? Thanks for the offer, but no. I think responsibility for that rests with each of us: to reject the view that something uncomfortable is necessarily bad, and to instead look for whether it is serving a useful purpose. I think that the point of your response is to make a general point and not to specifically urge any change in action, but I'm not quite sure. I just want to make sure I'm using your messages as you intend them. Yes, I want only to ensure that the naive interpretation of “this is uncomfortable for newcomers” is examined more thoroughly before action is taken. -- \ “Perhaps our role on this planet is not to worship God — but to | `\ create Him.” —Arthur C. Clarke, 1972 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqvqyzc4@benfinney.id.au
Re: Four days
On Mon, 4 Oct 2010, Ben Finney wrote: Asheesh Laroia ashe...@asheesh.org writes: Since we agree on that general point, can you be the watchdog -- that is, if we try removing pain points that are necessary or useful, can you specifically identify them and remind us why they're worth keeping? Thanks for the offer, but no. I think responsibility for that rests with each of us: to reject the view that something uncomfortable is necessarily bad, and to instead look for whether it is serving a useful purpose. Sure -- I'll always try to, too. I think that the point of your response is to make a general point and not to specifically urge any change in action, but I'm not quite sure. I just want to make sure I'm using your messages as you intend them. Yes, I want only to ensure that the naive interpretation of “this is uncomfortable for newcomers” is examined more thoroughly before action is taken. Got it. Yeah, I believe I examined it in this situation. Let's rush to give people pain through direct, actionable feedback to their packages rather than pain through silence. That's the idea. If you think it's not good then let me know and we'll see if some other plan is better. -- Asheesh. -- You may my glories and my state dispose, But not my griefs; still am I king of those. -- William Shakespeare, Richard II
Re: Four days
On Mon, 4 Oct 2010, Ben Finney wrote: Asheesh Laroia ashe...@asheesh.org writes: On Mon, 4 Oct 2010, Ben Finney wrote: So when we identify a point of pain, I think it's essential to ask: is this pain necessary to the learning process for this person? Ben, I'm not sure what you're saying. It sounds like you're saying, The silent treatment is a useful way to teach people humility. No, I wasn't speaking only of the lack of responses. (I disagree with your characterisation of it as “the silent treatment”; that carries the strong connotation that it is a deliberate punishment on the part of people who actively choose not to reply to each message. That's not a point I was making in earlier messages, though.) The discussion has brought in mention of points of pain other than lack of responses. I am cautioning against a naive and, in my view, incorrect focus of finding and removing points of pain as though they are universally bad. Ben, I agree with you in general. Not all pain is bad. It is true that we should not go around willy-nilly, removing all pain points. Since we agree on that general point, can you be the watchdog -- that is, if we try removing pain points that are necessary or useful, can you specifically identify them and remind us why they're worth keeping? I think that the point of your response is to make a general point and not to specifically urge any change in action, but I'm not quite sure. I just want to make sure I'm using your messages as you intend them. Yayfully, -- Asheesh. -- Today is the tomorrow you worried about yesterday.
Re: Four days
On Mon, 4 Oct 2010, Ben Finney wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: As someone who has attempted to go through the mentoring process, I agree very much that it is rather depressing. How much of that is actually a problem, though? How much is an integral part of gaining humility as to the state of the packaging work, and the pain of learning new conventions and processes? I'm all in favour of lowering *unnecessary* barriers. But not at the expense of the necessary parts of the mentoring process itself: to teach prospective maintainers to stand on their own feet and learn what doesn't work, as a necessary part of learning what does work. So when we identify a point of pain, I think it's essential to ask: is this pain necessary to the learning process for this person? Ben, I'm not sure what you're saying. It sounds like you're saying, The silent treatment is a useful way to teach people humility. I think that our silence teaches a terror based on the unpredictability of response on the list. By not responding to people's emails, we create the perception that our prospective mentees are not in control over the outcome of a situation. A related concept in psychology is learned helplessness, which you can read about at http://en.wikipedia.org/wiki/Learned_helplessness if you want. Often, we don't provide enough feedback to people to say what the problems are; so they don't know how to improve things. Even if the problem is just Debian developers are too busy, at least prospective mentees know the problem isn't (necessarily) their package -- they now need to get better at finding prospective mentors. Maybe they can reach out to their local community instead, or they can read the Debian wiki harder and discover teams relevant to their package. Anyway, it's just something Niels and I (and anyone else who wants to) are committed to. If you don't want to send any extra emails to the list, that's totally fine with me. The point of this thread is to tell mentees that they can expect a response within four days. It might be from me, or Niels, or anyone else, but my goal is that they'll get one. It doesn't create any extra work for you. If you find that the emails I send to the list are off-topic or otherwise bad for the list, then by all means let me know and I'll work to improve my behavior. I hope I've explained a little bit what I mean. It's 1 a.m., so I'm not entirely confident. I hope this email comes off with the positive attitude that I intend it to! -- Asheesh. -- You're not drunk if you can lie on the floor without holding on. -- Dean Martin -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1010040055520.16...@localhost
Re: Four days
Asheesh Laroia ashe...@asheesh.org writes: On Mon, 4 Oct 2010, Ben Finney wrote: So when we identify a point of pain, I think it's essential to ask: is this pain necessary to the learning process for this person? Ben, I'm not sure what you're saying. It sounds like you're saying, The silent treatment is a useful way to teach people humility. No, I wasn't speaking only of the lack of responses. (I disagree with your characterisation of it as “the silent treatment”; that carries the strong connotation that it is a deliberate punishment on the part of people who actively choose not to reply to each message. That's not a point I was making in earlier messages, though.) The discussion has brought in mention of points of pain other than lack of responses. I am cautioning against a naive and, in my view, incorrect focus of finding and removing points of pain as though they are universally bad. Not all pain is bad. As an example: the pain of having one's work criticised is, in my view, necessary to improving one's work and must be endured — and, preferably, welcomed as an exercise in learning humility and considering such criticism in future work. Rather, points of pain in the process are only bad if they are unnecessary to the purpose of the process: to teach people to become better maintainers, as part of the broader purpose of improving Debian. If you find that the emails I send to the list are off-topic or otherwise bad for the list, then by all means let me know and I'll work to improve my behavior. Not at all, the discussion is good to have. -- \ “The fact that I have no remedy for all the sorrows of the | `\ world is no reason for my accepting yours. It simply supports | _o__) the strong probability that yours is a fake.” —Henry L. Mencken | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyl2zdad@benfinney.id.au
Re: Using ccache with git-buildpackage
I haven't tried this, but from the manpage: --git-builder=BUILD_CMD Use BUILD_CMD instead of debuild -i\.git -I.git so specifying: --git-builder='debuild -i.git -I.git --prepend-path=/usr/lib/ccache' should work. On Sat, Oct 2, 2010 at 10:31 AM, Andrey Rahmatullin w...@wrar.name wrote: Hello. I use git-buildpackage and want to use ccache. I tried exporting overriden CC and PATH, but that had no effect and `echo' in debian/rules shows that both variables are reverted to the defaults. Does git-buildpackage clear the environment? How can I use ccache in this configuration? -- WBR, wRAR -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJMpu30AAoJEOih81koZvPBRIgH/1yJBDUo0fVBtvo0le9WNQ4H 77U5F4vZnHccUW6B7BGRHxfHmLD23V7S/M8HkjyRvPub+YPljZCcmaBlW0H/bnBf Rtgbd/fC00GnGsm7yKcLSSD472/BC3qSTeUp77RxLcqM0xYKpqI4+ZgUvDyntNZ3 mY1+Dz8a3q/Hlrps3GGyZgWnNn0nZ/veMvomhJWugDw6bZ9mBvaix4ZFUaetwEI+ itcnKFKjAsjL8syv24PzNTEljRQW/jXBOuCTePLCs+Gq8HzztvV+KzWVX5vJulJT 6Uiu/BdgC2D7myIm38u5iCkNHPL/NkrH9Lu8pduKEa9B3m41wItUeTGFwpV/s9Y= =mA8n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=a_8i9hbkhchifajvdmt-3cbu5dxmmumqgh...@mail.gmail.com
Re: RFS: dbmail (updated package needs new sponsor)
Michael, thanks for replying. On 10/03/2010 09:39 PM, Michael Tautschnig wrote: You might have noticed the thread started by Asheesh (with [1] being my reply). That thread prompted me to send out a ping. Your RFS email is prime example of those messages usually failing to pass my filter. So what's wrong this RFS email: - The package name dbmail isn't all too specific. Once I looked at the package page I noticed that I would indeed be interested in using such a software, but that I wouldn't have guessed from the package name alone. Well, in this case I must add that the short description base package for the dbmail email solution is not that useful either (saying that dbmail is dbmail...). That description has been in use for years now. I didn't look at it this time with a critic's eye. I have updated it now to be more descriptive. - This (updated package) mainly tells me can be ignored, they already had a sponsor earlier on. Mmm. Then what should a packager use if the previous sponsor has gone mia, and a new sponsor is sought? Maybe the new subject would draw the proper attention? I can't say that I'll take a look at it rightaway, but I'll take care of it in the next days. Meanwhile please contact the debian-l10n-english list to ask for a review of your package descriptions (and please improve the short descriptions I've subscribed to that list, and will send out a request for feedback. - I guess this is email *server* software, but this isn't clear), add a Homepage field to your package (doesn't seem to be there, at least there is no link on packages.debian.org/sid/dbmail), make sure it is lintian clean, etc. Although reply-to is set to the list, feel free to contact me in personal mail. I've updated the control file to include more recommended fields, among them the Homepage field. And yes, of course it's lintian clean. But perhaps you've started filtering out the boilerplate. I've learned quite some time ago already not to bother sponsors if the package isn't lintian clean for the latest standards-version on an fully up-to-date sid system. Again, thanks for your feedback so far. -- Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlandshttp://www.nfg.nl -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca990fa.8090...@nfg.nl
Re: RFS: fritzing
Hello, On Sun, Oct 03, 2010 at 05:42:48PM +0100, Enrique Hernández Bello wrote: It builds these binary packages: fritzing - Easy-to-use, electronic design software ---end quoted text--- * Please consider packaging it under pkg-electronics team [1]. * There are some lintian issues: W: fritzing source: unknown-field-in-dsc original-maintainer W: fritzing source: out-of-date-standards-version 3.8.4 (current is 3.9.1) I: fritzing: arch-dep-package-has-big-usr-share 57499kB 92% N: N:The package has a significant amount of architecture-independent data N:(over 4MB, or over 2MB and more than 50% of the package) in /usr/share N:but is an architecture-dependent package. This is wasteful of mirror N:space and bandwidth since it means distributing multiple copies of this N:data, one for each architecture. N: N:If the data in /usr/share is not architecture-independent, this is a N:Policy violation that should be fixed by moving the data elsewhere N:(usually /usr/lib). N: N:Refer to Debian Developer's Reference section 6.7.5 N:(Architecture-independent data) for details. N: N:Severity: wishlist, Certainty: certain N: W: fritzing: new-package-should-close-itp-bug W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/din-5_midi_connector.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/7-segment display.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/breadboard/breadboard.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/core/xbee.fzp W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/solenoid.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/loudspeaker.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/microphone.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/16-segment display.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/xbee.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/icon/infrared proximity sensor.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/infrared proximity sensor.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/schematic-arduino-diecimila_old.svg W: fritzing: executable-not-elf-or-script ./usr/share/fritzing/parts/svg/core/schematic/din-5_midi_connector.svg # This is because those files are marked as executable in upstream # tarball. Although dh_fixperms is run during build but it doesn't fix # those permissions, you can override dh_fixperms to fix those # permissions, also tell upstream about to fix that. I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/contrib/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/breadboard/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/icon/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/contrib/schematic/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/breadboard/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/icon/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/pcb/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/svg/user/schematic/ I: fritzing: package-contains-empty-directory usr/share/fritzing/parts/user/ N: N:This package installs an empty directory. This might be intentional but N:it's normally a mistake. If it is intentional, add a lintian override. N: N:If a package ships with or installs empty directories, you can remove N:them in debian/rules by calling: N: N: $ find path/to/base/dir -type d -empty -delete N: N:Severity: wishlist, Certainty: possible N: * Also please consider forwarding the .desktop manpage files you made to upstream. * Probably debian/dirs is not needed [1] http://wiki.debian.org/PkgElectronics -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Re: RFS: roxterm (updated package)
On Sun, 3 Oct 2010, Tony Houghton wrote: Dear mentors, I am looking for a sponsor for the new version 1.18.5-3 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The upload would fix these bugs: 598971 For anyone reading -- it's a bug where a terminal emulator isn't setting TERM properly. Kind of depressing, and kind of important! It's also basically a one line change. Also, as advice for the future, it would have been nice if you had said the above yourself. That way I wouldn't have had to go to the web and find out what the bug is about. I have a Debian work night scheduled for tonight, but I'm swamped working on mentors.debian.net stuff. But this is a good thing to see fixed, so hopefully you'll see a sponsor in the next few days...? (If not, we're probably just all busy.) Tony's also being really snappy -- the issue was first raised (initially within Ubuntu) on October 1, and here's this RFS! -- Asheesh. -- Your ignorance cramps my conversation. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1010040838530.25...@rose.makesad.us
Re: RFS: fritzing
On Sun, Oct 03, 2010 at 05:42:48PM +0100, Enrique Hernández Bello wrote: Dear mentors, I am looking for a sponsor for my package fritzing. * Package name: fritzing Version : 0.4.3b-1 Upstream Author : Fritzing Developers i...@fritzing.org * URL : http://fritzing.org * License : GPLv3 CC:BY-SA Section : electronics It builds these binary packages: fritzing - Easy-to-use, electronic design software Is there really a need for the comma here? G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence were in Chinese, it would say something else. signature.asc Description: Digital signature
Re: RFS: roxterm (updated package)
On 04/10/10 13:43, Asheesh Laroia wrote: For anyone reading -- it's a bug where a terminal emulator isn't setting TERM properly. Kind of depressing, and kind of important! It's also basically a one line change. Also, as advice for the future, it would have been nice if you had said the above yourself. That way I wouldn't have had to go to the web and find out what the bug is about. Yes, sorry. I've read more of the Four Days thread now so from now on I'll try to add more detail to my RFS messages. Perhaps the maintainer of the mdn website could add some comments encouraging sponsees to try to expand more on the template. I have a Debian work night scheduled for tonight, but I'm swamped working on mentors.debian.net stuff. But this is a good thing to see fixed, so hopefully you'll see a sponsor in the next few days...? (If not, we're probably just all busy.) Usually George Danchev uploads roxterm, but I think he prefers to read my RFSs here than to get private requests. Tony's also being really snappy -- the issue was first raised (initially within Ubuntu) on October 1, and here's this RFS! I didn't think I was that quick. But when I read Ubuntu were planning a 10/10/10 release instead of waiting until the end of the month I thought I'd better get on top of it quick even if it meant installing Maverick beta somewhere, because I don't want people to get a bad impression of roxterm from such a serious bug on one of the most popular distros. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004163830.6f268...@realh.co.uk
Re: Four days
On Mon, 04 Oct 2010 11:35:04 +1100, Ben Finney wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: As someone who has attempted to go through the mentoring process, I agree very much that it is rather depressing. How much of that is actually a problem, though? How much is an integral part of gaining humility as to the state of the packaging work, and the pain of learning new conventions and processes? The depressing part is that almost no one is interested in being a mentor, so its almost impossible to get your work into Debian, which makes the effort seem pointless. Note that I've actually succeeded many times, but I've also failed many times as well. And the failures are all due to lack of an interested mentor, not due to package quality (a bunch of my packages are on mentors.debian.net and lintian clean). I think that the efficiency of mentoring is the problem that needs to be solved. That could possibly be improved by treating mentoring tasks as bugs. It may also possibly be improved by treating mentoring as a team task. I see the complaint that DDs choose not to mentor because they end up stuck with unmaintained packages. Well, it would be less of a burden if those were team maintained (make new mentees part of those teams as well). Maybe mentorship should be a team effort? Start a new group of mentees every month that work together perhaps? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004114259.3f92086c.michael.s.gilb...@gmail.com
RFS: matrixssl
Dear mentors, I am looking for a sponsor for the new version 3.1.2-2 of my package matrixssl. It builds these binary packages: libmatrixssl3.1 - small SSL library optimized for embedded systems libmatrixssl3.1-dev - small SSL library optimized for embedded systems (development fil libmatrixssl3.1-doc - small SSL library optimized for embedded systems (documentation) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/matrixssl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/matrixssl/matrixssl_3.1.2-2.dsc I would be glad if someone uploaded this package for me. Kind regards Jonathan Gonzalez V. pgp2AiuVYRIL0.pgp Description: PGP signature
Re: RFS: pgfouine (updated package)
[Forgot to send the reply to the list, just read about Four Days thread] On Mon, Oct 04, 2010 at 03:38:42PM +1100, Matthew Palmer wrote: On Sun, Oct 03, 2010 at 10:59:51PM -0500, Luis Uribe wrote: I am looking for a sponsor for the new version 1.2-2 of my package pgfouine. Are you looking for a single sponsorship, or an on-going sponsoring relationship? Are you currently, or are you planning on becoming, a DM or DD? I was on NM process but i decided to go On Hold and when i tried to re-start, my AM was busy (luk), so the process got stuck. Later i ask the Front Desk for another AM and after a few mails with Enrico, we decided that the best thing to do was stop NM, do some more work and start with DM. On NM i almost reach the end of TS I. So i'm looking for a on-going sponsor for some of my packages (most active ones) and have another opinion of my work. I've been working with anibal (main sponsor) and with santiago and rmayorga, who have uploaded some packages a few times. I hope that with another sponsor opinion the DM process will be easy. Regards, -- Luis http://eviled.org signature.asc Description: Digital signature
Re: Four days
Hi Dne Mon, 4 Oct 2010 11:42:59 -0400 Michael Gilbert michael.s.gilb...@gmail.com napsal(a): On Mon, 04 Oct 2010 11:35:04 +1100, Ben Finney wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: As someone who has attempted to go through the mentoring process, I agree very much that it is rather depressing. How much of that is actually a problem, though? How much is an integral part of gaining humility as to the state of the packaging work, and the pain of learning new conventions and processes? The depressing part is that almost no one is interested in being a mentor, so its almost impossible to get your work into Debian, which makes the effort seem pointless. Note that I've actually succeeded many times, but I've also failed many times as well. And the failures are all due to lack of an interested mentor, not due to package quality (a bunch of my packages are on mentors.debian.net and lintian clean). Lack of interested mentors is indeed an issue. Nobody has unlimited time and chooses what attracts him. For me it usually means things I know and test or which I find interesting after reading RFS email. The level of this of course depends how heavy I am loaded with other tasks (what currently means that it is unlikely that some new package would attract my attention). I think that the efficiency of mentoring is the problem that needs to be solved. That could possibly be improved by treating mentoring tasks as bugs. Well it would be definitely useful having better tracked package reviews and problems found on earlier upload, so that it is clearly visible if there are still some not fixed issues. [1]:http://lists.debian.org/debian-mentors/2010/07/msg00183.html -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Four days
Hello, Michal Čihař ni...@debian.org wrote on 2010-10-04 18:14: Lack of interested mentors is indeed an issue. Nobody has unlimited time and chooses what attracts him. For me it usually means things I know and test or which I find interesting after reading RFS email. I will mention another point: We have Maintainer, Debian Maintainer (DM) and Debian Developer (DD). DD's and DM's is allowed to upload packages directly (DM's only their own packages). But the other Maintainer always need an sponsor - for every upload. It seems that the most problems are packages which are maintained by this group of Maintainer. Is there a way to reduce the number of usual Maintainer? This could help. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: Four days
On Mon, Oct 04, 2010 at 11:42:59AM -0400, Michael Gilbert wrote: On Mon, 04 Oct 2010 11:35:04 +1100, Ben Finney wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: As someone who has attempted to go through the mentoring process, I agree very much that it is rather depressing. How much of that is actually a problem, though? How much is an integral part of gaining humility as to the state of the packaging work, and the pain of learning new conventions and processes? The depressing part is that almost no one is interested in being a mentor, A state which isn't helped by the regular complaint that there's nobody to sponsor my packageees!. When I *do* sponsor something, I'm pretty much guaranteed to get at least one (other) person e-mail me personally with an RFS that's never seen the light of day here, and it's pretty much always for something I'd never touch (for some reason, it seems I see a lot of Java packages that way). Neither state of affairs encourages me to sponsor anything. so its almost impossible to get your work into Debian, which makes the effort seem pointless. Because having a nice package you can use yourself or put on a website somewhere has *no* value at all, naturally. Note that I've actually succeeded many times, but I've also failed many times as well. And the failures are all due to lack of an interested mentor, not due to package quality (a bunch of my packages are on mentors.debian.net and lintian clean). Those are not the be-all and end-all gauges of quality. I think that the efficiency of mentoring is the problem that needs to be solved. That could possibly be improved by treating mentoring tasks as bugs. It may also possibly be improved by treating mentoring as a team task. I see the complaint that DDs choose not to mentor because they end up stuck with unmaintained packages. Well, it would be less of a burden if those were team maintained (make new mentees part of those teams as well). Because packages that are unmaintained by a team that are indifferent are not any different, practially speaking, than those that are unmaintained by one person who is indifferent. Maybe mentorship should be a team effort? Start a new group of mentees every month that work together perhaps? Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004193022.ge32...@hezmatt.org
Re: RFS: pgfouine (updated package)
On Mon, Oct 04, 2010 at 11:35:55AM -0500, Luis Uribe wrote: [Forgot to send the reply to the list, just read about Four Days thread] On Mon, Oct 04, 2010 at 03:38:42PM +1100, Matthew Palmer wrote: On Sun, Oct 03, 2010 at 10:59:51PM -0500, Luis Uribe wrote: I am looking for a sponsor for the new version 1.2-2 of my package pgfouine. Are you looking for a single sponsorship, or an on-going sponsoring relationship? Are you currently, or are you planning on becoming, a DM or DD? I was on NM process but i decided to go On Hold and when i tried to re-start, my AM was busy (luk), so the process got stuck. Later i ask the Front Desk for another AM and after a few mails with Enrico, we decided that the best thing to do was stop NM, do some more work and start with DM. On NM i almost reach the end of TS I. So i'm looking for a on-going sponsor for some of my packages (most active ones) and have another opinion of my work. I've been working with anibal (main sponsor) and with santiago and rmayorga, who have uploaded some packages a few times. I hope that with another sponsor opinion the DM process will be easy. The DM process should be straightforward for you as it is. I'd recommend starting that process now, and I'll DMUA pgfouine if it looks good. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004194349.gf32...@hezmatt.org
Re: Four days
On Mon, Oct 04, 2010 at 09:17:24PM +0200, Joachim Wiedorn wrote: Hello, Michal ??iha?? ni...@debian.org wrote on 2010-10-04 18:14: Lack of interested mentors is indeed an issue. Nobody has unlimited time and chooses what attracts him. For me it usually means things I know and test or which I find interesting after reading RFS email. I will mention another point: We have Maintainer, Debian Maintainer (DM) and Debian Developer (DD). DD's and DM's is allowed to upload packages directly (DM's only their own packages). But the other Maintainer always need an sponsor - for every upload. It seems that the most problems are packages which are maintained by this group of Maintainer. Is there a way to reduce the number of usual Maintainer? This could help. Get more people into being DMs. No better way to learn than to get bug reports from irate users whose data you've just hosed. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004195027.gg32...@hezmatt.org
Re: RFS: matrixssl
Hi Dne Mon, 04 Oct 2010 11:57:44 -0400 z...@gnu.org napsal(a): I am looking for a sponsor for the new version 3.1.2-2 of my package matrixssl. It builds these binary packages: libmatrixssl3.1 - small SSL library optimized for embedded systems libmatrixssl3.1-dev - small SSL library optimized for embedded systems (development fil libmatrixssl3.1-doc - small SSL library optimized for embedded systems (documentation) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/matrixssl - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/matrixssl/matrixssl_3.1.2-2.dsc I would be glad if someone uploaded this package for me. It would be great if you've mentioned some other details in the RFS email - It is new package? Are you adopting it? What is your motivation to take care of this package? Does the upload fix any bugs? Quick look at the package: 1. It is orphaned package, you seem to want to addopt it, so why your latest changelog entry mentions NMU? 2. This seems to be quite major version update, are you sure you want to upload this to unstable in freeze? 3. You dropped dietlibc support without single mention in changelog/NEWS 4. Manually creating postinst/postrm is really not needed, just use debhelper. 5. Why is there another tarball and debian directory in .orig.tar.gz? Please check how the source package should look like. 6. Ever heard about lintian? I: matrixssl source: binary-control-field-duplicates-source field section in package libmatrixssl3.1 I: matrixssl source: duplicate-long-description libmatrixssl3.1-dev libmatrixssl3.1 libmatrixssl3.1-doc I: matrixssl source: missing-debian-source-format W: matrixssl source: changelog-should-not-mention-nmu I: matrixssl source: debian-watch-file-is-missing -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Four days
On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: On Mon, Oct 04, 2010 at 11:42:59AM -0400, Michael Gilbert wrote: On Mon, 04 Oct 2010 11:35:04 +1100, Ben Finney wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: As someone who has attempted to go through the mentoring process, I agree very much that it is rather depressing. How much of that is actually a problem, though? How much is an integral part of gaining humility as to the state of the packaging work, and the pain of learning new conventions and processes? The depressing part is that almost no one is interested in being a mentor, A state which isn't helped by the regular complaint that there's nobody to sponsor my packageees!. When I *do* sponsor something, I'm pretty much guaranteed to get at least one (other) person e-mail me personally with an RFS that's never seen the light of day here, and it's pretty much always for something I'd never touch (for some reason, it seems I see a lot of Java packages that way). Neither state of affairs encourages me to sponsor anything. so its almost impossible to get your work into Debian, which makes the effort seem pointless. Because having a nice package you can use yourself or put on a website somewhere has *no* value at all, naturally. Note that I've actually succeeded many times, but I've also failed many times as well. And the failures are all due to lack of an interested mentor, not due to package quality (a bunch of my packages are on mentors.debian.net and lintian clean). Those are not the be-all and end-all gauges of quality. Of course, but if there are actually problems in my packages, I've addressed them rapidly. At this point, I have no outstanding issues other than lack of an interested mentor. I think that the efficiency of mentoring is the problem that needs to be solved. That could possibly be improved by treating mentoring tasks as bugs. It may also possibly be improved by treating mentoring as a team task. I see the complaint that DDs choose not to mentor because they end up stuck with unmaintained packages. Well, it would be less of a burden if those were team maintained (make new mentees part of those teams as well). Because packages that are unmaintained by a team that are indifferent are not any different, practially speaking, than those that are unmaintained by one person who is indifferent. That's not the point I was making. The idea would be to form a mentors team that includes all mentors that act as a collaborative mentor, rather than an individual mentor. This would of course help the quickly orphaned package issue. Maybe mentorship should be a team effort? Start a new group of mentees every month that work together perhaps? Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? Especially when there are so many complaints from DDs not having time themselves. Change the DD role to watching the mentees work together, and only step in when needed. This also would help the quickly orphaned package issue since packages will come in with group maintainership right away. Anyway, I'm thinking about how to improve this rather depressing situation. It doesn't help my motivation when I get my ideas shot down just because they're new/different. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004161548.658dc459.michael.s.gilb...@gmail.com
Rescue Plan for apt-listbugs
Hi everybody, I need help. I am not a DD, nor a DM; nonetheless, I am one of the two current co-maintainers of apt-listbugs. The other one is Ryan Niebur. My problem is that I've lost contact with him: he seems to be currently (almost) MIA. It seems that I am not the only one: http://lists.debian.org/debian-devel/2010/08/msg00468.html http://lists.debian.org/debian-devel/2010/08/msg00482.html Please read the following bug report that I myself had to open against our own package, in order to try to get in touch with him again: http://bugs.debian.org/588636 Please note the dates of the various messages... :-( Ryan seems to have been unable to perform Debian-related work for quite some time (even though he does not seem to have been completely off-line). Now I am short of ideas on how to proceed: I would like to take over the maintenance of apt-listbugs (possibly with help from someone else, see below) and get direct push access to its public git repository on alioth. As I said on http://bugs.debian.org/588636#39 , I requested to join the alioth apt-listbugs project, but got no reply from any of the project members. Any suggestions on how I should proceed? Also, could someone please review the proposed git work-flow and tell me if it is OK? Finally, I would like to find someone else who could co-maintain the package with me: I usually manage to deal with bug reports and go ahead with developing work by myself, but I sometimes need help on Ruby (I am not yet the Ruby expert I would dream to be!) or on packaging techniques (I am still learning!). Any volunteer? Thanks in advance for your time! -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp94eg7oWqNy.pgp Description: PGP signature
Re: Rescue Plan for apt-listbugs
On Mon, 4 Oct 2010 23:29:28 +0200 Francesco Poli wrote: Hi everybody, [...] I forgot to add that I am not subscribed to debian-mentors or to debian-ruby: hence, please Cc: me on replies. Thanks again. -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpOeT4QQNSOR.pgp Description: PGP signature
RFS: ripit, a textbased audio CD ripper (updated package) 2nd attempt
Dear mentors, I am looking once again for a sponsor for the new version 3.9.0-1 of my package ripit. It should be uploaded to experimental, please. It builds these binary packages: ripit - Textbased audio CD ripper The package appears to be lintian clean. The upload would fix these bugs: 555701, 568685, 575634, 575642, 590946 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/ripit - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/ripit/ripit_3.9.0-1.dsc RFS on m.d.n doesn*t seem to work as the old version 3.8.0 resided 3 months at the repository without uploading. For me it is difficult to find out why no one uploads the package. There is no response in any direction, though. I would be glad if someone uploaded this package for me. Kind regards Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004212910.ga8...@samweis.home.lxtec.de
Re: RFS: matrixssl
Hi please keep the discussion on the list. Dne Mon, 04 Oct 2010 16:45:32 -0400 z...@gnu.org napsal(a): Michal Čihař ni...@debian.org writes: Hi! It would be great if you've mentioned some other details in the RFS email - It is new package? Are you adopting it? What is your motivation to take care of this package? Does the upload fix any bugs? No this package isn't new, in fact exist a previous version 1.8.8 which the current maintainer ask for someone to maintain, I'm responding to that bug 544057[1]. I want this package to be updated in Debian because I just finish the ssl plugin for the monkey http daemon project and it will use this version of matrixssl since the current (1.8.8) doesn't work so well. Great, it would be nice to know this in first email. Quick look at the package: 1. It is orphaned package, you seem to want to addopt it, so why your latest changelog entry mentions NMU? This it's the funny part, I had some troubles trying to understand what's the NMU didn't find a place to understand and then fix this issue. See http://www.debian.org/doc/developers-reference/pkgs.html#nmu. 2. This seems to be quite major version update, are you sure you want to upload this to unstable in freeze? What do you mean with unstable in freeze? If you think that it should be in other place just tell me and we will put it in other place. Generally uploading new library version to unstable while freeze is not a good idea. See freeze announcement for more details - http://lists.debian.org/debian-devel-announce/2010/08/msg0.html. 3. You dropped dietlibc support without single mention in changelog/NEWS Didn't know if you should mention that or where mention it, maybe I should not drop the support, whats your thoughts about it? I have no idea whether it was used or not, but it seems like some major feature removal, so it would deserve at least note in changelog or NEWS, see http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-news-debian. 4. Manually creating postinst/postrm is really not needed, just use debhelper. Ok, I'll take a more deep look on all the tools of debhelper maybe I missed something. 5. Why is there another tarball and debian directory in .orig.tar.gz? Please check how the source package should look like. I was running a command to generate de .origin.tar.gz maybe I forgot some option to run, I'll check more about that You don't need to generate orig.tar.gz, that should be just renamed upstream tarball. 6. Ever heard about lintian? I: matrixssl source: binary-control-field-duplicates-source field section in package libmatrixssl3.1 I: matrixssl source: duplicate-long-description libmatrixssl3.1-dev libmatrixssl3.1 libmatrixssl3.1-doc I: matrixssl source: missing-debian-source-format W: matrixssl source: changelog-should-not-mention-nmu I: matrixssl source: debian-watch-file-is-missing Of course, but I didn't saw those problems, can you send me the options I should use ? The I: warnings are generated by passing -I option to lintian. They are usually good things to fix, but not necessarily a bugs. I sent a RFS a few weeks ago with more details I think[2], thanks for you fast answer, [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544057 [2] http://lists.debian.org/debian-mentors/2010/09/msg00175.html -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Review of gnome-gmail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010-09-25 15:28, David Steele wrote:
Dear mentors,
I am looking for a sponsor for my package gnome-gmail.
* Package name: gnome-gmail
Version : 1.6-3
Upstream Author : David Steele da...@users.sourceforge.net
* URL : http://gnome-gmail.sourceforge.net/
* License : GPL
Section : gnome
Language : Python
It builds these binary packages:
gnome-gmail- Add Gmail support to GNOME
The package appears to be lintian clean.
The upload would fix these bugs: 597903
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gnome-gmail/
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/g/gnome-gmail/gnome-gmail_1.6-3.dsc
Gnome Gmail adds support for the Gmail web client as a GNOME Preferred
Application for email. Once selected, mailto links, Nautilus Send
File commands, Open Office Send Document commands, etc, will cause
an appropriate Gmail window to open in your default browser.
You can read more about Gnome Gmail from the following Press coverage:
Lifehacker -
http://lifehacker.com/5493654/gnome-gmail-tightly-integrates-gmail-into-linux-desktops
Linux Magazine Online -
http://www.linux-magazine.com/content/view/full/42375
Sourceforge Blog - http://sourceforge.net/blog/gnome-gmail-made-simple/
Thanks for your assistance
Hi
(Sorry for the double mail - I forgot to send it to the mentor list as
well so others could see it had been answered)
Thanks for your interest in Debian. It looks like you have not received
any feedback on nor found a sponsor for your package yet. I have spent
some time reviewing your package and got a few comments for you, which I
hope you find useful.
Please note that I am not a Debian Developer (DD), so I cannot sponsor
your package even if you address all my comments/remarks. Also neither
python nor GNOME is my strong suit, so there are possibly some
python/GNOME specific things that I have missed in my review.
On a related note have you considered contacting/joining the Debian
GNOME or the Debian Python Apps team? These teams may be a better source
for help with your package and possibly also sponsors for your package.
Also you may want to read [1] if you have not already done so; there are
talks about how to improve the current RFS template and what some
mentors look for/would like to see in an RFS.
Anyhow; my review:
d/watch:
- Contains a lot of unused comments (left overs from dh_make)
d/rules:
- lots of unused comments (looks like left overs from dh_make)
- Consider using either dh $@ (a.k.a. the dh7 method or tiny rules)
or cdbs. These tools can handle your entire build without any
override targets/modification to their default setup/run.
This would also remove a warning during the build [2].
- Even if you do not use dh7 or cdbs you should clean up your
d/rules files. As an example, there is nothing to do in the
binary-arch target.
Note: if you are joining a team, the team may have a helper tool
preference or a build style. In that case you probably want to stick
with the build styles preferred by the team.
d/control:
- ${shlibs:Depends} does not make sense for arch: all packages.
It finds arch dependent dependencies for native shared libraries.
- The Description (and possibly the Synopsis) needs improvement.
It might be a help to have a look at [3].
d/changelog:
- You have multiple revisions in your changelog, but this package has
not been released into Debian. Consider merging it into a single
entry[4].
Note there is no reason to repeat the closes for the
same bug (see man dpkg-buildpackage/dpkg-genchanges about the -v
flag for more information). Though if you need the package built
with the -v flag be sure to mention this in your RFS, so that your
sponsor is aware of it.
d/copyright:
- Looks like a mix of freestyle and the DEP-5 machine readable
format.
Either of those formats are acceptable, but the mix appears a bit
weird for me. I would recommend you choose either of the formats
and stick to it.
- You have claimed copyright for the year 2009, but there is no
mention of copyright in the upstream files except for
gnomemail.glade, which claims copyright for the year 2010 (about 200
lines into the file).
I am not sure if that single copyright mention in gnomemail.glade is
enough for the FTP-masters. Optimally you would write your copyright
statement plus the license header in all your source files.
- There is no explicit mention of allowing the GPLv2 or later in your
upstream pacakge as far as I can tell. COPYING only contains GPLv2
and none of the source file seems to carry an explicit license.
Note: The How to apply GPL v2 to your program example in COPYING
is not a
Re: Four days
On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert michael.s.gilb...@gmail.com wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktincphouthsaqb3qdptpmtda+mejl32afccpm...@mail.gmail.com
RFS: pipemeter
Dear mentors, I am looking for a sponsor for my package pipemeter. * Package name: pipemeter Version : 1.1.3-1 Upstream Author : Me, Clint Byrum cl...@ubuntu.com * URL : https://launchpad.net/pipemeter , http://spamaps.org/pipemeter.php * License : GPL-2+ Section : admin It builds these binary packages: pipemeter - cli utility that shows the speed of data moving from input to out The package appears to be lintian clean. The upload would fix these bugs: 599134 My motivation for maintaining this package is: I wrote pipemeter a few years ago and there are many users. It is a lightweight alternative to 'pv'. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pipemeter - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pipemeter/pipemeter_1.1.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards Clint Byrum -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86867cb8-7ee1-4f44-9f0e-d56b7f3af...@ubuntu.com
Re: RFS: pgfouine (updated package)
On Sun, Oct 03, 2010 at 10:59:51PM -0500, Luis Uribe wrote: I am looking for a sponsor for the new version 1.2-2 of my package pgfouine. The package is really, *really* not Lintian clean, and claiming otherwise in the RFS was bad form. All those CVS dirs in the resulting package definitely need gutting, and you'll want to look into why geshi is still getting installed in the package, given that it appears to be correctly depended on. Apart from that, though, it builds, installs, and runs pgfouine --help, so you're over most of the big humps. - Matt signature.asc Description: Digital signature
Re: Four days
On Mon, 4 Oct 2010 17:37:19 -0700 PJ Weisberg wrote: On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. OK, I see the attempt at irony now; although that really misses my original idea, which is to revamp the mentoring process with more of a team-based focus. Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004223224.99c46338.michael.s.gilb...@gmail.com
Re: Four days
On Mon, Oct 04, 2010 at 10:32:24PM -0400, Michael Gilbert wrote: On Mon, 4 Oct 2010 17:37:19 -0700 PJ Weisberg wrote: On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. OK, I see the attempt at irony now; although that really misses my original idea, which is to revamp the mentoring process with more of a team-based focus. On the contrary; what is different about a team of people within Debian who wish to assist and mentor potential new developers, as opposed to the membership of the debian-mentors mailing list? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005025209.gj32...@hezmatt.org
Re: RFS: pipemeter
Hi, On Tue, Oct 5, 2010 at 9:03 AM, Clint Byrum cl...@ubuntu.com wrote: Dear mentors, I am looking for a sponsor for my package pipemeter. A few notes: debian/README.source is a template file, fill it or just delete it. debian/rules has template comments that can be safely removed. debian/patches/debian-changes-1.1.3-1 replaces expanded $Id$ tag with unexpanded $Id$ tag. It seems you weren't generating the source package from original tarball? What is the results.txt in the docs for? Needs better short and long description. What is the input and output? Form the description I can't figure out it's a utility to show the meter of data passing through the pipe. pv is a good example for the descriptions :) Cheers, Kanru -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikm6=89vajsozkspqva8c9_kdc+fg_0bwe2s...@mail.gmail.com
Re: Four days
On Tue, 5 Oct 2010 13:52:09 +1100 Matthew Palmer wrote: On Mon, Oct 04, 2010 at 10:32:24PM -0400, Michael Gilbert wrote: On Mon, 4 Oct 2010 17:37:19 -0700 PJ Weisberg wrote: On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. OK, I see the attempt at irony now; although that really misses my original idea, which is to revamp the mentoring process with more of a team-based focus. On the contrary; what is different about a team of people within Debian who wish to assist and mentor potential new developers, as opposed to the membership of the debian-mentors mailing list? A lot. The current process is individualized mentorship, not team mentorship. Again, there are two new ideas that I am suggesting. One is to use the mentors mailing list as the maintainer for mentee packages. That way the burden of quickly orphaned packages is dispersed over the whole set of mentors rather than just one. Perhaps that will encourage more DD participation since they won't stick themselves with a lot of orphaned packages. The other idea is to reduce DD involvement in the mentoring process itself by making mentees more responsible for themselves. Take a set of mentees, have them work together to get their packages in shape, then maybe once a month (or every couple weeks) have them show the set of packages that they have ready to the mentors list. That would also reduce RFS traffic on this list. This list would become more of a coordination point for joining mentee teams. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005001436.62abce94.michael.s.gilb...@gmail.com
Re: Four days
Michael Gilbert michael.s.gilb...@gmail.com writes: A lot. The current process is individualized mentorship, not team mentorship. How so? Anyone can provide input on a question asked here, and frequently a question will get a team of mentors descending to mentor the querent. You might be talking, not about mentors, but about *sponsorship*. Yes, of course there needs to be some individual sponsoring a particular release for upload into Debian. But sponsoring is done per release per package. That's not the mentorship process, which happens in the open, in a team environment, here in discussions in this forum. One is to use the mentors mailing list as the maintainer for mentee packages. With this wording it's becoming clear that you don't mean “mentor”, but rather mean “sponsor”. I'll proceed on that basis. That way the burden of quickly orphaned packages is dispersed over the whole set of mentors rather than just one. I think it's a mistake to make a mailing list take on the role of sponsor; not everyone on this list is in a position to sponsor packages (I am not), and you get the problem that responsibility for sponsorship would be diluted. Teams should form around areas of interest and expertise in a particular kind of package. I don't think there's a useful expertise of “packages maintained by people who aren't yet Debian members”, so it's not sensible to make such a team. So I don't think a “team sponsor” would be a good idea. Rather, if packages deserve team maintenance or not, that's orthogonal to whether the package needs its releases sponsored into Debian. The other idea is to reduce DD involvement in the mentoring process itself by making mentees more responsible for themselves. Take a set of mentees, have them work together to get their packages in shape, then maybe once a month (or every couple weeks) have them show the set of packages that they have ready to the mentors list. That would also reduce RFS traffic on this list. This list would become more of a coordination point for joining mentee teams. That doesn't need a separate forum though; people already come here to ‘debian-mentors’ as a forum to ask advice about packaging, and they do in fact get that advice, from Debian members and non-members alike. I agree that advice should be sought much more commonly before the RFS is sent; I think this forum is already good for that purpose. How do you propose encouraging that behaviour, though? -- \ “For every complex problem, there is a solution that is simple, | `\ neat, and wrong.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762xhz1ft@benfinney.id.au
Re: Four days
On Tue, Oct 05, 2010 at 12:14:36AM -0400, Michael Gilbert wrote: On Tue, 5 Oct 2010 13:52:09 +1100 Matthew Palmer wrote: On Mon, Oct 04, 2010 at 10:32:24PM -0400, Michael Gilbert wrote: On Mon, 4 Oct 2010 17:37:19 -0700 PJ Weisberg wrote: On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. OK, I see the attempt at irony now; although that really misses my original idea, which is to revamp the mentoring process with more of a team-based focus. On the contrary; what is different about a team of people within Debian who wish to assist and mentor potential new developers, as opposed to the membership of the debian-mentors mailing list? A lot. The current process is individualized mentorship, not team mentorship.??? Not to my knowledge. Whilst some new maintainers may have an invitation from certain DDs to e-mail them privately with their questions, in general the intended process is that questions are asked on this mailing list, and answers are given and discussed by anyone who feels qualified to answer -- DD, DM, mentee, or interested bystander. One is to use the mentors mailing list as the maintainer for mentee packages. That way the burden of quickly orphaned packages is dispersed over the whole set of mentors rather than just one. Perhaps that will encourage more DD participation since they won't stick themselves with a lot of orphaned packages. To clarify: the intended point of this proposal is to solve the perceived problem that DDs don't sponsor packages because they're concerned that they'll end up taking responsibility for a package if the maintainer ups and leaves? I don't actually see that as a problem. There are simple ways to deal with orphaned packages, regardless of the way the upload was made, and they work. If a package I sponsor is abandoned by the maintainer, it gets NMUed, orphaned and assigned to debian-qa like any other, and is then available for adoption. The variant of this problem I do see, however, is the uploading of surely-soon-to-be-unmaintained low-quality or near-duplicate packages, clogging up the archive and making extra work for debian-qa et al. *That* problem isn't going to be solved by changing the maintainer, it's only going to be solved by not uploading the surely-soon-to-be-unmaintained low-quality or near-duplicate packages in the first place. On a practical point, making d-mentors the maintainer would clog the list with large quantities of (mostly) bug-related e-mail, a la debian-boot, making the list far worse for discussion. However a separate mailing list could be created to avoid that problem (at the cost of requiring people to subscribe to the other list, splitting attention, etc). The other idea is to reduce DD involvement in the mentoring process itself by making mentees more responsible for themselves. Take a set of mentees, have them work together to get their packages in shape, then maybe once a month (or every couple weeks) have them show the set of packages that they have ready to the mentors list. That would also reduce RFS traffic on this list. This list would become more of a coordination point for joining mentee teams. There's nothing stopping that from happening now on this list. I don't see that batching RFSes is going to either (a) reduce RFS traffic (because nothing's stopping people from still posting them here, and even the batch will have to be sent out some time), or (b) improve sponsorship rates (in fact it'd probably decrease them, because checking 1 package a day every day is far less daunting than checking 14 packages once a fortnight). However, if you want to give it a go, don't let me (or anyone else) stop you. Take Asheesh's lead and just start something, don't ask or wait for official endorsement of your idea, because it will never come. Do it, and if it works it'll catch on, and if it doesn't then... try something else. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005053037.gk32...@hezmatt.org
Re: RFS: pipemeter
On Oct 4, 2010, at 8:41 PM, Kan-Ru Chen wrote: Hi, Hello Kan-Ru, thanks so much for looking at it so quickly! I've uploaded a version with some changes.. see below.. On Tue, Oct 5, 2010 at 9:03 AM, Clint Byrum cl...@ubuntu.com wrote: Dear mentors, I am looking for a sponsor for my package pipemeter. A few notes: debian/README.source is a template file, fill it or just delete it. Removed. debian/rules has template comments that can be safely removed. Comments removed, though I left the comment above DH_VERBOSE as it is a useful reminder. :) debian/patches/debian-changes-1.1.3-1 replaces expanded $Id$ tag with unexpanded $Id$ tag. It seems you weren't generating the source package from original tarball? Indeed, I had imported it into bzr where I used bzr builddeb. I've added a .bzr/rules file to fix that and re-imported the files from orig source. What is the results.txt in the docs for? It was something I used early on to gauge the performance of pipemeter on various platforms. dh_make must have picked it up. I've removed it from debian/docs. Needs better short and long description. What is the input and output? Form the description I can't figure out it's a utility to show the meter of data passing through the pipe. pv is a good example for the descriptions :) Updated. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f1b92716-b396-4def-9c02-0c9c36776...@ubuntu.com
