FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 11-02-2009, 01:45 AM
Robbie Williamson
 
Default Lucid auto-syncing with Debian testing

For those first hearing of the sync with testing, the schedule was
included in the Lucid Lynx announcement in September:
http://fridge.ubuntu.com/node/1916
and while it has undergone some changes since the announcement, the sync
from Debian testing as been there the entire time. With that said, I'm
sorry we have not announced in u-d-a yet, and I promise to do this as
soon as possible this week.

With our decision to merge from testing for the LTS (to reduce the
number of regressions and bugs normally introduced when we sync from
unstable), I've struggled with the DIF date during this cycle. In
practice, the Debian freeze policy means that we would be getting lots
of added bugfix goodness, so a later than usual freeze is acceptable in
that it would end up at exactly the time we want to be in bugfixing
mode. Ideally, the earlier in our cycle Debian freezes the more
stabilization benefits we get by autosyncing from testing. We would
want to allow for at least a couple of weeks of continued autosyncing
from testing (*after* testing is frozen) to let us shake off the results
of Debian developers' last-minute-before-the-freeze uploads.

However, with Debian announcing their freeze in *March*, we are faced
with a situation of getting hit with these last-minute-before-the-freeze
uploads without sufficient time to recover before release. So now we
need to shut down autosyncing *before* we start accumulating these
last-minute uploads. With only a month provided by the Debian Release
Team for their freeze (i.e. no day or week), what is an acceptable
buffer? After speaking with slangasek, we originally decided to put in
early February, but then I became a bit concerned last week that it was
too late in the cycle and moved it to January. In hindsight, this was
done in haste and I've moved it back to the week of Feb 11th.

I understand the concern of the Lucid+1 release containing a deluge of
merges and being a "shock" to developers (and users). One way to handle
this issue is to start merges 2 weeks *before* the release of Lucid in a
PPA(s) (week of April 15th), and then move these over once the Lucid+1
release opens up in Launchpad (since we cannot have more than one open
at a time).

We are in some uncharted waters with this new LTS schedule, and thus
will no doubt make some mistakes early on. I again, apologize for not
making more noise about this earlier on, this was not the plan. It
simply fell down in my list of priorities during Karmic as some things
heated up late in the cycle (e.g. boot "fun" in Alpha 6/Beta). I would
like to point out that all of these changes are geared towards trying to
meet the needs and expectations that we've received from LTS users,
while still keeping the release as "shiny and new" as possible...which
isn't easy.

Thanks,
Robbie

--
Robbie Williamson twitter/identi.ca: undacuvabrutha
Ubuntu Foundations & Security Team Manager robbiew[irc.freenode.net]
http://wiki.ubuntu.com robbie@ubuntu.com

"You can't be lucky all the time, but you can be smart everyday"
-Mos Def

"Arrogance is thinking you are better than everyone else, while
Confidence is knowing no one else is better than you." -Me



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 03:14 AM
Jordan Mantha
 
Default Lucid auto-syncing with Debian testing

On Sun, Nov 1, 2009 at 9:45 PM, Robbie Williamson
<robbie.williamson@canonical.com> wrote:
> For those first hearing of the sync with testing, the schedule was
> included in the Lucid Lynx announcement in September:
> *http://fridge.ubuntu.com/node/1916
> and while it has undergone some changes since the announcement, the sync
> from Debian testing as been there the entire time. With that said, I'm
> sorry we have not announced in u-d-a yet, and I promise to do this as
> soon as possible this week.

But it was never mentioned in the actual announcement. It is a pretty
dramatic change and I would think one that would get more general
discussion, not just an announcement.

> With our decision to merge from testing for the LTS (to reduce the
> number of regressions and bugs normally introduced when we sync from
> unstable), I've struggled with the DIF date during this cycle. In
> practice, the Debian freeze policy means that we would be getting lots
> of added bugfix goodness, so a later than usual freeze is acceptable in
> that it would end up at exactly the time we want to be in bugfixing
> mode. *Ideally, the earlier in our cycle Debian freezes the more
> stabilization benefits we get by autosyncing from testing. *We would
> want to allow for at least a couple of weeks of continued autosyncing
> from testing (*after* testing is frozen) to let us shake off the results
> of Debian developers' last-minute-before-the-freeze uploads.

