Core vs. Non-Core definitions

Wed Aug 29 16:42:57 UTC 2012

Clarification: I meant "a bug's importance" (see bold changes in the quote
below)

On Wed, Aug 29, 2012 at 12:31 PM, Thomas Ward
<trekcaptainusa.tw at gmail.com>wrote:

> 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.
>
>
> ------
> 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/fb869657/attachment.html>