[Mageia-dev] Mirror layout, round two

Sun Nov 28 21:12:54 CET 2010

Michael scherer skrev 27.11.2010 23:07:
+> 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 ?
+>
+
+Nope.
+The package movement only happends in Cauldron, never in a Stable 
+release. If a package gets "orphaned" in a stable release, we have to 
+cope with that.
+
+> IE, a package could be in core for one release, and extras in another.
+>
+
+Yep.
+
+> What happen to such shrodingerian packages ?
+> What happen if this break the self containement ?
+
+Then the package needing that should be reviewed:
+- Is it an essential feature that gives the requirement?
+- if not, can that part be disabled?
+- if it's essential, pick up the maintainership, or get someone to do it.
+
+> And finally, isn't it redoing contribs/main , leading in the future to the same
+> problem we tried to avoid ?
+>
+
+Not really, since all stuff maintained in old contribs is now in /core/
+I'm trying to get a fully maintained /core/
+
+Or do you think it's better to have a single media wich pretty much 
+would be a dumping ground ?
+
+Of course one easy option (for us) is to simply start dropping 
+unmaintained packages from the mirrors.
+Or as a middle ground we could set the rule on /extra/ that after a 
+"grace period" of x months, it will get dropped.
+
+Oh, and looking at current cooker:
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*mdk.*|wc -l
+69
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2007.0*|wc -l
+55
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2007.1*|wc -l
+71
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2008.0*|wc -l
+212
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2008.1*|wc -l
+573
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2009.0*|wc -l
+980
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2009.1*|wc -l
+596
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2010.0*|wc -l
+5989
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2010.1*|wc -l
+11236
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*2011.0*|wc -l
+22182
+[thomas at tmb Cooker]$ ls 
+{i586,x86_64}/media/{main,contrib}/release/*mnb*|wc -l
+316
+
+So if we ignore the >=2010 and mnb* packages,
+we still have 2256 packages that does not even have been rebuilt
+
+>>> 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 ?
+
+That's a risk, yeah. but if the package newer get touched, it will still 
+show...
+
+>
+>>> 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.
+
+This would be an option.
+
+
+>
+>> 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.
+>
+
+True.
+
+> 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"
+>
+Could be done...
+
+One thing hit me now...
+I've only been thinking of current cooker and all of the old stuff there...
+
+But since we are going to have to import/rebuild every package we need, 
+it gets real easy... We just dont import any unmaintained stuff.
+
+That way we get a clean mirror start for Mageia.
+
+And if someone import a package, it makes him the maintainer.
+
+Then if a package loses it maintainer, we need a policy like "if its not 
+maintained for X months, we drop it from the mirrors...
+
+So the mirror medias accordingly to all comments so far would be a simple:
+
+* core
+   - enabled by default
+   - mirrors must mirror this media to be listed as a mirror
+   - only GPL stuff
+   - must be selfcontained
+
+* nonfree
+   - disabled by default, installer will ask to enable it if
+     it detects hw that need driver/fw from here...
+   - mirrors must mirror this media to be listed as a mirror
+   - contains apps/drivers/firmware that are free to redistribute,
+     but we dont have GPL source for
+   - for example ati/nvidia drivers/firmware, Oracle Java, ...
+
+* tainted
+   - disabled by default
+   - mirrors are free to not mirror this media
+   - stuff we think we can redistribute, but that may have some
+     patent issues or other restrictions in oter countries.
+
+
+--
+Thomas
+