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