Re: distinguish between "core" and "main"?
-----BEGIN PGP SIGNED MESSAGE-----
On 06/05/11 13:17, Tshepang Lekhonkhobe wrote:
> On Sun, 2011-06-05 at 08:29 +0200, Harald Dunkel wrote:
>> Understood. If you reduce the number of packages to be released by
>> focusing on a core package set with 1000 or 1500 packages instead
>> of +30000, then your can do more rapid releases because there are
>> fewer packages to wait for matching the release criteria.
> By rapid releases, are you referring to core/stable or main/testing? How
> rapid? Do you mean people would now do system upgrades in less than 2-3
> years (life of a Debian release)?
Only core/stable should be released. The "rest" comes from
I cannot speak for others, but I don't wait 3 years. I do
regular updates/upgrades to include the most recent security
and bug fixes. We've scheduled regular maintenance weekends
every 3 months for this. Important updates are installed
>> Of course this doesn't make the +29000 packages outside of the
>> proposed core repository go away. But I think we already agreed to
>> use testing for installations of "non-core" packages.
> But it makes them second-class.
They are surely not second-class, they are just not within core/stable.
Debian already classifies packages in different priorities, to
be used today when package updates are pushed into testing, for
example. I just cannot use these priorities in sources.list, _and_ I
cannot rely upon the packages in today's testing to work with the
core packages in stable
> Also, backports is supposed to fix this
> anyway. All needed there is volunteers willing to do the work. Why would
> you want a different scheme?
Because backports is not supported as good as the current
testing repo. Why have a 3rd repository next to stable and
testing with a similar package set, instead of keeping an
eye upon compatibility right from the start?
I understand that splitting main into core/stable and
main/testing would be a deep cut. Surely I do not expect it
to happen within the next few weeks or months. Just think
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----