[Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

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:
> > >
> > >what are the rules to move a package from extra to core, and vice-versa?
> > >who can do it? will it be done automatically? will this imply a rebuild
> > >for the package?
> > 
> > If a maintainer picks up maintainership of a package  in /extra/ it will
> > be rebuilt and moved to /core/ asap.
> > 
> > if a package in /core/ ends up nomaintainer@, then after a "grace
> > period" (1-3 months ?) it will be moved to /extra/.
> > and sometime before RC1 or so, any momaintainer@ package in /core/
> > will get moved to /extra/ as for a release the /core/ should only
> > contain maintained packages.
> 
> But isn't it in contradiction with the fact that release should not be
> changed ?
> 
> IE, a package could be in core for one release, and extras in another.
> 
> What happen to such shrodingerian packages ?
> What happen if this break the self containement ?
> And finally, isn't it redoing contribs/main , leading in the future to the
> same problem we tried to avoid ?
> 
> > >what are the dependency rules? can a core package depend on an extra
> > >package? or with a buildrequires?
> > 
> > No.
> > If you need to build against a package in /extra/, either pick up
> > the maintainership of it, or try to get someone other to maintain
> > it.
> > then it can get into /core/
> 
> And so, if no one step, wouldn't it be like current mdv, where people will
> say they maintain the package just because someone has to do the job ?
> 
> > >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.

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

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. if i have 2 packages that do the 
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.

futhermore: (no separate extra)
 - huge amount of packages (think of the mirrors)
 - huge hdlists