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 +0000, 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. > > once user login/register is finished I will work on the above points, > > I will let you know when it's ready, hopefully next week. > > > > I was already very motivated because I get frequent feedback from > > getdeb users, most of the packages and features are based on them. I > > am happy to know that I will be able to cooperate even more with the > > Ubuntu community. > > The packages you provide seem to fall into three categories: > > 1. NEW packages. It'd be interesting for us to know about those and > > get the source somewhere. That way we could work with you on > including them in Ubuntu. > 2. Backported packages. You seem to know quite well what would be > interesting for backports and what not. What do you think about > https://wiki.ubuntu.com/BackportRequestProcess ? > 3. Changed packages. If you apply changes or fix packages in > certain ways, it'd be great to get the source for the change > somewhere. > > > I encourage you to get as much of these changes done in Ubuntu. The > reasons for that are pretty simple: > > * If you encounter problems or bugs here are a lot of hands who > can help you with that. > * Where do your users report bugs? Right: most likely in > Launchpad. Who will fix those bugs? -- Sorry if this sounds > provocative. It's merely meant to start the discussion about the > > practise of working together. > * Reach even more users with your fixes and changes - get those > fixes installed by default. > > > Let us know what you think about it. > > Have a nice day, > Daniel > > > -- João Pinto GetDeb Packager http://www.getdeb.net
<http://www.getdeb.net> -- 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
