Core vs. Non-Core definitions

Wed Aug 29 16:31:49 UTC 2012

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

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.

------
Thomas Ward
LPID: trekcaptainusa-tw
Ubuntu BugSquad Member

On Tue, Aug 7, 2012 at 9:52 AM, Emmet Hikory <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.
>
> --
> Emmet HIKORY
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20120829/4440dd27/attachment.html>