How was it determined that using testing as a merge/sync base would
reduce the number of regressions or bugs? It is not clear to me at all
that it would necessarily follow. Ubuntu has had a history of using
packages from Debian experimental or not yet even in Debian at all.
This seems like a bit of an over-reaction to try to make the LTS
release more stable, but we haven't seen an argument for why using
Debian testing as a sync/merge base will in fact produce a better
Ubuntu release.

I've seen many cases where we gained an awful lot by getting the
latest Debian version and I've seen packages get hung up from going to
testing for things that would really not effect an Ubuntu release or
would be easily fixable in Ubuntu.

My concern is that one of the major complaints leveled against Ubuntu
is that it fails to incorporate fixes from upstreams because it is so
far downstream. Basing off of testing would seem to me to make that
problem worse. It also adds an extra level of checking that Ubuntu
developers need to do: "I better check to see if I should request a
sync from unstable instead, there might be newer patches".

<snip>
> We are in some uncharted waters with this new LTS schedule, and thus
> will no doubt make some mistakes early on. I again, apologize for not
> making more noise about this earlier on, this was not the plan. It
> simply fell down in my list of priorities during Karmic as some things
> heated up late in the cycle (e.g. boot "fun" in Alpha 6/Beta). I would
> like to point out that all of these changes are geared towards trying to
> meet the needs and expectations that we've received from LTS users,
> while still keeping the release as "shiny and new" as possible...which
> isn't easy.

A few questions:
1) why go into uncharted waters with an LTS? it seems the opposite of
what you're trying to accomplish
2) why are you determining the development cycle? (I mean this in the
sense of, shouldn't that load be spread around among the team leaders
and the Technical Board?)
3) who's the "we" in "we've received from LTS users"? Are these needs
and expectations written down somewhere? It would be nice if all
Ubuntu developers were on the same page and reading from the same play
book.

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 03:35 AM
Scott Kitterman
 
Default Lucid auto-syncing with Debian testing

On Sun, 01 Nov 2009 18:45:34 -0800 Robbie Williamson
<robbie.williamson@canonical.com> wrote:
>For those first hearing of the sync with testing, the schedule was
>included in the Lucid Lynx announcement in September:
> http://fridge.ubuntu.com/node/1916
>and while it has undergone some changes since the announcement, the sync
>from Debian testing as been there the entire time. With that said, I'm
>sorry we have not announced in u-d-a yet, and I promise to do this as
>soon as possible this week.
>
>With our decision to merge from testing for the LTS (to reduce the
>number of regressions and bugs normally introduced when we sync from
>unstable), I've struggled with the DIF date during this cycle. In
>practice, the Debian freeze policy means that we would be getting lots
>of added bugfix goodness, so a later than usual freeze is acceptable in
>that it would end up at exactly the time we want to be in bugfixing
>mode. Ideally, the earlier in our cycle Debian freezes the more
>stabilization benefits we get by autosyncing from testing. We would
>want to allow for at least a couple of weeks of continued autosyncing
>from testing (*after* testing is frozen) to let us shake off the results
>of Debian developers' last-minute-before-the-freeze uploads.
>
>However, with Debian announcing their freeze in *March*, we are faced
>with a situation of getting hit with these last-minute-before-the-freeze
>uploads without sufficient time to recover before release. So now we
>need to shut down autosyncing *before* we start accumulating these
>last-minute uploads. With only a month provided by the Debian Release
>Team for their freeze (i.e. no day or week), what is an acceptable
>buffer? After speaking with slangasek, we originally decided to put in
>early February, but then I became a bit concerned last week that it was
>too late in the cycle and moved it to January. In hindsight, this was
>done in haste and I've moved it back to the week of Feb 11th.
>
>I understand the concern of the Lucid+1 release containing a deluge of
>merges and being a "shock" to developers (and users). One way to handle
>this issue is to start merges 2 weeks *before* the release of Lucid in a
>PPA(s) (week of April 15th), and then move these over once the Lucid+1
>release opens up in Launchpad (since we cannot have more than one open
>at a time).
>
>We are in some uncharted waters with this new LTS schedule, and thus
>will no doubt make some mistakes early on. I again, apologize for not
>making more noise about this earlier on, this was not the plan. It
>simply fell down in my list of priorities during Karmic as some things
>heated up late in the cycle (e.g. boot "fun" in Alpha 6/Beta). I would
>like to point out that all of these changes are geared towards trying to
>meet the needs and expectations that we've received from LTS users,
>while still keeping the release as "shiny and new" as possible...which
>isn't easy.

