[arch-dev-public] Repo Distinctions
Essien Ita Essien
me at essienitaessien.com
Wed Oct 17 06:22:47 EDT 2007
sorry guys... i've been battling internet connection issues, so i have a
lorry load of mails to catch up on. This issue is pretty close to my
nuggin, and i've harped on it before so here goes my 2[insert favourite
coin currency here]
Roman Kyrylych wrote:
> 2007/10/17, Paul Mattal <paul at mattal.com>:
> What about all those users who will have to change their pacman.conf every time?
> The separation of extra gives no good results, zero, void, nil.
I agree. The only thing it creates is a hierarchical distinction b/w
"very official packages" and "not so very very official packages" (oh!
and it applies those same labels to the ppl _NOT_ allowed to maintain
packages in the said repos.
>> Of course, if the argument is that devs should maintain packages in
>> [community] because the distinction between devs and TUs isn't
>> important, another solution would be to flatten things and have [core],
>> [mantle] and [extra] and let TUs and devs maintain packages in [extra].
> Another thing would be to have community integrated in extra.
This has always been my preferred solution. Heresy you may say, but just
sit back and think of it. Some developers prefer packaging work and
others prefer tool-chain kinda work. If we could clone those that prefer
packaging work, would it increase the amount of high quality and
maintained packages in [extra] ? (can i get a big "oh... yeah!") (mooo!)
I think with current cloning techniques its possible to take our best
[extra] packager and clone him/her. I swear I saw it on tv last week.
The took this guy... and they put him in a class and he first documented
what he did and worked through with others untill first the _imbibed_
what he was teaching them to the letter, then he let them loose.
This cloning technique eventually raised some clones who where in a lot
of ways better than the original specimen (yeah... it blew the
researchers mind's too!)
joking aside though. I think we just need to actually DOCUMENT a strict
packaging standard (this exists already. no?), and then open up the
flood gates to new upcoming would be _packagers_. No distinctions...
just one high quality highly udated repository.
>> But I still think it's worth separating the devs and the TUs.. this is
>> not to say we shouldn't poach regularly from the TU pool to devs, but
>> the TU post is a great way to get yourself trained to be a good dev.
>> Look at how many came through that way!
Instead of devs and TUs... i'd call them Developers and Packagers. Small
distinction yes, but in the light of what i'm suggesting above... the
net gain would be huge.
> Separation of devs and TUs is not the same as separation of their
> packages into different repos just by factor of package ownership.
I would say... _all_ packagers can maintain in [extra] but only
Packagers who are also Developers can maintain in [core]. After that...
maintain your own private repo or something. You say what about AUR?
I'll try to keep this post on topic, but i think AUR can actually become
the interface for this new breed of Packagers. 'noda post... 'noda day.
> Seriously, what's wrong with main/mantle packages staying in extra and
> moving unimportant to community?
who's to say what's unimportant? pretty subjective.
> What's the difference between packages maintained by developers and
> _trusted_ users? Community packages are not system-critical anyway.
who is to say what is system critical on my system? Me of course... not
any dev or tu or packager any where. All packages _are_ system critical,
but the packages in [core] _define_ Archlinux.
c'mon guys... are we afraid we'll actually raise packager better than us?
The first step will be to extend this hand to the current TUs and let
them be the first level clones (ouch!).
A key point to keep in mind is that ANY (sorry for the raised voice)
packager that slacks in maintainance of their packages WILL be revoked
and if no taker is up for the maintainance of that package, the package
will be moved out of the repositories with loud shouts on all mailing
lists and news front page.
More information about the arch-dev-public