[arch-dev-public] next major steps have to be planned
The repo shuffle is almost done. Next big tasks are pending. So i want to discuss with you the order for the next steps and how much time we need to finish remaining tasks. 1) Xorg is in testing for months. should we move it knowing some things will be broken. Should it stay in testing for some more time. Give up the bump and delay the upgrade? It's not good to have such a big player in testing for so long. I'm not sure if any other pkg we want to build in testing will link against it and might make trouble later moving it to extra. 2) Pending big updates: db, heimdal, cups 1.3.x together with gpl ghostscript. You all know how long the list of rebuilds will become... 3) We need to make sure all packages in core/extra have at least one active(!) maintainer(not talking about wanted package divisions). Right now we have 550(before core move)-700(now) orphaned packages. Even 112 orphaned core packages after the move. This is not acceptable! Also some maintained packages keep waiting for updates for too long. 4) This brings us to the real repo cleanup. We had a Wiki side collecting ideas for removal and somebody was talking about an improved ArchStats. Both can help us. We should also leave the way how we choose packages we bring into the repo from "hey, I like it so I bring it in" to the needs of our users/community. 5) Move to another version control system. Was it a common decision to move to svn? Then we should prepare the move well not to far away. 6) Setup a standard build tool for all devs: force everyone to make use of a unionfs based devtool. 7) State of repoman? I don't want to hurry from one chaos to the next one. But I also don't want to see us again falling back and watch several months passing. Andy
On 9/18/07, Andreas Radke <a.radke@arcor.de> wrote:
The repo shuffle is almost done. Next big tasks are pending. So i want to discuss with you the order for the next steps and how much time we need to finish remaining tasks.
1) Xorg is in testing for months. should we move it knowing some things will be broken. Should it stay in testing for some more time. Give up the bump and delay the upgrade? It's not good to have such a big player in testing for so long. I'm not sure if any other pkg we want to build in testing will link against it and might make trouble later moving it to extra.
2) Pending big updates: db, heimdal, cups 1.3.x together with gpl ghostscript. You all know how long the list of rebuilds will become...
3) We need to make sure all packages in core/extra have at least one active(!) maintainer(not talking about wanted package divisions). Right now we have 550(before core move)-700(now) orphaned packages. Even 112 orphaned core packages after the move. This is not acceptable! Also some maintained packages keep waiting for updates for too long.
4) This brings us to the real repo cleanup. We had a Wiki side collecting ideas for removal and somebody was talking about an improved ArchStats. Both can help us. We should also leave the way how we choose packages we bring into the repo from "hey, I like it so I bring it in" to the needs of our users/community.
5) Move to another version control system. Was it a common decision to move to svn? Then we should prepare the move well not to far away.
6) Setup a standard build tool for all devs: force everyone to make use of a unionfs based devtool.
7) State of repoman?
I don't want to hurry from one chaos to the next one. But I also don't want to see us again falling back and watch several months passing.
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. 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. 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. 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? Thanks Andy! As always, this is all up for debate, and if I happened to point at you for something here, feel free to say no, I'm just trying to get the ball rolling.
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
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?
Sure. I already have a few names in my mind because a while ago I tried porting packages to x86_64 and came across several ones where the sources were missing or that were dead projects. I'll also check again the wiki list and the orphaned packages in the repo. Before removing anything, I'll post the list of candidates for removal here with a short reason for the removal to inform you and give an occasion to contest the removal of a package. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (4)
-
Aaron Griffin
-
Andreas Radke
-
Eric Belanger
-
Paul Mattal