I think doko's concerns about blockage due to transition issues from
Unstable to Testing are a reasonable consideration. I think syncing from
Debian Unstable is fine. IMO, most of our recent toolchain related
problems (Python 2.6 in Jaunty and GCC 4.4 in Karmic) were for being newer
than Debian Unstable.

I wouldn't worry about Lucid +1. LTS +1 releases are notoriously crackful.
A few extra merges won't affect that significantly.

I'm personally quite dissappointed this decision was taken without
significant community input. IIRC, this is not what we discussed at the
LTS/Debian planning session at the last UDS.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 08:08 AM
Steve Langasek
 
Default Lucid auto-syncing with Debian testing

On Sun, Nov 01, 2009 at 10:32:28PM +0100, Matthias Klose wrote:
> On 01.11.2009 22:10, Robbie Williamson wrote:
> > Please see https://wiki.ubuntu.com/LTS.

> > Note that our synching from testing is *only* for the LTS release.

> IMO that's a bad idea which doesn't help starting lucid at all.

> - you rely on unstable -> testing transitions which currently
> are blocked by eglibc/xulrunner/sqlite. waiting for every
> such transition hinders lucid, it doesn't help it. The
> merge/sync window is short enough this cycle, please don't
> delay it further.

> - For an LTS we are going to try reducing the number of
> versions for a software; consolidating on the versions
> that Debian currently switches to reduces the amount of
> resources spent on these tasks.

> To get advantages, we should start syncing from unstable, and later
> switch to syncing from testing.

What happens then when Ubuntu reaches feature freeze and these packages have
still not reached testing due to release-critical bugs in Debian? Debian's
Release Manager has announced a March freeze for squeeze:

http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html

Trying to extend the auto-sync from Debian until after the start of the
squeeze freeze in order to pick up bugfix-only changes in Debian is not
viable, because best case scenario is that this would take us past Beta 1,
cutting into the time available for stabilizing Ubuntu itself for release.

Having our import freeze coincide with the Debian freeze would be counter to
the aim of stabilizing for release, because that would mean shutting down
the import right *after* the last round of "quick, upload this new feature
right now before the release team cuts us off" changes.

And a DIF earlier than the Debian freeze with syncing from testing, after
starting out syncing from unstable, increases the risk *both* of pulling in
not-yet-stabilized changes from testing, and of important fixes superseding
whatever random packages we pulled from unstable at the beginning of the
cycle not having reached testing yet by the time we freeze.

So I think that autosyncing from testing *only* is the right thing to do
here. I don't see any reason to think that autosyncing from unstable for
the next few months is going to significantly improve the release quality
for Lucid. It would get us closer to having the same upstream versions of
software in the Lucid and Squeeze releases - but mainly for those packages
that no one in Ubuntu is looking at, and not a whole lot more given when
Debian is freezing.

Bear in mind that nothing about this autosync policy prevents *targeted*
syncs/merges from unstable for packages where that's the correct thing to
do.

On Mon, Nov 02, 2009 at 10:32:51AM +1100, Robert Collins wrote:
> > - you rely on unstable -> testing transitions which currently
> > are blocked by eglibc/xulrunner/sqlite. waiting for every
> > such transition hinders lucid, it doesn't help it. The
> > merge/sync window is short enough this cycle, please don't
> > delay it further.

