From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101127/001471.html | 155 ++++++++++++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101127/001471.html (limited to 'zarb-ml/mageia-dev/20101127/001471.html') diff --git a/zarb-ml/mageia-dev/20101127/001471.html b/zarb-ml/mageia-dev/20101127/001471.html new file mode 100644 index 000000000..e4e124341 --- /dev/null +++ b/zarb-ml/mageia-dev/20101127/001471.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Mirror layout, round two + + + + + + + + + +

[Mageia-dev] Mirror layout, round two

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Nov 27 23:16:57 CET 2010 +

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

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1