Hi Chris, On 3/23/06, Chris Bainbridge <[EMAIL PROTECTED]> wrote: > Developers are using overlays, however, the majority of users aren't.
True. But does that have to be the audience for overlays? > If the usage of overlays is to increase, then remote overlay support > should be added to emerge. Additionally, in order for users to be able > to contribute to the overlays, it would help if they had anonymous > read access. I forgot to mention that anonymous read access would be available, although we'll have to see how that impacts the hardware. We may need to raise some funds / scrounge some extra kit to make o.g.o scale if it proves wildly popular. As for remote overlay support ... try using layman to see if that's enough for today. If we find we need more support in future, we can revisit the situation. We're not trying to get all users to use overlays instead of the Portage tree. We're just creating a social space where non-devs who want to contribute can work more easily with existing devs. > The safety net was intended for developers. Then it's a change in topic. Please start a new thread on here for it. > Packages often get broken > in unexpected ways - something depends on it, a patch is conditional > on some USE flag or arch etc. It would be useful to get an email 5 > minutes after a commit saying "you broke something", rather than a bug > report being filed a week later. How does that differ from the service that autorepoman already provides? Maybe you need to be talking directly to Mark and the QA team about this. > I don't think it is unrealistic to expect that if a user puts a lot of > work into an ebuild, and it works, then it should somehow end up in > the tree. Okay, that's something I'd like to nip in the bud right there. Something "working" is not the only criteria that Gentoo requires for a package to go into the tree. I'm sure you already know that. If we don't have a developer willing to maintain the package, it doesn't belong in the tree. It's not sustainable to have "fire-and-forget" packages lying around. One problem I've seen with recruitment is devs who don't "stick", who stop contributing after a short period of time, and who fade away. I'm not saying they're the only answer, but overlays can be used to see whether someone will make a sustained effort over a decent period of time, before they are recruited. > Rejecting isn't very nice, Agreed. > the amount of effort and barriers to become a dev are too great I can't agree with you there. I believe we can make it easier, and do so without changing the amount of effort or the deliberate barriers we have today. > so we end up with good ebuilds not being added. Good ebuilds aren't enough. > Adding the ebuilds to overlays is one option, but > then other users will be expected to find an overlay with their > package in, and then add it to make.conf. As the number of overlays > increases, the amount of effort in synchronising dependencies and > dealing with other problems between them will increase. Perhaps. Perhaps not. But that's only one aspect of overlays - it's not the whole shebang. There are developers and teams that use overlays to maintain packages that are in the tree, and then they push the packages from the overlay to the tree when the packages are ready for wider testing. > Maybe in the real world managing the relationships between overlays > won't be as big a problem as it appears it could be. Take layman out for a spin, and let the author know how well it helps with this. > Not much - time is a great constraint, and writing emails takes much > less time than writing code... I appreciate your honesty there :) Best regards, Stu -- gentoo-dev@gentoo.org mailing list
