[Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op zondag 28 november 2010 18:50:28 schreef Michael scherer:
> On Sat, Nov 27, 2010 at 11:16:57PM +0100, Maarten Vanraes wrote:
> > Op zaterdag 27 november 2010 22:07:43 schreef Michael scherer:
> > > On Sat, Nov 27, 2010 at 08:23:59PM +0200, Thomas Backlund wrote:
> > > > Jerome Quelin skrev 27.11.2010 19:11:
> > > > >On 10/11/27 17:59 +0100, Maarten Vanraes wrote:
> > > > >and, more importantly: what is the advantage? that is, what does
> > > > >that bring you, except more admin?
> > > > 
> > > > QA!
> > > > and enduser satisfaction.
> > > > 
> > > > Just take a look on many bugreports in MDV Bugzilla.
> > > > If the report is against a nomaintainer@ package, currently Triage
> > > > pretty much only can state "thanks for your report, but since it has
> > > > no maintainer, nothing will probably happend" wich is not good answer
> > > > for a person that have taken the time to report a bug.
> > > 
> > > Then why don't we either :
> > > - decide that non maintened package must be taken care by trainee, as
> > > part of the training
> > > - decide to clean them.
> > 
> > that's a great idea, we need more trainees! but of course, we can't do
> > that with all 5000+ unmaintained packages...
> > 
> > is there a way to get rpm usage stats from those unmaintained packages.
> 
> No. We can only get download stats from mirrors. While it may be biased
> toward some geographical preference ( ie, I doubt many people download
> locale-zh from distrib-coffee ), it can give at least some ideas. Nothing
> precise, but still better than random.
> 
> > > > By having the /extra/ disabled by default, and a popup notifying the
> > > > user if he enables it that the packages are "unmaintained" he knows
> > > > he's "on his own"
> > > 
> > > That's already what the GPL say, basically :)
> > > ( you have no garantee of anything ).
> > > 
> > > Yet, I fail to see what benefit it does really bring to users. Most of
> > > them will enable the media ( because some people enable everything ),
> > > will forget the message ( because we always forget popup, thanks
> > > to endless abuse of such popup ),
> > > and the only benefit is that we could tell "we told you". Not really
> > > satisfying, and if I was a user, it would not really please me, nor
> > > inspire confidence.
> > 
> > some would, but that they'd also enable testing, backports, debug, etc...
> > if they really do so, it's kind of their own fault. i don't think the
> > majority does that. the majority leaves it at default.
> 
> And so the majority will say "$distro is bad because there is not enough
> software".

i think for most people what we have is enough, sometimes too much choice is 
bad too.

however, when a search doesn't give anything, it can search some of the 
disabled sections; that would alleviate this problem.

> > The thing is that you have no guarantee, but the thing is, with mdv,
> > there's too much packages that just don't work; you install it, you
> > click in the menu and nothing happens because it doesn't work.
> 
> So too much is 10%, more ?
> 
> > same thing and one of them is in extra; then i get only one, if i can't
> > find any, i can enable the searching in extra and try to find a package
> > that works.
> > 
> > that's why i personally would prefer to leave these off by default.
> > 
> > > We could avoid adding a media by merging this media with core,
> > > and show the popup when a user install a package without maintainer,
> > > telling either "beware, this package is currently marked as not
> > > maintained, and may be buggy. We will try to do what we can to help in
> > > this case, but no one is officialy in charge" or "we are seeking help
> > > on taking care of this package, if you use it often, please register
> > > on $URL"
> > 
> > this popup will get ignored too; and persons who are perfectly aware of
> > it, will grow irritated.
> 
> Then, we can do a single "do not ask me again", or just show it once ?
> 
> > futhermore: (no separate extra)
> > 
> >  - huge amount of packages (think of the mirrors)
> 
> mirror space is taken with extra or core. So the argument do not stand
> much. Now, this would be a arguent for simply erasing those unmaintained
> packages.

well, indeed, except that i'm kind of against that; and would prefer mirrors 
with storage issues to just NOT include 'extra'. after all, the mirrorlist 
could just get them from another mirror.

> >  - huge hdlists
> 
> Indeed. But if we want to have people be able to search
> inside like you said you would, this would still be downloaded, be used (
> so in memory ) and on the mirror. So that's also not much a good reason.
> ( however, if we remove them... )

you do have a point here; except that this also goes with updating; since 
extra is unmaintained, fetching newer versions will likely have less impact.