Ubuntu AppUpdate

[Ryan Oram]

On Thu, Jul 8, 2010 at 7:20 PM, Joao Pinto <joao.pinto at getdeb.net> wrote:
> The last time I have checked pbuilder used chroots just as sbuild does,
> where can I read about the VM technology used for the PPAs ?
> How does it improve package quality compared to a regular chroot based build
> ?
> The dependency and scripts validation being specific to pbuilder is not
> correct, that depends on installing the package in a clean chroot, something
> that we do with sbuild.
>
> I am sorry, but again that is not correct, please check
> "https://wiki.ubuntu.com/MOTU/Contributing", search for "Build the package
> with sbuild or pbuilder" .

I apologize. I was completely mistaken. It seems as if Ubuntu and
Debian allow the use of sbuild as well, just not vanilla debuild.
Launchpad also uses sbuild, as the Ubuntu developer said in a previous
reply. Looking my Launchpad build logs, I can verify this. Launchpad
does run lintian afterwards, though I suppose your building process
can easily add this step.

However, on an end user machine, pbuilder is a bit more convient than
sbuild as it automates a lot more, making it easier to check if your
package will compile in a chroot environment. This is a bit irrelevant
in this case, though, I do recommend developers use pbuilder in their
package testing due to being a bit easier to use.

In reply to Soren, everything being on external virtual servers is
also an example of making the creation of these packages as easy and
transparent as possible for developers, while keeping all the safety
measures and checks in place. It provides a standard environment that
developers can easily use to create and their packages. It gives
developers one less thing to worry about. This may be a side effect,
but it's certainly a good one.

> We avoid to provide information the main page which is useful for a few
> users, we do have a "Contact" link :)

You should add a tiny link on the front page, so others won't have to ask. :P

> The GetDeb repository is just as integrated as a PPA, it's a regular 3rd
> party repository,  we don't use PPAs because:
> 1) our build system is prior to PPAs
> 2) some of our packages are not acceptable per PPA's software licence
> requirements
> 3) we have more flexibility to integrate features which wouldn't have much
> use on the PPA scenario

I can see the purpose behind why you don't use Launchpad. However, it
is a huge convenience for developers as it  transparently shows them
the build process and even tells them via e-mail when their build has
failed. I think it is also important to standardize the build process
for Ubuntu apps and allow for users to easily see the steps taken in
generating and testing the packages.

The restriction of Launchpad not being able to be used with closed
software is a bit of a flaw, however, this would also encourage users
to look at open source alternatives. It is a bit inappropriate for
closed applications to be included in an auto update service, as the
methods of package generation and the source code can not be parsed
during testing. I feel that including closed sourced applications in
such a service is a security flaw. I guess this is example of the
differing priorities of our projects, though these differing
priorities are certainly not a bad thing.

> The PPA does not validate if a package is Ubuntu/Debian policy compliant,
> such is not  possible in a fully automated fashion, lintian helps a lot but
> does not replace a human reviewer.

It does allow easy access to the logs, however, so developers can
review these recommendations easily online. My service will require
each package be put into a week long testing phrase so that anything
that automation doesn't catch will have a catch to be caught by a
tester.

>> I would be more than happy to assist your project and help integrate
>> it into the Launchpad and PPA processes. However, this would be a huge
>> restructuring of your project, requiring many time-consuming changes.

It adds transparency and accesible documentation for testers. This is
crucial for the week long testing period, as it will allow me and the
testers to directly advise the developments on what changes need be
made on their packages and allows us to make suggestions.

-----

With all of this in mind, our projects still have plenty of room for
collaboration. I am certainly interested in apt-portal and there is
nothing stopping us from sharing package sources. However, I do feel
that integration with Launchpad is very important to developers and
users alike as it will allow better communication. I'm a believer in
keeping the process out in the open, as that is the only way it can be
made better.

I respect your project and appreciate the progress it has enabled by
allowing developers to release their applications outside of the
Ubuntu system, which has been at times too strict and a bit
unforgiving. However, the lack of Launchpad integration is major
sticking point and the major reason why Ubuntu AppUpdate was created
in the first place. This doesn't mean I'm not willing collaborate to
with your team on side-projects (in fact expect a bit of collaboration
with the apt-portal project), but it does mean that my project will
likely stay separate.

Good luck,
Ryan