[gentoo-dev] EAPI 2 policy for portage tree

[gentoo-dev] EAPI 2 policy for portage tree

[Jean-Marc Hengen]

Hi,

I like to write about an observation about gentoo, I made the past 
weeks, which does frustrate me personally a little bit, mainly because 
it makes administration a bit harder for me. It could be considered as 
an issue or as yet another case of "When you play with unstable 
packages, you're on your own.". It's about EAPI 2 and maybe it isn't 
worth changing anything with portage 2.1.6 on the way, but I guess, with 
future EAPI's such a situation could be repeated, so maybe there's 
interest in discussing it. If I'm to late and missed the discussion, I 
apologize for the spam.

This mail is about EAPI usage in the portage tree. Let me describe it, 
with what happened today: I'm running a mostly stable system (91 of 1255 
installed packages are unstable), but I test here and there some 
packages. On of the packages, which I installed and is currently masked 
unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy 
with it so far. Today, while updating, portage wanted to downgrade cmake 
to the stable release, due to all cmake 2.6.x version masked by EAPI 2. 
The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a 
bug). My rule of thumb is to only use unstable on none system packages 
after checking, what can go wrong with the unstable package and if I can 
afford the worst case. Generally I consider portage to be a no-go as 
unstable package. So I'm in the situation, where I used cmake-2.6.2 on a 
daily basis and like to continue, but I can't with the current state of 
tree and my policies (more precisely: I can't keep current stable 
portage and cmake-2.6.2). My solution to the problem, was to copy the 
ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. 
The drawback of this workaround is, I could miss important fixes, like 
security fixes.

This isn't the first issue I had with EAPI 2, but they were until now 
always upgrades to new version or new packages, so I abandoned and 
stayed with the current version or didn't install the package at all and 
wait for stable portage with EAPI 2 support. Up till now I could always 
do without those packages, but if I needed one necessarily, I guess, I 
would have backported the ebuild to a older EAPI, rather than upgrading 
portage. What I don't want to say, is that EAPI 2 should be blocked, 
rather the contrary, I look forward to EAPI 2, but from my perspective, 
in the particular case of cmake described above, I rather had added a 
new revision (cmake-2.6.2-r1) with EAPI 2 and the fix and wouldn't touch 
the cmake-2.6.2 ebuild. This has the advantage, that people with a setup 
like mine can continue to use, what they already use and work on the 
cmake ebuild can continue in the new revision. If the new revision fixes 
a security issue, one can mask the old version, with a message with bug 
telling this. So persons like me know, that they have to decide, what to 
do. Certainly one can have a different approach (like the one, that the 
maintainer of cmake took), which I do accept and what I descriped would 
be my solution.

So this is about, if the current "policy" for using EAPI 2 in the tree 
is really "good" or it should be improved, when introducing future 
EAPI's, where portage supporting that EAPI is still unstable. My 
proposal would be, to only use new EAPI with a new version or revision 
and also let the last non new EAPI version for unstable packages in the 
tree. This would allow users of that unstable package with stable 
portage to not downgrade or maintain their local version or forced to 
upgrade portage. This would be a start.

I guess, I'm not the only one, having such a setup and it prevent user's 
like me testing unstable packages. I need my PC on a daily basis, I 
can't afford, having it to reinstall, only because I played with 
unstable software. That's why I'm strict, when it comes to system 
packages or important packages to me (and I have to congratulate the 
gentoo devs for their work, my system just works like a charm and I'm 
very happy with gentoo, only hardware failures could make me headaches). 
So what I expect, is to find out, if setups like mine can or should be 
somehow supported. I'm fine, when the outcome is, that I won't be 
supported, then I know and should rethink my strategy to manage my 
gentoo boxes.

With kind regards,
Jean-Marc Hengen, a happy gentoo user

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote:
> So this is about, if the current "policy" for using EAPI 2 in the tree 
> is really "good" or it should be improved, when introducing future 
> EAPI's, where portage supporting that EAPI is still unstable. My 
> proposal would be, to only use new EAPI with a new version or revision 
> and also let the last non new EAPI version for unstable packages in the 
> tree. This would allow users of that unstable package with stable 
> portage to not downgrade or maintain their local version or forced to 
> upgrade portage. This would be a start.
> 
> I guess, I'm not the only one, having such a setup and it prevent user's 
> like me testing unstable packages. I need my PC on a daily basis, I 
> can't afford, having it to reinstall, only because I played with 
> unstable software. That's why I'm strict, when it comes to system 
> packages or important packages to me (and I have to congratulate the 
> gentoo devs for their work, my system just works like a charm and I'm 
> very happy with gentoo, only hardware failures could make me headaches). 
> So what I expect, is to find out, if setups like mine can or should be 
> somehow supported. I'm fine, when the outcome is, that I won't be 
> supported, then I know and should rethink my strategy to manage my 
> gentoo boxes.

