Le 07/01/2013 16:16, Stephen M. Webb a écrit :
On 01/07/2013 09:40 AM, Didier Roche wrote:
Le 07/01/2013 15:09, Ted Gould a écrit :
On Mon, 2013-01-07 at 07:35 +0100, Didier Roche wrote:
Also, that we have to do that because there is a bad history of committing to
ABI and API stability, remember that
normally, in every normal upstream project, such a breakage ask to change the
soname, and in this case, we will know
beforehand on which version of the -dev package to build-dep. We are just
workarounding here bad upstream practice.
The problem is that we're not talking about released versions, which certainly
should manage their API/ABI with proper
SO numbers etc, we're talking about development trunk. We've removed the
ability to have a playground before
committing to an API that developers are committing to. We can't expect
merging to trunk to be a long term commitment
to API or ABI stability. Doing a release is saying "this is baked" and we'll
commit to it, proposing a merge is not.
Indeed, we removed a playground, but that was 2 cycles beforehand already.
Starting the 11.10 release development cycle,
we went to "trunk is sacred" thanks to the acceptance criteria and that's how
we start raising the quality bar. This
means that trunk is not a playfield anymore, but rather when something hits
trunk, the quality is high enough to pass tests.
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 :)
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.
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.
--
Mailing list: https://launchpad.net/~unity-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~unity-dev
More help : https://help.launchpad.net/ListHelp
