pyjamas (and dependent) packaging: examples of failure of ubuntu packaging and development process

Sat Jul 3 16:09:40 BST 2010

Disclaimer: I'm not a member of the ubuntu-devel team, and I only follow
this list to keep up with the news.

I think you have a point, but the way you put it doesnt' help. And people
that COULD help solving your issue most probably willl not get involved.

Instead of blaming the six month process, or the lack of component testing,
it would be way better to put forward a proposal to help solve the
defficiencies you pointed out.

As for the defficiencies:

1) The six month cycle has pros and cons, and for most of the people the
pros outweight the cons. Blaming the cycle does not lead anywhere.

2) Testing is difficult. You're never sure if you've done enough testing.
There's always "one last bug" to find. And for a distribution with hundreds
or thousands of dependencies, testing is *very* hard. If you get too
conservative you're not going anywhere. You can't innovate, so it's a matter
of balance.

One idea that came to me while pondering about these issues is that Ubuntu
could do with a "two-step" development cycle. Instead of maturing a new
distribution in a single six month process, Ubuntu could try a different
scheme, with two overlapping schedules. The first half would be essentially
the same cycle that is used today - but instead of launching immediately,
there would be time for a second "maturing" cycle to get things right. As
soon as you get to this "maturing" point, you split the team. One half keeps
testing and maturing the distro, and has time to "rollback" some of the
changes that turn out to be immature for release; at the same time the other
half start a new development cycle.

Pros:
- More time to mature the distribution.
- Better testing (regression, etc.).
- Reliabitliy.

Cons:
- Needs a lot more discipline.
- Requires more people.
- Keeping the two teams in sync is hard, and can make communication
potentially much more confusing.
- Takes another six months to get innovation out of the door.

Hope it helps ;-)

Carlos Ribeiro

On Wed, Jun 16, 2010 at 17:49, Luke Kenneth Casson Leighton <
luke.leighton at gmail.com> wrote:

> dear ubuntu developers,
>
> i've been shouting for years quite vocally about various problems i've
> seen with ubuntu development, and have been strongly recommending to
> the average linux developer, of whom there are a considerable number
> on the pyjamas-dev mailing lists, to NOT use ubuntu for _any_ reason.
>
> finally i thought it might be a good idea to simply state what the
> problems encountered are, so that you can a) explain to me why, so
> that i can then explain to other people b) deal with them - a) or b) i
> don't mind which.
>
> the majority of the issues are related to how pyjamas is adversely
> affected by the ubuntu development process: i feel certain that
> pyjamas is not the only suite of packages affected.
>
> root cause of the problem: The 6 Month Release Cycle
>
> the 6 month release cycle results in picking up "broken" versions of
> software; doesn't leave enough time for testing; if it don't work,
> it's out, and all rdependencies are just deleted, period.
>
> taking pyjamas-desktop as a specific example: it depends on
> python-hulahop.  python-hulahop depends on python-xpcom.  python-xpcom
> is - was - part of xulrunner.  python-xpcom has been merely moved into
> a "third party" category whilst the mozilla foundation, which is
> losing its grip on reality, panics to avert a mindshare and identity
> crisis to webkit, and focusses on "speed, speed, speed".
>
> so, _no_ other major linux distribution, not gentoo, not fedora, not
> debian, not arch-linux, has yet picked up xulrunner 1.9.2 ... yet lo
> and behold, ubuntu has, for the 10 series.  result: OLPC's web browser
> has gone, and ... wait... the *entire* pyjamas package has been
> destroyed?  when only one of its sub-dependencies has gone?
>
> err... so, there's this broken bit of software, which was picked up
> far too early, and, rather than back out and wait for the mozilla team
> to fix it... ubuntu _removes_ several pieces of useful software?
>
> please could i have an explanation for this decision.
>
> then - that software is removed _without_ checking whether one of them
> is a "multi-package" where only _one_ of the packages
> (pyjamas-desktop) in the source package (pyjamas) relies on
> python-hulahop and python-xpcom, where all the _other_ packages have
> only python and python-support as dependencies?
>
> please could i have an explanation for this decision.
>
> second issue, highlighted by ubuntu 9.04: failure to test components.
>
> the packaging of python-xpcom for ubuntu 9.04 was a total failure.
> yes it was built, but it was built so badly that it couldn't actually
> be used.  even doing a basic "import xpcom" by the package maintainer
> would have showed that it wasn't going to work.
>
> by doing "apt-get build-dep python-xpcom; apt-get source python-xpcom;
> cd {pkgname}; dpkg-buildpackage", it could be clearly seen that the
> person who built python-xpcom failed to actually use ubuntu 9.04 to
> perform the build, because it was impossible to actually build
> python-xpcom on ubuntu 9.04
>
> we had to give instructions to pyjamas developers, who are _not_
> c-programmers they're python programmers, to download UPSTREAM
> xulrunner sources, perform a manual build and then extract xpcom.so
> manually, which is a _totally_ unsatisfactory situation in a large
> number of ways.
>
> please could i have an explanation for the failures, here.
>
> i believe there were some additional failures associated with
> python-hulahop around ubuntu 9.04 as well, but it is sufficient time
> ago that i cannot exactly recall.  i seem to remember that hulahop.so
> would not work with python 2.6, but would work with python 2.5...
> which wasn't installed!
>
> overall, the process is deeply dissatisfactory, and the answer *is
> not* "we don't care: it's your problem - go compile everything from
> source" because i personally, as a debian developer, do not care
> either: what i _do_ care about is that "it's your problem" means "it's
> your (plural) problem" i.e. "your problem as pyjamas developers" -
> none of whom are c-programmers or ubuntu maintainers.
>
> thus, these people are completely reliant on _you_ - the ubuntu
> maintainers - to get this stuff right.  the fedora team got it right;
> the arch linux people got it right; debian/testing is absolutely fine,
> so what is wrong with the process that ubuntu is following, that makes
> this so hard to get right, *especially* when ubuntu is based on
> debian?
>
> some answers really appreciated, so that i can talk with confidence to
> ubuntu users that they are being looked after, as opposed to me
> unequivocably steering them _away_ from ubuntu.
>
> l.
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

-- 
Carlos Ribeiro
Consultoria em Projetos
twitter: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100703/6020f157/attachment-0001.htm 