[arch-dev-public] next major steps have to be planned
paul at mattal.com
Wed Sep 19 14:33:58 EDT 2007
Aaron Griffin wrote:
> One step at a time here, man! None of this will get done doing it this way.
> I have a suggestion, to start with. This is going to make things go
> MUCH smoother in the long run, I promise.
> All of these things Andy has mentioned are important, but we can't
> carry on like a maelstrom.
> Lets move one step at a time. We need people in charge of these
> projects instead of everyone trying to run the show. So right now, for
> each of these points, I'm going to nominate someone to spearhead the
Thanks for leading the delegation!
> 1) Xorg move. Alex is our xorg guy if I'm not mistaken, could you send
> us (new email thread, please) a little status report as to the state
> of things?
> 2) Please keep us in the loop here. I, myself, was unaware of these
> incoming updates. Andy, seeing as you seem to know the details, could
> you give me information as to the schedule of these updates (another
> email thread please), I will work to get things in order and planned
> so this will go smoothly, I just need the information to do so.
> 3) This has historically be a problem forever - unmaintained packages.
> Some of us do a lot of development work (Dan, Eliott, etc) and don't
> have huge amounts of time to help out with 200 packages at once. But
> we do need a way to stabilize this load a little better.
> Andy, you seem to know our current package set better than anyone.
> Could you possibly keep on bringing this up to people - in an attempt
> to push the load around just a little bit.
> By this, I mean, if we have a person with 10 packages (not people
> doing heavy development work) and others with 300, we should do
> something about that - you seem the best person for this job.
I remain convinced that the way to tackle this problem is to allow
more than one maintainer per package. If groups of people are
responsible for a package, people will feel more empowered to work
on packages that aren't "theirs" and will know who to coordinate
with to do so.
I know I personally would sign up as a maintainer for more packages
if I weren't the "only one" taking them on but rather part of a team
maintaining those packages.
This switch will be facilitated by repoman, when it is finally done.
Since repoman will maintain its own database tying all the
pieces/aspects of a repo together, it will also keep track of things
like who maintains what and allow this type of flexibility.
> 4) So we need to revisit, once again, the package cleanup that I had
> started months ago. Eric, you were helpful last time - would you be ok
> with figuring out the details of another round of cleanup?
> 5) I would like to address this issue coming up soon. All of us
> working on real code are sick of having things in CVS, and I know the
> hardcore packagers must feel the same.
> Believe me, this is a critical issue in my book. If everyone else can
> hold up their end on these other points, I will tackle this one.
I think we should consider git before we switch to svn. Seems like a
lot of things are moving in the decentralized direction, and git
seems like it's the popular decentralized choice. Even though we'd
need a shared git repo to serve as the authoritative place for
PKGBUILDs that are actually in the binary repos, if everything's
moving toward git, I'd rather not have to migrate AGAIN in a few months.
> 6) We talked about this in IRC. I have 2 or 3 scripts that I want to
> combine and polish up for inclusion in devtools, or a similar package.
> These scripts use a prebuild clean chroot and a unionfs overlay to
> build packages in a chroot. They work nicely, but, as I said, they are
> rough on the edges.
> I *WILL* make this available to you all by the weekend for testing and
> the like. 8)
> 7) Paul, could you give us a status update? I know I'm not subscribed
> to the ML (too much mail already), and other devs probably are not as
> well. Could you perhaps start up another email thread for the status
> and timeline?
The timeline on this has obviously slipped, and for various reasons.
For starters, remind me never ever to plan big project activity
across a summer again! Things just lose momentum in the summer, and
I'm as much to blame for that as anyone.
My next step is to code up a barebones repoman. The ideas have been
rolling around for a while, things have begun to crystallize in my
head for the design, now it's time to write some code.
I will try to do this next step over the weekend of October 6 when I
expect to have a chunk of free time. In the meanwhile, I'll try to
fire up discussions on any other repoman topics that are still
unsettled in my mind.
If this starts the devel process proper for repoman, then I imagine
we'll start to have have something ready for serious testing by
Christmas, but that's really a guess at this point. It will depend a
lot on how much time existing AUR maintenance diverts me and what
other directions we decide we want to take.
At least this is a couple of next steps, which would make David
More information about the arch-dev-public