[arch-dev-public] Which Way Forward For Package Maintainance [was: next major steps have to be planned]
aaron.proxy_mail();
Essien had some points to say on this topic, so I figured it was a
good time to break this point out into a separate thread too.
Here goes:
---------- Forwarded message ----------
From: Essien Ita Essien
<snip>
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 agree with Paul here, but I even go futher and *formalize* the problem scope. The problem like I see it is that you *need* to be an *archlinux-developer* to be allowed to maintain packages in core and extra. I guess this is just to guarantee quality of packages but i think there are other ways of guaranteeing package quality and at the same time allowing the current strict definition of arch developers to be the only ones responsible for package maintainance. I want to propose the following approach. 1. The package management team should be properly defined out of the rest of the *blessed* archlinux development team. 2. Every member of this team will be a package Maintainer (even if you maintain just one package, you are a maintainer). But not every member of this team will be able to *commit* to the official repositories. 3. There will be some members of the team called _sponsors_ who will be the only ppl able to commit to the actual repositories and will also act as the QA guards to ensure proper quality of packages. 4. The other maintainers will have to go thru the sponsors to get their packages accepted or updated, and a sponsor can decide to desponsor a package for various reasons (like inactive maintainance by a maintainer or a maintainers non-response to bug reports). The thing is we already have this kind of setup:- namely the community/aur system. I think we _need_ to admit to ourselves that the communit/aur repo works properly, but we need to somehow co-opt that system now that our workload is growing. I propose that: 1. first... all *orphaned packages* from extra, core, community, aur, etc, should be moved into an [unmaintained] repository and just be done with it. 2. Then we should extend official status to community. (adding it to pacman repo files) 3. Then we should slowly start setting up the sponsor/maintainer infrastructure, with all TUs automatically becoming sponsors in the new dispensation along with current developers who want to continue with package maintainance tasks as opposed to other development tasks (ISO building, etc). 4. The new sponsors should go around and for packages that list them as Maintainers but have seperate Contributors, invite those contributors to become Maintainers. 5. Draw up guidelines for the operation of the sponsor/maintainer relationship. I'll be willing to help in any documentation that will be needed if this is to be done. 6. Encourage ppl that are maintaining packages on AUR to apply for package sponsorship for their packages and let the rest happen from there.
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.
I think the system i describe above is more efficient than staying tied to just a small team doing all the work. cheers, Essien
Aaron Griffin wrote:
aaron.proxy_mail();
Essien had some points to say on this topic, so I figured it was a good time to break this point out into a separate thread too.
Here goes:
---------- Forwarded message ---------- From: Essien Ita Essien
You know, we really need to have properly defined seperate dev teams, this main is going to focus on just one of them teams, but in a later mail i'll elaborate my ideas further.
Paul Mattal wrote:
<snip>
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 agree with Paul here, but I even go futher and *formalize* the problem scope.
The problem like I see it is that you *need* to be an *archlinux-developer* to be allowed to maintain packages in core and extra.
I guess this is just to guarantee quality of packages but i think there are other ways of guaranteeing package quality and at the same time allowing the current strict definition of arch developers to be the only ones responsible for package maintainance.
I want to propose the following approach.
1. The package management team should be properly defined out of the rest of the *blessed* archlinux development team.
2. Every member of this team will be a package Maintainer (even if you maintain just one package, you are a maintainer). But not every member of this team will be able to *commit* to the official repositories.
3. There will be some members of the team called _sponsors_ who will be the only ppl able to commit to the actual repositories and will also act as the QA guards to ensure proper quality of packages.
4. The other maintainers will have to go thru the sponsors to get their packages accepted or updated, and a sponsor can decide to desponsor a package for various reasons (like inactive maintainance by a maintainer or a maintainers non-response to bug reports).
The thing is we already have this kind of setup:- namely the community/aur system.
I think we _need_ to admit to ourselves that the communit/aur repo works properly, but we need to somehow co-opt that system now that our workload is growing.
I propose that:
1. first... all *orphaned packages* from extra, core, community, aur, etc, should be moved into an [unmaintained] repository and just be done with it.
2. Then we should extend official status to community. (adding it to pacman repo files)
3. Then we should slowly start setting up the sponsor/maintainer infrastructure, with all TUs automatically becoming sponsors in the new dispensation along with current developers who want to continue with package maintainance tasks as opposed to other development tasks (ISO building, etc).
4. The new sponsors should go around and for packages that list them as Maintainers but have seperate Contributors, invite those contributors to become Maintainers.
5. Draw up guidelines for the operation of the sponsor/maintainer relationship. I'll be willing to help in any documentation that will be needed if this is to be done.
6. Encourage ppl that are maintaining packages on AUR to apply for package sponsorship for their packages and let the rest happen from there.
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.
I think the system i describe above is more efficient than staying tied to just a small team doing all the work.
Not to sound like a cry baby or anything, but I was of the impression that this was a pressing problem. Especially now that there are about 770 orphaned package in extra. (According to an earlier mail). No? Or maybe devs are just too busy with all the other ongoing s restructurings to say/do something about this for now? Consider this a gentle prod in the proverbial backside to those _interested_ in this problem space.
cheers, Essien
I agree with Paul here, but I even go futher and *formalize* the problem scope.
The problem like I see it is that you *need* to be an *archlinux-developer* to be allowed to maintain packages in core and extra.
I guess this is just to guarantee quality of packages but i think there are other ways of guaranteeing package quality and at the same time allowing the current strict definition of arch developers to be the only ones responsible for package maintainance.
I want to propose the following approach.
1. The package management team should be properly defined out of the rest of the *blessed* archlinux development team.
2. Every member of this team will be a package Maintainer (even if you maintain just one package, you are a maintainer). But not every member of this team will be able to *commit* to the official repositories.
3. There will be some members of the team called _sponsors_ who will be the only ppl able to commit to the actual repositories and will also act as the QA guards to ensure proper quality of packages.
4. The other maintainers will have to go thru the sponsors to get their packages accepted or updated, and a sponsor can decide to desponsor a package for various reasons (like inactive maintainance by a maintainer or a maintainers non-response to bug reports).
The thing is we already have this kind of setup:- namely the community/aur system.
I think we _need_ to admit to ourselves that the communit/aur repo works properly, but we need to somehow co-opt that system now that our workload is growing.
Agreed.
I propose that:
1. first... all *orphaned packages* from extra, core, community, aur, etc, should be moved into an [unmaintained] repository and just be done with it.
This one should probably wait till we have a concerted effort to adopt orphaned packages. The reason there are so many right now is because everything that went to core and everything that moved from current to extra lost its maintainer. Once we clean those up it's probably a good idea.
2. Then we should extend official status to community. (adding it to pacman repo files)
Isn't it already in by default?
3. Then we should slowly start setting up the sponsor/maintainer infrastructure, with all TUs automatically becoming sponsors in the new dispensation along with current developers who want to continue with package maintainance tasks as opposed to other development tasks (ISO building, etc).
How do you propose we do this?
4. The new sponsors should go around and for packages that list them as Maintainers but have seperate Contributors, invite those contributors to become Maintainers.
5. Draw up guidelines for the operation of the sponsor/maintainer relationship. I'll be willing to help in any documentation that will be needed if this is to be done.
6. Encourage ppl that are maintaining packages on AUR to apply for package sponsorship for their packages and let the rest happen from there.
I think contributions will be driven by the ease of communication... I don't know what sorts of problems we'll run into there...
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.
I think the system i describe above is more efficient than staying tied to just a small team doing all the work.
I like the thought of doing it slowly. It's always easier to adjust for the unforseen when you can do things one step at a time. Jason
participants (3)
-
Aaron Griffin
-
Essien Ita Essien
-
Jason Chu