[Mageia-dev] Mirror layout, round two

Maarten Vanraes maarten.vanraes at gmail.com
Fri Dec 3 01:55:26 CET 2010


Op donderdag 02 december 2010 08:20:15 schreef andre999:
> Maarten Vanraes a écrit :
> > Op woensdag 01 december 2010 21:54:48 schreef andre999:
> > [...]
> > 
> > allthough interesting, this thread is about mirror layout; and is not
> > about removing the distinction between supported packages and not. (this
> > wasn't all that clear to me at first.)
> 
> I'll discuss further down why I think that this is a critical part of
> the question.
> 
> > i do understand that you think other methods of having the distinction
> > might not work; i have reservations myself that way. (i do feel the
> > disctinction is important.)
> 
> Glad to see that you understand my concerns.
> 
> > i also see that mirror layout should be as easy as possible for mirror
> > admins.
> 
> Agreed.  However keeping an extra set of repositories for core packages
> would just add a few extra directories (without changing the number/size
> of their total content), thus have little impact on mirror administration.

One would think so; however, a few people who replied where mirror 
administrators; and it seems, IIUC that they said it does have impact.

I'm just gonna trust their judgement on this, since they know more about this 
than myself.

[... snipping tainted stuff...] 
> In any case, rsync is a pretty straight-forward application.
> 
> > however, looking at the big picture, i think that logically it's sounds
> > to have one purpose to one thing; and thus for the mirror layout; only
> > the mirror admins should be looked at; the viewpoint of a user _should_
> > not really matter.
> 
> I agree that the user viewpoint is not of major importance : I see that
> as just a positive side effect.
> 
> I am trying to look at the big picture.  And perhaps I haven't been very
> effective at expressing my concerns.
> In my mind, we should always consider important side effects of major
> changes.  And removing separate "core"/"extra" (or "main"/"contrib"
> repositories does have an important side effect.
> Realigning "core" so it is really core should very much help packagers,
> as well as maintaining an important distinction.
> 
> Note that if, down the road, we find another effective method for
> distinquishing core / non-core, it is relatively simple to transfer
> packages in "extra" to "core".
> But if we eliminate the parallel set of repositories, and find later
> that we have a problem giving priority to core packages, moving in the
> other direction would be a much more difficult process.

IIRC someone with experience said in this thread that we could always go to 
that sort of scenario if like this it wouldn't work well. Again, i'm gonna 
trust their judgement on this.

> The suggestion that we only transfer to Mageia packages that we see as
> important to keep, sounds like a very good approach.
> This would also facilitate maintaining the core / non-core distinction.

I suppose, however, I think that developers are their own users; they write 
for theirselves; hence people will pull what they think is important for them.

but at the very least, since it's something they will use, it'll at least be 
tested some. (even if QA doesn't test it)

> I'm not trying to say that defining core / non-core in detail is a
> trivial process.  But it is in the interest of Mageia to define it.
> 
> I realise, at least at first, that things will be more difficult for
> packagers.  But firmly believe that this will be largely alleviated by a
> careful triage of existing "main" and "contrib" packages.
> Thus I am more than willing to put in a lot of effort, since it will
> have an important impact on the future of Mageia.
> 
> I also realise that many of those proposing eliminating a set of repos
> have a lot of valuable experience.  And I'm sure that if/when we can
> agree on this concern, that we will be able to work very well together.
> And I look forward to becoming a Mageia packager.
> 
> another 2 cents :)
> 
> - André


More information about the Mageia-dev mailing list