Re: [gentoo-dev] Lack of Gnome Development

[Spider]

begin  quote
On Sat, 10 Jul 2004 15:49:43 +1000
Andrew Cowie <andrew@×××××××××××××××××××.com> wrote:

> Hey Spider, welcome home.

Thanks, The same to you, I think :)

> On Fri, 2004-07-09 at 20:05 +0200, Spider wrote:
> > We are subscribed, if you post a bug to repeat that info to us, you
> > are simply cluttering our buglists.   My current -unread- list of
> > bugs is way over six thousand.  around a thousand of those are Gnome
> > related.  See my issue?
>
> Well, realistically, if your unread email queue is over 6000 (not an
> unheard of situation for any of us, really), how can you be expected
> to pay attention to ftp-release-list@×××××.org?

Actually, thats a simple one, since it is a stack of mail, its my
working "todo" list of releases when I start doing updates.   And I far
prefer the digest of the days releases compared to the often duplicated
messages to bugzilla which generate far more traffic and actually forces
me to load it, reply and close (and find a duplicate at that too..)



>
> > Also, unstable releases never end up in the tree, but are maintained
> > (usually ;) in paralell by devs, who then at some time compare notes
> > and push it into the tree as package.masked during the rc phase of
> > Gnome development.
>
> That makes good sense for the late RC stage, sure. But it *does not*
> make sense for the point releases that are largely full of bug fixes
> that immediately follow a major version release

Note that this was -only- the policy for the development series, as that
was implied as "desired" by the previous poster (2.7.x series) And not
either policy or practice for normal stable releases.



> - those need to get out (to ~arch, at least) as quickly as possible. I
> mean, it's absurd that we have presented 2.6.0 as stable to our user
> population, when we all know it's a mess full of glitches (in the
> upstream code, not the ebuilds) - glitches that were promptly fixed by
> upstream and released as 2.6.1 and 2.6.2

I agree, and this has simply been the case of developer evaporation, I
left the country (and hence my cvs access  + ssh keys..) Something we
hope to fix up as soon as I'm through the gnome@g.o bugs to see if there
are outstanding issues.  (There are some for ppc + corba fex.)


>
>
> Here's the thing: as I said to you in the room at GUADEC when 2.6.2
> was announced, the trouble is that no one outside you and foser and
> one or two others have any idea what's going on with the ebuilds
> around Gnome.
>
> So a few suggestions:
>
> * One approach is the hard mask thing, which is a lot of work.

No, its not an acceptable  approach to the development series.  We
really don't want to clutter the whole tree with commits, and even if
things are hard masked, each update would require Manifest and digest
checks on all other builds.  adding the developer series to the tree
will simply overload it too much.


>
> * Another would be using a meta-bug to record discussion around a
> point release issue. For example,
> http://bugs.gentoo.org/show_bug.cgi?id=55947
> (which has a growing Cc list) could be used as a place to discuss
> what's up with the ebuilds that collectively make up a release, and
> how progress is going to fixing them. Indeed, people's being on the Cc
> list can be used as an indication of their potential willingness to be
> beta testers.


its a viable solution, yes.  Currently theres a few issues.. Gstreamer
is unpleasant in some situations, which completely break media setups in
some machines.  Other issues are the spontaneous documentation breakage
( text-apps herd might have some feedback there ) 



> * Find a way to bring more manpower to the situation. When spider is
> away for a two months and foser has a broken hand, things kinda grind
> to a halt in Gnome ebuild land. That makes you two somewhat of a
> single point of failure; systematic ways to prevent that sort of thing
> are important.

Yeah, We need this all over the whole diestirbution, the herds is a step
in that direction, and helps us concentrate some more on it, however it
doesn't help if everyone in a herd dissappears at the same time.  
Unfortuately, Gentoo as a whole is understaffed.

>
> Naturally, Gentoo/Gnome is not your paid employment, but that so many
> of us depend on your work means that we do need to come up with
> solutions that address the needs of the community.

Yeah, unfortunately that is far too true. : ) 

It helped when I had the time to work 50+ hours / week on gentoo (
basically 10 hour workdays ), sadly, I don't have the time for that
anymore.


//Spider
-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end