As a arch developer and mostly stable user, I also find this very
frustrating.

I'd like to go further and ask that for the next EAPI change, we only
allow ebuilds using it into the tree once a version of portage that
supports it has gone stable. And then, not make any ebuild with the new
EAPI stable for 60 more days so that the new EAPI related code in
portage can be tested properly.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Mon, 08 Dec 2008 19:09:50 -0500
Olivier Crête <tester@gentoo.org> wrote:
> I'd like to go further and ask that for the next EAPI change, we only
> allow ebuilds using it into the tree once a version of portage that
> supports it has gone stable. And then, not make any ebuild with the
> new EAPI stable for 60 more days so that the new EAPI related code in
> portage can be tested properly.

The "can be tested properly" phase is when it's in ~arch...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Tue, 2008-12-09 at 00:11 +0000, Ciaran McCreesh wrote:
> On Mon, 08 Dec 2008 19:09:50 -0500
> Olivier Crête <tester@gentoo.org> wrote:
> > I'd like to go further and ask that for the next EAPI change, we only
> > allow ebuilds using it into the tree once a version of portage that
> > supports it has gone stable. And then, not make any ebuild with the
> > new EAPI stable for 60 more days so that the new EAPI related code in
> > portage can be tested properly.
> 
> The "can be tested properly" phase is when it's in ~arch...

That also means that to pull a significant number of ebuilds it forces
mostly everyone to test it.. and that part is annoying.. The testing
should be two phased, the first for regression (against existing
ebuilds), and once thats stable, then we can test with new ebuilds...

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Mon, 08 Dec 2008 19:25:44 -0500
Olivier Crête <tester@gentoo.org> wrote:
> > The "can be tested properly" phase is when it's in ~arch...
> 
> That also means that to pull a significant number of ebuilds it forces
> mostly everyone to test it.. and that part is annoying..

If you don't like it, don't run ~arch.

> The testing should be two phased, the first for regression (against
> existing ebuilds), and once thats stable, then we can test with new
> ebuilds...

Uh, regression testing's handled by the package manager's extensive set
of unit tests, which can cover this with targetted accuracy with much
more reliability than making sure random ebuilds still work.

What you're suggesting here is making everyone wait four more months
for no increase in safety.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Tue, 2008-12-09 at 00:29 +0000, Ciaran McCreesh wrote:
> On Mon, 08 Dec 2008 19:25:44 -0500
> Olivier Crête <tester@gentoo.org> wrote:
> > The testing should be two phased, the first for regression (against
> > existing ebuilds), and once thats stable, then we can test with new
> > ebuilds...
> 
> Uh, regression testing's handled by the package manager's extensive set
> of unit tests, which can cover this with targetted accuracy with much
> more reliability than making sure random ebuilds still work.

We all know that portage doesn't have an extensive testing suite... And
that test suites can't cover all the cases that the whole tree does...

> What you're suggesting here is making everyone wait four more months
> for no increase in safety.

I'm not suggesting waiting any longer, just not pushing ebuilds into the
tree until we have a stable enough version of portage that handles them
(and if we do, then lets mark it as stable..).

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Mon, 08 Dec 2008 19:25:44 -0500
> Olivier Crête <tester@gentoo.org> wrote:
>>> The "can be tested properly" phase is when it's in ~arch...
>> That also means that to pull a significant number of ebuilds it forces
>> mostly everyone to test it.. and that part is annoying..
> 
> If you don't like it, don't run ~arch.
> 

I have to agree with Ciaran on this one.
Furthermore, it's "unrealist" and to an extent "unfair" to impose
limitations on "~arch" ebuilds because of "arch" users. Gentoo should
support "arch" users, but that doesn't mean making sure "~arch" ebuilds
work for "arch" users. When a "arch" user opts to use an "~arch" ebuild,
he/she does so at his own risk.
About replacing "EAPI-{0,1}" ebuilds with "EAPI-2" ebuilds, I can agree
with the proposal, although one can pick earlier versions/revisions from
http://sources.gentoo.org/viewcvs.py/gentoo-x86/

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk9zYcACgkQcAWygvVEyAKEmQCfblj0GaZSITsF6/L0PvZVBLyA
1QsAoIote0hbzetNbcrPvWUpTuIOPITW
=XnAf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Robert R. Russell]

