[gentoo-dev] Lack of Gnome Development

[gentoo-dev] Lack of Gnome Development

[Simon Watson]

Hello,

I recently joined the #gentoo-bugs channel on the bug day on Saturday
3rd July. I wanted to help out with getting some of the gnome-related
bugs removed, as well as getting gnome bumped up to the latest point
releases.

I tried this after submitting my own ebuild, getting on for a month ago,
which resulted in the following unhelpful response shown at:
http://bugs.gentoo.org/show_bug.cgi?id=54008 - and has not yet been updated.

My attempt at creating further discussion with very helpful advice from
kloeri on IRC resulted  http://bugs.gentoo.org/show_bug.cgi?id=55947
being created. There has not yet been any comment on that from any gnome
devs.

I understand that developers must be under pressure, and that they
cannot have updates ready as soon as the software is released. However
most of gnome in portage is nearly a month old, with no packages for the
latest "stable" releases in the unstable branch. I have been bumping
most of this software locally, and unless I have missed something, they
are very simple updates that involve merely copying the ebuilds to their
new version names. I note that the gnome team was not advertising for
new developers during the bug day. May I suggest that this happens?

This is not in anyway intended to annoy/anger/upset/get at anybody. It
is just an attempt to get Gnome in portage a little more up to date than
it currently is.

Thank you for your time,

Simon


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Lack of Gnome Development

[Spider]

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

begin  quote
On Fri, 09 Jul 2004 18:44:08 +0100
Simon Watson <simon@swat.me.uk> wrote:

> This is not in anyway intended to annoy/anger/upset/get at anybody. It
> is just an attempt to get Gnome in portage a little more up to date
> than it currently is.
> 
> Thank you for your time,
> 

Snipping most of this message just to do a public announcement of sorts:

I'm back ;)

I'm just catching up on email (mark list as read works wonders when you
have more than 6000 messages waiting ;) and some systems maintainance,
Will see about getting into cvs commits during this weekend, if things
work as I want them to.

Now, time to update chinstrap builds, which are sadly outdated.

//Spider

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Lack of Gnome Development

[Spider]

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

begin  quote
On Fri, 09 Jul 2004 18:44:08 +0100
Simon Watson <simon@swat.me.uk> wrote:

> I tried this after submitting my own ebuild, getting on for a month
> ago, which resulted in the following unhelpful response shown at:
> http://bugs.gentoo.org/show_bug.cgi?id=54008 - and has not yet been
> updated.


okay, you just got a generic answer, so I figure I'd post this one too:
there is a list, also known as ftp-release-list@gnome.org .. 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?

Also, submitting your own version does very little when you don't tell
what you changed.   Better use the "diff -u" command to show us.  if its
only the change of "mv nautilus-$OLDVERSION.ebuild
nautilus-$NEWVERSION.ebuild" ... don't bother.

in your case, the only difference is a (broken, on top of it) change of
the eel dependency from $PV to strict .1 (when .2 is the latest....) 

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.


Make my work a bit easier, dont file bugs for every of the 60+ packages
released.

( And yes, I saw the announcement of Gnome 2.6.2... I was in the room at
 GVADEC )


Sorry if I sound harsh and bitter, but I'm wading through bugreport
emails right now, and its not made much easier by annoying extras.

//Spider

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Lack of Gnome Development

[Andrew Cowie]

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

Hey Spider, welcome home.

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@gnome.org?

> 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 - 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

> Sorry if I sound harsh and bitter, but I'm wading through bugreport
> emails right now, and its not made much easier by annoying extras.

[No, you're actually being quite reasonable]

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.

* 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.

* 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.

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.

AfC
Sydney

-- 
Andrew Frederick Cowie

OPERATIONAL DYNAMICS
Operations Consultants and Infrastructure Engineers

http://www.operationaldynamics.com/

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

Re: [gentoo-dev] Lack of Gnome Development

[Spider]

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

begin  quote
On Sat, 10 Jul 2004 15:49:43 +1000
Andrew Cowie <andrew@operationaldynamics.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@gnome.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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]