[arch-dev-public] next major steps have to be planned

[Paul Mattal]

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
> charge.

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 
Allen happy.

- P