> Also we'll be waiting 10 days even for normal changes unless we fiddle
> the urgency field in Debian - that sort of latency would make it pretty
> hard to fix any bug by doing an upload to Debian *even for packages we
> maintain there*.

Feel free to fire off a request to sync from unstable at the same time that
you upload? (Or, if you're like LaMont and too impatient to even wait for
the package to clear the Debian incoming queue...

On Sun, Nov 01, 2009 at 05:15:08PM -0500, Scott Kitterman wrote:
> Once Debian freezez we should sync from Testing up until at least Beta
> Freeze (and for Universe all the way to Final Freeze).

Well, see above regarding the Debian freeze timeline and why this is
therefore not viable as a blanket policy.

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 09:11 AM
Steve Langasek
 
Default Lucid auto-syncing with Debian testing

On Sun, Nov 01, 2009 at 11:35:43PM -0500, Scott Kitterman wrote:
> I think doko's concerns about blockage due to transition issues from
> Unstable to Testing are a reasonable consideration. I think syncing from
> Debian Unstable is fine. IMO, most of our recent toolchain related
> problems (Python 2.6 in Jaunty and GCC 4.4 in Karmic) were for being newer
> than Debian Unstable.

Do you think the clarification that Ubuntu developers should consider
themselves at liberty to request syncs from unstable for anything they think
is appropriate addresses this issue?

> I wouldn't worry about Lucid +1. LTS +1 releases are notoriously crackful.
> A few extra merges won't affect that significantly.

Agreed.

> I'm personally quite dissappointed this decision was taken without
> significant community input. IIRC, this is not what we discussed at the
> LTS/Debian planning session at the last UDS.

This was certainly unintentional; my own recollection was that "sync from
testing" was discussed at UDS and that it was not met with any major
objections. If I've misremembered and inadvertently kept the community out
of the loop as a result, I apologize.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 12:54 PM
Scott Kitterman
 
Default Lucid auto-syncing with Debian testing

On Mon, 2 Nov 2009 02:11:49 -0800 Steve Langasek
<steve.langasek@ubuntu.com> wrote:
>On Sun, Nov 01, 2009 at 11:35:43PM -0500, Scott Kitterman wrote:
>> I think doko's concerns about blockage due to transition issues from
>> Unstable to Testing are a reasonable consideration. I think syncing
from
>> Debian Unstable is fine. IMO, most of our recent toolchain related
>> problems (Python 2.6 in Jaunty and GCC 4.4 in Karmic) were for being
newer
>> than Debian Unstable.
>
>Do you think the clarification that Ubuntu developers should consider
>themselves at liberty to request syncs from unstable for anything they
think
>is appropriate addresses this issue?

It would, in part. I am left somewhat uncertain about how to handle
merges. Manual merges are significantly more labor intensive than merges
using MoM's output as a basis. They are also, I suspect, significantly
more error prone. Perhaps we could run a second MoM instance so the
packages more appropriately pulled from Unstable the need merging won't
need a manual merge?

>> I wouldn't worry about Lucid +1. LTS +1 releases are notoriously
crackful.
>> A few extra merges won't affect that significantly.
>
>Agreed.
>
>> I'm personally quite dissappointed this decision was taken without
>> significant community input. IIRC, this is not what we discussed at the
>> LTS/Debian planning session at the last UDS.
>
>This was certainly unintentional; my own recollection was that "sync from
>testing" was discussed at UDS and that it was not met with any major
>objections. If I've misremembered and inadvertently kept the community out
>of the loop as a result, I apologize.
>
My recollection (which may well be wrong), is that post freeze/DIF syncing
from Testing to pick up additional fixes, not syncing from testing the
entire cycle, is what was discussed.

It sounds like we are past the Rubicon, so we ought to focus on
documentation and updating needed tools. In addition to MoM (as I mention
above) and requestsync, that others have mentioned, I'm pretty sure there
are others. The u-u-d-t pull-debian-source script is one that comes to
mind.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 01:25 PM
Dustin Kirkland
 
Default Lucid auto-syncing with Debian testing

On Sun, Nov 1, 2009 at 11:35 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:
> I'm personally quite dissappointed this decision was taken without
> significant community input. *IIRC, this is not what we discussed at the
> LTS/Debian planning session at the last UDS.

The notes from the UDS Barcelona session on "LTS Policies" can be found here:
* https://blueprints.edge.launchpad.net/ubuntu/+spec/server-karmic-lts-policies

While I proposed this blueprint, the ownership has been appropriately
transferred to Steve Langasek. I'm having trouble finding the video,
but this session was videoed (it was "fishbowl" style).

We most certainly discussed auto-syncing from Debian testing. As I
recall the session, the consensus was that we wanted our automated
archive tooling to pull the large subset of packages that we (in
Ubuntu) don't generally modify from Debian testing--in the interest of
LTS stability and eventually better synchronization with Debian's
stable release.

We also said that this would not be a "rule" for manually merged or
synced packages. Any individual package could be merged or synced
from Debian unstable or even experimental, on a per package basis.

:-Dustin

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 01:48 PM
Morten Kjeldgaard
 
Default Lucid auto-syncing with Debian testing

Steve Langasek wrote:

>> I'm personally quite dissappointed this decision was taken without
>> significant community input. IIRC, this is not what we discussed at the
>> LTS/Debian planning session at the last UDS.
>
> This was certainly unintentional; my own recollection was that "sync from
> testing" was discussed at UDS and that it was not met with any major
> objections. If I've misremembered and inadvertently kept the community out
> of the loop as a result, I apologize.

I think there's been quite a few ooopses lately when it comes to involving
the unwashed masses in the planning, and even communicating decisions to the
community. It would be proper to tighten up on the practices in this regard!

Regarding the schedule, I suggest that the 10.4 release be delayed to a 10.6
release, to accomodate and benefit maximally from the upcoming Debian
release schedule. In any case it would be good to have a bit more time to
finalize the LTS release, the Hardy Heron was not a very successful release
and that needs to be improved.

Cheers,
Morten

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 05:30 PM
Bryce Harrington
 
Default Lucid auto-syncing with Debian testing

On Mon, Nov 02, 2009 at 02:11:49AM -0800, Steve Langasek wrote:
> On Sun, Nov 01, 2009 at 11:35:43PM -0500, Scott Kitterman wrote:
> > I'm personally quite dissappointed this decision was taken without
> > significant community input. IIRC, this is not what we discussed at the
> > LTS/Debian planning session at the last UDS.
>
> This was certainly unintentional; my own recollection was that "sync from
> testing" was discussed at UDS and that it was not met with any major
> objections. If I've misremembered and inadvertently kept the community out
> of the loop as a result, I apologize.

Perhaps what could be helpful in the future is to have a kickoff email
describing new process/toolset changes, at around the time the release
codename is announced*, similar to the alpha/etc. release announcements.

For most normal releases it'd just be the basic info... This release is
named $name, the release schedule is at $url, the archive will open for
development on or after $date, etc. Then, for special releases like
this one, additional directions and guidance can be given, referencing
the appropriate UDS discussions or etc.

Bryce

* Or some other convenient timing, prior to when things in the -1
release start getting busy.


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 11-02-2009, 05:37 PM
"Michael Bienia"
 
Default Lucid auto-syncing with Debian testing

On 2009-11-02 08:54:24 -0500, Scott Kitterman wrote:
> It sounds like we are past the Rubicon, so we ought to focus on
> documentation and updating needed tools. In addition to MoM (as I mention
> above) and requestsync, that others have mentioned, I'm pretty sure there
> are others. The u-u-d-t pull-debian-source script is one that comes to
> mind.

I've changed the defaults for requestsync and pull-debian-source in the
ubuntu-dev-tools bzr.

But I'm not sure yet if and how to update ubuntu-dev-tools in karmic: is
a backport enough (once the changes got uploaded to lucid) or better
prepare a SRU so it reaches far more developers and contributors?

Michael

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 05:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org