Lucid auto-syncing with Debian testing

[Michael Bienia-3]

Hi,

as I just read on https://wiki.ubuntu.com/LTS, lucid is going to
auto-sync with Debian testing instead of Debian unstable.

As I consider this an important change compared to current processes, I
was wondering if this will be announced on u-d-a or has every developer
to find it out by himself? Did I miss any other important changes I
might need to know as a developer?

How will this affect development?
- Is it still possible to sync with Debian unstable if needed? Or only
  with Debian testing?
- Do we need to update our tools?
  - Will MoM (merges.ubuntu.com) list pending merges against testing or
    still against unstable?
  - Should we change requestsync to file sync requests from testing
    instead of unstable? Or will they all get synced from testing even
    if the title mentions unstable?

Michael

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

[Robbie Williamson-2]

Please see https://wiki.ubuntu.com/LTS.

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

-Robbie

On Sun, 2009-11-01 at 13:51 +0100, Michael Bienia wrote:

> Hi,
>
> as I just read on https://wiki.ubuntu.com/LTS, lucid is going to
> auto-sync with Debian testing instead of Debian unstable.
>
> As I consider this an important change compared to current processes, I
> was wondering if this will be announced on u-d-a or has every developer
> to find it out by himself? Did I miss any other important changes I
> might need to know as a developer?
>
> How will this affect development?
> - Is it still possible to sync with Debian unstable if needed? Or only
>   with Debian testing?
> - Do we need to update our tools?
>   - Will MoM (merges.ubuntu.com) list pending merges against testing or
>     still against unstable?
>   - Should we change requestsync to file sync requests from testing
>     instead of unstable? Or will they all get synced from testing even
>     if the title mentions unstable?
>
> Michael
>

--
Robbie Williamson <robbie@...>
Ubuntu


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

[Matthias Klose-6]

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.

   Matthias

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

[Scott Kitterman-3]

On Sun, 01 Nov 2009 22:32:28 +0100 Matthias Klose <doko@...> 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.

+1

Once Debian freezez we should sync from Testing up until at least Beta Freeze (and for Universe
all the way to Final Freeze).

Scott K

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

[Michael Bienia-3]

On 2009-11-01 13:10:11 -0800, Robbie Williamson wrote:
> Note that our synching from testing is *only* for the LTS release.

That I've understood, but this still leaves the question about our
development tools, like MoM or requestsync. Should they be modified (or
has it perhaps already happend?) to work against Debian testing for lucid
(and changed back to unstable for lucid+1)?
MoM will be pretty useless during lucid development if it still
continues to prepare merges against unstable. And requestsync needs to
be told to request a sync from testing instead of it's default of
unstable.

And how should the sponsoring teams process with sync request from
unstable? Reject them if no rationale to sync from unstable is given?
Modify them to sync from testing instead?

Those are questions this page doesn't answer (if I haven't overlooked
something). And I guess there are some more of our processes affected by
this change.

And what about a proper announcement of this? I don't know if all
developers know already about it and what implications it has on current
processes. This should be announced properly on u-d-a (that's the
channel I expect to see such announcements) as it's a pretty important
change compared to all past development cycles. And this should be done
before lucid opens and people start uploading merges against unstable
like they done till now when the archive opens for the new release.

Michael

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

[Bryce Harrington-5]

On Sun, Nov 01, 2009 at 11:36:44PM +0100, Michael Bienia wrote:
> On 2009-11-01 13:10:11 -0800, Robbie Williamson wrote:
> > Note that our synching from testing is *only* for the LTS release.
>
> That I've understood, but this still leaves the question about our
> development tools, like MoM or requestsync. Should they be modified (or
> has it perhaps already happend?) to work against Debian testing for lucid
> (and changed back to unstable for lucid+1)?

Seems pretty certain they should be modified, just a question of if that
work's been done.

> And how should the sponsoring teams process with sync request from
> unstable? Reject them if no rationale to sync from unstable is given?
> Modify them to sync from testing instead?

Assuming requestsync is updated to by default request syncs against
testing, I wouldn't imagine this to be happening by accident very
frequently, and given that it wouldn't seem to add value to add
additional bureaucracy to the process.

> And what about a proper announcement of this? I don't know if all
> developers know already about it and what implications it has on current
> processes.

Fwiw, this thread was the first I'd heard about this.  (At least, that I
can recall... maybe it was mentioned at one of the conferences but I
don't remember.)

> This should be announced properly on u-d-a.

Agreed.

Bryce

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

On Sunday 01 November 2009 6:18:09 pm Bryce Harrington wrote:
> On Sun, Nov 01, 2009 at 11:36:44PM +0100, Michael Bienia wrote:
> > And what about a proper announcement of this? I don't know if all
> > developers know already about it and what implications it has on current
> > processes.
>
> Fwiw, this thread was the first I'd heard about this.  (At least, that I
> can recall... maybe it was mentioned at one of the conferences but I
> don't remember.)

Same...

--
Mackenzie Morgan
http://ubuntulinuxtipstricks.blogspot.com
apt-get moo

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

[Robert Collins-8]

On Sun, 2009-11-01 at 22:32 +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.

I agree.

>   - 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*. Thats bad, because it mwans we'll have more merges in
Lucid+1 (or even in Lucid) rather than simple syncs - increasing the
cost of maintainance.

-Rob


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

[Daniel Chen-2]

On Sun, Nov 1, 2009 at 4:10 PM, Robbie Williamson <robbie@...> wrote:
> Note that our synching from testing is *only* for the LTS release.

I agree with others concerned with syncing from testing immediately.

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

[Scott Kitterman-3]

On Sun, 1 Nov 2009 15:18:09 -0800 Bryce Harrington <bryce@...>
wrote:
>Fwiw, this thread was the first I'd heard about this.  (At least, that I
>can recall... maybe it was mentioned at one of the conferences but I
>don't remember.)
>
>> This should be announced properly on u-d-a.
>
>Agreed.
>

IIRC, this was a topic of discussion at the last UDS in the coordination
with Debian discussion.  It was discussed in context of continuing to sync
from testing after DIF and after Debian was frozen, not in general.

Scott K

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

[Robbie Williamson-3]

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@...

"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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Jordan Mantha-5]

On Sun, Nov 1, 2009 at 9:45 PM, Robbie Williamson
<robbie.williamson@...> 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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Scott Kitterman-3]

On Sun, 01 Nov 2009 18:45:34 -0800 Robbie Williamson
<robbie.williamson@...> 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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Steve Langasek-6]

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@...                                     vorlon@...


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

[Steve Langasek-6]

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@...                                     vorlon@...


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

[Scott Kitterman-3]

On Mon, 2 Nov 2009 02:11:49 -0800 Steve Langasek
<steve.langasek@...> 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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Dustin Kirkland-5]

On Sun, Nov 1, 2009 at 11:35 PM, Scott Kitterman <ubuntu@...> 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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Morten Kjeldgaard]

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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Bryce Harrington-5]

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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Michael Bienia-3]

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@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel