Sponsorship for new packages
Hello, is there any plan to provide a sponsorship[1] like process for new packages ? I am thinking on something like, a process which would allow a non MOTU Hopeful to upload a package, it would be triaged and either enter a queue where it could be reworked by MOTUs or it would be discarded. Thanks [1] https://wiki.ubuntu.com/SponsorshipProcess -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: non-MOTU Hopeful contributions (was:: GetDeb Project (Why I participate))
> I very much agree with what Scott said here. Understanding the process, > talking to people when you're unsure and being a good team player is > very important in the MOTU team. > > Does anybody have any ideas, what we could do to 'lower the bar' or > change the things to bring new contributors to the point where they > understand better what our core values are? > IMHO, the point is not about lowering the bar, is is about not having the "bar" at all, the key is about converting the current MOTU processes which are based on a long pipe workflow with known bottlenecks into a grid workflow . The current process requires, developers which love debian/rules, but which hate debian/copyright to be expert on both. The current process requires end users, which love to test new software, and which would be the best functional testers for new packages/updates to subscribe this list in order to get "please test" notifications. IThis list is not really interesting for those people which spend more time using applications, than packaging them. The key, is about moving from single processing, to multiprocessing, different people, with different skills can provide their specif contribute to the final product which is, a good package, proper tested from both a packaging and functional perspective and which will be updated according to a policy which also meet users expectations. Changing from single to multi processing is not simple, it is not just about adding new processors (in this case, people), it is about changing the application, building reliable interfaces between processes, handling shared resources, handling synchronization, etc. The documentation improvement is important because it is the entry point for participation, however, it is not sufficient. Best regards, -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
GetDeb Project
Hello, I am the GetDeb project founder and manager, I would like to present GetDeb, current status and planned goals. Introduction --- The GetDeb idea born about 1 year ago, the motivation came from forums participation, where it was very common to find end users struggling to build some software on their systems, or just asking for help on broken systems after trying to use incompatible repositories. I did some research on the processes to get a software updated or introduced into Ubuntu at that time, they were complex, developers (not users) oriented and with requirements that could not be covered by a significant part of the software packaging requests. Policy and Methodology -- We provide packages only for the "current" Ubuntu distribution release, our updates are upstream based, the opposite of the Ubuntu Stable Update Release policy, we take the latest upstream update as the most stable and apply the packaging and/or Debian/Ubuntu integration specific patches, when available we use Debian/Ubuntu or 3rd parties merging work. Package updates which depend on library updates that may interfere with other main/universe packages are NOT provided. Current Status --- After 1 year of existence the project turned from a 1 person spare time package building, web development and, the most important task, users feedback handling to a small team work project with occasional but very important third party contributers. On a daily basis we provide an average of >5K .deb packages, 100 GBs distributed over about 10 mirrors. We have > 7K registered users (the only features available on registration is the ability to comment releases and get site news). One of our important accessibility factors is internationalization, 99% of the site template is translatable and already translated into more than 20 languages. The applications description is also translatable, however that is still a young and not very polished feature, at this moment we have about 1K application descriptions translated to random languages. Despite of our short existence we are listed on the first page of google searches for Ubuntu software, which we observe as a good popularity indication. Financial --- Our work is volunteer mostly free time work, we have no business financial goals, we do accept financial support, mostly for material acquisition. Our automated build system server is about to become paid (500 Euros) from paypal donations. The web site hosting costs are covered with the google adsense income. The download traffic is covered by the entities which are supporting us with mirrors. Future Plans --- Move to APT based software distribution - Most people ask why aren't we using APT yet, the answer is simple, there is no APT based implementation for a project with our distribution model, there are some limitations that we still need to address Internationalization improvement - One of the current problems is the mix between english contents and local contents and contacts (this can be seen on the comments section) I have no specific mention to collaboration with the Ubuntu/Debian universe, backports, developers, packaging teams, that is our philosophy and practice, we belong to the same community. I will appreciate any questions/comments/suggestions. References -- The Site: http://www.getdeb.net/ Download stats: http://www.getdeb.net/graphs/release_all.php Internationalization: http://www.getdeb.net/languages.php Financial: http://www.getdeb.net/financial.php Building Process: http://wiki.getdeb.net/Package_Building Launchpad Project: https://launchpad.net/getdeb.net Best regards, -- João Pinto IRC: Lamego @ irc.freenode.net Jabber ID: [EMAIL PROTECTED] GetDeb Project Manager - http://www.getdeb.net -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: XSB-Url header for Upstream Homepages
Hello, in my opinion it is a good option, a specific machine readable homepage URL could later be used by package management tools to provide more information about the software being installed. Best regards, 2007/8/19, Reinhard Tartler <[EMAIL PROTECTED]>: > > Hi fellow ubuntu developers, > > in the past, we have been adding Urls to the project homepages to the > package description. ATM, there is a (small) debate if a XSB-Url header > should be invented for this purpose. > > How do you feel about that? > > -- > Gruesse/greetings, > Reinhard Tartler, KeyID 945348A4 > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- João Pinto GetDeb Package Builder http://www.getdeb.net -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Packages updates on REVU
Hello, I hope that you also agree that is not very encouraging for a new packager to submit a package to REVU and because he does not have enough patient to keep on an IRC channel he waits 2 months to get a comment like "There is a new upstream version" and no comments on all the packaging aspects that maybe relevant for the package upgrade. A few more weeks and a more experienced package maybe uploading it to Debian, and eventually the work is lost. Sorry but I will need to write a very negative comment, in my humble opinion REVU is horrible, the application and the process, I can't help improving it because I do have a different idea for software availability which does not match with the Ubuntu release cycle. Best regards. 2007/4/22, Scott Kitterman <[EMAIL PROTECTED]>: On Sunday 22 April 2007 12:28, Lionel Le Folgoc wrote: > * So, how can we improve this? > > I think the REVU/wiki page has to be updated, to explicitely say: > "When-you-upload-a-package-go-on-#ubuntu-motu-and-cry-and-yell-until-you-ge >t-a-MOTU-to-review-it". I think that it probably needs more of a come join in with maintaining Universe and we'll be glad to make you stuff more of a priority perspective. Yes, packagers need to be proactive, but they also can help themselves by helping Ubuntu. They also need to understand that you can't force volunteers. There was one guy that uploaded a package and when it hadn't gotten a complete review in a handful of hours went and complained to sabdfl. I'd given the guy a few suggestions in what time I had, but his impatience and complaining to sabdfl have pretty well demotivated me with respect to helping him (not that my help's such a big deal, but I'm guessing I'm not the only one that would react that way). Finally, I think it would be useful if there were people who, while not yet MOTU, had some packaging experience, were authorized to comment (but not advocate) packages on REVU. There are a number of packages that have basic issues that less experienced reviewers can help with. If we can help with those packages, the MOTUs can better focus on ones that are close/ready to upload. This would also give MOTUs an additional source of information on people's ability to review packages when they are deciding if someone is ready to be a MOTU. Scott K P.S. I came in in the middle of Feisty development and have no complaints about the attention my packages got or the quality of the reviews. Whatever improvements can be made, I don't think the situation is broken. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- João Pinto GetDeb Packager http://www.getdeb.net -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: getdeb.net
Hello, some more comments about upgrades in general and the backport request process. I hope it is clear for the Ubuntu development team that the existing SRU policy fails to meet the majority of desktop users expectations regarding application upgrades. You can confirm that by looking into the forums for the several postings about users asking when version Y will be available on the updates. This is also because on other OSes (guess which) most of the applications have already self-upgrade functions, such upgrades are defined by the authors according to the applications own roadmap. The back porting process is expected to overcome this but in my opinion it still doest not meet users expectations because: - Backports are Ubuntu+1 release based (in my opinion they should be application release based) - It's visibility is not sufficient (at the moment most people which uses backports are probably those which know how to build from the source) The current backport request process is a technical oriented processed, meaning backports are initiated by technical persons, which have the ability to lookup if the package is in Ubuntu+1, if the upgrade can be done as an SRU or not, etc. This results on backports being implemented for applications which have a broader technical audience and not based on users requirements. I understand that there are a lot f other things to manage besides user's expectations like applications stability, Ubuntu specific integration, etc. but I still feel that the current rules/procedures are too blind. There are critical and non critical applications there complex and trivial changes and they can't simply be treated all by the same rules Best regards, -- João Pinto GetDeb Packager http://www.getdeb.net 2007/3/8, João Pinto < [EMAIL PROTECTED]>: Daniel, before answering to your questions let me explain better the context of my comments regarding the packaging and updates policy. From my experience, home PCs and enterprise PCs don't share the same requirements. The current policy/processes are mandatory for enterprise/business IT managed environments where sw and hw upgrades are (slow) business driven and the key factors are security, stability, certification and support. At home, upgrades are user's driven and the key factors are features, people want to be able to use their latest gadget and to export files to the newest online service they have subscribed, etc, etc., for those this strict policy may be an adoption blocker. I believe Ubuntu/Debian packaging aims business IT, while I am aiming home users. Answering your questions: The sources are not available online yet, I have this pending with the script which is not yet implemented that will take care of populating the getdeb database and upload all the files, please note that I am not using a repository and the associated tools. I am providing the sources every time I get a request, which is rare, most of getdeb visitors are end users which have no use for the source. I understand the benefits on working a greater team like the MOTU but to be honest I don't believe I would be able to participate to the Ubuntu users as much I believe I am doing with GetDeb. Browsing on REVU I don't see that much activity and I see packages introduced from September which are pending, to be honest, such "Welcome to REVU" is not encouraging for someone willing to provide the newest applications to the users. Please don't get me wrong but in my opinion the best hands to fix bugs are the software developers not the software packagers, if it's a trivial bug, I will fix it and contact the author, if is not trivial it should be up to the upstream developers to fix it, turning the packagers into co-developers is not very efficient, specially for bug fixing. Ideally it would be the way around, developers providing and updating their own packages. I have not decided yet about the bug reporting system, it will point to a launchpad entry or I will use the upstream bug reporting system. Despite our different approaches and concerns I am sure we will be able to cooperate. Best regards, 2007/3/8, Daniel Holbach <[EMAIL PROTECTED] >: > > Hello João, > > On Do, 2007-03-08 at 13:33 +, João Pinto wrote: > > I have been a software developer for a long time and just recently got > > interested into software packaging, mostly because during my Ubuntu > > forum's participation I realized there is a lot of non-developers > > spending too much time to get a specific application or feature which > > is not yet available on the repositories. > > I am not an experienced packager but I did understood the strict > > policy/requirements to be a Debian/Ubuntu maintainer by looking into > > REVU and Debian mentors, I would never be able to keep > > updating/creating packages with such quality requirements and be
Trying MOTU
Hello, following Daniel's comments and questions regarding the ability to support/keep the Getdeb packages in a proper quality level I have decided to try the MOTU way. I have a few starting comments and questions. The REVU main page is terrible, what is the sort criteria for the packages list ? The following detail should be presented on the main list: - last uploader comment, last reviewer comment, package status This would allow a better assessment for both the reviewers and uploaders on packages needing more activity. I couldn't found a description of the package live cycle. Questions: 1) What is the REVU package life cycle ? I couldn't find a description on when/who classifies the package as properly packaged, and what happens at that time. Does a MOTU member need to adopt the package as a maintainer so that it gets into Universe ? 2) Should I send a notification to the MOTU informing about that I need reviewer's feedback or I should expect proper activity from the reviewers notification ml ? (I have submitted my first package yesterday and I was expecting a quick "this is bad" comment). I didn't submitted my suggestion on the revu Development Center, because it seems to be broken: http://revu.tauware.de/cgi-bin/trac.cgi The packaging guide ( http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html) is very clear, most of the remaining documentation and process description on how to get a new application into Ubuntu is quite puzzling. Best regards, -- João Pinto GetDeb Packager http://www.getdeb.net -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
About SRU and Backports
Hello, some more comments about upgrades in general and the backport request process. I hope it is clear for the Ubuntu development team that the existing SRU policy fails to meet the majority of desktop users expectations regarding application upgrades. You can confirm that by looking into the forums for the several postings about users asking when version Y will be available on the updates. This is also because on other OSes (guess which) most of the applications have already self-upgrade functions, such upgrades are defined by the authors according to the applications own roadmap. The back porting process is expected to overcome this but in my opinion it still doest not meet users expectations because: - Backports are Ubuntu+1 release based (in my opinion they should be application release based) - It's visibility is not sufficient (at the moment most people which uses backports are probably those which know how to build from the source) The current backport request process is a technical oriented processed, meaning backports are initiated by technical persons, which have the ability to lookup if the package is in Ubuntu+1, if the upgrade can be done as an SRU or not, etc. This results on backports being implemented for applications which have a broader technical audience and not based on users requirements. I understand that there are a lot f other things to manage besides user's expectations like applications stability, Ubuntu specific integration, etc. but I still feel that the current rules/procedures are too blind. There are critical and non critical applications there complex and trivial changes and they can't simply be treated all by the same rules Best regards, -- João Pinto GetDeb Packager http://www.getdeb.net 2007/3/8, João Pinto < [EMAIL PROTECTED]>: Daniel, before answering to your questions let me explain better the context of my comments regarding the packaging and updates policy. From my experience, home PCs and enterprise PCs don't share the same requirements. The current policy/processes are mandatory for enterprise/business IT managed environments where sw and hw upgrades are (slow) business driven and the key factors are security, stability, certification and support. At home, upgrades are user's driven and the key factors are features, people want to be able to use their latest gadget and to export files to the newest online service they have subscribed, etc, etc., for those this strict policy may be an adoption blocker. I believe Ubuntu/Debian packaging aims business IT, while I am aiming home users. Answering your questions: The sources are not available online yet, I have this pending with the script which is not yet implemented that will take care of populating the getdeb database and upload all the files, please note that I am not using a repository and the associated tools. I am providing the sources every time I get a request, which is rare, most of getdeb visitors are end users which have no use for the source. I understand the benefits on working a greater team like the MOTU but to be honest I don't believe I would be able to participate to the Ubuntu users as much I believe I am doing with GetDeb. Browsing on REVU I don't see that much activity and I see packages introduced from September which are pending, to be honest, such "Welcome to REVU" is not encouraging for someone willing to provide the newest applications to the users. Please don't get me wrong but in my opinion the best hands to fix bugs are the software developers not the software packagers, if it's a trivial bug, I will fix it and contact the author, if is not trivial it should be up to the upstream developers to fix it, turning the packagers into co-developers is not very efficient, specially for bug fixing. Ideally it would be the way around, developers providing and updating their own packages. I have not decided yet about the bug reporting system, it will point to a launchpad entry or I will use the upstream bug reporting system. Despite our different approaches and concerns I am sure we will be able to cooperate. Best regards, 2007/3/8, Daniel Holbach <[EMAIL PROTECTED] >: > > Hello João, > > On Do, 2007-03-08 at 13:33 +, João Pinto wrote: > > I have been a software developer for a long time and just recently got > > interested into software packaging, mostly because during my Ubuntu > > forum's participation I realized there is a lot of non-developers > > spending too much time to get a specific application or feature which > > is not yet available on the repositories. > > I am not an experienced packager but I did understood the strict > > policy/requirements to be a Debian/Ubuntu maintainer by looking into > > REVU and Debian mentors, I would never be able to keep > > updating/creating packages with such quality requirements and be
Re: getdeb.net
Daniel, before answering to your questions let me explain better the context of my comments regarding the packaging and updates policy. From my experience, home PCs and enterprise PCs don't share the same requirements. The current policy/processes are mandatory for enterprise/business IT managed environments where sw and hw upgrades are (slow) business driven and the key factors are security, stability, certification and support. At home, upgrades are user's driven and the key factors are features, people want to be able to use their latest gadget and to export files to the newest online service they have subscribed, etc, etc., for those this strict policy may be an adoption blocker. I believe Ubuntu/Debian packaging aims business IT, while I am aiming home users. Answering your questions: The sources are not available online yet, I have this pending with the script which is not yet implemented that will take care of populating the getdeb database and upload all the files, please note that I am not using a repository and the associated tools. I am providing the sources every time I get a request, which is rare, most of getdeb visitors are end users which have no use for the source. I understand the benefits on working a greater team like the MOTU but to be honest I don't believe I would be able to participate to the Ubuntu users as much I believe I am doing with GetDeb. Browsing on REVU I don't see that much activity and I see packages introduced from September which are pending, to be honest, such "Welcome to REVU" is not encouraging for someone willing to provide the newest applications to the users. Please don't get me wrong but in my opinion the best hands to fix bugs are the software developers not the software packagers, if it's a trivial bug, I will fix it and contact the author, if is not trivial it should be up to the upstream developers to fix it, turning the packagers into co-developers is not very efficient, specially for bug fixing. Ideally it would be the way around, developers providing and updating their own packages. I have not decided yet about the bug reporting system, it will point to a launchpad entry or I will use the upstream bug reporting system. Despite our different approaches and concerns I am sure we will be able to cooperate. Best regards, 2007/3/8, Daniel Holbach <[EMAIL PROTECTED]>: Hello João, On Do, 2007-03-08 at 13:33 +, João Pinto wrote: > I have been a software developer for a long time and just recently got > interested into software packaging, mostly because during my Ubuntu > forum's participation I realized there is a lot of non-developers > spending too much time to get a specific application or feature which > is not yet available on the repositories. > I am not an experienced packager but I did understood the strict > policy/requirements to be a Debian/Ubuntu maintainer by looking into > REVU and Debian mentors, I would never be able to keep > updating/creating packages with such quality requirements and be able > to have "0 days" packages together with the site building and > packaging requests scouting. I can see your point. It often takes a while to get packages * conform to the packaging policy * reviewed * included. Each of these steps takes a certain amount of time, but that for a reason. 1. Packages which conform to the packaging policy are less likely to cause problems on the user's machines. 2. Reviewed packages are less buggy, contain all the necessary information and reviewer and package maintainer both learn during the process. 3. Packages that went through the archive admins' hands are redistributable and won't cause problems for the user or the distributor of those packages. It's clear that our current process it not optimal. Therefore we're working on a new process that will make step 2 easier and shorter because of collaboration on the packaging. [1] Documentation could be easier and better, to make step 1 quicker. It'd be nice if you could check [2] and give feedback on it. [1] https://wiki.ubuntu.com/MOTU/Processes/REVU [2] https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html > Today I have added RSS Feed to GetDeb > (http://www.getdeb.net/rss.php?distro_id=3 , the id is based on the > distro selection) I think it could be a good start to monitor package > releases, however I am still missing a core requirements: > 1. The debian diffs are not (yet) available > 2. Internal revision/notification in case an already published > package needs to be updated (I am justing uploading the new .deb now) Do you publish the source somewhere? > Right now I am working on accounts support I am planning to provide > future services like new releases emails, users rating, comments, etc. >