On Monday 08 December 2008 06:00:10 pm Jean-Marc Hengen wrote:
<snip>
> This mail is about EAPI usage in the portage tree. Let me describe it,
> with what happened today: I'm running a mostly stable system (91 of 1255
> installed packages are unstable), but I test here and there some
> packages. On of the packages, which I installed and is currently masked
> unstable, is dev-util/cmake-2.6.2. I use it on a daily basis and happy
> with it so far. Today, while updating, portage wanted to downgrade cmake
> to the stable release, due to all cmake 2.6.x version masked by EAPI 2.
> The cmake-2.6.2 ebuild was updated to use EAPI 2 (along with fixing a
> bug). My rule of thumb is to only use unstable on none system packages
>
<snip>
>
> With kind regards,
> Jean-Marc Hengen, a happy gentoo user

The problem is not that an EAPI 2 supporting portage is unstable or that he is 
using a ~arch version of one particular package, but the during a bugfix the 
maintainer moved the ebuild to EAPI 2 without a version bump forcing 
Jean-Marc to downgrade to the stable version. The question on policy is, can 
a maintainer upgrade an ebuild to the latest EAPI while doing some other 
bugfixing without a version bump?

My personal opinion on this matter is pick one of the following:
1)  perform the bugfix without a version bump and remain at the current EAPI 
version
2)  perform the bugfix with a version bump and remain at the current EAPI 
version
3)  perform the bugfix with a version bump and upgrade to the latest EAPI
Options 1 and 2 are how most updates are done, the user can mask the latest 
version or upgrade. Option 3 allows the user to continue using the previous 
version while they decide to update to a portage version that supports the 
new EAPI.

I would prefer that option 3 be made policy because I run several ~arch 
packages that either don't have a stable version (kradio) or have a feature 
that I need (gentoo-sources), and will not be pushed to stable immediately 
for various reasons from lack of maintainer time to everybody says it 
conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, 
and xorg).

[gentoo-dev] Re: EAPI 2 policy for portage tree

[Duncan]

Olivier Crête <tester@gentoo.org> posted
1228783422.7351.8.camel@TesterTop3.tester.ca, excerpted below, on  Mon, 08
Dec 2008 19:43:42 -0500:

> I'm not suggesting waiting any longer, just not pushing ebuilds into the
> tree until we have a stable enough version of portage that handles them
> (and if we do, then lets mark it as stable..).

FWIW this ~arch user's perspective:

AFAIK, the policy is now that no EAPI is allowed to pass where the 
corresponding version of portage is, stability-wise.  That means, if a 
portage supporting that EAPI is only available in overlays, ebuilds/
eclasses supporting it must also remain in overlays -- they can't be 
added to the tree.  (It's worth mentioning here that overlays aren't 
restricted to portage features at all, some use features not in portage, 
period, only in one of the other PMs.)

Once a portage supporting that EAPI is in the tree, hard-masked for 
testing, ebuilds using it may also be in the tree, but also hard-masked.

Once a portage supporting that EAPI is in ~arch for testing, then ebuilds 
using it can likewise move to ~arch for testing, but they can't go stable 
yet.

Only after a portage supporting a particular EAPI is stable can an ebuild 
requiring that EAPI stabilize as well.

Note that in the above there's NOTHING stating that an ebuild that's in 
~arch for testing, cannot switch to an EAPI only likewise in ~arch for 
testing.  It's quite possible that such an ebuild still in ~arch will be 
found to work better with features only in a new EAPI, and it's quite 
legitimate in my opinion to change the ~arch ebuild (still testing, 
remember) to require it, as long as a version of portage with support is 
already in ~arch as well.  Of course, by doing so the maintainer accepts 
that he may not stabilize that ebuild until the supporting portage goes 
stable as well, but if that's the case, there should be nothing blocking 
an existing ~arch ebuild from being modified to require an existing ~arch 
portage, both of them still being in ~arch testing, after all.

