| 1 |
Hey Spider, welcome home. |
| 2 |
|
| 3 |
On Fri, 2004-07-09 at 20:05 +0200, Spider wrote: |
| 4 |
> We are subscribed, if you post a bug to repeat that info to us, you are simply |
| 5 |
> cluttering our buglists. My current -unread- list of bugs is way over |
| 6 |
> six thousand. around a thousand of those are Gnome related. See my |
| 7 |
> issue? |
| 8 |
|
| 9 |
Well, realistically, if your unread email queue is over 6000 (not an |
| 10 |
unheard of situation for any of us, really), how can you be expected to |
| 11 |
pay attention to ftp-release-list@×××××.org? |
| 12 |
|
| 13 |
> Also, unstable releases never end up in the tree, but are maintained |
| 14 |
> (usually ;) in paralell by devs, who then at some time compare notes and |
| 15 |
> push it into the tree as package.masked during the rc phase of Gnome |
| 16 |
> development. |
| 17 |
|
| 18 |
That makes good sense for the late RC stage, sure. But it *does not* |
| 19 |
make sense for the point releases that are largely full of bug fixes |
| 20 |
that immediately follow a major version release - those need to get out |
| 21 |
(to ~arch, at least) as quickly as possible. I mean, it's absurd that we |
| 22 |
have presented 2.6.0 as stable to our user population, when we all know |
| 23 |
it's a mess full of glitches (in the upstream code, not the ebuilds) - |
| 24 |
glitches that were promptly fixed by upstream and released as 2.6.1 and |
| 25 |
2.6.2 |
| 26 |
|
| 27 |
> Sorry if I sound harsh and bitter, but I'm wading through bugreport |
| 28 |
> emails right now, and its not made much easier by annoying extras. |
| 29 |
|
| 30 |
[No, you're actually being quite reasonable] |
| 31 |
|
| 32 |
Here's the thing: as I said to you in the room at GUADEC when 2.6.2 was |
| 33 |
announced, the trouble is that no one outside you and foser and one or |
| 34 |
two others have any idea what's going on with the ebuilds around Gnome. |
| 35 |
|
| 36 |
So a few suggestions: |
| 37 |
|
| 38 |
* One approach is the hard mask thing, which is a lot of work. |
| 39 |
|
| 40 |
* Another would be using a meta-bug to record discussion around a point |
| 41 |
release issue. For example, http://bugs.gentoo.org/show_bug.cgi?id=55947 |
| 42 |
(which has a growing Cc list) could be used as a place to discuss what's |
| 43 |
up with the ebuilds that collectively make up a release, and how |
| 44 |
progress is going to fixing them. Indeed, people's being on the Cc list |
| 45 |
can be used as an indication of their potential willingness to be beta |
| 46 |
testers. |
| 47 |
|
| 48 |
* Find a way to bring more manpower to the situation. When spider is |
| 49 |
away for a two months and foser has a broken hand, things kinda grind to |
| 50 |
a halt in Gnome ebuild land. That makes you two somewhat of a single |
| 51 |
point of failure; systematic ways to prevent that sort of thing are |
| 52 |
important. |
| 53 |
|
| 54 |
Naturally, Gentoo/Gnome is not your paid employment, but that so many of |
| 55 |
us depend on your work means that we do need to come up with solutions |
| 56 |
that address the needs of the community. |
| 57 |
|
| 58 |
AfC |
| 59 |
Sydney |
| 60 |
|
| 61 |
-- |
| 62 |
Andrew Frederick Cowie |
| 63 |
|
| 64 |
OPERATIONAL DYNAMICS |
| 65 |
Operations Consultants and Infrastructure Engineers |
| 66 |
|
| 67 |
http://www.operationaldynamics.com/ |
Archives