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

[Mageia-dev] Mirror layout, round two

+ andre999 + andr55 at laposte.net +
+ Mon Nov 29 10:51:24 CET 2010 +

+
+ +
Michael scherer a écrit :
+> 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 ?
+>    
+
+It's simply not workable to base a package's repository on whether it is 
+currently maintained or not.
+It is much better to classify it on whether it *should* be maintained, 
+in order to have a fully functional user's system.
+That is, it is in core because it is *core* to a typical fully 
+functional desktop or server or developer's system.  Or very useful to 
+such a system.
+So if such a package is not being properly maintained, there is a 
+collective focus to make sure that it is maintained, so that user's 
+systems remain functional.
+
+Extra should be just that.  Packages that are extra to a fully 
+functional core Mageia system.
+
+It is inevitable that most packages, whatever their importance, will be 
+unmaintained - or at least without an official maintainer - from time to 
+time.
+What we don't want to happen is a repository yoyo - where a package 
+bounces from core to main and back - just on the basis of its current 
+maintenance status.
+
+And a package should *never* change repositories between releases.
+>
+>    
+>>> 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/
+>>      
+
+Seems like a lot of wasted effort - which could be better applied simply 
+maintaining core packages.
+> 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 ?
+>    
+
+Note that Mandriva is currently overhauling their system - to remove 
+much non-core packages from main.
+>
+>    
+>>> 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.
+>    
+
+Exactly.
+>> 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 ridiculous.  We should be in the cooperative spirit of the GPL, 
+instead of saying "too bad, you can't depend on Mageia."
+> That's already what the GPL say, basically :)
+> ( you have no garantee of anything ).
+>    
+
+But no garantee doesn't mean no help.
+> 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"
+>
+>    
+Not a bad idea.  Why not both messages ?
+Really better than an option to exclude seeing officially non-maintained 
+packages.
+Some packages on my system work perfectly well, but haven't been 
+"maintained" for several years.
+
+I would still keep a separate core and extra, where core is core, and 
+extra is extra.
+(As I described above and in more detail in previous posts to this thread.)
+
+- André
+
+
+ + + + + + +
+

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