If people want to play with a few ~arch packages here or there, while 
most of the system stays arch/stable, fine, but the choice and results of 
the choice should both be their responsibility.  Maintaining devs 
shouldn't have to worry about changing an ebuild that after all is still 
in ~arch, if they judge it will ultimately make for a more stable ebuild 
headed into stable.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Graham Murray]

"Robert R. Russell" <nahoy_kbiki@hushmail.com> writes:

> 3)  perform the bugfix with a version bump and upgrade to the latest EAPI
> Options 1 and 2 are how most updates are done, the user can mask the latest 
> version or upgrade. Option 3 allows the user to continue using the previous 
> version while they decide to update to a portage version that supports the 
> new EAPI.
>
> I would prefer that option 3 be made policy because I run several ~arch 
> packages that either don't have a stable version (kradio) or have a feature 
> that I need (gentoo-sources), and will not be pushed to stable immediately 
> for various reasons from lack of maintainer time to everybody says it 
> conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, 
> and xorg).

Another reason for preferring option 3 for bug fix (but not for
'cosmetic' changes or ones which prevent some users from installing the
package) is that (~arch) users will already have the pre-bug fixed
version installed and portage will not install the bug fix unless either
the version is bumped or USE flags have changed and the --newuse emerge
option is used.

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

Jean-Marc Hengen wrote:
> tree and my policies (more precisely: I can't keep current stable 
> portage and cmake-2.6.2). My solution to the problem, was to copy the 
> ebuild in /var/db/pkg to my local overlay and I'm fine with it for now. 
> The drawback of this workaround is, I could miss important fixes, like 
> security fixes.

[snip]

> the cmake-2.6.2 ebuild. This has the advantage, that people with a setup 
> like mine can continue to use, what they already use and work on the 
> cmake ebuild can continue in the new revision. If the new revision fixes 
> a security issue, one can mask the old version, with a message with bug 
> telling this.

Just FYI, there's no difference -- when you've chosen to use the ~arch 
version, you *have* to follow any updates to it as soon as possible if 
you want to be reasonably sure you aren't affected by a security bug, as 
our security team doesn't issue GLSAs for ~arch packages. Sticking with 
a version that works for you doesn't mean you're somehow protected form 
security bugs.

So to put this into perspective with cmake -- if there was a security 
bug in current version (which you'd keep as you don't want to upgrade 
Portage) and the fix for this bug would be using EAPI=2 (which is not an 
unrealistic situation), you'd be affected.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

Robert R. Russell wrote:
> 
> My personal opinion on this matter is pick one of the following:
> 1)  perform the bugfix without a version bump and remain at the current EAPI 
> version
> 2)  perform the bugfix with a version bump and remain at the current EAPI 
> version
> 3)  perform the bugfix with a version bump and upgrade to the latest EAPI
> Options 1 and 2 are how most updates are done, the user can mask the latest 
> version or upgrade. Option 3 allows the user to continue using the previous 
> version while they decide to update to a portage version that supports the 
> new EAPI.
> 

The current policy states that ebuilds should only be bumped if the
installed files change. Changing EAPI from 1 to 2 has no effect outside
the vdb so the current policy means developers should use option 3.
There was a bug in stable Portage when EAPI 2 went in the tree that made
Portage stack trace but that's a problem with Portage not with the
policy in general.

> I would prefer that option 3 be made policy because I run several ~arch 
> packages that either don't have a stable version (kradio) or have a feature 
> that I need (gentoo-sources), and will not be pushed to stable immediately 
> for various reasons from lack of maintainer time to everybody says it 
> conflicts with major pieces of the system (Firefox 3, 64 bit netscape-flash, 
> and xorg).
> 

Why should we prefer making it a little bit easier for stable users over
making ~arch users needlessly recompile stuff?

Regards,
Petteri



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Robert R. Russell]

