Re: Paths into Debian
Moray Allan said: - Whether/how it would be useful to promote more local Debian groups I didn't see the Local Groups page mentioned. https://wiki.debian.org/LocalGroups I attended at least one of the group meetings more than 10 years ago, but the group is no longer active and I am not longer in the area. Chuck -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131002034918.gn25...@xen.axs.org
Press path (Re: Paths into Debian)
Hi Daniel, On 2013-09-22 06:46, Daniel Pocock wrote: [...] On 29/08/13 20:39, Filipus Klutiero wrote: It also briefly mentions the fundraising path and the press path, which are rarely directly accessible for newcomers. Your talk shows improvements which could be done to our roads and to our maps: http://www.debian.org/intro/help http://www.debian.org/devel/join/ http://www.debian.org/devel/join/newmaint The press path has some risk associated with it Look at the Jayme Diaz video to see an extreme example of the press cutting someone to pieces. Each path has some associated risk. I'm not sure what parallel can be drawn between the video and Debian. Debian doesn't have interviewers (officially anyway). If you mean that Debian contributors could make mistakes when being interviewed, live interviews are rare, usually with the DPL or some veteran contributor, not with the kind of people we mean when discussing paths into Debian. The only way to deal with that is to either have people who know their topic inside out (e.g. because of long time Debian/free software involvement) or engaging experienced media handlers. The risk I do see in the press path is a contributor releasing an incorrect or otherwise damaging piece of information. But this is not something really hard to deal with. Minimal PR reviewing guidelines were suggested on the debian-publicity mailing list a couple of years ago. -- Filipus Klutiero http://www.philippecloutier.com -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5248913c.3010...@gmail.com
Re: Paths into Debian
On 25/09/13 11:51, Thijs Kinkhorst wrote: On Tue, September 24, 2013 14:02, Stefano Zacchiroli wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). I would name it after what you want it to signal. If it wants to signal starting points for new contributors at entry level, then startingpoint, newcontributor or entrylevel could be good choices that leave not much to interpretation. My feeling is that newcontributor or startingpoint is a message that is essentially derived from the fact that the bug is somewhat self-contained or easy to resolve. A strong solution would probably make some low level classification (e.g. java+beginner or whatever) and then some portal for new contributions could be constructed that has links to various reports that will help them. E.g. the portal would try to help people rate themselves a) preferred one or two programming languages, b) years of experience, c) career level (student, graduate, professional, hacker) d) packages (or sections) they are interested in (e.g. science, finance, networking) and from there it would prepare a bug search query using some assortment of tags that will reveal discrete tasks they can complete. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52489493.3010...@pocock.com.au
ITS gift tag and specifying requirements in tickets (Re: Paths into Debian)
Lucas Nussbaum wrote: On 24/09/13 at 08:37 +0200, Thijs Kinkhorst wrote: On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote: Did you tag them 'gift'? https://wiki.debian.org/qa.debian.org/GiftTag This may just be me, as it's very personal, and no offense intended at you, but I really detest the name 'gift' of that tag and that prevents me from using it. Tagging something 'gift' gives me a really condescending association, where the Big Maintainer has been so kind to hand out a 'gift' of doing work to the little newbie who should be grateful to receive it. Because these are the connotations of the word gift to me: that people should feel happy to receive it, while actually we should be happy if people do work for the project. Yeah, the 'gift' name was intended the other way around: make a gift to Debian. With such a definition, it seems every ticket should be tagged gift. I realize this is absolutely not your intention in naming this tag and also that it's highly subjective matter. I'm raising it only because it prevents me from using it. If it's just me, than that's that. We could try to tune documentation into either clarifying the 'gift' name, or diminishing its importance (by hiding the name where it's not strictly needed). Whether or not the gift name can make sense in some way, I agree the name should be avoided. But I'd suggest to consider solutions other than renaming. The gift tag appears to convey 2 or 3 pieces of information: 1. The change required is not too difficult 2. Someone can coach whoever wants to do the change and has volunteered 3. Perhaps, the change is interesting (not trivial) The second objective might be achieved better with a field listing volunteers who are interested in mentoring whoever wants to work on a fix. A Resource persons field with email addresses, maybe. Points 1 and 3 could be achieved with a field indicating the difficulty of solving the ticket. Specifying a difficulty for tickets was discussed in #704874 as data instrumental to ticket prioritization. It should be noted that in #704874, difficulty is essentially synonym to the time needed to implement a fix. Another definition of difficulty would be how much skills one needs to tackle a solution. Clearly, there is correlation between these 2 definitions. But they aren't the same. Some changes may require following a simple method, but they can be costly if a lot of code needs to be examined. The small and bitesized suggestions from others make me think about the first definition (cost), not about the kind of difficulty which the gift tag seems to be interested in. A rather simple way to specify requirements could be to quantify the time needed for solving and to separately say how skilled an interested contributor would need to be. #234567 needs 1 hour from a contributor with medium skills, say. Obviously, such a system would be imperfect. Someone with high skills may be able to solve in, say, just 40 minutes. Or, someone with low skills could have to start by spending an hour learning, but still manage to solve after. Moreover, quantifying someone's Debian development skills in a simple scale going from lowest to highest is quite simplistic. Just see SourceForge's developer profiles to see how granular skills can be made. In addition to the intrinsic difficulty of specifying requirements, we must consider that the exact skills needed to solve an issue are sometimes not well known in advance, and that time spent specifying required skills is costly. With all these difficulties, I think it would be wise to try finding inspiration in how other ITS-s specify requirements (those I know don't). I wish a solution could also get rid of the help tag, although we'd first need to agree on what that one means. If it means maintainers don't have enough time, shouldn't maintainers rather file an RFH (or find some other way to attribute that information directly to the package)? If it means a change would take too much time for them or require too much skills, then the fields discussed above appear to be less relative solutions. If it means a change is important, an importance field as discussed in #704874 would be more meaningful. -- Filipus Klutiero http://www.philippecloutier.com
Re: Paths into Debian
On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote: Did you tag them 'gift'? https://wiki.debian.org/qa.debian.org/GiftTag This may just be me, as it's very personal, and no offense intended at you, but I really detest the name 'gift' of that tag and that prevents me from using it. Tagging something 'gift' gives me a really condescending association, where the Big Maintainer has been so kind to hand out a 'gift' of doing work to the little newbie who should be grateful to receive it. Because these are the connotations of the word gift to me: that people should feel happy to receive it, while actually we should be happy if people do work for the project. I realize this is absolutely not your intention in naming this tag and also that it's highly subjective matter. I'm raising it only because it prevents me from using it. If it's just me, than that's that. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/491fcd683b50d2f0d8aa866bd90d4655.squir...@aphrodite.kinkhorst.nl
Re: Paths into Debian
On Sep 24, 2013 2:37 AM, Thijs Kinkhorst th...@debian.org wrote: On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote: Did you tag them 'gift'? https://wiki.debian.org/qa.debian.org/GiftTag This may just be me, as it's very personal, and no offense intended at you, but I really detest the name 'gift' of that tag and that prevents me from using it. Tagging something 'gift' gives me a really condescending association, where the Big Maintainer has been so kind to hand out a 'gift' of doing work to the little newbie who should be grateful to receive it. Because these are the connotations of the word gift to me: that people should feel happy to receive it, while actually we should be happy if people do work for the project. I realize this is absolutely not your intention in naming this tag and also that it's highly subjective matter. I'm raising it only because it prevents me from using it. If it's just me, than that's that. Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. T Cheers, Thijs -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/491fcd683b50d2f0d8aa866bd90d4655.squir...@aphrodite.kinkhorst.nl
Re: Paths into Debian
On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Paths into Debian
On 24/09/13 at 08:37 +0200, Thijs Kinkhorst wrote: On Mon, September 23, 2013 14:46, Lucas Nussbaum wrote: Did you tag them 'gift'? https://wiki.debian.org/qa.debian.org/GiftTag This may just be me, as it's very personal, and no offense intended at you, but I really detest the name 'gift' of that tag and that prevents me from using it. Tagging something 'gift' gives me a really condescending association, where the Big Maintainer has been so kind to hand out a 'gift' of doing work to the little newbie who should be grateful to receive it. Because these are the connotations of the word gift to me: that people should feel happy to receive it, while actually we should be happy if people do work for the project. Yeah, the 'gift' name was intended the other way around: make a gift to Debian. But I see how it can be misunderstood. I realize this is absolutely not your intention in naming this tag and also that it's highly subjective matter. I'm raising it only because it prevents me from using it. If it's just me, than that's that. We could try to tune documentation into either clarifying the 'gift' name, or diminishing its importance (by hiding the name where it's not strictly needed). Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130924115758.ga8...@xanadu.blop.info
Re: Paths into Debian
On Sep 24, 2013 8:03 AM, Stefano Zacchiroli z...@debian.org wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). I don't want to give the wrong impression - I'll still use the chosen tag, but if I'm to play the Umarell, I'd be most likely to use bitesize Seriously, I don't want to get between work getting done, though. T Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Re: Paths into Debian
debian-love? :P On 24/09/13 14:02, Stefano Zacchiroli wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). Cheers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52417ff5.70...@qindel.com
Re: Paths into Debian
On 24/09/13 14:09, Paul Tagliamonte wrote: On Sep 24, 2013 8:03 AM, Stefano Zacchiroli z...@debian.org mailto:z...@debian.org wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). I don't want to give the wrong impression - I'll still use the chosen tag, but if I'm to play the Umarell, I'd be most likely to use bitesize Seriously, I don't want to get between work getting done, though. However people feel about gift, there is also the jargon factor. For newcomers, jargon is a barrier and potential time waster Can we use a word that is neutral and obvious? Maybe trivial-to-fix or something like that?
Re: Paths into Debian
Btw, i didnt exaclty came up with debian-love myself https://wiki.gnome.org/GnomeLove On 24/09/13 14:05, Alberto Fuentes wrote: debian-love? :P On 24/09/13 14:02, Stefano Zacchiroli wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). Cheers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52419641.4050...@qindel.com
Re: Paths into Debian
On 24/09/13 at 14:46 +0200, Daniel Pocock wrote: On 24/09/13 14:09, Paul Tagliamonte wrote: On Sep 24, 2013 8:03 AM, Stefano Zacchiroli z...@debian.org mailto:z...@debian.org wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). I don't want to give the wrong impression - I'll still use the chosen tag, but if I'm to play the Umarell, I'd be most likely to use bitesize Seriously, I don't want to get between work getting done, though. However people feel about gift, there is also the jargon factor. For newcomers, jargon is a barrier and potential time waster Can we use a word that is neutral and obvious? Maybe trivial-to-fix or something like that? Wouldn't new contributors feel bad if they can't fix a trivial-to-fix bug? I think that if we change the name because 'gift' sends a wrong message, it would be better to change to something that doesn't try to convey a message, like suitable-for-new-contributors, or new-contributors. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130924144118.gb19...@xanadu.blop.info
Re: Paths into Debian
On 24/09/13 16:41, Lucas Nussbaum wrote: On 24/09/13 at 14:46 +0200, Daniel Pocock wrote: On 24/09/13 14:09, Paul Tagliamonte wrote: On Sep 24, 2013 8:03 AM, Stefano Zacchiroli z...@debian.org mailto:z...@debian.org wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). I don't want to give the wrong impression - I'll still use the chosen tag, but if I'm to play the Umarell, I'd be most likely to use bitesize Seriously, I don't want to get between work getting done, though. However people feel about gift, there is also the jargon factor. For newcomers, jargon is a barrier and potential time waster Can we use a word that is neutral and obvious? Maybe trivial-to-fix or something like that? Wouldn't new contributors feel bad if they can't fix a trivial-to-fix bug? I think that if we change the name because 'gift' sends a wrong message, it would be better to change to something that doesn't try to convey a message, like suitable-for-new-contributors, or new-contributors. It is contextual as well What is trivial for an experienced Java programmer is not trivial to a Java beginner or somebody who only knows Python and C. My feeling is that a Java task marked trivial or whatever should be trivial for a Java beginner but it would not need to imply that it is trivial for somebody who knows Python. Maybe there could be tags such as java-bitesize or python-quickfix or c-trivial and in each case, it assumes the person attacking it has beginner level knowledge of the technology in question -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5241a857.1030...@pocock.com.au
Re: Paths into Debian
On 09/24/2013 05:41 PM, Lucas Nussbaum wrote: On 24/09/13 at 14:46 +0200, Daniel Pocock wrote: On 24/09/13 14:09, Paul Tagliamonte wrote: On Sep 24, 2013 8:03 AM, Stefano Zacchiroli z...@debian.org mailto:z...@debian.org wrote: On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote: Its not just you - while I appreciate using a word other than bitesized or low-hanging-fruit, I tend to get the same slightly off putting feeling about gift Not to bikeshead. So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). I don't want to give the wrong impression - I'll still use the chosen tag, but if I'm to play the Umarell, I'd be most likely to use bitesize Seriously, I don't want to get between work getting done, though. However people feel about gift, there is also the jargon factor. For newcomers, jargon is a barrier and potential time waster Can we use a word that is neutral and obvious? Maybe trivial-to-fix or something like that? Wouldn't new contributors feel bad if they can't fix a trivial-to-fix bug? I think that if we change the name because 'gift' sends a wrong message, it would be better to change to something that doesn't try to convey a message, like suitable-for-new-contributors, or new-contributors. Hi everyone! I've been following the topic for some time; IMHO the word should be something real, something that is, *literally*, what it claims to be. It would be far less confusing this way. I'd like to propose entry-level or any variation of it, or at least hear a reasonable argument favoring jargon terms. FWIW, I agree with Daniel on this one. But hey, any longer discussion on this particular terminology problem bears a high risk of bikeshedding! Let's be all aware of that. Cheers, -- . o . Victor Nițu . . o debian.org.ro o o o nightsh @OFTC 772B 3AD9 007D A980 330F BDCE 03EF 1B1B F206 F2FC -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5241a6c8.6040...@debian.org.ro
Re: Paths into Debian
On Tue, Sep 24, 2013 at 04:41:18PM +0200, Lucas Nussbaum wrote: On 24/09/13 at 14:46 +0200, Daniel Pocock wrote: Can we use a word that is neutral and obvious? Maybe trivial-to-fix or something like that? Wouldn't new contributors feel bad if they can't fix a trivial-to-fix bug? We could also assume that we are technoids and call it entry-point as a reference to way dynamic linking works. It seems to me that these bugs may be easy or may be hard, it depends a lot, but they are like the best way to get involved... Bye, Mt. -- If you can't do it in ANSI C, it isn't worth doing. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130924153134.gs3...@alphonse.loria.fr
Re: Paths into Debian
I think the original intent of gift was that fixing the bug would be a welcome and happy gift to the maintainer, rather than that the bug was a gift to the person fixing it from the maintainer. But I agree that doesn't come across all that clearly. Stefano Zacchiroli z...@debian.org writes: So, folks, what do you propose instead? :) If the chosen terminology send the wrong message, and hence it's potentially a blocker, let's change it (but better do it only *once*, hence the need of getting it right this time). We already have an existing help tag for bugs that the maintainer would like someone else to fix. As I understand it, the problem with using help for this purpose was that the help tag could be put on anything up to and including major rewrites, and the goal of this tag was to identify things that could be addressed by people new to the package. Given that, how about something based on the existing help tag, like help-small? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y56mkwrx@windlord.stanford.edu
Re: Paths into Debian
Hi, On 22/09/13 at 12:46 +0200, Daniel Pocock wrote: - I've started creating wishlist bugs in my packages, these provide useful coding tasks for people, especially students. They are particularly useful for GSoC applicants, because they need to demonstrate their coding skills during the selection process. Even maintainers who have no time to interact with GSoC or anything could still create such bugs and tag them in some way to provide entry points for people to start contributing. Did you tag them 'gift'? https://wiki.debian.org/qa.debian.org/GiftTag Tagging them 'gift' makes them get listed in how-can-i-help. - the github fork and pull request phenomenon. It is tremendously easy for people to contribute what they want. There has been some talk about getting something like Gerrit into Alioth, that may help us in that direction. Alternatively, maybe we should review the current process for one-shot patches. Assuming that someone wants to fix a typo in a package and submit it as a patch, the current simpler process is (TTBOMK): 1. 'debcheckout packagename' (but this fails when the package is not maintained in a VCS. maybe it should fallback to using 'apt-get source'?) 2. Build a source package, so that we can run nmudiff later: 'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S' (depending on the Vcs used.) 3. 'cd packagename' 4. make the change (which might involve adding a patch with dpkg-source --commit, depending on the source format version used) 5. dch --nmu; enter comment 6. build package (and test, obviously) 7. nmudiff There are lots of variations depending on whether the package is maintained in a VCS or not, on the source format version used, etc. Steps 1 and 2 could clearly be improved: - debcheckout could automatically build the source package - debcheckout could use gbp-clone instead of git clone, so that the local pristine-tar branch would be set up to track the remote pristine-tar branch. (a warning is displayed by git-buildpackage, though apparently a correct source tarball is generated, so maybe the warning is harmless and should not be displayed?) Additionally, the fact that one needs to think about the source format version used in step (4) makes things quite inconvenient (though I don't see how this could be fixed). Using nmudiff in step (7) is also a bit cumbersome if someone just wants to submit a patch. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130923124610.ga12...@xanadu.blop.info
Re: Paths into Debian
* Lucas Nussbaum lu...@debian.org, 2013-09-23, 14:46: Alternatively, maybe we should review the current process for one-shot patches. Assuming that someone wants to fix a typo in a package and submit it as a patch, the current simpler process is (TTBOMK): 1. 'debcheckout packagename' (but this fails when the package is not maintained in a VCS. maybe it should fallback to using 'apt-get source'?) 2. Build a source package, so that we can run nmudiff later: 'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S' (depending on the Vcs used.) If you don't fancy running untrusted code, point 2 is more like this: - Build the VCS checkout of the package using dpkg-buildpackage -S -nc. - Grab last version of the same package from the archive. - Run debdiff between the two *.dsc. - Start reading the diff. - Realize that the diff is flippin' huge. - Nuke the VCS checkout; use the version from the archive instead. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130923173128.ga5...@jwilk.net
Re: Paths into Debian
On 23/09/13 19:31, Jakub Wilk wrote: * Lucas Nussbaum lu...@debian.org, 2013-09-23, 14:46: Alternatively, maybe we should review the current process for one-shot patches. Assuming that someone wants to fix a typo in a package and submit it as a patch, the current simpler process is (TTBOMK): 1. 'debcheckout packagename' (but this fails when the package is not maintained in a VCS. maybe it should fallback to using 'apt-get source'?) 2. Build a source package, so that we can run nmudiff later: 'dpkg-buildpackage -us -uc -S' or 'git-buildpackage -us -uc -S' (depending on the Vcs used.) If you don't fancy running untrusted code, point 2 is more like this: - Build the VCS checkout of the package using dpkg-buildpackage -S -nc. - Grab last version of the same package from the archive. - Run debdiff between the two *.dsc. - Start reading the diff. - Realize that the diff is flippin' huge. - Nuke the VCS checkout; use the version from the archive instead. There are some other ways about it: - allow untested patch submission - for things like doc fixes, it would be nice if the maintainer could easily cherry pick such patches from the bug tracker next time he does a build, no need to expect every contributor to make a build for such things - use of CI (e.g. Jenkins) to try and build each contribution. People could then contribute patches (possibly cherry picked from upstream) and the maintainer could see whether the package builds successfully in Jenkins and if so, the maintainer just makes one click to accept it. This would be good for packages that are suitable for CI of course. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5240aee2.8080...@pocock.com.au
Re: Paths into Debian
Just a few of my own comments, mainly from interacting with GSoC students, although this could be just as applicable to anybody: - While people joining the NM process or the mentors list are aiming to have some package added, students don't always come with a clear idea of some package they want to create or maintain. Rather, they have an idea about the topic they want to work with (e.g. security, VoIP). - I've started creating wishlist bugs in my packages, these provide useful coding tasks for people, especially students. They are particularly useful for GSoC applicants, because they need to demonstrate their coding skills during the selection process. Even maintainers who have no time to interact with GSoC or anything could still create such bugs and tag them in some way to provide entry points for people to start contributing. - Maintainer lists (e.g. pkg-voip-maintainers) are full of automated notifications and may scare people away. More effort may be needed to separate discussion from other automated stuff. - the github fork and pull request phenomenon. It is tremendously easy for people to contribute what they want. There has been some talk about getting something like Gerrit into Alioth, that may help us in that direction. - Having a single VCS (e.g. Git or Mercurial and abolishing SVN, CVS) would also help reduce complexity of Alioth tool support and lower the learning curve for first-time contributors. On 29/08/13 20:39, Filipus Klutiero wrote: It also briefly mentions the fundraising path and the press path, which are rarely directly accessible for newcomers. Your talk shows improvements which could be done to our roads and to our maps: http://www.debian.org/intro/help http://www.debian.org/devel/join/ http://www.debian.org/devel/join/newmaint The press path has some risk associated with it Look at the Jayme Diaz video to see an extreme example of the press cutting someone to pieces. The only way to deal with that is to either have people who know their topic inside out (e.g. because of long time Debian/free software involvement) or engaging experienced media handlers. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523eca7d.2010...@pocock.com.au
Re: DebConf slides (was Re: Paths into Debian)
Hi, On Mittwoch, 28. August 2013, Moray Allan wrote: On 2013-08-28 13:36, Andreas Tille wrote: Thanks for the pointer. It seems there is currently no way to submit slides to Penta. I also uploaded my slides to my talks page and added a link to this in Penta. Is this something we should report or am I just missing something? Submitting slides works fine. But Penta isn't exporting them correctly, there's no content behind the generated links. Someone needs to fix this, yes. these someones are reachable at ad...@debconf.org cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Paths into Debian
to adopt, go say so on the ticket, upload a new version when the maintainer agrees, closing the ticket, and have fun. But we don't have an equivalent process for someone who would be willing to help packaging the radeon driver. Yet, packages not on WNPP are probably better options for starting the packaging path than packages on WNPP, as those not on WNPP should have a larger team ready to mentor the prospect (unless a package should be on WNPP but isn't because the maintainer is just MIA). On the other hand, a healthy package might be a worse option since it usually has more users, hence errors will have a greater impact. So basically, starting with a package on WNPP may be harder for the contributor, but starting with one not on WNPP may be less useful and safe for users. What can we do to encourage (or at least not discourage) prospects from helping with packages that matter? Which other distributions do better? More paths The first map listed above (/intro/help) has 11 items, most of which could be considered as paths. I find the first 2 points there very interesting. The first says people can test and/or report issues. This certainly constitutes a path (quality?). The second says people can help advise users (IRC, mailing lists). If we talk strictly about Debian development paths, support for users may not be a path, as this would at best indirectly contribute to Debian's improvement. However, in the metaphor I described, following a path means to improve yourself as a contributor, and people following the support path can definitely learn a lot about Debian while helping users. Then, if we jump a bit further to point 5 and 6, we see there's also a documentation path, either by writing or translating packaged documentation, or by contributing to a website such as the wiki or www.debian.org. I believe the people who are most likely to need driving directions are those with the least driving experience. Those who know the least on computer science, and particularly on free software. I also believe the quality path, the support path and the documentation path are particularly interesting for newcomers, as they offer some safe and accessible roads. A contributor simply travelling each of these roads could do a pretty nice Debian trip. Therefore, I believe our sourcing efforts should pay attention to these 3 paths (others are important too). I'd like to expand on them a bit. These paths are very interesting because in a sense they have absolutely no barrier to entry: 1. Quality: A user reporting an issue, perhaps for selfish reasons, will have to go through a number of tickets to make sure he's not reporting a duplicate. From there, it's very natural to comment on a ticket the user isn't experiencing, and then to find himself contributing to the package's tickets. 2. Support: A user asking a question on IRC will see other users asking while waiting for the answer to his own questions. If the user can answer someone else's question, it would be a shame not to - if you managed to ask a question on IRC, answering one shouldn't be difficult. From there, it's very natural to stay and answer a few more questions... 3. Documentation: A user following a howto on the wiki notices a typo. If the user is familiar with wikis, fixing it is about 2 clicks and a keystroke away. In these cases, one can go from user to contributor in one minute (perhaps ignoring wiki registration here). However, these paths are also imperfect. As our projects ages, our infrastructure does too. 1. Our 20th-century ITS has no web-based edition capability. Adding information to a ticket is quite easy, and opening one isn't difficult, but there's a certain barrier to go beyond. 2. We have no forums nor any system designed specifically for support. 1. Support mailing lists have been going down for a long time while support has mostly moved to unofficial channels. 2. Even IRC isn't in great shape, with our forces still split on 2 networks years after the move to OFTC (which is poorly managed). FWIW, I found myself in a discussion on another project's usage of IRC for user support, already a couple of years ago. Although IRC is certainly not perfect, I was arguing that nothing could match its efficiency (or IM's efficiency) from the contributor point of view. Those who brought up the topic said other media (they were thinking web stuff) could attract more users (which is supposed to be a good thing ;-) ). If I go really deep in my memories, I think I may relate to that. It could be that people new to free software will find IRC intimidating. Idea: add a screenshot of someone asking on #debian to our support page? 3. Our web documentation is split between www.debian.org and the wiki. 2 technologies, quite some redundancy. The wiki is newer, but goes back to 2001. In both cases, history has let us with serious licensing issues, particularly on the wiki. While the wiki
Re: Paths into Debian
Hi Moray, On Fri, Aug 23, 2013 at 08:59:24PM +0100, Moray Allan wrote: At DebConf13 I was interested to hear people's views in the discussion session on Paths into Debian. The video of the session is available here: http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/999_Paths_into_Debian.ogv http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/999_Paths_into_Debian.ogv I have also put up a copy of my introductory slides, though they really just contain headings for what I said/for discussion, rather than much content: http://people.debian.org/~moray/paths-into-debian.pdf Thanks for the pointer. It seems there is currently no way to submit slides to Penta. I also uploaded my slides to my talks page and added a link to this in Penta. Is this something we should report or am I just missing something? The two points that seemed to gather most potential volunteers were improving the Debian website pages about how to contribute, and encouraging more local Debian meetings -- I hope that some of the apparent enthusiasm on these points can now be channelled into productive action! +1 Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130828123621.gl31...@an3as.eu
DebConf slides (was Re: Paths into Debian)
On 2013-08-28 13:36, Andreas Tille wrote: Thanks for the pointer. It seems there is currently no way to submit slides to Penta. I also uploaded my slides to my talks page and added a link to this in Penta. Is this something we should report or am I just missing something? Submitting slides works fine. But Penta isn't exporting them correctly, there's no content behind the generated links. Someone needs to fix this, yes. -- Moray -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/056bcffefa66b18386488f504b587...@www.morayallan.com
Paths into Debian / local groups
Hi, As Moray pointed out in a previous post [1] we would like to encourage more local user groups. This is to provide personal contact to Debian people. Because during the Paths into Debian session one of the impressions was it would be easier for people who wants to join if they had personal contact. There is already a wiki page [2] but looking into the page history a good few entries seem to be quite outdated. So I'll contact the localGroup owner and see if they are still valid. But if you meet up regularly/irregularly (though regular would be better), could you let me know (on/off list) and I'll update the wiki or add the required entry. Cheers, Christian [1] http://lists.debian.org/debian-project/2013/08/msg00053.html [2] https://wiki.debian.org/LocalGroups -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5219ea86.9070...@ps-xaf.de
Re: Paths into Debian
Hi Jose, Quoting Jose Luis Rivas (2013-08-24 02:34:28) I think we have missed opportunities to bring more people into Debian like not taking enough attention into support Raspberry Pi. [snip] That may seem a constructive point, but please read https://wiki.debian.org/RaspberryPi before continuing. As well as not adapting easily enough to how other people does stuff. We all love APT, but is not the only way to do stuff. Some communities like the Node.js handles their own packages in a different way [snip] Debian includes a slew of local package managers, for users wanting Debian only as core system, with different package management on top. I suspect your issues with Node.js instead are tied to Node.js and NPM not shipped with Wheezy and lacking behind even in testing/unstable. Those issues are IMO off topic for this thread. - 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: Paths into Debian
On 8/24/13 5:03 AM, Jonas Smedegaard wrote: Hi Jose, Quoting Jose Luis Rivas (2013-08-24 02:34:28) I think we have missed opportunities to bring more people into Debian like not taking enough attention into support Raspberry Pi. [snip] That may seem a constructive point, but please read https://wiki.debian.org/RaspberryPi before continuing. I got that. And I think you did too. Thousands of hackers are using it and if Raspbian has been so easy to get into it, why not Debian directly? We are in need of more contributors, after all. And there are more chances of getting someone to code something into Debian if they are using a Raspberry than an x86. We should support them. As well as not adapting easily enough to how other people does stuff. We all love APT, but is not the only way to do stuff. Some communities like the Node.js handles their own packages in a different way [snip] Debian includes a slew of local package managers, for users wanting Debian only as core system, with different package management on top. I suspect your issues with Node.js instead are tied to Node.js and NPM not shipped with Wheezy and lacking behind even in testing/unstable. Those issues are IMO off topic for this thread. Indeed, they are and as you suspected. -- Jose Luis Rivas http://joseluisrivas.net/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52188423.7040...@gmail.com
Paths into Debian
At DebConf13 I was interested to hear people's views in the discussion session on Paths into Debian. The video of the session is available here: http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/999_Paths_into_Debian.ogv http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/999_Paths_into_Debian.ogv I have also put up a copy of my introductory slides, though they really just contain headings for what I said/for discussion, rather than much content: http://people.debian.org/~moray/paths-into-debian.pdf Some of the topics discussed: - How do people come to Debian? - Possible routes in, and the support offered to different types of contributor - What we advertise about routes in, compared to other distributions - Other things we could do, including a list of initial tasks for for new people - Whether/how it would be useful to promote more local Debian groups The two points that seemed to gather most potential volunteers were improving the Debian website pages about how to contribute, and encouraging more local Debian meetings -- I hope that some of the apparent enthusiasm on these points can now be channelled into productive action! -- Moray -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9373e93872326154e9149b26a261f...@www.morayallan.com
Re: Paths into Debian
On 2013-08-23 20:59, Moray Allan wrote: - What we advertise about routes in, compared to other distributions Not mentioned in the room, but relevant is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608400 -- Moray -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6d0cf3485ce0624ab456186bd0606...@www.morayallan.com
Re: Paths into Debian
On 8/23/13 3:29 PM, Moray Allan wrote: At DebConf13 I was interested to hear people's views in the discussion session on Paths into Debian. The video of the session is available here: http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/999_Paths_into_Debian.ogv http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/999_Paths_into_Debian.ogv I have also put up a copy of my introductory slides, though they really just contain headings for what I said/for discussion, rather than much content: http://people.debian.org/~moray/paths-into-debian.pdf Some of the topics discussed: - How do people come to Debian? - Possible routes in, and the support offered to different types of contributor - What we advertise about routes in, compared to other distributions - Other things we could do, including a list of initial tasks for for new people - Whether/how it would be useful to promote more local Debian groups The two points that seemed to gather most potential volunteers were improving the Debian website pages about how to contribute, and encouraging more local Debian meetings -- I hope that some of the apparent enthusiasm on these points can now be channelled into productive action! I think we have missed opportunities to bring more people into Debian like not taking enough attention into support Raspberry Pi. (Which created Raspbian, and is not the same as Debian definitely. Now we have a full rebuild of Debian - just wheezy - while things could have been done inside the project). As well as not adapting easily enough to how other people does stuff. We all love APT, but is not the only way to do stuff. Some communities like the Node.js handles their own packages in a different way and a little bit of comprehension about this have moved people to prefer SmartOS which is really hard to understand at the beggining for their servers instead of the more common Debian distribution. (Being myself a developer on Node.js full-time, I'm not even using a single .deb package for handling my Node.js needs. Using .debs would create conflicts with most people workflow). These are just 2 examples which could bring huge amount of people into Debian and don't depend on local Debian groups but specialized ones. -- Jose Luis Rivas http://joseluisrivas.net/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5217ff94.3070...@gmail.com
