Core vs. Non-Core definitions
Micah Gersten
micahg at ubuntu.com
Sun Sep 2 22:28:28 UTC 2012
Corrected top posting...
On 08/29/2012 11:42 AM, Thomas Ward wrote:
> On Wed, Aug 29, 2012 at 12:31 PM, Thomas Ward
> <trekcaptainusa.tw at gmail.com <mailto:trekcaptainusa.tw at gmail.com>> wrote:
>
> On Tue, Aug 7, 2012 at 9:52 AM, Emmet Hikory <persia at ubuntu.com
> <mailto:persia at ubuntu.com>> wrote:
>
> Marcel Admiraal wrote:
> > If we use the "Task" field to identify whether or not an
> application
> > is "core". We should ensure that the "Task" field is defined
> > somewhere. This definition should explain why it can be used to
> > define whether or not an application is "core", and what values
> > would define an application as "core". Since this is part of the
> > Debian package control file, I would expect this to be done at a
> > Debian level. Although it could be made Ubuntu specific, I don't
> > think that would be the right approach. Personally I don't
> > understand what the "Task" field is for, or why it signifies
> that an
> > application is important.
>
>
> The tasks are generated by launchpad based on the content
> of the
> seeds used to define the flavours, by a process that is similar to
> the means by which the common metapackages are generated
> (e.g. xubuntu-desktop). You can compare the similarity by
> looking at the
> output of the following commands:
>
> `apt-cache show xubuntu-desktop` (describes the metapackage)
> `apt-cache show xubuntu-desktop^' (describes the content of
> the task)
>
> Note that the set of packages described by the second command
> matches the set of packages listed as dependencies and
> recommendations
> in the first command (barring the potential for intentional
> variation).
>
> Packages that are included in tasks are considered
> important because
> the developers of the various Ubuntu flavours have deemed them
> important:
> this information is Ubuntu specific and entirely independent
> of any
> information included in source packages imported from Debian.
> It ought
> be safe to consider these "core" packages, because they are
> packages that
> are specifically identified as being important to one or
> another flavour
> of Ubuntu, or the (transitive) dependencies and
> recommendations of these
> packages so identified.
>
> Note that reliance entirely on tasks isn't quite
> sufficient, as
> there exist some packages that are transitive
> build-dependencies of
> the "core" packages that also need the same level of attention and
> triage as bugs there may affect packages in tasks, but it is most
> likely that most users would report bugs against packages in
> tasks,
> which we would then reassign to packages not in tasks as they
> became
> understood, making the use of tasks an acceptable heuristic
> for most
> regular bug triage activity.
>
> It is worth mentioning that during any given development
> cycle, there
> are unavoidable delays between changes in the seeds and the
> availability
> of updated binary metapackages, so that there may be observed
> skew between
> the packages considered transitive dependencies of a
> metapackage and the
> packages included in a task: this ought only be a temporary
> phenomenon, and
> should never be the case once a given cycle as completed
> (release happened).
>
> > Clearly this discussion is based on the fact that the
> definition of
> > "core" is open to interpretation; so there will be
> disagreement on
> > what people consider "core", but personally I think the fact
> that an
> > application is important to the system is what defines an
> > application as core, and not whether it's important to a
> user. This
> > is why I suggested using the "Priority" field, which is
> defined at
> > the Debian level, and consider both "required" and "important"
> > applications as "core".
>
> The issue here is that if we only consider "required" and
> "important"
> packages as core, we end up defining nearly every package
> users notice or
> intentionally use as "non-core". With a few exceptions, just
> about everything
> of direct user interest is Priority: optional (as an example,
> xserver-xorg is
> optional). Making everything that the flavours consider
> critical higher
> than optional would mean we had no differentiation of
> flavours, and a >5GB
> download for install, as every user would be required to
> install all the
> packages used for all the flavours. Making all the packages
> not considered
> critical by the flavours less than optional would involve a
> massive amount
> of work (more than 10,000 packages affected, and needing
> continued maintenance
> over time, as such a change would be unsuitable for Debian),
> and then fail
> to usefully distinguish packages users are encouraged not to
> use (Priority:
> extra).
>
> > I agree that all "core" packages should be in the "main"
> repository
> > i.e. they are free and supported. However, we should note
> that this
> > shouldn't be used as part of a definition, because there is a
> > theoretical possibility that a "core" application may not be in
> > "main", because it's been removed, which itself would be a
> bug. I
> > know this has happened to free applications that are removed
> from
> > the universe repository for some reason e.g. when VLC and
> mplayer,
> > which are both free, were not included. Saying that it's not
> "core"
> > because it's not in "main" would lead to a circular argument.
>
> I don't think it is appropriate to declare a package "core" or
> "non-core" based on the component in which it happens to fall: if
> such an approach is taken, all flavours will need to put all the
> packages of direct interest into main, requiring a vast amount
> of processing of main inclusion reports, and similar. While there
> are historical reasons that the component definitions were
> interesting,
> we ought not limit ourselves by adding more complexity to the
> currently
> existing semantics surrounding them, especially when we have
> significantly
> more flexible and richer tools available from which to select
> those same
> semantics, and heuristics to apply those semantics.
>
> For the avoidance of doubt, my personal definition of
> "core" is packages
> that affect the content of shipping products, these being the
> ogre-model
> constrained set of transitive dependencies, recommendations,
> and build
> dependencies for all packages referenced in the seeds for all
> products, plus
> those packages in the unconstrained transitive dependencies,
> recommendations,
> and build dependencies of the infrastructure used to produce
> product images.
> In practice, the use of the Task: header in local apt caches
> is close enough
> to the above that the exceptions can often be held in the
> heads of those
> developers with direct intrest in the production of product
> artifacts.
>
> Those bugsquad members with an exclusive interest in a
> subset of flavours
> may wish to avoid work on packages only represented in Tasks:
> for which they
> have little interest.
>
> So, now that we've pretty much agreed on using the task field in
> practice, I spoke with Brian Murray (bdmurray on IRC). We just
> need to add to the BugSquad documentation
> (https://wiki.ubuntu.com/Bugs/Importance) and anywhere else in the
> documentation where we reference "core" vs. "non-core" with
> footnotes on how to define them. As far as I am aware, its only
> in the Importance docs where we actually have such a definition.
>
> Now, time to do the wording. We do want to keep this somewhat
> non-complex, for the newer or less experienced people who wish to
> suggest importances for *a bug's importance*.
>
> I came up with some wording as a start, but I'd welcome
> suggestions as they come up before we throw this into the wiki's
> documentation (because i think the idea is to not change that
> document often). If we decide to use that wording, i'll go ahead
> and add this to the wiki page:
>
> "core" | A core package can be identified as being part of a task
> in the apt-cache headers. You can see the apt-cache headers by
> running `apt-cache show [package]` in a terminal, and looking at
> the "Task: " field in the output.
>
> "non-core" | A non-core package can be identified as a package
> that is not part of a task, and is not in 'main'. You can see the
> apt-cache headers by running `apt-cache show [package]` in a
> terminal, and looking at the "Task: " field in the output.
>
> Clarification: I meant "a bug's importance" (see bold changes in the
> quote below)
The one issue I see with this is that the task headers and the component
change from release to release. One should have to check them for the
releases in question that the bug affects. Maybe we can get
seeded-in-ubuntu (in ubuntu-dev-tools) extended to allow querying stable
releases as well. In that case, anything marked as supported or on an
image should qualify.
Thanks,
Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120902/3facda32/attachment.html>
More information about the Ubuntu-bugsquad
mailing list