Re: writing a release announcement
Hi, Andreas,
On Mon, Apr 29, 2002 at 09:39:39AM +0200, Andreas Metzler wrote:
> Osamu Aoki <debian@aokiconsulting.com> wrote:
> > On Sat, Apr 27, 2002 at 02:39:22PM -0400, Andrew Pimlott wrote:
> >> On Sat, Apr 27, 2002 at 04:28:58PM +0200, Andreas Metzler wrote:
> >>> Joey Hess <joeyh@debian.org> wrote:
> >>>> Some things from the woody release notes that we could mention include:
> >>>> - apt pinning
> [...]
> >>> I do not think this should be advertised that widely without a
> >>> big warning.
>
> > ??? Why ???
>
> > I think warning should exist not for pinning but for running
> > testing/unstable package IN GENERAL.
> <Ack.>
I may have made a wrong impression here. I do not expect any warning
for running testing/unstable packages in the release notes. That should
exist places where running testing/unstable packages are described in
details. In this sense, http://www.debian.org/releases/testing/ could
be more frank about possible conflict issues user may face. (That is
different issue and worth discussing in debian-www@l,d.o.)
For release notes, important features affecting distribution must be
mentioned whether it is easy to use or not. In this sense, it is
justified to mention apt pinning, I think.
> The release notes is not targeted to people already accustomed
> to testing/unstable and apt's pin feature (and its difficulties).
> /You/ understand
It is aimed at everyone :) I hope I am certainly an audience.
> apt pinning, to ease partial upgrades to our testing branch as "apt
> pin _eases_ it, but it is still very complicated." Joe user OTOH will
> read" apt pin makes it _easy_ to pull selected packages from
> testing/unstable", and thinks "Great, if we had this feature in
> potato, Ivan could've spared the time backporting KDE to potato,
> there'd have been no need for Charl's XFree4 backports, and Adrian
> wouldn't have had to hassle with Kernel2.4 for potato."
I think we all know there are possible dependency issues if you pull
some packages from the testing to the stable. I am losing your argument
here, to be honest. Just because some back ports were done and useful
for some packages does not prohibit nice functionality such as "apt
pinning" :)
I think real issue was "too long a interval between releases". We all
know that was bad. Just looking at DPL election can tell there are
enough people concerned.
> > Let me try to defend why pin is great from non-programmer's view point.
>
> [You know more about pinning than me, thanks for the link I'll take a
> look at it.]
> >>> - I assume it won't work well for people running primarily stable
> >>> and tracking some packages from testing (or even unstable) - after a
> >>> short time (5 months) the dependency-chain is going to pull in
> >>> _lots_ of packages from the unstable-part, including first
> >>> libc/gcc*/, followed by debconf and X. The resulting mixture'd
> >>> probably be less stable than running testing.
Again my story. After libc6 fiasco, I was running stable until base
freeze for my router. (except mutt thanks to pinning) I actually
downgraded at one point to semi-stable (except perl/apt) system to have
somewhat functioning workstation. I did not even use gnome but I hit
problems. It was bad to follow testing initially. "Testing" is TESTING
and not for an average JOE like me when there is some storm. But apt
pinning gave me some protection I need.
> > If dependency try to pull something from unstable, if properly set, it
> > should stop.
> [...]
>
> I cannot see your argument (probably because mine was undetectable)
>
> If stable users pull foo from unstable they have to fulfill foo's
> dependencies, which "after a short time (5 months)" will require
> lots of packages from unstable.
Just because you have pinning capability, you do not need to use it if it
is difficult to handle. Getting source package and compile under stable
-dev package environment is one option.
> The main point I am trying to make is that pinning cannot work
> miracles,
Everyone agrees.
> pulling packages from a unstable will require _big_ updates and the
> resulting mixture stable/testing is doomed to be less stable than full
> fledged testing.
In many cases, if pinning is used without care, we hit problems as you
described. But what is wrong with it. Sheer capability to have soft
landing of following partial unstable under somewhat controlled
environment under the stable package (apt) is GREAT!
> Don't you think that pinning is almost useless for stable and that its
> target is testing-users pulling selective packages from unstable?
If Ardo's debiandoc-sgml does not get updated with newer package, I will
certainly pull one from future testing. The one in testing (future
stable) has all the key functions right but there may be some trivial
bug fixes coming soon which affect no other packages but creates
aesthetically nice code. Only pinning will allow me to do that under
next stable :)
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki @ Cupertino CA USA
See "User's Guide": http://www.debian.org/doc/manuals/users-guide/
See "Debian reference": http://www.debian.org/doc/manuals/reference/
"Debian reference" Project at: http://qref.sf.net
I welcome your constructive criticisms and corrections.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: