unity-dev team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Le 07/01/2013 17:03, Stephen M. Webb a écrit :
> On 01/07/2013 10:39 AM, Didier Roche wrote:
> > > > You can take whatever other branch you want, like calling it "next foo feature", then, using that one and having other
> > > > people and yourself branching from it, merge into it, writing tests, experimenting with other ppas containing it. Once
> > > > it's baked and ready for more people to use it, you then propose this feature branch for a full review against trunk.
> > > > After having it accepted and tests passing, the feature, merged to trunk is then pushed to ubuntu.
> > > So exactly what problem was supposed to be solved by eliminating upstream releases for a project and blurring the
> > > distinction between upstream and distro if it requires having a separate 'upstream' branch where all the work is done
> > > and then a single upstream branch is frozen and released into trunk?
> > I didn't mention "upstream" branch, but "feature branch". So a feature is backed somewhere and once ready and high
> > quality enough, merged to trunk. We have more than one feature backing in parallel most of the time :)
> What you described is the way upstream branches normally work.  You call it a "feature branch" but the workflow is the
> same.
right, sorry, I misread it as you meant "trunk". Sure, so we agree here :)

> > > Don't get me wrong, trunk needs to be sacred. Requiring downstreams to be aware of all upstream changes that get pushed
> > > on them, and for upstreams to do all the work in downstreams if they break things before each and every commit anywhere
> > > is just not working.  It sounds to me like this current experiment is turning up some negative results (some of which
> > > were explicitly predicted) and we might need to adjust some theory or parameters.
> > How can you talk about negative results of daily release when we don't have them yet (because there are some UTAH issues
> > with raring that are under fixes)? The current discussion was about the staging ppa beeing broken. The staging ppa has
> > nothing to do with daily release and is there for a year and half already.
> The "negative result" is that the trunk is frequently broken by factors beyond the control of the immediate project.
> About once a week, trunk builds of Unity either break during building or running the test suite, or fail at run time,
> because an upstream dependency has changed and the first notification the Unity maintainers receive is that the build
> fails (or a manual upgrade reveals a non-working system).  If the goal if to never have this happen, we're not meeting
> that goal, and something needs to be fixed.
I think we need to fix those breakage time. That's why I want the 
staging ppa which is per commit build and rather have the per daily 
release (once activated), which is what the final goal we are closed to 
is. Some of the breakage are naturals (like I'm breaking the soname) and 
transient, hence the "things that are pushed in a day work should be 
coherent, even if this span multiple projects". I won't break bamf 
without having the branch ready to merge in unity to have it working 
with it for instance.

However, in most of the projects we are upstream for, requirement 
versioning were never updated (if you look at unity, there is even no 
version at all provided). The only one updating them was me in the 
packaging. Now that we need to do that as part of the merge, we are 
seeing consequently the same behavior in build dependencies in 
debian/control here. This seems to be (apart from the PCH issue here), 
the most common issue. What I can propose to "fix" that is that the 
daily build provider is always forcing the latest and greatest of all 
build-deps we are releasing as part of the stack it will encounter. 
Maybe this requirement will be over zealous, but in practice, the 
components are moving so fact that we almost always requested the last 
libunity/dee/bamf/nux/compiz… in all our releases. That will enable us 
to remove this large part of what will be in the future, what I can see 
as the biggest source of mistake of daily release. What do you think 
about that?

> An experiment that yields negative results is not a failed experiment.  On the contrary, it's a successful experiment.
> We have more data on where we need to focus our attention.
It's interesting that we are able to see that even before those daily 
release are activated, it's time to refine and improve both on our 
process side and try to automate as much as possible to not having a lot 
of "dirty work" to do manually.

> > How things are not working when the switch is not even on? The only issue I can see here was that a commit was
> > introduced breaking the build system. A workaround was applied to disable pch support in the merger bot and instead of
> > debian/rules, resulting on no-one fixing it.
> I'm not sure what went on with the PCH changes, but Martin and Jussi were working on it up to the start of the holidays,
> and Jussi said it built using a raring pbuilder but not in the autobuilder because the autobuilder does something in
> addition to what the debian/rules file does.  Then the holidays happened.
I think you meant launchpad and not the autobuilder :) The issue was 
that the environment of pbuilder on the merger was different from soyuz, 
but I guess Francis fixed it now. A test on raring with bzr bd was 
giving the same issue than launchpad. But this issue is part from past 
as told on Friday, I tracked that down with Jussi (+ I fixed the 
build-dep issues) and we disabled PCH in debian/rules for now, but it's 
still available for a local upstream build when not built with -O2 -g

Cheers
Didier