Re: vanity packages (was: mentors.debian.net reloading)
On Sun, 28 Oct 2007 22:47:42 + The Fungi [EMAIL PROTECTED] wrote: On Sun, Oct 28, 2007 at 09:19:12PM +, Neil Williams wrote: [...] What kind of popcon score? i.e. does anyone else think it is a useful addition? I would consider its popularity low (187 popcon installs with 46 votes). It's not that low. It looks like quite a few people find it useful, so that's good. Admittedly, Russ sponsored it because he said thought he was likely to find it useful. If it's consensus among the Debian community, or even merely the opinion of my sponsor, that the package I currently maintain is of little enough worth as not to outweigh its drain on (security team, mirror operator, release management) resources, I would certainly not protest its removal. I was only curious. Still, I will potentially be looking to maintain more of my projects within Debian, as they reach functional maturity, and may then revisit entering NM; Personally, I would encourage that. Although don't forget that being a DD is not all about packages in the archive. There are other ways that you can contribute and completing NM only increases the possibilities. At any rate, the goal was not to talk about myself per se (as I entertain no illusions that either I or my work is of any great value to Debian, nor will I claim to be more than even a marginal example in favor of my point), but merely to stand up and be counted. I don't expect to sway your opinion that only packages maintained by people intent on becoming official DDs are of any quality or worth; but just as you seemed inclined to provide it, I felt compelled to present a counter-argument against such broad generalization. I think you have misinterpreted my position. Sponsoring is an introduction to NM and whether or not the maintainer is looking to join NM has no effect on the quality of packages at the start of sponsoring. However, the likelihood of starting or being in the NM process itself is the perfect time to improve the quality of the current packages and all subsequent packages from that maintainer because the topics covered in NM are often best understood by being explained in the context of a package that is being actively sponsored at the same time. I would rather sponsor someone prepared to go through NM for a couple of reasons: 1. Demonstration of commitment to the package and to Debian. 2. The NM process teaches a lot of things that would otherwise take up time on mentors or between maintainer and sponsor. 3. Sponsoring eases the NM process itself so the NM queue is processed more quickly, benefiting everyone in the NM process. 4. Someone in the NM queue will, eventually, become able to upload their own packages which not only gives them an incentive but gives me an escape route so that I'm not sponsoring that maintainer for ever and a day. In recent years, I have seen several discussions on devel in which it was suggested that the number of DDs is unnecessarily high, and that it's entirely possible to provide a wide variety of valuable resources to the project without requiring official DD status. True - but each of those methods of contribution become easier, quicker and generally more compatible with the rest of Debian if a DD is involved. My work in Emdebian is an example - it is a mix of DD's and non DD's and when things in Debian need tweaking, it is often easier if one of the recognised names makes the request. Like it or not, other DD's are prepared to listen to another DD more than a random maintainer. NM is recognised as a significant step in and of itself and once completed, doing anything in Debian just becomes easier. These arguments seemed (to me) quite cogent, just as have the arguments suggesting the number of packages in main is unnecessarily high. If you (or others) feel that I am part of the problem, I suppose I'll just have to live with that. No, you aren't part of the problem. The benefits of being in NM are such that I agree with other sponsors that I feel I must give priority to those maintainers who take the step to join Debian. It is better for them, it is better for me, it is better for Debian and it is better for the packages themselves. The problem is that like all contributors, my time is limited and if I do give priority to those willing to do NM, I have no time left for those who do not consider NM worthy of their time. Like it or not, a maintainer who is prepared to start NM deserves more of my time and assistance than a maintainer who does not. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp3bKLPJTpcC.pgp Description: PGP signature
Re: mentors.debian.net reloading
On Sun, Oct 28, 2007 at 04:45:03PM +0100, Ondrej Certik wrote: BTW, I just found: http://www.bononia.it/~zack/blog/posts/2007/07/python_debfile.html There could be some interesting code to use. On Sun, Oct 28, 2007 at 08:33:00PM +0100, Christoph Haas wrote: Cool, thanks for the link. It looks very powerful and hardly documented. That code has been integrated in the python-debian package since some months now; it's also already in testing. I consider it quite documented, but yes ... only in the most common Python: doc strings. In addition to that there are a couple of examples under /usr/share/doc/python-debian/examples/debfile/ (of course after installing python-debian). debfile has also been use extensively on all the .debs of the archive (by Cyril IIRC) failing only in a couple of cases for strange .debs. Feel free to ask directly if you have any other questions. /me going to update the above blog post mentioning where the code is now. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: mentors.debian.net reloading
Do you know about Django? I heard good things about it. Your thoughts? I remember http://www.djangoproject.com/weblog/2007/oct/26/security-fix/ ;) Otherwise I've heard only good things about it. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vanity packages (was: mentors.debian.net reloading)
Neil Williams wrote: I would consider its popularity low (187 popcon installs with 46 votes). It's not that low. It looks like quite a few people find it useful, so that's good. Using absolute popcon numbers as indications of a package's popularity isn't the best idea anyway, since we don't know what percentage of users use popcon. Comparing popcon stats for two packages is more useful. -- see shy jo signature.asc Description: Digital signature
Re: vanity packages (was: mentors.debian.net reloading)
On Mon, Oct 29, 2007 at 07:44:28AM +, Neil Williams wrote:
[...]
I think you have misinterpreted my position. Sponsoring is an
introduction to NM and whether or not the maintainer is looking to join
NM has no effect on the quality of packages at the start of sponsoring.
[...]
The problem is that like all contributors, my time is limited and if
I do give priority to those willing to do NM, I have no time left for
those who do not consider NM worthy of their time.
[...]
This sounds like a much more reasonable position than I had
previously credited you based on your earlier sponsoring is a step
towards joining Debian comment. I can accept that sponsoring, for
you, must be a step in your sponsoree's journey toward official DD
status. I suppose my point was that it does not have to be that way
for all sponsors and sponsorees, but I must admit you clearly
indicated it was merely your opinion.
Apologies for the noise, and thanks as always for the great insight!
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
It might be interesting to have an additional seeking comments tag. Sometimes the package is not really ready for sponsorship, or the usual sponsor is too busy right now, and all I really care is for comments on the package rather than an actual upload. This is useful when working with a package you don't have experience with: the first library, the first multi-binary package, a relatively complex package. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 10/29/07, Felipe Sateler [EMAIL PROTECTED] wrote: It might be interesting to have an additional seeking comments tag. Sometimes the package is not really ready for sponsorship, or the usual sponsor is too busy right now, and all I really care is for comments on the package rather than an actual upload. This is useful when working with a package you don't have experience with: the first library, the first multi-binary package, a relatively complex package. Exactly. For me this applies to every package I make. I first want to make it build, upload it to mentors/PPA/whatever and then use it. And graudally fix it. And only then look for a sponsor. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vanity packages (was: mentors.debian.net reloading)
On Sunday 28 October 2007 07:10:57 pm Paul Wise wrote: On 10/29/07, The Fungi [EMAIL PROTECTED] wrote: I would consider its popularity low (187 popcon installs with 46 votes). I consider such fringe packages to be the main benefit of using Debian. That is; it is the diversity (or universality) of Debian that is attractive and useful. -- bye, pabs http://wiki.debian.org/PaulWise Generally, I agree. But at some point a line should probably be drawn, where fringe packages are replaced by more popular ones. It's just a matter of resources; every package takes space, and if only a marginal number of people at best are using the package, it could be considered a mild waste of resources to keep them there. On the other hand, having seemingly-useless packages in the repository takes only disk space, and almost no bandwidth, and disk space is getting cheaper by the month. It may be worth keeping some of them around for those people who DO decide to use them. I suppose which of these is the best for any particular package would depend on, and available resources, but I would say a package with under 100 popcon installations (obviously not this one) is a candidate for examination, at least. -- Sincerely, Jack Mudge [EMAIL PROTECTED] My GPG Public Key can be found at: https://www.theanythingbox.com/pgp.htm Signatures are appreciated, email them to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Cyril Brulebois wrote: Thomas Goirand [EMAIL PROTECTED] (28/10/2007): With that, what you will see is that maintainers that have lots of friends, or that are maintaining famous packages, will get a high score. The opposite is true too. Infamous wannabe-maintainers could get blacklisted or so. Unsure how bad that would be. This list is GREAT because people are giving advice even for the most stupid questions. I think that everybody has the rights to learn, I really hate that kind of behaviour I could see with some on IRC putting disgrace on learners (maybe just to pretend to be better than others?). They'd better just shut up if they don't feel they want to help. 2 years ago I was creating my package by building a tree of files, and then calling directly dpkg-deb --build, since then, I can build an (almost) perfect (simple) package within an hour. I got discouraged many times, but when I found some of the people here so nice and helpful, I could learn so much. The learning curve is quite long, and I still have so many things to learn. That vote system goes totally on the opposite direction, and blacklisting or discouraging people that are trying to learn is really not a good thing, IMHO. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
times, but when I found some of the people here so nice and helpful, I could learn so much. The learning curve is quite long, and I still have so many things to learn. That vote system goes totally on the opposite direction, and blacklisting or discouraging people that are trying to learn is really not a good thing, IMHO. Yes, I feel the same. the service will automatically build and check the package. Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? During the sponsoring process having a binary package is pretty useless. A sponsor will/should always take the source package, build it again and check both the source and the binary package. I think It is a great idea because me, as a new user trying to create my first debian package, I don't want to waste other's people time. What I want is some automatic service, that will automatically check my package and tell me - improve this, improve that etc etc. First, and second - I, and I think it's the same with others, I am doing the packaging especially because I want to fix the problem for myself. But when I am doing it, of course I want to fix it for others too (because that's easy, when I already fixed it for myself). So I want to package a new program and use it now - but that's the argument for PPA, which I think you agree with. So far so good. Although you shouldn't rely on an automated tool but rather use it in addition. I wouldn't sponsor a package just because lintian doesn't complain. Agree. At the moment I need to do all of this by hand and it's very time consuming. So is package maintenance. It is, but when something can be automated, it should. And then my sponsor needs to do the same, to be sure I didn't make a mistake. Correct. Because the sponsor will be responsible for the package at that moment. The only solution I see here is that the package maintainer becomes a Debian developer or Debian contributor. That's the next step. With Debian PPA, my sponsor can easily be sure the technical things are ok and concenrate on QA. Aren't technical things == QA? As I said, I think what can be automated should be automated. Parts of QA checks are pbuilder, lintian, linda, piuparts logs. All of those could be automated and listed on the Debian PPA's page (be it mentors.debian.net, or other page, that's ok). QA things are imho manually checking, I runtime depend on all needed packages, that copyright is fine, that the package is dfsg free, that debian/rules is robust, that my patches are ok, the package description is ok, etc. etc. It contains links to all relevant discussions about this issue. But when I found svnbuildstat, I want to work with Goneri. As Gonéri said, we are trying to create such building blogs - a server that will accept source packages (I only need source packages, Goneri also needs input from VCS), and buildbots, that will do the compiling. Isn't that what buildds are about? Yes, they are. But I want to make them easy to install, also I think pbuilder/cowbuilder is better. PPA is a means how to get the packages to Debian and to ease the process of it, for everyone. What do you mean by get the package to Debian? Sponsorship? Or creating a competing repository for end-users? I mean getting it to the official Debian unstable main archive. Besides those you also have a social argument - that you fear it will actually decrease the number of new packages in Debian, or that it will increase the number of unhappy users. I think it will actually be the opposite, but that's just my opinion. I'm scared by the thought that there will be a dozen PPAs that end-users will use to get their software from third-party sources. IMHO good packages should go officially into Debian. And bad packages should go to hell. Sponsorship might be a problem sometimes which may be solved by the Debian Maintainer status which should allow you to upload packages into Debian. I would hate to read on mailing lists the version of 'kaffeine' in Debian is outdated. There is a newer version in PPA X that you could use. Or you use the version in PPA Y which is even newer but I hard it's broken. (shiver) Why not? It's like with Ubuntu - it also has some newer packages. I think more options are good, not bad. The official archive is the unstable one - and that's the only one that is supported. And to ensure high quality of it, I like this whole sponsorship thing, the NEW queue and everything. But also, as the user, I want to use immediatelly the packages that I create, and also that other people create. I want to use them unofficially, until the package hits unstable, which can take up to 2 months. Basically I think all of those and similar problems can be solved, if we want to. I'm absolutely on your side. Just not for the binary package part which scares me. The debian mentors site doesn't have to provide the binary part. But I want some
Re: mentors.debian.net reloading
Thomas Goirand [EMAIL PROTECTED] (28/10/2007): This list is GREAT because people are giving advice even for the most stupid questions. I think that everybody has the rights to learn, I really hate that kind of behaviour I could see with some on IRC putting disgrace on learners (maybe just to pretend to be better than others?). See my last paragraph. 2 years ago I was creating my package by building a tree of files, and then calling directly dpkg-deb --build I'm not sure the New Maintainer guide mentions it. Didn't you read it first? since then, I can build an (almost) perfect (simple) package within an hour. Is dtc considered an (almost) perfect (simple) package from your point of view? The learning curve is quite long, and I still have so many things to learn. Sure, but that's not the point, see below. That vote system goes totally on the opposite direction, and blacklisting or discouraging people that are trying to learn is really not a good thing, IMHO. There are people clearly not willing to fix problems. And not willing to learn. I've seen “there're still errors, but that's OK with me, feel free to fix them before uploading” [1]. I've seen people blaming people submitting patches for RC bugs, instead of being a little thankful. I've seen people wanting to (tentatively) hijack packages because the maintainer didn't want to push a more-buggy-than-the-present-one new upstream release. I've seen people doing all the above at the same time. And that's definitely not what I consider being “trying to learn”. I don't know about you, but I'd like to avoid such maintainers, be them Debian Developers, Debian Maintainers, New Maintainer applicants, or occasional Maintainers. And again, that's not about bashing newbies, see the previous list. -- Cyril Brulebois Footnotes: 1. The exact quote is “I don't understand why, please ignore it or fix it by yourself”. signature.asc Description: Digital signature
Re: mentors.debian.net reloading
On Sun, Oct 28, 2007 at 11:19:14AM +0100, Ondrej Certik wrote: times, but when I found some of the people here so nice and helpful, I could learn so much. The learning curve is quite long, and I still have so many things to learn. That vote system goes totally on the opposite direction, and blacklisting or discouraging people that are trying to learn is really not a good thing, IMHO. Yes, I feel the same. I think I also second that. It's like the number of signatures on the PGP key doesn't mean someone is more skilled (socially and or technically) than others. Those people are just attending more KSPs (or even not - in the worst case). :) First, and second - I, and I think it's the same with others, I am doing the packaging especially because I want to fix the problem for myself. But when I am doing it, of course I want to fix it for others too (because that's easy, when I already fixed it for myself). So I want to package a new program and use it now - but that's the argument for PPA, which I think you agree with. Definitely. I'm scared by the thought that there will be a dozen PPAs that end-users will use to get their software from third-party sources. IMHO good packages should go officially into Debian. And bad packages should go to hell. Sponsorship might be a problem sometimes which may be solved by the Debian Maintainer status which should allow you to upload packages into Debian. I would hate to read on mailing lists the version of 'kaffeine' in Debian is outdated. There is a newer version in PPA X that you could use. Or you use the version in PPA Y which is even newer but I hard it's broken. (shiver) Why not? It's like with Ubuntu - it also has some newer packages. Really? I'm not doing much with Ubuntu. How are they doing that? I think more options are good, not bad. The official archive is the unstable one - and that's the only one that is supported. And to ensure high quality of it, I like this whole sponsorship thing, the NEW queue and everything. But also, as the user, I want to use immediatelly the packages that I create, and also that other people create. I want to use them unofficially, until the package hits unstable, which can take up to 2 months. Ah, okay, I get it now. You want to provide binary packages for software that is not yet accepted in Debian. Interesting idea. Like a not-even-yet-in-unstable repository. I fear that it might lead to end-users complaining that Debian sucks though because they don't know what they are doing and that PPAs are without the responsibility of the actual Debian project. I sometimes find myself taking other people's source packages and use them because they are not yet available in unstable although they come from an ITP or RFS that is two years old and the package is really in a bad condition. Couldn't hurt to offer that. If you know what you are doing it might be better to get an inofficial and partly broken package and fix that instead of starting with nothing. Basically I think all of those and similar problems can be solved, if we want to. I'm absolutely on your side. Just not for the binary package part which scares me. The debian mentors site doesn't have to provide the binary part. But I want some site, that will provide it. I've thought about all the needs, the arguments, the idea of PPAs and what mentors is about and should be. My current idea is to work on something similar but more low-level than PPAs that could be generic enough to be a basis both for binary archives and for mentors. Perhaps that's idiotic because the needs look a bit different. PPAs would currently be there to publish packages and build them. mentors.d.n would be there to get source packages sponsored. But there is a common ground that both software would need: - storage for source (and optionally: binary) packages - QA checks when uploading source packages - social interaction (e.g. notification of new uploads of a certain package - could be interesting for end-users as well as sponsors) I'm positive that this is similar to what you were proposing all the time. :) Currently I'm trying to get all the features together and see how it can be implemented while staying as generic as possible. Let's see what that leads to. I hope it will finally be something that can be used for other services, too. Perhaps even for PPA-like services. I'm thinking a similar way (using a Python web framework - although a different one). So at least I expect to come up with a Python module that helps dealing with Debian source packages and repositories. I hoped that python-apt would help but last time I looked it was only there to deal with the APT cache. I spent a lot of time parsing control files correctly and will tidy that up and publish that properly at least. But anyway, I prefer to do something rather than to talk, so I bought a virtualserver with unlimited bandwidth and I am going to try to build the
Re: mentors.debian.net reloading
I'm scared by the thought that there will be a dozen PPAs that end-users will use to get their software from third-party sources. IMHO good packages should go officially into Debian. And bad packages should go to hell. Sponsorship might be a problem sometimes which may be solved by the Debian Maintainer status which should allow you to upload packages into Debian. I would hate to read on mailing lists the version of 'kaffeine' in Debian is outdated. There is a newer version in PPA X that you could use. Or you use the version in PPA Y which is even newer but I hard it's broken. (shiver) Why not? It's like with Ubuntu - it also has some newer packages. Really? I'm not doing much with Ubuntu. How are they doing that? I meant that some packages in Ubuntu are newer than in Debian. And I wanted to point out that it is not bad for Debian - becuase when someone decides he wants to fix it in Debian, he can simply take the Ubuntu package to have something to start with. Ah, okay, I get it now. You want to provide binary packages for software that is not yet accepted in Debian. Interesting idea. Like a not-even-yet-in-unstable repository. I fear that it might lead to Yep. end-users complaining that Debian sucks though because they don't know what they are doing and that PPAs are without the responsibility of the actual Debian project. I sometimes find myself taking other people's source packages and use them because they are not yet available in unstable although they come from an ITP or RFS that is two years old and the package is really in a bad condition. Couldn't hurt to offer that. If you know what you are doing it might be better to get an inofficial and partly broken package and fix that instead of starting with nothing. It's just a social thing. If there is ever going to be something like an official debian ppa, there should be a clear statement on the PPA website: The only official and supported repo is the Debian main archive (unstable, testing, stable). Take it or leave it. It takes time to get high quality packages in there, so this PPA can be used to get any packges now. Quality may differ, please don't complain on Debian lists about it, but rather take the package from PPA, improve it and get it to Debian through the standard procedure. I've thought about all the needs, the arguments, the idea of PPAs and what mentors is about and should be. My current idea is to work on something similar but more low-level than PPAs that could be generic enough to be a basis both for binary archives and for mentors. Perhaps that's idiotic because the needs look a bit different. PPAs would currently be there to publish packages and build them. mentors.d.n would be there to get source packages sponsored. But there is a common ground that both software would need: - storage for source (and optionally: binary) packages - QA checks when uploading source packages - social interaction (e.g. notification of new uploads of a certain package - could be interesting for end-users as well as sponsors) I'm positive that this is similar to what you were proposing all the time. :) Currently I'm trying to get all the features together and see how it can be implemented while staying as generic as possible. Let's see what that leads to. I hope it will finally be something that can be used for other services, too. Perhaps even for PPA-like services. I'm thinking a similar way (using a Python web framework - although a different one). Yeah, unforutunately there are several good python frameworks. But I don't mind any framework, as long as its going to work. So at least I expect to come up with a Python module that helps dealing with Debian source packages and repositories. I hoped that python-apt would help but last time I looked it was only there to deal with the APT cache. I spent a lot of time parsing control files correctly and will tidy that up and publish that properly at least. Exactly! Please do so. I was also looking at python-apt, but it's not usable for me. I was just about to write exactly as you did, so if you publish it, it will help me a lot. That's we should do - build the services from small robust blocks, that other people can easily reuse to build their own good service of their wishes. But anyway, I prefer to do something rather than to talk, so I bought a virtualserver with unlimited bandwidth and I am going to try to build the debian PPA, just for myself at the beginning. And I'll see how it works. Good idea. You'll probably be able to show something off much quicker than me still philosophing about mentors.d.n V3.0. :) I'm curious but could imagine that ppa.debian.net (or mypackages.debian.net or inofficial.debian.net or whatever) might become a useful resource. Yes. I am trying my ideas here: http://debian.certik.cz/ But currently it's only a regular repository. When you release your scripts to help with
Re: mentors.debian.net reloading
So at least I expect to come up with a Python module that helps dealing with Debian source packages and repositories. I hoped that python-apt would help but last time I looked it was only there to deal with the APT cache. I spent a lot of time parsing control files correctly and will tidy that up and publish that properly at least. Exactly! Please do so. I was also looking at python-apt, but it's not usable for me. I was just about to write exactly as you did, so if you publish it, it will help me a lot. BTW, I just found: http://www.bononia.it/~zack/blog/posts/2007/07/python_debfile.html There could be some interesting code to use. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
times, but when I found some of the people here so nice and helpful, I could learn so much. The learning curve is quite long, and I still have so many things to learn. That vote system goes totally on the opposite direction, and blacklisting or discouraging people that are trying to learn is really not a good thing, IMHO. Yes, I feel the same. the service will automatically build and check the package. Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? During the sponsoring process having a binary package is pretty useless. A sponsor will/should always take the source package, build it again and check both the source and the binary package. I think It is a great idea because me, as a new user trying to create my first debian package, I don't want to waste other's people time. What I want is some automatic service, that will automatically check my package and tell me - improve this, improve that etc etc. First, and second - I, and I think it's the same with others, I am doing the packaging especially because I want to fix the problem for myself. But when I am doing it, of course I want to fix it for others too (because that's easy, when I already fixed it for myself). So I want to package a new program and use it now - but that's the argument for PPA, which I think you agree with. As a longtime software developer (but fairly recent Debian user), my experience that is when it works for me, that is just the first step on a long road. So I am sure that the job of mentors is much more complicated than just looking over the shoulder of package maintainers. I think it is also likely that many package maintainers will never become DDs, because they may be maintaining the package for other distros, or simply have too much else to do. So I read the original post on this thread to be asking, How can we make life easier for _current_ mentors and package maintainers? When I look at the quality of Etch, I believe that it would be best to tweak the process instead of introducing major changes. The goal of Debian has always been to be the premier community distro and the numbers of Debian users and the success of distros built on it support the claim that it is achieving that goal. While there is always room for improvement, if it ain't broke, don't fix it. If there is no Debian package for an application, then users should use the application's installation procedure. Anything even implying support from the Debian community will create a distraction that will take focus off of the main goal. That being said, it would be nice to have something to help people create Debian packages. IMHO, package management should be limited to the distro's PM, except in extreme cases. If upstream teams provided packages of their apps for the major distros, users would be able to follow this rule more easily. _And_ there would be a pool of new apps with 'pretty good packages' already built. I have only looked at it briefly, but the ESP Package Manager (http://epmhome.org/index.php, and epm is already a Debian package) could encourage application teams to create reasonably good packages for multiple distros. I suggest that those who are concerned about new packages look into making sure this creates good Debian packages, encourage other distros to do the same, and promote it to development teams. Later . . . Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Sun, Oct 28, 2007 at 04:45:03PM +0100, Ondrej Certik wrote: BTW, I just found: http://www.bononia.it/~zack/blog/posts/2007/07/python_debfile.html There could be some interesting code to use. Cool, thanks for the link. It looks very powerful and hardly documented. I love text adventures. :) Seems to spare me a lot of wheel reinvention. Kindly Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Hi all, In my very personal opinion I think m.d.n is fine as it is now. About more (building, piuparts, linda/lintian on binaries, etc) QA checks: I think the maintainer should make all of these checks before even uploading the package to m.d.n but it is complicated to setup foo/bar/etc: if somebody is not able to setup the tool he should read a little further before trying to create a package. I'm involved with several projects and I'm sad most people doesn't read anything, they just download and install. I think the first QA check is to make sure the maintainer is able to check the quality of his packages on his own. The mentor then should also make sure everything is ok. A mentor of course could automate the build/checks process but that's up to him. My main sponsor, Anibal, has written some script which automate the job done by dget/pbuilder/piuparts/linda/lintian. He has already created a package for those tools, and when they are ready he will upload them. So other mentors/sponsors could easily install and use them. Since the first time I heard about doing all that job on m.d.n I tough it was a waste of time (implementing) and resources. Ratings system: As others have already said, they are useless and may cause more conflicts. Comments system: We already have [EMAIL PROTECTED]; adding a comments system might of course reduce the number of emails sent to the list but might also prevent many useful comments from being said. Subscribing to packages, /msg to sponsors: I also think it is a waste of time. Maintainers should either contact their sponsor or send an email to the list when they need a mentor/sponsor. Communication between the maintainer and the sponsor is very important; and most of the suggested features just reduce the communication between them. If somebody wants to get a package in Debian's archive they should get more involved with the _community_. And the key point on this is communication. Shorter urls: This can be done with mod_rewrite; there's no need to change anything on the backend. Making information available to others through proper interfaces...: Is this really needed? make the Python code available...: Cristoph already said he was worried about sharing the code (maybe he used other words). As I already said at the beginning of my message, m.d.n is just fine for me. So all I can think about is making the code public for DD's only until everybody working on it agrees it is safe to make it world accessible. m.d.n as a deb-src: I only use dget :) statistics: As a maintainer I don't really find useful to know the number of times a package has been downloaded nor the number of page views if the person who downloaded/visited doesn't give any feedback. So I think these could be dropped. When I first decided to create my first package I found kind of difficult to find the right information. So here are some comments that might help improving the websites and documentation: Some people pointed me to the maintainer's guide, but some of its pages should be updated. There are many tools now that should be mentioned. The first thing that comes to my mind is section 4.1 which describes the control file and how to find build-depends: dpkg-genbuilddeps could be mentioned in this case. Some guides/documentation point to mentors.d.n or sponsors.d.n; but as a newcomer I was clueless on what I was supposed to do there. Providing an start point at m.d.n would be great and I think it would help a lot of people who want to get involved but don't know exactly where to start. I think this is all for the moment. -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Raphael, thanks for your thoughts. On Sun, Oct 28, 2007 at 01:33:20PM -0600, Raphael Geissert wrote: In my very personal opinion I think m.d.n is fine as it is now. It itches in my fingers to add a few fancy features. :) And I've seen what Python web frameworks can do so I'd be willing to do more than what's absolutely needed anyway. But I wouldn't say that it doesn't work. I wouldn't even say that a ppa.debian.net would supersede mentors.debian.net. Since the first time I heard about doing all that job on m.d.n I tough it was a waste of time (implementing) and resources. Partly. Perhaps. But on the [EMAIL PROTECTED] list you don't get a proper impression of which packages need sponsoring. I've often sponsored a package when the maintainer afterwards mailed me that some other DD has already jumped in. I didn't know that. And some basic automatic QA checking was needed, too, because I've hardly ever had a package that was ready to be uploaded without a few changes. I was thinking a lot about the sponsorship process back then and even talked to the Ubuntu guys when they were brainstorming about MOTUs and the REVU tool. Sponsorship should be made as easy as possible or otherwise Debian might miss interesting software and maintainers (who are not DDs) might get frustrated for creating packages that never get used. Implementing that was also partly fun and even helped me learn more about the syntactical subtleties of control files and possible repository layouts. Ratings system: As others have already said, they are useless and may cause more conflicts. IMHO rating packages is good (like pointing out problems or saying the classical I'm not a DD but I've tested your package and it looks good). Rating people sucks though. However I think that rating and commenting is the same feature. More like: 2 people were happy with your package - 12 said it's unworthy to get sponsored. Comments system: We already have [EMAIL PROTECTED]; adding a comments system might of course reduce the number of emails sent to the list but might also prevent many useful comments from being said. Other maintainers might not learn from hints they get from a RFS thread on the mailing list. But having to follow different media is distracting. You have uploaded your package to a website but discuss matters on the mailing list. I think that mailing lists are good to discuss general matters or to get help. But when you need to get comments on a package I think the comments should be found where the package is. Like I don't like to create cryptic mails when being on the shell but using the bts command-line tool. There are a few examples where information is kept together. Subscribing to packages, /msg to sponsors: I also think it is a waste of time. Maintainers should either contact their sponsor or send an email to the list when they need a mentor/sponsor. Same applies here. Why can you subscribe to bugs in the BTS then? Communication between the maintainer and the sponsor is very important; and most of the suggested features just reduce the communication between them. IMHO it makes the communication easier and the people involved do not have to jump between BTS, email, mailing lists, IRC and a web site. As a sponsoree I'd perhaps manage multiple packages and would like to see what I have to do, which package was sponsored, where I have to fix bugs etc. Maintainers should know which means of communication Debian uses. But just because RFS have been sent to the mailing list doesn't mean it's the best way. But that's probably the same like when my coworkers try to convince me that web forums (phpbb etc.) are the only means to communicate and mailing lists stink. If somebody wants to get a package in Debian's archive they should get more involved with the _community_. And the key point on this is communication. No denying that. But the community is distributed across different media. I wouldn't expect someone to just use mentors.debian.net and not being subscribed to [EMAIL PROTECTED] Many DDs dislike IRC. Many aren't subscribed to anything but debian-devel-announce. I myself unsubscribed from debian-devel from time to time because my asbestos pants where in the washing machine. Shorter urls: This can be done with mod_rewrite; there's no need to change anything on the backend. Just cosmetics. Simple with web frameworks, too. Apache and CGI sucks for certain tasks. I even have a daemon to watch the apache access.log to count downloads of DSC files. It should have given me a hint that I was working around Apache. I just like that I can call qa.debian.org and packages.debian.org with my email address or a package name and get information on that. Making information available to others through proper interfaces...: Is this really needed? Neil McGovern asked for a proper interface to use for sponsors.debian.net once. make the Python code available...: Cristoph already said he was worried about sharing the
Re: mentors.debian.net reloading
On Sun, Oct 28, 2007 at 06:04:36PM +, Neil Williams wrote:
[...]
I certainly think that sponsoring is a step towards joining Debian.
[...]
Perhaps not entirely true, though I will accept that I may not be a
typical non-DD maintainer. I have one (very simple) app sponsored
into main for which I am also upstream, which I felt was a useful
addition, and am not at all interested in going through NM at the
present time. I do, however, closely follow debian-devel, dda and
mentors (and have for about five years), use Debian on hundreds of
systems including most of the supported architectures, and try to
provide bug reports and patches for broken apps as I run across
them. Still, if I were to apply for NM in my present situation, that
*would* be vanity in my opinion, and I don't forsee my situation
changing any time soon.
On the other hand, I see many people helpfully participating in the
MLs, BTS, translation teams and *yes* even package maintenance,
without any desire to personally represent Debian, get their keys
into the keyring, vote in GRs and flash their official developer
status as if it's some prize to be won. At the same time, I will
agree that there are many so-called vanity packages in the
archive, but I am not a fan of generalization and stereotyping.
After all, not all of them can be attributed to non-maintainers, as
I'm sure you'll agree.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Sun, 28 Oct 2007 20:26:01 + Jeremy Stanley [EMAIL PROTECTED] wrote: On Sun, Oct 28, 2007 at 06:04:36PM +, Neil Williams wrote: [...] I certainly think that sponsoring is a step towards joining Debian. [...] Perhaps not entirely true It is true for those maintainers that I choose to sponsor and I will continue to require this for future sponsorship. Other sponsors feel the same. Cutting out those sponsors will only reduce the chances of a new package being sponsored. , though I will accept that I may not be a typical non-DD maintainer. I have one (very simple) app sponsored into main for which I am also upstream, which I felt was a useful addition What kind of popcon score? i.e. does anyone else think it is a useful addition? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpv7MfYNm8hD.pgp Description: PGP signature
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 05:19:38PM +0200, Christoph Haas wrote: On Fri, Oct 26, 2007 at 04:51:01PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 16:06 +0200, Christoph Haas wrote: (...) What Ondrej proposes is to turn mentors into a package archive, where packages would be built automatically on several arches, and people could download them. In that case, it's required to build package for all archs available in the service (you can't ask the uploader to do that hmiself). Did Ondrej say that we need a public buildd? Actually that is something I would ratner not do because I have certain (very bad) experience with it. When we kept the uploaded binary (.deb) packages our support mailbox was literally flooded with end-users (!) complaints that the packages were buggy. They used it as debian-multimedia or other inofficial binary package repositories. I think that making it more a PPA-style service it a good idea - for *source* packages. But don't you think the focus is still the sponsoring process? I can't think of a case where people want to publish Debian packages but don't want them to get into Debian. Traffic is another concern. Without binary packages we are having less than 1 GB traffic from mentors. With binary packages it was a few hundred GB. I didn't have to pay for it but if people (ab)use it as marillat V2.0 then I wouldn't bet on the numbers any more. It's basicly what svnbuildstat.d.n do. It's not perfect but shouldn't we work on the integration of the two tools. 1/ John Smith uploads its package on http://mentors.debian.net/ 2/ m.d.n accepts the package and notifys svnbs.d.n 3/ svnbs.d.n fetchs the new source package 4/ svnbs.d.n add the package in its DB 5/ the buildbots build and run the QA tools and upload there results to svnbs.d.n 6/ provide through an undefined webservice an access to the DB. Cheers, Gonéri signature.asc Description: Digital signature
vanity packages (was: mentors.debian.net reloading)
On Sun, Oct 28, 2007 at 09:19:12PM +, Neil Williams wrote:
[...]
What kind of popcon score? i.e. does anyone else think it is a useful
addition?
I would consider its popularity low (187 popcon installs with 46
votes). Admittedly, Russ sponsored it because he said thought he was
likely to find it useful. If it's consensus among the Debian
community, or even merely the opinion of my sponsor, that the
package I currently maintain is of little enough worth as not to
outweigh its drain on (security team, mirror operator, release
management) resources, I would certainly not protest its removal.
Still, I will potentially be looking to maintain more of my projects
within Debian, as they reach functional maturity, and may then
revisit entering NM; but for now it seems unnecessary given my
limited availability to participate in a more project-centric
capacity, attend conferences and so on (I know none of that is
*necessary* to be a DD, but I take any comittment, even those of a
voluntary nature, very seriously).
At any rate, the goal was not to talk about myself per se (as I
entertain no illusions that either I or my work is of any great
value to Debian, nor will I claim to be more than even a marginal
example in favor of my point), but merely to stand up and be
counted. I don't expect to sway your opinion that only packages
maintained by people intent on becoming official DDs are of any
quality or worth; but just as you seemed inclined to provide it, I
felt compelled to present a counter-argument against such broad
generalization.
In recent years, I have seen several discussions on devel in which
it was suggested that the number of DDs is unnecessarily high, and
that it's entirely possible to provide a wide variety of valuable
resources to the project without requiring official DD status. These
arguments seemed (to me) quite cogent, just as have the arguments
suggesting the number of packages in main is unnecessarily high. If
you (or others) feel that I am part of the problem, I suppose I'll
just have to live with that.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 10/26/07, Christoph Haas [EMAIL PROTECTED] wrote: We have been running mentors.debian.net for years already Some thoughts: Aside from the metrics idea I put on the wiki page, I think it is fairly important to merge REVU, mentors.d.o and sponsors.d.o into one site. The metrics idea would allow me to prioritise packages based on criteria that I think are important (failed puiparts, FTBFS on sid or on $arch, 5 zillion lintian errors, overrode all the lintian errors instead of fixing them, won't enter NM become a DD), preventing me from wasting time on packages that I won't sponsor due to too many problems. It also helps sponsees see how their packages stack up to the quality standards of DDs who will be doing uploads and also helps them improve their packages. For each metric, the sponsee should also be able to add a comment; for example: these linda errors are bugs in linda or this package is only for $arch. I think having buildds behind mentors.d.n is important, if only for the lintian and puiparts checks on the resulting binary packages and the effect of those on the metrics. If we don't have physical machines that could do builds testing (buildd.net folks could probably help there), then qemubuilder and vlosuts could be one option. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Cyril Brulebois wrote: Is dtc considered an (almost) perfect (simple) package from your point of view? No. It's far from perfect, and all but simple. And also, I consider it VERY outdated in the archive, I wish my corrections were uploaded. Anyway, why are you talking about it? It's completely away from this thread. There are people clearly not willing to fix problems. And not willing to learn. I've seen “there're still errors, but that's OK with me, feel free to fix them before uploading” [1]. I've seen people blaming people submitting patches for RC bugs, instead of being a little thankful. I've seen people wanting to (tentatively) hijack packages because the maintainer didn't want to push a more-buggy-than-the-present-one new upstream release. I've seen people doing all the above at the same time. And that's definitely not what I consider being “trying to learn”. I don't know about you, but I'd like to avoid such maintainers, be them Debian Developers, Debian Maintainers, New Maintainer applicants, or occasional Maintainers. And again, that's not about bashing newbies, see the previous list. Isn't that a minority? And do you think that a voting system would prevent that? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vanity packages (was: mentors.debian.net reloading)
On 10/29/07, The Fungi [EMAIL PROTECTED] wrote: I would consider its popularity low (187 popcon installs with 46 votes). I consider such fringe packages to be the main benefit of using Debian. That is; it is the diversity (or universality) of Debian that is attractive and useful. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Ondrej Certik wrote: Perhaps even for PPA-like services. I'm thinking a similar way (using a Python web framework - although a different one). Yeah, unforutunately there are several good python frameworks. But I don't mind any framework, as long as its going to work. Do you know about Django? I heard good things about it. Your thoughts? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 10/29/07, Thomas Goirand [EMAIL PROTECTED] wrote: Ondrej Certik wrote: Perhaps even for PPA-like services. I'm thinking a similar way (using a Python web framework - although a different one). Yeah, unforutunately there are several good python frameworks. But I don't mind any framework, as long as its going to work. Do you know about Django? I heard good things about it. Your thoughts? That's what I am using in debppa. Works well for me. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Henrik Andreasson wrote: And a possibillity to vote for the package maybe, then a sponsor can use that information if the want in the decission what packages to sponsor? I don't like this idea at all. With that, what you will see is that maintainers that have lots of friends, or that are maintaining famous packages, will get a high score. I don't think it will help to distinguish good or interesting packages. Also, I don't think a package should be left behind just because not a lot of people voted for it. How about very specific things, like for science tools, for which the big majority don't even understand the purposes? For sure, they wouldn't get a big score with a voting system. It doesn't make them less valuable, and I think it make sense to have them included in main... Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Thomas Goirand [EMAIL PROTECTED] (28/10/2007): With that, what you will see is that maintainers that have lots of friends, or that are maintaining famous packages, will get a high score. The opposite is true too. Infamous wannabe-maintainers could get blacklisted or so. Unsure how bad that would be. How about very specific things, like for science tools, for which the big majority don't even understand the purposes? For sure, they wouldn't get a big score with a voting system. It doesn't make them less valuable, and I think it make sense to have them included in main... AFAICT there are several DDs in those teams; manpower is lacking, not upload rights. -- Cyril Brulebois signature.asc Description: Digital signature
mentors.debian.net reloading
Valued community... We have been running mentors.debian.net for years already and I really enjoy seeing how many people are using it. It was a lot of effort writing all the scripts and magic that makes the service useful although a lot may be hidden in the background. It is watching debian-devel-changes to see if packages were sponsored. It is monitoring downloads to give the package maintainer statistical information. It announces new uploads on IRC. It informs the Uploaders:. It does a lot of QA checks etc. Many parts of the site need improvement though and I received a lot of feature requests during the last months already. Unfortunately the Python code isn't something to be entirely proud of. So it makes sense to rethink and refactor its design instead of quickly adding dirty hacks to add features. I read Lucas Nussbaum's blog entry on [0] and while it comes up with only few things I did not yet have on the todo list I think he's right. And he motivated me to start working on the concepts these days. So the goal is to make mentors.debian.net a hybrid of what it currently is (with cleaner Python code) and a social networking site. I was also pointed at the svnbuildstat site [1] to gather ideas although it rather deals with how well the team-maintained packages build. And there is Ubuntu's effort of personal package archives [2] where their Launchpad application allows people to publish packages they upload. Last but not least we have the sponsors site [3] run by Neil McGovern which is also a classic in package sponsoring. I don't think we have many clashes with other services though. I wouldn't like to steal anybody's show. Least do I like to hear of other people making similar efforts. Competition is a good thing of course but I'd find it demotivating to offer a service and investing a whole lot of spare time only to find out to be in a race-condition with a competitive project. That would be a waste of time. I don't want to win a prize. I'd like to improve the service while making it more useful and having a little fun while doing that. So the reason I'm posting here is that I'd like to allow everybody to contribute ideas and perhaps even manpower to the redesign. In the past we have started the project as a team but since everyone else had their own priorities and since such a big project can't be coded in a month they lost interest so that in the end it was me poor guy being left alone. I don't mind that but I'd rather enjoy if other enthusiasts would have fun with concepts, database design, web design, Python/Pylons coding, doing user support etc. so that we may create an even better mentors site than it is now. I have summarized a current list of ideas on my wiki [4]. If you like to edit the page please register an account at the wiki and mail me your wiki name. Due to spamming the wiki is read-only for the public crowd by default. Feel free to drag items out of that list and discuss it here. I intend to create a few mockups in the next days so that it may become clearer what ideas I have on my mind. If you like to get your hands dirty feel free to subscribe to the mentors-ops [5] mailing list. Hopefully we'll get a nice team together and have some coding fun. Thanks for your time. Kindly Christoph [0] http://www.lucas-nussbaum.net/blog/?p=258 [1] http://svnbuildstat.debian.net/ [2] https://launchpad.net/ubuntu/+ppas [3] http://sponsors.debian.net/ [4] http://workaround.org/moin/MentorsTodoList [5] http://workaround.org/cgi-bin/mailman/listinfo/mentors-ops -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 26/10/07 at 11:42 +0200, Christoph Haas wrote: It does a lot of QA checks etc. Could you please describe what's currently being done wrt QA checks? I have summarized a current list of ideas on my wiki [4]. Any reason why wiki.d.o is not used for this? It would make it much easier for people to contribute. Some comments: Please seperate features list and implementation details: if you want other people to contribute, you might have to be flexible with things such as which framework/language you choose. Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 12:11:06PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 11:42 +0200, Christoph Haas wrote: It does a lot of QA checks etc. Could you please describe what's currently being done wrt QA checks? Done. See Uploading/Importer on http://wiki.debian.org/DebianMentorsNet I have summarized a current list of ideas on my wiki [4]. Any reason why wiki.d.o is not used for this? It would make it much easier for people to contribute. Right. Moved to wiki.debian.org. Some comments: Please seperate features list and implementation details: if you want other people to contribute, you might have to be flexible with things such as which framework/language you choose. Regarding frameworks: since I'm pretty active in the Pylons project and probably will have to do 50% of the work myself anyway (currently 99%) I chose the weapons. I hope others are more flexible and like my choice. :) The list is deliberately kept a bit sketchy. When it comes to planning the actual application I intend to have a thorough documentation. Right now it's more like mental notes on how to do certain things. Just ignore them if they don't make sense. Nothing is fixed on the list. But I won't turn a coffee machine into an nuclear power plant so some parameters are fixed. And it will have to be Python because otherwise even the utility libraries would have to be rewritten. It's not like we'd have to start entirely from scratch. Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. Might be helping the sponsor to determine if the package builds. But I'm not sure if it's worth it. Just my personal opinion. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 12:11:06PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 11:42 +0200, Christoph Haas wrote: It's time for me to introduct svnbuildstat.d.n :). I began to work on svnbuildstat 1,5 year ago. We, the Debian Games Team, saw the number of packages in our repository constently growing up (170 today). We were about 10 actives maintainers and it was had to find the packages to take care on. The initial release was based on a collection of shell script and pbuilder. The builds were done directly on my server. But there were some problems: * The tool was designed to fetch information from just one svn repository * They was no database and doing statistic stuff without a DB sucks big * time! * The shell scripts were hard to maintain * Resource expensive stuff were done directly on the webserver (the build, lintian, linda, piuparts) Some mouths after I rewrote from scratch what is the current svnbuildstat.d.n. This time it's based on a real database and a modern MVC framework. It's definitivly a better solution. I used : * Perl; * Catalyst, a MVC framework; * DBIx::Class a DB abstaction layer like Hebernate; * PostgreSQL (the DB is about 500MB today) * a collection of perl scripts to retrieve the different informations * a client/server model for the build/lintian/linda/piuparts. Just a * status file is returned to the server at the end of the process. Today, I'm working these point: * The agent does too much stuff, I want to split it to have one agent * per service (build, lintian, ...). Today, if I want to change the * lintian revision, I've to update of the build host and one of them is * behind a firewall. * Ondrej Certik is working on a patch for pbuilder to detect the no space on device errors. it's most of the false positive. * The DB schema needs some clean up. I already did most of them (I wish:)). * being able to accept other sources of packages. I want to be able to retrive information for the rest of the VCS used in Debian but also from a pool of packages like mentors.debian.net or ftp.debian.org * RPC services. * Thanks to Ondrek Certif, svnbuildstat has a tutorial now on wiki.d.o but there is still a lot to do here * I want to get another server. Mine is a bit to slow. I think, svnbp should be (one day*) used as backend for http://mentors.debian.net/ but also for Lucas's QA check. *Like most of yours, I've a family, packages and softwares to maintain and a job. To be honest, it's hard for me the give a clear planning. The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat Regards, Gonéri signature.asc Description: Digital signature
Re: mentors.debian.net reloading
Hi, The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat I believe Debian needs the same as Ubuntu has: Personal Package Archives, where new maintainers could upload their source packages and the service will automatically build and check the package. And if the service says YES, it means the package will builds on buildd hosts and is lintian/linda/piuparts clean, all bugs are correctly closed, etc. etc.. I, as a user, need this feature, so that when I fix something in a package, or create a new one, can simply check it a little at my computer and then upload it to Debian PPA and it will do the rest of the checks for me. And if it says YES, I'll ask my sponsor to upload it. At the moment I need to do all of this by hand and it's very time consuming. And then my sponsor needs to do the same, to be sure I didn't make a mistake. With Debian PPA, my sponsor can easily be sure the technical things are ok and concenrate on QA. There is of course a question who will provide the resources for DebPPA. But as first step, all the building blogs should be as Debian packages, so that I can just install a few packages, setup a few config files and I'll be having my own DebPPA up and running. I started: http://code.google.com/p/debppa/ It contains links to all relevant discussions about this issue. But when I found svnbuildstat, I want to work with Goneri. As Gonéri said, we are trying to create such building blogs - a server that will accept source packages (I only need source packages, Goneri also needs input from VCS), and buildbots, that will do the compiling. As I see, we all have a little different views and what the service should or shouldn't be doing. But if we make sure we create robust and small building blocks, then all of us can easily set up a service that each of us wants. Ondrej
Re: mentors.debian.net reloading
It could be better. I just doubt that the private issue is the problem. Everybody who likes to get involved could always join the team. We are open. So it's really no giant master plan that the sources weren't made public yet. Perhaps with the relaunch we can start to make I think it is a major problem, that anyone who wants to create a similar things, like me, but for example providing the building and personal archives (that you don't want, or at least didn't want, because of the download bandwidth) has to reinvent everything from scratch. everything public right from the start. The only reason it's a one-man-show is that from our 3-people-team one (Ivo) is studying like hell and the other (Matthijs) is kept busy by his boss at work. I don't intend to be posessive here. mentors.debian.net was invented to improve the sponsorees' situation. I'm confident it has done that and believe that way more packages are sponsored instead of trashed. I wouldn't want to see it perish for no reason. But I'm also not the showstopper when it comes to changing things. There is no doubt mentors.debian.net is doing it's job and doing it well, so no need to perish it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 26/10/07 at 14:18 +0200, Christoph Haas wrote: Please seperate features list and implementation details: if you want other people to contribute, you might have to be flexible with things such as which framework/language you choose. Regarding frameworks: since I'm pretty active in the Pylons project and probably will have to do 50% of the work myself anyway (currently 99%) I chose the weapons. I hope others are more flexible and like my choice. :) The list is deliberately kept a bit sketchy. When it comes to planning the actual application I intend to have a thorough documentation. Right now it's more like mental notes on how to do certain things. Just ignore them if they don't make sense. Nothing is fixed on the list. But I won't turn a coffee machine into an nuclear power plant so some parameters are fixed. And it will have to be Python because otherwise even the utility libraries would have to be rewritten. It's not like we'd have to start entirely from scratch. Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. Might be helping the sponsor to determine if the package builds. But I'm not sure if it's worth it. Just my personal opinion. I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. Your emotion chip went a bit wrong, but not totally ;) I have the feeling that the lack of open-ness in mentors.d.n caused several people to reinvent it (with sponsors.d.n and REVU). Of course, it's not the only cause, but I have the feeling that mentors could be much better than it currently is, but isn't, because of the fact that it was developed privately. I hope that things will change, but everybody has to have an open mind if we want this to happen. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 14:18 +0200, Christoph Haas wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). Right. But although I used to sponsor a lot of packages hardly any of them actually failed to build. Mostly because the maintainer forget a certain dependency. But it's certainly possible to run pbuilder on the package. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. Your emotion chip went a bit wrong, but not totally ;) I have the feeling that the lack of open-ness in mentors.d.n caused several people to reinvent it (with sponsors.d.n and REVU). I know that several people have asked for the source code of mentors.debian.net and I always hesitated because in the beginning the code stunk and I feared security implications. (Yes, I believe that security by obscurity partly works.) sponsors.debian.net came up shortly *after* the time that mentors.debian.net was put online. And we talked about how to join forces in the early stages. REVU was developed a while after mentors.debian.net was launched. I'm not sure but I think mentors.debian.net was already there when nobody even talked about Ubuntu. Mark invited me to the Ubuntu conference in Mataro in 2004 after mentors.d.n was online for a while. It was the time that the MOTU process and REVU was planned. And IMHO REVU doesn't do as much as mentors.d.n - although it has a comment feature already. Of course, it's not the only cause, but I have the feeling that mentors could be much better than it currently is, but isn't, because of the fact that it was developed privately. It could be better. I just doubt that the private issue is the problem. Everybody who likes to get involved could always join the team. We are open. So it's really no giant master plan that the sources weren't made public yet. Perhaps with the relaunch we can start to make everything public right from the start. The only reason it's a one-man-show is that from our 3-people-team one (Ivo) is studying like hell and the other (Matthijs) is kept busy by his boss at work. I don't intend to be posessive here. mentors.debian.net was invented to improve the sponsorees' situation. I'm confident it has done that and believe that way more packages are sponsored instead of trashed. I wouldn't want to see it perish for no reason. But I'm also not the showstopper when it comes to changing things. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Hello, On Fri, 26 Oct 2007, Christoph Haas wrote: That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Perhaps this is not what your question is about but, ... One way is to use some package caching proxy like approx (which I use) to get the packages. Over time this builds itself a copy of the relevant portions of the Debian archive. Of course, since the builds are against unstable the cache gets out-of-date often but most of these caching tools are good at handling that. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Hi, There is of course a question who will provide the resources for DebPPA. You could at least ping the experimental/backports/volatile people. I started: http://code.google.com/p/debppa/ Why on code.google.com? Is Alioth not good enough? Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 26/10/07 at 16:06 +0200, Christoph Haas wrote: On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 14:18 +0200, Christoph Haas wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) It works fine, but takes some time. I ran piuparts several times over the whole archive, without running into severe problems. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). Right. But although I used to sponsor a lot of packages hardly any of them actually failed to build. Mostly because the maintainer forget a certain dependency. But it's certainly possible to run pbuilder on the package. What Ondrej proposes is to turn mentors into a package archive, where packages would be built automatically on several arches, and people could download them. In that case, it's required to build package for all archs available in the service (you can't ask the uploader to do that hmiself). -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, 26 Oct 2007, Christoph Haas wrote: Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. Might be helping the sponsor to determine if the package builds. But I'm not sure if it's worth it. Just my personal opinion. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. I would like to briefly comment that if you want some compute time for something lke this, let me know. I see above that you think you should be okay, but should that ever change let me know; I'd be very happy to donate my spare cycles to making package sponsoring work better. I'm personally very much a fan of automatic testing/building of packages. -- Asheesh. -- I am not now, nor have I ever been, a member of the demigodic party. -- Dennis Ritchie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 04:51:01PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 16:06 +0200, Christoph Haas wrote: On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 14:18 +0200, Christoph Haas wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) It works fine, but takes some time. I ran piuparts several times over the whole archive, without running into severe problems. I'll try that out. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). Right. But although I used to sponsor a lot of packages hardly any of them actually failed to build. Mostly because the maintainer forget a certain dependency. But it's certainly possible to run pbuilder on the package. What Ondrej proposes is to turn mentors into a package archive, where packages would be built automatically on several arches, and people could download them. In that case, it's required to build package for all archs available in the service (you can't ask the uploader to do that hmiself). Did Ondrej say that we need a public buildd? Actually that is something I would ratner not do because I have certain (very bad) experience with it. When we kept the uploaded binary (.deb) packages our support mailbox was literally flooded with end-users (!) complaints that the packages were buggy. They used it as debian-multimedia or other inofficial binary package repositories. I think that making it more a PPA-style service it a good idea - for *source* packages. But don't you think the focus is still the sponsoring process? I can't think of a case where people want to publish Debian packages but don't want them to get into Debian. Traffic is another concern. Without binary packages we are having less than 1 GB traffic from mentors. With binary packages it was a few hundred GB. I didn't have to pay for it but if people (ab)use it as marillat V2.0 then I wouldn't bet on the numbers any more. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Friday 26 October 2007 15:26, Lucas Nussbaum wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. I'm not sure if I understand this right, but what would be done with the result of the tests you'd run on mentors? My problem with piuparts is not the setting up, but the amount of false positives it gives, at least on my packages. If you flag packages as does not pass piuparts it may be percieved as a package being of inferior quality, but there may be many reasons to fail piuparts. Most notably piuparts can not discriminate between a problem in my package or in a package I depend on. That could have changed of course in the very recent past? To be clear, I think that piuparts is a very worthwhile tool, but not something to require of packages to pass, or to use as a binary quality measurement for a package. The results are very useful, but only if you thoroughly inspect the cause of failure. Which has to happen by hand. Thijs pgprpQLavkeRr.pgp Description: PGP signature
Re: mentors.debian.net reloading
Did Ondrej say that we need a public buildd? Actually that is something I would ratner not do because I have certain (very bad) experience with it. When we kept the uploaded binary (.deb) packages our support mailbox was literally flooded with end-users (!) complaints that the packages were buggy. They used it as debian-multimedia or other inofficial binary package repositories. I think that making it more a PPA-style service it a good idea - for *source* packages. But don't you think the focus is still the sponsoring process? I can't think of a case where people want to publish Debian packages but don't want them to get into Debian. PPA is a means how to get the packages to Debian and to ease the process of it, for everyone. And I think we need a public PPA. Your technical counterarguments can be solved imho, see below. Besides those you also have a social argument - that you fear it will actually decrease the number of new packages in Debian, or that it will increase the number of unhappy users. I think it will actually be the opposite, but that's just my opinion. --- By providing buildbots as a debian package, so that anyonce with a computing power can just install the bot and it will automatically start compiling the packages and uploading them to PPA etc (as to security, I am sure that can be solved satisfactorily too). The traffic can be solved by providing an easy packages, so that more people can host PPA on their servers. Etc. Basically I think all of those and similar problems can be solved, if we want to. There is of course a question who will provide the resources for DebPPA. You could at least ping the experimental/backports/volatile people. Right. But even if we don't find anyone now, who can host it, I still would like to have those packages, so that I can at least easily install it for myself. I started: http://code.google.com/p/debppa/ Why on code.google.com? Is Alioth not good enough? Google has much better interface and I can create wiki pages with documentation in there. But alioth is powered by gforge, right? That looks quite good too: http://gforge.org/projects/gforge/ And even seems to have wiki. Is alioth going to be upgraded? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 03:47:09PM +0200, Ondrej Certik wrote: The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat I believe Debian needs the same as Ubuntu has: Personal Package Archives, where new maintainers could upload their source packages and Agreed. the service will automatically build and check the package. Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? During the sponsoring process having a binary package is pretty useless. A sponsor will/should always take the source package, build it again and check both the source and the binary package. And if the service says YES, it means the package will builds on buildd hosts and is lintian/linda/piuparts clean, all bugs are correctly closed, etc. etc.. I, as a user, need this feature, so that when I fix something in a package, or create a new one, can simply check it a little at my computer and then upload it to Debian PPA and it will do the rest of the checks for me. And if it says YES, I'll ask my sponsor to upload it. So far so good. Although you shouldn't rely on an automated tool but rather use it in addition. I wouldn't sponsor a package just because lintian doesn't complain. At the moment I need to do all of this by hand and it's very time consuming. So is package maintenance. And then my sponsor needs to do the same, to be sure I didn't make a mistake. Correct. Because the sponsor will be responsible for the package at that moment. The only solution I see here is that the package maintainer becomes a Debian developer or Debian contributor. With Debian PPA, my sponsor can easily be sure the technical things are ok and concenrate on QA. Aren't technical things == QA? There is of course a question who will provide the resources for DebPPA. And for the many architectures we have. It contains links to all relevant discussions about this issue. But when I found svnbuildstat, I want to work with Goneri. As Gonéri said, we are trying to create such building blogs - a server that will accept source packages (I only need source packages, Goneri also needs input from VCS), and buildbots, that will do the compiling. Isn't that what buildds are about? Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 07:55:09PM +0200, Ondrej Certik wrote: PPA is a means how to get the packages to Debian and to ease the process of it, for everyone. What do you mean by get the package to Debian? Sponsorship? Or creating a competing repository for end-users? Besides those you also have a social argument - that you fear it will actually decrease the number of new packages in Debian, or that it will increase the number of unhappy users. I think it will actually be the opposite, but that's just my opinion. I'm scared by the thought that there will be a dozen PPAs that end-users will use to get their software from third-party sources. IMHO good packages should go officially into Debian. And bad packages should go to hell. Sponsorship might be a problem sometimes which may be solved by the Debian Maintainer status which should allow you to upload packages into Debian. I would hate to read on mailing lists the version of 'kaffeine' in Debian is outdated. There is a newer version in PPA X that you could use. Or you use the version in PPA Y which is even newer but I hard it's broken. (shiver) Basically I think all of those and similar problems can be solved, if we want to. I'm absolutely on your side. Just not for the binary package part which scares me. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, 26 Oct 2007, Christoph Haas wrote: On Fri, Oct 26, 2007 at 03:47:09PM +0200, Ondrej Certik wrote: The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat I believe Debian needs the same as Ubuntu has: Personal Package Archives, where new maintainers could upload their source packages and Agreed. the service will automatically build and check the package. Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? Every once in a while, people post to debian-mentors about their package failing to build on the buildd for some architecture they don't have access to. It'd be nice to get automated complaints about that before buildd time. This does not need to be part of the core Debian Mentors architecture; someone could just automatically grab all the .dsc files and spend CPU cycles emulating every architecture we have and building some packages and posting the log. (I'm willing to use my cycles for that, for example.) -- Asheesh. -- Nothing is as simple as it seems at first Or as hopeless as it seems in the middle Or as finished as it seems in the end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Google has much better interface and I can create wiki pages with documentation in there. But alioth is powered by gforge, right? You can just use your favorite wiki software on alioth. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, 26 Oct 2007, Christoph Haas wrote: One idea I have (but is not sure it should go into mentors though) is to try to add a use-report to build-report, anybody could download and try to build and accually use the package, then submit a report that the program accually works and does what's in the description. Also a rating on the package maybe ? And a possibillity to vote for the package maybe, then a sponsor can use that information if the want in the decission what packages to sponsor? //Henrik Andreasson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26-10-2007 11:26, Lucas Nussbaum wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). I'm not sure if Ana is subscribed to -mentors, so I'm cc:ing her. Ana (cc:ed), aren't you working on something like piuparts.d.n (or maybe piuparts.d.o)? Perhaps it could be related/integrated with mentors.d.n? Take a look at this thread: http://lists.debian.org/debian-mentors/2007/10/msg00301.html Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIkfmCjAO0JDlykYRAroUAKCLkRTHv8ll+guAHaWRSSoHsCJl3wCg004g HPwX94l1ikgOmuNg6nDEGx8= =ypEm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Asheesh Laroia [EMAIL PROTECTED] (26/10/2007): Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? Every once in a while, people post to debian-mentors about their package failing to build on the buildd for some architecture they don't have access to. It'd be nice to get automated complaints about that before buildd time. I had such a problem on a very single architecture (hppa) for openscenegraph. Once that one *knows* that there are some problems on this or that arch, the point is about solving it. Not being told in advance whether this problem is fixed, or isn't. BTW, buildd time is considered cheap these days (discussed some time ago on d-release@ or #d-release) — although I agree that periodically some archs have troubles to keep up. This does not need to be part of the core Debian Mentors architecture; someone could just automatically grab all the .dsc files and spend CPU cycles emulating every architecture we have and building some packages and posting the log. (I'm willing to use my cycles for that, for example.) I'd better see the possibility of getting an access to the offending archs to try and figure out what the problems are and to fix them. Depending on the archs, it can be easy to get an account (hppa is a very good example, thanks to the available clusters), or it can be very tricky; in that latter case, emulation can help a lot. Cheers, -- Cyril Brulebois signature.asc Description: Digital signature
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 10:34:03PM +0200, Cyril Brulebois wrote:
[...]
I'd better see the possibility of getting an access to the offending
archs to try and figure out what the problems are and to fix them.
Depending on the archs, it can be easy to get an account (hppa is a very
good example, thanks to the available clusters), or it can be very
tricky; in that latter case, emulation can help a lot.
I went to the extreme of trying to collect and maintain Debian on an
actual physical representative from each supported architecture (I'm
up to 9 now, missing arm, ia64 and s390 still), and can say from
experience that it's neither a simple nor entirely cheap
alternative.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Christoph Haas wrote: That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Best option is to run something like apt-proxy or even squid (if you can't afford a full mirror) so you don't have to pull and pull again the same packages all the time. I don't think that downloading the dependency would be the issue, unless you have a VERY slow network. I don't intend to be posessive here. mentors.debian.net was invented to improve the sponsorees' situation. I'm confident it has done that and believe that way more packages are sponsored instead of trashed. I don't know if it helped that some package were not trashed, but I'm 100% sure that what you did is VERY convenient. Lucas Nussbaum wrote: Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. If a server is needed, we could provide it as sponsorship. Something like a core 2 quad core (Q6600) running Xen with few gigabytes of RAM could be provided if it's needed to have such power, and if it can help to have such computer. Let me know if you want us to do so. Thomas Goirand, GPLHost CEO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