On Tuesday 09 December 2008 12:13:40 pm Petteri Räty wrote:
> Robert R. Russell wrote:
> > My personal opinion on this matter is pick one of the following:
> > 1)  perform the bugfix without a version bump and remain at the current
> > EAPI version
> > 2)  perform the bugfix with a version bump and remain at the current EAPI
> > version
> > 3)  perform the bugfix with a version bump and upgrade to the latest EAPI
> > Options 1 and 2 are how most updates are done, the user can mask the
> > latest version or upgrade. Option 3 allows the user to continue using the
> > previous version while they decide to update to a portage version that
> > supports the new EAPI.
>
> The current policy states that ebuilds should only be bumped if the
> installed files change. Changing EAPI from 1 to 2 has no effect outside
> the vdb so the current policy means developers should use option 3.
> There was a bug in stable Portage when EAPI 2 went in the tree that made
> Portage stack trace but that's a problem with Portage not with the
> policy in general.
>
> > I would prefer that option 3 be made policy because I run several ~arch
> > packages that either don't have a stable version (kradio) or have a
> > feature that I need (gentoo-sources), and will not be pushed to stable
> > immediately for various reasons from lack of maintainer time to everybody
> > says it conflicts with major pieces of the system (Firefox 3, 64 bit
> > netscape-flash, and xorg).
>
> Why should we prefer making it a little bit easier for stable users over
> making ~arch users needlessly recompile stuff?
>
> Regards,
> Petteri

My answer is a simple example from my own system. My current system uses a 
motherboard that is around 6 months old and is only correctly supported by 
the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old 
nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I 
am using the latest ~arch xorg-x11. The internal video card isn't even 
recognized by the xf86-video-intel drivers except the ~arch versions. Even 
some of the packages I use for school work such as kile have bugfixes and 
other improvements between the versions in stable and ~arch that are 
important to getting work done. The ability to selectively upgrade only the 
specific packages needed to get a working system is a major strength for 
Gentoo. Why should I have to run more packages from ~arch than I absolutely 
need to? We all know that upgrading more software than absolutely necessary 
will result in bad things happening to a computer.

The easiest solution to the problem with ~arch having the only working 
versions of some packages is to get more of those packages stabilized. But, 
we all know that the manpower required simply doesn't exist.

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Daniel Drake]

Robert R. Russell wrote:
> My answer is a simple example from my own system. My current system uses a 
> motherboard that is around 6 months old and is only correctly supported by 
> the latest ~arch gentoo-sources. The add on video card, a 1 to 2 year old 
> nvidia card, works great with x11-drivers/xf86-video-nv-2.1.12 as long as I 
> am using the latest ~arch xorg-x11. The internal video card isn't even 
> recognized by the xf86-video-intel drivers except the ~arch versions. Even 
> some of the packages I use for school work such as kile have bugfixes and 
> other improvements between the versions in stable and ~arch that are 
> important to getting work done. The ability to selectively upgrade only the 
> specific packages needed to get a working system is a major strength for 
> Gentoo.

With all of these problems, it sounds like in your case, our stable tree 
isn't living up to our hopes. *This* is the problem you should be 
bringing to our attention, instead of complications with portage and EAPI.

I looked up your email address on bugzilla, hoping to find at least 5 
bug reports, one for each of the problems you describe above. I could 
only find one (and even that one doesn't really make clear the fact that 
the current stable has problems which is affecting your schoolwork). 
Please could you fix that?

Thanks!
Daniel

Re: [gentoo-dev] EAPI 2 policy for portage tree

[Daniel Drake]

why offlist?

Robert R. Russell wrote:
> Stabilization reports for ~xorg-x11 and the ~xf86-video-intel drivers aren't 
> likely to go any where given the number of issues people are asking about on 
> the forums

But the important thing is that you notify the maintainers that you're 
in trouble. That may encourage them to focus more on the remaining 
blockers. But at the very minimum it makes them aware, and it serves as 
documentation for others who may hit the same problem.

> and the time taken to fix even simple bugs like this one 
> https://bugs.gentoo.org/show_bug.cgi?id=227895

You can't judge the whole of Gentoo on your experience with one bug. It 
is also not an excuse for not filing the bugs, even if they take a while 
to get fixed. A user reporting the problem is just as significant as a 
developer fixing it.

> A more accurate guide to what the devs want on a filed bug report 
> or a reply to a bug report( patches to the ebuilds, patches to the software, 
> and the like) would help me out in giving the devs what they need or want.

Suggestions appreciated. My advice would be, if something is broken, 
then file a bug (after doing some sanity checking to attempt to confirm 
it's not your fault, and nobody else has filed it).

> As far as the kile stabilization report, what priority do stabilization 
> reports need? Do I need to give exact details on what doesn't work in the old 
> version compared to the new version, which is unlikely because I can't even 
> remember the problem that forced an upgrade?

I wouldn't bother with the priority field. But information on the 
benefits and importance of stabling is important. Give developers 
motivation to fix the bug, by describing what problems the stabilisation 
solves.

> The end of school will also help with the bug filling rate going up in the 
> next week or so.

Great!

Daniel