Mart Raudsepp schrieb: >> If people are a) too lazy to contribute to sunrise, b) don't >> know about sunrise, or c) don't know enough about ebuilds to contribute >> to sunrise, then we need to fix[1] that. > > Sure, the sunrise project can do all of that. That doesn't make the > packages available in the official tree. The maintainer-wanted project > however can tap into the work done by sunrise when a popular package is > to be added to the tree that already exists in Sunrise. If certain > interested in the package users are contributing to Sunrise for that > package, they could hopefully be turned into proxy maintainers in the > official tree version and perhaps even eventually become developers as > well when they have interest in a larger set of packages. If they have > been maintaining a lot of different package in Sunrise before that, they > seem to be a good candidate in joining the maintainer-wanted team too > then, as they seem to be motivated by the kind of work they do, as same > work was done in an overlay by him/her before. > Close collaboration with Sunrise is good, that is. So the end outcome > would be that the packages that are used by many people are available in > the official tree.
I think, you overrate the possible additional free time that developers are able and willing to contribute to Gentoo for such a project. If a dev is intersted in a package, he can create an ebuild, add it to the main tree and maintain it there. If a dev would like to add a popular package, also not being personally interested, he can still do it, nothing prevents him from that. But this does not happen and i think, there is a simple reason: The number of active developers with access to the main tree is limited and the amount of work they can do is it too. In the end, this project would create some or even many packages, that end as m-needed because the team is not willing or able to maintain the amount of ebuilds they initially added. If users are interested in a package and willing to create an ebuild and maintain it, they can add it to the sunrise overlay. If they do continual good work, they can even become developers themselves and move some apps to the main tree (like i did). If they dont continue the maintainence, the ebuild will stay in sunrise as a base for everyone interested without polluting the main tree. Based on this, i would suggest another basic idea (details can be discussed, if accepted): -Make the sunrise overlay more known on different places like front page, blogs, forum etc -Based on some checks (good QA, maintained, fixed reported problems or whatever), add good ebuilds to the main tree with some restrictions (maybe some additional var, only unstable keywords or similar). If there are no complains and bugs get fixed (either some dev or the maintainer (user) does it), it will stay there, if not, it gets removed from the tree again and moved back to the sunrise overlay. Whith this, users would get a central place to start with reading, contributing, learning and proxy maintaining their ebuilds, would be able to get their work to some audience (either those adding sunrise overlay or with good work even the main tree), could learn enough to become developers with main tree access themselves. And if they leave their work alone, it just gets moved from the main tree back to the sunrise overlay and so cannot harm Gentoo, the security team or anyone else for a longer time. Just for clarification: Those contributors would still only commit to a branch not accessable via layman nor does it automaticly write to the main tree. These contributions then get currently moved to the reviewed tree (which is what users get via layman) after some sunrise dev did review the commit. In this proposal, the move to the main tree and any update would go the same way, so no direct access to the main tree by (user) contributors until they got recruited as ebuild deveopers. With this proposal, we could recruite new people to work on things they are intersted in, so it should be relatively easy to get popular packages in the main tree, while not using some (probably not existing) additional dev-time. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
