[arch-dev-public] Repo Distinctions
Essien Ita Essien
me at essienitaessien.com
Wed Oct 17 12:58:30 EDT 2007
Aaron Griffin wrote:
> On 10/16/07, Simo Leone <simo at archlinux.org> wrote:
>> Sounds like making a mountain out of a mole hill to me.
> At first, I didn't think Simo was right. I thought this would go the
> way of a sane discussion.
> But in typical devland fashion, we decided to stab this issue to death
> with the knives of blather.
> Let me see if I can steer this cart away from the cliff a bit, but we
> might be going too fast to abort.
> Everyone makes these grand claims like "repoman will fix THAT" and
> "lets move TUs up and start 'firing' crappy packagers" and all these
> sorts of things. Don't get me wrong, they're perfectly valid
> suggestions and good ones.
> The problem is the timeline. This is always an issue. A lot of these
> suggestions will take a large chunk of work, and a lot of effort.
> I know how our dev team works. If we actually decide that these things
> are a good idea, there will be two people doing the work while
> everyone else keeps wondering why it's not done.
> So we simply can't do that. Fact.
> We need to move in baby steps. We WILL have a problem implementing
> these large sweeping suggestions, so here's the question I pose to all
> of you who have very strong opinions:
> What's the first step?
Step 1 (for the BDFL) - (1 day):
Let's create an 'Arch Linux Packaging Standards Group' or something to
that effect. I suggest that Aaron our dear BDFL selects 3 ppl to make up
this group. These persons should be the *best* (in Aaron's opinion - use
other's opinions too? but Aaron should make the appointment, so we don't
waste time deciding) Packagers on Archlinux Development Team.
Step 2 (for the committee) - (1 weekend for version one. we'll roll with
that for now):
Draw up all the currently known metrics that namcap judges packages by
and all the current warnings that makepkg issues.
Jason can help the committee with this. (if they ask nicely :P)
Step 3(for the committee - (1 weekend for version one)):
Which of these MUST be passed before a package is acceptable.
The rest should happen after these have been completed.
Step 4 - (i can't put time here, but i'm serious about putting my money
where my mouth is).
coders work on this. I'm ready to put my money where my mouth is and get
work done here:
- modify namcap and makepkg to spit out metrics in a more obvious way
to rhyme with the results of step 3 above.
Step 5 - (a one month test period is okay to shake out the version one
of the tools).
Test these tools to death and begin to use these with our current
Are the above steps granular enough?
I'll want to stop here... if we get here... the journey is 50% completed.
The next steps will involve the actual collapsing of [extra] and
[community] into eachh other... but a tool needs to be in place before
that happens. But if we can get from step 1 to 5... the hardest parts
will be done.
PS: I won't have internet again till some time tmrw. can't reply :(
> I don't want to look at these giant "we can finish this in 3 months"
> solutions. What I want is a "here's a small step that helps solve it
> and works toward the larger solution".
> The other option, of course, is for someone to sit down, write some
> code, and "put your money where your mouth is", as they say.
> arch-dev-public mailing list
> arch-dev-public at archlinux.org
More information about the arch-dev-public