Karmic Release Schedule

[Emmet Hikory]

Robbie Williamson wrote:
> This was suggested by some of the platform leads. Some partners not familiar
> with our release process assume that FeatureFreeze is the deadline by which they
> can submit their code *for the first time*...that is, they have not made *any*
> public drops to us or anyone else in the Ubuntu community until this point.  The
> FeatureDefinitionFreeze and NewPackageDeadline was created to be able to keep
> these entities "honest", with regards to the schedule.  Maybe we rename it to
> PartnerNewPackageDeadline, to indicate the audience...would that be better?

    If the problem is related to the availability of public code drops,
perhaps it may be better to have something like
"NewPackageProposalDeadline", by which deadline any packages intended
for inclusion in a given release must have been posted for review and
discussion.  The exact requirements for "posted for review" might be
somewhat flexible, but I'd expect an upload to either REVU or Debian to
be considered sufficient, at a minimum.

    Part of the rationale is that I'm not convinced that this deadline
ought only apply to Canonical Partners.  I have personal experience with
other entities seeking to drop code into Ubuntu very close to the
deadline, often with the result that shortcuts are taken in the quality
of the packaging and integration efforts in order to meet the deadline;
and I have certainly seen significant numbers of new packages being
proposed in the final week before the freeze, often to the
disappointment of the packager when the package was not accepted before
the deadline.

    I'm also uncertain of the value of having FeatureDefinitionFreeze in
advance of DebianImportFreeze.  Given that we may inherit all sorts of
features or transitions from Debian in the ensuing week, might it not
make more sense to simply require that all features be disclosed and
approved by the release team at DIF?

    Personally, I like the FeatureDefinitionFreeze name better, and
think we might do as well to simply have DIF coincide with this, to
avoid undisclosed features being pulled from Debian without discussion.
 This would both better define the rationale behind DIF (which has led
to debate and discussion in the past), and provide clearer guidance to
those developers who primarily upload to Debian on when they should
expect to have defined the set of changes they expect in the next Ubuntu
release.  Whether the 18th or 25th of June is a better date for this for
Karmic is something on which I do not have an opinion.

Scott Kitterman wrote (addressing Canonical-specific items above, in the
extended thread):
> I can see how that would be a problem, but I still view that as a
Canonical
> issue and not an Ubuntu issue.  I know the distinction is subtle, but I
> think important to preserve.  My suggestion would be to publish a
schedule
> on canonical.com with additional milestones related to Canonical's
> commercial efforts.

    I'm not sure this is a complete solution.  While there's a certain
value in any given commercial sponsor providing clear guidance to any
partners or customers regarding any internal schedule for delivery into
Ubuntu, I think there also exists a clear interest by Ubuntu generally
in having code available for review sometime before FeatureFreeze, both
to ensure appropriate time for review and inclusion of any proposed
code, and to provide the opportunity to determine that the expected
features provided by a given package or code may not be fully realised
in time for a given release (especially where other packages are affected).

    Robbie has since added PartnerUploadDeadline (1) to
KarmicReleaseSchedule (2), but I believe the definition is both too
narrow in terms of the audience it ought address, and fails to address
Scott's concerns about the distinction between deadlines of primary
concern to Canonical and deadlines of primary concern to Ubuntu.

    In it's place, I'd like to suggest NewPackageProposalDeadline, with
the following definition:

===
By this date, all code expected to be included in the next release of
Ubuntu must have been formally proposed for inclusion to the Ubuntu
Developers, in the form of a package for review.  Packages proposed
after this point will not be considered for inclusion in the next release.
===

    I've specifically left the definition of a formal proposal vague, as
I believe that individual developers are best suited to determine if
there has been such a proposal, although I'd hope it takes the form of a
REVU upload or sync request.

    Further, as new packages traditionally drop into the universe
component, I'd like to propose that the MOTU Release team be responsible
for approving any exception requests to this deadline, in those cases
where there is an overriding rationale to include completely new code
between NewPackageProposalDeadline and FeatureFreeze.


1: https://wiki.ubuntu.com/PartnerUploadDeadline
2: https://wiki.ubuntu.com/KarmicReleaseSchedule


-- 
Emmet HIKORY