On Wed, Dec 12, 2007 at 12:56:22AM +0900, I wrote:
> 1) Go visit MoM, DaD, or multidistrotools, and merge everything by
> Wednesday night/ Don't worry if it doesn't have your name on it: at
> this point any merge is fair game. Further, if you were waiting for a
> sync, now is the time to push the merge in: there's no more wait
> needed.
On Dec 12, 2007 1:00 AM, Scott Kitterman wrote:
> I would add that if stuff should not be merged from some reason, it'd be very
> good to note that in the comments field on DaD so others will know.
On Dec 12, 2007 9:59 AM, Steve Langasek wrote:
> This sounds like a reasonable policy to me for packages which have not yet
> been merged in hardy (which is what the deadline is actually for - initial
> merges), but I also don't presume to speak authoritatively here; as Scott
> mentions, there may be reasons for not merging a particular package, and I
> don't want to be blamed for encouraging people to merge recklessly. :-)
I'd agree with both of you on this. My apologies if my message
failed to indicate that due care should be taken to not merge things
that shouldn't be merged, or that people should not continue to
coordinate merges as a team.
On Dec 12, 2007 9:59 AM, Steve Langasek wrote:
> On Wed, Dec 12, 2007 at 12:56:22AM +0900, Emmet Hikory wrote:
> > Further, if you were waiting for a sync, now is the time to push the merge
> > in: there's no more wait needed.
>
> I'm not sure I understand what you mean here. By "waiting for a sync" do
> you mean "waiting for the archive admins to sync a package", or "waiting for
> the Debian package to be in a state that's syncable"? If the latter, I
> agree completely. If you mean the former, I would hope that's not an issue,
> and if it is please let me know so that we can address that.
Entirely the latter. Prior to DIF, it is common practice to work
with Debian to try to get the package in an identical state for both
distributions. Once the autosync ends, this is still a useful goal,
but I don't believe it should be a blocker for uploads to hardy any
longer. The former seems well handled by the rotating sync processing
days.
> > 2) After this point, merges may still be done, but should only be
> > done when the Debian change is explicitly desireable for inclusion in
> > hardy (e.g. "Contains feature foo which integrates better with the
> > default installation", or "Fixes bug bar which annoys a bunch of
> > people" or "The assigned merger didn't merge by the deadline, and we
> > want the new updates" (the last of these should be done in the next
> > week or two)). Merges that change binary package names or otherwise
> > cause transitions should be avoided, and anyone contemplating such a
> > merge becomes responsible for coordinating updates to all the rdepends
> > (this typically requires a truly significant feature or important bug)
>
> I think this is a bit more conservative than necessary. The aim of the DIF,
> as I understand it, is to make sure we don't find ourselves with packages
> getting merged right before FeatureFreeze for the first time in the release
> cycle, bringing in six months worth of Debian changes when we're supposed to
> be stabilizing. As long as the bulk of these changes have been merged in
> advance of the DIF, I don't think the justification for an "updated merge"
> needs to be particularly elaborate.
Again, apologies for any confusion: I hadn't meant it to be
particularly conservative, just that we should focus on features and
bugfixes desired for hardy, rather than chasing every Debian update.
I'd consider "a member of ~ubuntu-dev thinks it's a good idea"
sufficient justification until feature freeze, and encourage the
adoption of any Debian bugfix uploads, which means that members of
~ubuntu-dev should feel no obligation to restrict processing. For
those not members of ~ubuntu-dev, it's worth writing up two or three
reasons why the merge or sync is useful for hardy, just to ease
sponsorship.
--
Emmet HIKORY
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
