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/001470.html | 137 ++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101127/001470.html (limited to 'zarb-ml/mageia-dev/20101127/001470.html') diff --git a/zarb-ml/mageia-dev/20101127/001470.html b/zarb-ml/mageia-dev/20101127/001470.html new file mode 100644 index 000000000..2afe31593 --- /dev/null +++ b/zarb-ml/mageia-dev/20101127/001470.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] Mirror layout, round two + + + + + + + + + +

[Mageia-dev] Mirror layout, round two

+ Michael scherer + misc at zarb.org +
+ Sat Nov 27 22:07:43 CET 2010 +

+
+ +
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. 
+
+> 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.
+
+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"
+
+-- 
+Michael Scherer
+
+ + + +
+

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