Vote result (was: Poll (was: Popularity of bzr-builddeb and dh-make))
Hi, the week is over and here are the results from the vote: There were 64 participants in total. dh-make === 46 people want dh-make recommended. 27 people (+ 3 with a question mark) want dh-make suggested. 58 people voted for (at least) one of the above options. Recommending dh-make instead of suggesting was the clear winner. I will move dh-make from Suggests to Recommends in packaging-dev. bzr-builddeb 8 people (+ 3 with a question mark) want bzr-builddeb recommended. 30 people (+ 10 with a question mark) want bzr-builddeb suggested. 44 people voted for (at least) one of the above options. What will I do? Am Samstag, den 13.10.2012, 00:10 +0900 schrieb Charles Plessy: > Le Fri, Oct 12, 2012 at 12:06:11PM +0200, Benjamin Drung a écrit : > > Am Freitag, den 12.10.2012, 10:04 +0800 schrieb Paul Wise: > > > > https://dudle.inf.tu-dresden.de/Popularity_of_bzr-builddeb_and_dh-make/ > > > > The poll will be closed in one week (if enough votes are collected). > > Hello everybody, > > if the point is to have a package that pulls everything one needs when doing > random work in Debian (as opposed with working specifically in one team where > it is predictable which helpers are used and which are not), then I do not > understand the point of not including *-buildpackage and dh-make, which are > tiny regarding to most other things that mk-builddeps will pull in later. > > I think that it is exactly the case where we should not vote. Unless the > wheight of bzr and dh-make is unbearable to otherwise users of packaging-dev, > even if the majority do not use them, what is the harm recommending them ? > Not to mention that there is no evidence that the people who vote for or > against recommending them are really using packaging-dev... I agree with your opinion. packaging-dev targets especially newcomers and should give them a good starting point. It should allow doing random work in Debian and therefore recommends packages that are used by a portion (could be lower than 50%) of Debian developers. For example, gnome-pkg-tools and pkg-kde-tools are recommended. Not every developer touches a GNOME or KDE packages, but these desktop environments are important enough to recommend these helpers. The poll showed that bzr-builddeb is wanted by a portion of developers (18 % up to 25 %), but not by most of them. Therefore I will keep bzr-builddeb recommended until someone has another good reason to demote the package to suggests. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: Vote result (was: Poll)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 20/10/2012 07:35, Benjamin Drung a écrit : > bzr-builddeb > > > 8 people (+ 3 with a question mark) want bzr-builddeb recommended. > 30 people (+ 10 with a question mark) want bzr-builddeb suggested. > 44 people voted for (at least) one of the above options. [...] > The poll showed that bzr-builddeb is wanted by a portion of developers > (18 % up to 25 %), but not by most of them. Funny, the only thing I can see in the result is that most people who took the time to vote (30) prefer bzr-builddeb suggested than recommended (8). > Therefore I will keep > bzr-builddeb recommended until someone has another good reason to demote > the package to suggests. I suggest that next time you want to discuss relationship of the packaging-dev package, especially if you don't intend to follow most people advices or vote, you just skip debian-devel from the discussion. TIA David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQgp0xAAoJELgqIXr9/gnybt8P/i1VQanDqonFFtfBswRfq1vz w3J/5SgMgnPkFT/BEyxAOXk22U9GWoMPJJIsQnnAPOJvogWgDxJTOTrQUyyqbOrw 4DrvV/tyqfOakTxeOJ9xj28OScmJnQmtdJx0u+MeEswm/NYr93gUNUAO2FQVGNMF a+oPswfd+nT1btnMaP8DI6F2DZF3zmh3NuCgWd5J3Gs659ow6imlQChGEEzUEke5 m0GUGcVL6zYD6gEDrtyg/9oJ9KBMzw2L1Z+94IBPeuYAn/we0sSve0JQ+LqXm7M2 GEdwo8Uc6qiXG1gPK0o9YHpMyEPlV6t3q/0aVnrrSNRi5gTiga5asG4FhBOvAy6X RMsUXHtjE8BPYRAF1wooPIrukqfXdh4bHVu9c16b3gfHBPi5uWuvuV4OMFIoUefA X2f/BZ3CdzKIwlTW4vpUNn7+WScqVZPdnX0Y9icri1vvRZPJ0cGHSYvGEYMwQKXd ar1Wu0TxGNR/akyaLQgOCA/fjQciIYnTHLL8R6+GZPT2S99ZdWALjrK2WbMLO/vo HuW3c7PVejLwkN+NvfcSpTCmHA1wA6XRoRTI1YKnE9CWsncgWLhMn4k7+Io9gPT+ hrIKiF8nNLPBEkV8vlgVt4Tzp4OwpEWcJsHU0hEv6/Fu9eDIqs/an42KIF3pvUCH 8+AvrkJdojbK0Ia8+XnB =XttQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50829d32.2070...@debian.org
Re: Discarding uploaded binary packages
On 10/17/2012 09:56 AM, Chow Loong Jin wrote: On 17/10/2012 08:36, Russell Coker wrote: On Wed, 17 Oct 2012, Barry Warsaw wrote: I also think allowing source-only uploads makes for easier contributions, and thus hopefully more contributions. Why would it be easier? Surely we still want people to build packages first to ensure that we don't needlessly get FTBFS bugs. Because binary packages are big, and uploading them reliably from a region with crappy internet access sucks, especially when trying to upload them over SFTP. Honestly, if we're not going to be using these, why upload them? It's a pointless waste of bandwidth. Dropping the uploaded binary and rebuilding it after upload doesn't necessarily mean that we allow uploading a source-only upload. I think it would be a good thing to continue to require source + binary. What would be even better, would be to rebuild, and if there's a difference with what was uploaded (for example, calculated library dependencies), then reject the upload. The main point of dropping uploaded binary, IMO, is to make sure that the binary is built with the correct library currently in SID (not everyone uses pbuilder / cowbuilder, and mistakes can happen). Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5082b761.2080...@debian.org
Re: Discarding uploaded binary packages
On 20/10/2012 22:38, Thomas Goirand wrote: > On 10/17/2012 09:56 AM, Chow Loong Jin wrote: >> On 17/10/2012 08:36, Russell Coker wrote: >>> On Wed, 17 Oct 2012, Barry Warsaw wrote: I also think allowing source-only uploads makes for easier contributions, and thus hopefully more contributions. >>> Why would it be easier? Surely we still want people to build packages >>> first to >>> ensure that we don't needlessly get FTBFS bugs. >> Because binary packages are big, and uploading them reliably from a region >> with >> crappy internet access sucks, especially when trying to upload them over >> SFTP. >> Honestly, if we're not going to be using these, why upload them? It's a >> pointless waste of bandwidth. >> > Dropping the uploaded binary and rebuilding it after upload doesn't > necessarily mean that we allow uploading a source-only upload. I think > it would be a good thing to continue to require source + binary. What > would be even better, would be to rebuild, and if there's a difference > with what was uploaded (for example, calculated library dependencies), > then reject the upload. > > The main point of dropping uploaded binary, IMO, is to make sure that > the binary is built with the correct library currently in SID (not > everyone uses pbuilder / cowbuilder, and mistakes can happen). But my point was: if we're going to be dropping the uploaded binary in the first place, why do we have to upload it? Source-only uploads would make so much more sense. The only argument I have seen for binary uploads is to ensure that DDs have built the package prior to uploading it. But as someone else pointed out earlier in the thread, we seem to be trusting DDs a lot in other aspects, so why not trust that they test-build packages prior to uploading them as well? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Discarding uploaded binary packages
* Chow Loong Jin [121020 18:10]: > The only argument I have seen for binary uploads is to ensure that DDs have > built the package prior to uploading it. But as someone else pointed out > earlier > in the thread, we seem to be trusting DDs a lot in other aspects, so why not > trust that they test-build packages prior to uploading them as well? Because trusting someone in one thing is not the same as trusting someone in another. Trust works best when there is accountablity. Having the binary file around, even if it is not easily accessible on some remote archive, noone can claim "I tested this, it just did work here, something must be different on the buildds" and hope to get away with it. Given that source only uploads where tried in another project and the results are scary, this accountability might make the difference to make it work. And to also name another argument: having the files actually uploaded means it is easy to add additional checks. (Like starting with making sure the list of files does not differ between the two versions, or some check to see only versions of generated dependencies differ but not the packages depended and so on). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121020162948.gb14...@client.brlink.eu
Re: (seemingly) declinging bug report numbers
On Fri, Oct 19, 2012 at 09:40:12AM +0200, Christian PERRIER wrote: > I will take this last sentence from Russ' mail to give out my own > feeling about these issues. Thanks for this in-depth view on your feeling on this matter. I've been following with interest your blog posts on the "decline" of Debian (bug reports) since quite a while (was the first time ~3 years ago?). I've a theory on this, although not particularly original one: I think that once we're convinced of something (say, the decline), it's pretty hard to change our mind about that. It's a natural tendency to notice more prominently confirmations of our theses than counter-examples. (Unfortunately, that mixes with the tendency of noticing more prominently negative experiences than positive ones --- which is a pretty dangerous mix in a community.) Christian has shown data about the number bug reports. Those are facts. On that front I'm personally fully satisfied by the argument developed at the beginning of this thread, namely: bug reports now flow in through derivatives. I understand that others are skeptical about that, but ~1 year ago at UDS I've shown data about the amount of patches we got forwarded from Ubuntu: they were at their historical maximum, with a positive trend. But sure enough: there's always more to do, right? (and therefore reasons to be sad about the current state of affairs) Christian has also taken the d-i example. IIRC, that was an example we've used also during the Squeeze release, worrying (probably rightly so) about a not "strong" enough coordination in d-i release preparation. This time, d-i releases seem to go pretty well. I'm not personally involved in d-i development, but as mere developer I see: periodic releases, calls for testing, features coming in, etc. So now the reason to worry (again: probably rightly so) is that it is a one-person band coordination show (and I'd like to erect a KiBi-monument for that). I don't dispute that it would be *better* to have more people on the hot seats. But I can't help noticing that we seem to be way more inclined to look at the "bad" that still needs to be fixed, rather than the significant improvement over the past release cycle. About "core" teams. I remember years, not that far past, where teams like DSA, ftp-masters, keyring, DAM were one-person teams (and often the person in question was the same...). Nowadays they're lively, efficient teams with good turnover. Those are good examples to me, denoting significant improvements in core teams staffing, and I could find thousands more. I'm sure we can also find thousands *bad* examples. The problem is that the bad examples seem too stick in the collective memory of the community, while the good ones don't. We forget the good ones and move on, looking at what's the next bad thing we should be sad about. (Note: this is not specific to Christian. It's just a (meta-)feeling of mine that seemed relevant enough to this discussion for sharing it.) But if we stay at this level, the discussion might appear to be a typical optimistic-vs-pessimistic one (with the optimistic being invariably less visible, but fair enough). This is why, instead of discussing impressions abstractly, I often prefer to look for data that could confirm or counter those impressions. As I agree with Christian that the most important factor is our ability to attract contributors, I've tried to gather data about the number of people that decide to join Debian per year. The easiest data to found was those about DDs and DMs; they are not a full picture of our contributors community (no translators, no project members on Alioth, etc.), but they're probably correlated significantly with it. Here is the data I've collected and how: - with the invaluable help of Enrico Zini, number of NM applications per year, starting 2000 (see attached stats-dd.txt, data before 2000 are spurious) - in a way more hackish way (see attached dm-keyring-stats.pl and cry for my rusty Perl-fu) I've approximated the number of DM applications per year grepping through the keyring changelog I've then plotted the data in a LibreOffice spreadsheet (see attached stats-dd.ods). My own interpretation of the data is as follows: - if we look at DDs alone (excluding DMs) the number of applications per year looks stable since 2002: there are important variations with spike up and down (in particular in 2011 and 2004), but they are close to +/-1 standard deviation interval - but if we're interested in our ability to maintain _packages_ (something Christian and others have focused on), we should also take into account DMs. And if we do that, the trend is positive, and strikingly so. - Unfortunately, simply adding up DMs and DDs is not correct, as DMs become DDs, but I didn't have time/energy to do this properly. In the meantime, we know that the truth is in between the previous two points, which looks like a WIN to me. Please review the above data and methods, and
[MailServer Notification]Attachment Blocking Notification
The dm-keyring-stats.pl has been blocked, and Quarantine entire message has been taken on 10/20/2012 8:18:39 PM. Message details: Server: HEMATIT Sender: z...@debian.org; Recipient: debian-devel@lists.debian.org; Subject: Re: (seemingly) declinging bug report numbers Attachment name: dm-keyring-stats.pl -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6cce3f9007324510a752815dc9749...@dpt.gov.tr
Re: Discarding uploaded binary packages
> But my point was: if we're going to be dropping the uploaded binary in the > first > place, why do we have to upload it? Source-only uploads would make so much > more > sense. Only theoretical. Practical it would mean we will have many more build failures. > The only argument I have seen for binary uploads is to ensure that DDs have > built the package prior to uploading it. But as someone else pointed out > earlier > in the thread, we seem to be trusting DDs a lot in other aspects, so why not > trust that they test-build packages prior to uploading them as well? And we trust people to know their way around open source and see whats clearly non-free. Or incompatible licenses (to a point). Yet, we have MANY rejects from NEW for even very simple to spot issues. Trust may work - but it has to be earned. From a rough guess, I would trust around 10 to 20% of our uploaders to do it right most of the time.[1] For some more deep insight you might want to talk to Ubuntu people. They do allow source-only uploads, and I seem to remember them having written that it lead to lots of useless uploads that just can't have been tested.[2] [1] And that doesn't mean that I think 80 or 90% of DDs are stupid/brainless idiots. (That number is smaller). But it is *WAY* to easy and convinient to go "ah, just upload this, I think it works, no time for testing now", when you can do it. And this will happen. [2] I am not an ubuntu person. This is from reading stuff in mailing lists and on irc and my memory might be wrong. Go to them to get a definite say. -- bye, Joerg Flanders has cooties … Flanders has cooties … Flanders has cooties … -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txtpj9pz@gkar.ganneff.de
Re: Discarding uploaded binary packages
* Joerg Jaspert , 2012-10-20, 20:10: For some more deep insight you might want to talk to Ubuntu people. They do allow source-only uploads, and I seem to remember them having written that it lead to lots of useless uploads that just can't have been tested. http://lists.debian.org/20091116012917.gc4...@dario.dodds.net -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121020192626.ga5...@jwilk.net
Re: Discarding uploaded binary packages
On Sun, Oct 21, 2012 at 12:10:02AM +0800, Chow Loong Jin wrote: > I also think allowing source-only uploads makes for easier contributions, > and thus hopefully more contributions. > >>> Why would it be easier? Surely we still want people to build packages > >>> first to > >>> ensure that we don't needlessly get FTBFS bugs. > >> Because binary packages are big, and uploading them reliably from a region > >> with > >> crappy internet access sucks, especially when trying to upload them over > >> SFTP. > >> Honestly, if we're not going to be using these, why upload them? It's a > >> pointless waste of bandwidth. > >> > > Dropping the uploaded binary and rebuilding it after upload doesn't > > necessarily mean that we allow uploading a source-only upload. I think > > it would be a good thing to continue to require source + binary. What > > would be even better, would be to rebuild, and if there's a difference > > with what was uploaded (for example, calculated library dependencies), > > then reject the upload. > > > > The main point of dropping uploaded binary, IMO, is to make sure that > > the binary is built with the correct library currently in SID (not > > everyone uses pbuilder / cowbuilder, and mistakes can happen). > > But my point was: if we're going to be dropping the uploaded binary in the > first > place, why do we have to upload it? Source-only uploads would make so much > more > sense. There are two main arguments: "why should we upload binaries if they will be discarded anyway" and "if we allow source-only uploads people will upload packages that weren't tested to be buildable". Please don't repeat these arguments, it's pointless. Please. -- WBR, wRAR signature.asc Description: Digital signature
Re: (seemingly) declinging bug report numbers
On Thu, 2012-10-18 at 20:10 -0700, Russ Allbery wrote: > I'm not seeing any signs that Ubuntu actually wants to take over what > Debian is the best at, which is maintaining a very broad range of packages > at high quality. Notice the number of folks who start doing Debian > packaging because they want to introduce their packages upstream of > Ubuntu, and the number of less-widely-used packages that are maintained > entirely in Debian and just imported into Ubuntu. > > Ubuntu has full-time developer resources available to focus on certain > core work, which means they can drive archive-wide changes faster than we > can and can do focused development on specific priorities often easier > than we can. Having centralized decision-making also helps with both of > those. But they're not as good at the things that large pools of > volunteers are good at, like maintaining lots of packages that are of > interest to small groups of people. > > I think the relationship is fairly synergistic, honestly. Well... I hope you're right :) Reading however Shuttleworth's blog[0] makes me really worried about what Ubuntu may mean to opensource... reads a lot like non-open development in secrecy just to be as cool and media-attractive as companies like Apple. Anyway... that discussion was just thought about the bug numbers originally... and I guess everything has been said already. And as I was privately notified that my contributions to Debian are too little for writing a lot at debian-devel... so EOT here for me, too. Cheers, Chris. [0] http://www.markshuttleworth.com/archives/1200 smime.p7s Description: S/MIME cryptographic signature
Re: Discarding uploaded binary packages
Le Sat, Oct 20, 2012 at 06:29:50PM +0200, Bernhard R. Link a écrit : > * Chow Loong Jin [121020 18:10]: > > The only argument I have seen for binary uploads is to ensure that DDs have > > built the package prior to uploading it. But as someone else pointed out > > earlier > > in the thread, we seem to be trusting DDs a lot in other aspects, so why not > > trust that they test-build packages prior to uploading them as well? > > Having the binary file around, even if it is not easily accessible > on some remote archive, noone can claim "I tested this, it just did > work here, something must be different on the buildds" and hope to > get away with it. In the end, it is not so relevant that a local build could work on the DD's machine. With source uploads, we will switch from a model where most of the packages that our users install were built and tested by hand, to a model where most pakcages were autobuilt. In that model, it will be important that after the build, one developer downloads the binary packages and tests them. The 10 days of staging in Unstable do not offer much protection when packages have a small number of users who are not upgrading their system every week. In that context, it would be helpful to have an email notification after the packcages are autobuilt on amd64. For command-line programs, regression tests with autopkgtest will also be instrumental in helping developers to ensure that binary packages are functional. (http://dep.debian.net/deps/dep8/) Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121021004724.gb23...@falafel.plessy.net
Re: Discarding uploaded binary packages
On 21/10/2012 02:10, Joerg Jaspert wrote: > > For some more deep insight you might want to talk to Ubuntu people. They > do allow source-only uploads, and I seem to remember them having written > that it lead to lots of useless uploads that just can't have been tested.[2] I am an Ubuntu developer though, and I haven't seen any evidence that source-only uploads are a problem in Ubuntu. But then again I've only been actively involved in Ubuntu development since 2008, so I wouldn't know about any issues that have appeared in the past. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Discarding uploaded binary packages
On 21/10/2012 05:17, Andrey Rahmatullin wrote: > On Sun, Oct 21, 2012 at 12:10:02AM +0800, Chow Loong Jin wrote: >> I also think allowing source-only uploads makes for easier contributions, >> and thus hopefully more contributions. > Why would it be easier? Surely we still want people to build packages > first to > ensure that we don't needlessly get FTBFS bugs. Because binary packages are big, and uploading them reliably from a region with crappy internet access sucks, especially when trying to upload them over SFTP. Honestly, if we're not going to be using these, why upload them? It's a pointless waste of bandwidth. >>> Dropping the uploaded binary and rebuilding it after upload doesn't >>> necessarily mean that we allow uploading a source-only upload. I think >>> it would be a good thing to continue to require source + binary. What >>> would be even better, would be to rebuild, and if there's a difference >>> with what was uploaded (for example, calculated library dependencies), >>> then reject the upload. >>> >>> The main point of dropping uploaded binary, IMO, is to make sure that >>> the binary is built with the correct library currently in SID (not >>> everyone uses pbuilder / cowbuilder, and mistakes can happen). >> >> But my point was: if we're going to be dropping the uploaded binary in the >> first >> place, why do we have to upload it? Source-only uploads would make so much >> more >> sense. > There are two main arguments: "why should we upload binaries if they will > be discarded anyway" and "if we allow source-only uploads people will > upload packages that weren't tested to be buildable". > Please don't repeat these arguments, it's pointless. Please. Great, so let's just leave it at a stalemate and not get anything done. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: (seemingly) declinging bug report numbers
Le Fri, Oct 19, 2012 at 09:40:12AM +0200, Christian PERRIER a écrit : > > But, still, yes, I feel we are in danger in some way. That may sound alarming > (death of Debian predicted, film at 11), but, really, getting new > blood is important for usif we don't want to shrink into a club of > old chaps who are doing Debian "just for their needs" but can't manage > to do it anymore because there is too much to do..:-). Along these lines, I am worried that we are missing a turning point, the generalisation of application stores. How can we attract the creative people who entered the field of software development and distribution on Android or iOS ? Worse, because of the fragmentation of the « Linux » landscape, if they want to distribute their work on « Linux », these developers need to learn how to do so on Debian, Ubuntu, Fedora, openSUSE, etc., or need to convince develpers to package their work. And this still does not save them from learning complex details, as for instance it is not obvious to determine how long it will take for a package to migrate from Debian to Ubuntu. It looks like from big projects like Mozilla, GNOME, etc., their answer is to provide their own extension store, which co-exist with our package sytstem, adding one more level of fragmentation. I think that our long-term survival will depend on our capacity to join efforts with the other « Linux » distributions and the major Free application/extension stores, and provide a simplified and standardised entry point to our packaging systems, so that the works that do not need the most sophisticated parts of our packaging systems can be maintained in a trans-distribution way. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121021042656.gd23...@falafel.plessy.net
