[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Ryan Hill]

On Mon, 28 Mar 2011 02:55:14 +0530
Nirbheek Chauhan <nirbheek@g.o> wrote:

> The current problem is burnt-out or semi-active devs who commit
> occasionally, but aren't able to help with any herd-related work
> because they're out of touch. As such, their presence in the team
> gives a false indication of strength. This problem was much less
> severe in 2007 (afair).

What?  If anything it was much worse. It used to be next to impossible to get
any answer whatsoever out of some herds until you gave up and fixed it
yourself.  Then they would bitch you out for touching their junk.  My job has
gotten a lot easier lately.

> > The community got pissed when I deleted unmaintained packages from the
> > tree 'just because it was unmaintained.'  Thats why there were a set
> > of criteria for removal.  Maybe they changed their mind and you can
> > convince them.
>
> Well, I bet that more than half of them retired or stopped being active.

Nope, still here, still bitching. :)

> > At least during my tenure there were still hundreds of
> > unmaintained and broken packages; so I didn't much care about
> > unmaintained but working stuff (since there was plenty of work to do.)
> >  I would argue the tree is still in a similar state.
>
> The fun part is that we really don't even know in what state those
> packages are w.r.t. runtime issues. I know that deigo's tinderbox
> keeps track of compile-time issues *extremely* well, but we have zero
> runtime testing.

Well, that /is/ what bugzilla is for, after all.  We can only fix what we
know is broken.  And I don't see how that's any different than "maintained"
packages.

> >> I really don't understand *why* people want to keep around
> >> unmaintained packages. If a package is not maintained, we should come
> >> up and say it outright. Trying to maintain the illusion of maintenance
> >> is really bad — for each person reporting a bug about a package, 100
> >> people who got that same bug don't report it at all. So what happens
> >> when there are just 50 users for some packages? Half the time we won't
> >> even know that one of them is broken[1]. The rest of the time, users
> >> will get a bad impression of Gentoo saying "Man, half the packages
> >> don't even work".
> >
> > Properly tagged I don't think there is any illusion.
> > Maintainer-needed is maintainer-needed after all.
>
> The problem is that from the PoV of the user, everything in the tree
> is "official". After all, that's how all the distros function.

The problem is that you assume that anything that is maintainer-needed is
automatically broken, when the vast majority of it is not.  Would it make you
feel better if packages had default herds they could fall back on rather than
go maintainer-needed (eg. app-crypt packages would automatically go into the
crypto herd, media-gfx go to graphics, etc.)?  That's something we could be
more aggressive about.

> > So launch gstats and get usage numbers.  If no one is using a package
> > that is a keen indicator it can be punted; however no one will get off
> > their ass and get more data to back anything up (myself included...)
>
> If we launch gstats *today*, it'll take us at least a long time before
> we get decent numbers, and even after that, those numbers will be
> biased towards those people who are really active in following Gentoo
> news and developments. Unlike Firefox's usage stats, we have no way of
> prompting pre-existing gentoo installations with a "Do want to take
> part in gstats?" question.

Last I checked we had a nifty news system for making announcements.  And I
thought we were supposed to have Smolt support like two years ago.  What
happened to it?

> > All of your points above assume we have a decent metric of 'how many
> > users a package has' and about the only way we know that is when users
> > file bugs for it (version bump, bug, feature req, etc..)
>
> Yes. But we have another (more reliable) way: p.mask it and wait for
> people to complain.

Hey, maybe next we can slip random build errors into packages and see who
files bugs.  I don't know why people continue to think that breaking the
tree to see who complains is an acceptable form of QA.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662