[arch-dev-public] Repo Distinctions

[Eric Belanger]

On Wed, 17 Oct 2007, Paul Mattal wrote:

> Eric Belanger wrote:
>> Shouldn't the first step be to identify clearly what current or potential
>> problems are we trying to solve?  Maybe that whole repo reorganisation is
>> not needed after all.
>
> Here are some I'm trying to solve:
>
> 1) Unclarity about what our committment is to packages in various
> repos. We need some clear way for the dev team to commit to
> maintaining a package in the long term, and some way to easily
> identify and track packages identified thusly.

I think that we already have a good idea about the importance of packages 
without the need to be in a specific repo.

I'm also concerned about the guidelines that we will need to follow to 
determine if a package should go in mantle or crust.  If they are too 
strict, we'll end up with only a few package in mantle. That won't help 
much as I just said earlier: no need to have X in a mantle repo to know 
that it'll stay in the distro. On the contrary, if they are too 
loose almost all packages will end up in mantle, as Damir suggested, with 
maybe 30 or so packages in crust. We could even  end up with a practically 
empty crust repo at one point if its packages gets orphaned and removed. 
Is it worth all that inconvenience to our users and our work and time to 
just separate a few packages from the rest? I don't think so as no harm 
it done by keeping them with the rest and dealing with them when they'll 
become orphans.  At last, if the guidelines are anywhere between strict 
and loose, we risk going into a bikeshed discussion with for result two 
repos  with packages more or less randomly distributed between them.


>
> 2) Gross numbers of orphans everywhere and no clear method to follow
> to proceed to eliminate them on an ongoing basis. (not saying your
> proposal doesn't address this.. but you asked for the problem list)

The way I see it, after the current cleanup/adoption process, there will 
be no orphans left. The packages that we need to keep (dependencies, etc) 
will be adopted and/or assigned. the rest will be moved to 
unsupported. Future orphans can be delt on a 
case-by case basis with what I suggested. I'll repost it here in case it 
got lost in the numerous threads posted lately (it's open to 
discussion/modifications:

 	When he orphans it he post to the ML so that we know about the issue and
 	to perhaps speed up its readoption by another dev. If no dev wants to
 	adopt it and if its movable to community (above reasons), we ask if a TU
 	wants to adopt it. If so, we move the package in community.  If no TU
 	wants to keep it, we could keep it in extra, especially if it's up-to-date
 	and in working condition. We might be able to maintain it as an orphan as
 	a group effort if people check it regularly for update and fixes.  I don't
 	have any problem in having a few orphans.  If the package becomes stale or
 	a pain to update/maintain, we can ask again the TU and this time move it
 	to unsupported if no one wants it. We could also do the same if the number
 	of orphans becomes too large to handle.

>
> 3) Reducing the inefficiencies in the tools that developers and
> community members have at their disposal currently to contribute
> their stellar efforts for the benefit of everyone. Specifically:
>
> a) Moving packages from one repo to another is hard.
> b) Placing packages in multiple repos is hard.
> c) Continued separate-track development on a package while in
> testing is hard.
> d) Tracking multiple binary repos for different architectures is hard.
> e) Maintenance of a package by more than one person is hard.

The above issues will be better solved by using other means than a 
split-up of extra, like switching to a new SCM as Jason pointed out in 
another thread.


>
> This is just a start. All of these goals can be served or affected
> by the choices we make for repo design.
>
>> If the main issue here is a potential increase in the number of orphans
>> after the current cleanup, I posted a simple solution in another thread
>> that would work with the current repo setup with zero work involved.
>
> This is one of the main issues, yes.
>
>> BTW, we should wait until the cleqanup/adoption is completed before doing
>> any repo work.
>
> That might make sense, depending on whether or not this would help
> or get in the way of the cleanup/adoption effort.
>

We should focus our effort on the cleanup/adoption to complete it once for 
all. It has been started months ago.  The longer we keep these packages, the 
more effort/time  we put in them for updates/fixes/rebuilds for .so bump. 
Time and effort that could be better spent. Plus they clutter the package 
interface.


> - P
>
> _______________________________________________
> arch-dev-public mailing list
> arch-dev-public at archlinux.org
> http://archlinux.org/mailman/listinfo/arch-dev-public
>
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.