From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FMPGo-00081s-H4 for garchives@archives.gentoo.org; Thu, 23 Mar 2006 12:50:31 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.5) with SMTP id k2NCo0G2001016; Thu, 23 Mar 2006 12:50:00 GMT Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by robin.gentoo.org (8.13.6/8.13.5) with ESMTP id k2NClDp3025170 for ; Thu, 23 Mar 2006 12:47:14 GMT Received: by wproxy.gmail.com with SMTP id 37so626627wra for ; Thu, 23 Mar 2006 04:47:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qihUZ3a+WTT2zgFhRJGDHHY5hsKlJdabwO8v4ABJ9Zyosp5vASjt+9PbQ/JlkAnFEO1lxV23H8pF+Xgc234SjkJvVu46Yfiin1q3WMsLWV6gCDZ3XTDFcyvJKHKdpMR2S+4iSwZaE5CzeQn5LvhuWAOBlxVd4yi1M0tcDXc6038= Received: by 10.54.89.17 with SMTP id m17mr325792wrb; Thu, 23 Mar 2006 04:47:13 -0800 (PST) Received: by 10.54.157.1 with HTTP; Thu, 23 Mar 2006 04:47:13 -0800 (PST) Message-ID: <623652d50603230447l4938aaeam@mail.gmail.com> Date: Thu, 23 Mar 2006 12:47:13 +0000 From: "Chris Bainbridge" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Official overlay support In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <441F35B9.8000406@gentoo.org> <4421836A.8040000@gentoo.org> <200603230910.00496.kugelfang@gentoo.org> <623652d50603230209i1f915562v@mail.gmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id k2NClDp3025170 X-Archives-Salt: 7d5040ed-c176-4924-9950-a3cc509e8b3e X-Archives-Hash: b026b6da8b20fa024dcdcf2166e4256c On 23/03/06, Stuart Herbert wrote: > Developers are already using overlays, and some teams (including ones > I've been involved in) are actively and successfully using them to > help with recruitment and to provide a way to access ebuilds that > would otherwise still be rotting in Bugzilla. Developers are using overlays, however, the majority of users aren't. 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. > > Surely the solution is to provide that safety net within the tree? > > I cannot imagine a day when non-devs are given commit access to the > Portage tree. As long as that limitation remains in place, if we're > going to reach out beyond our developer community, we have to reach > out beyond the Portage tree too. The safety net was intended for developers. 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. > > The current system of overlay usage is very annoying for users, > > particularly when bugs are hanging around with packages in the tree, > > and after filing bug reports the user is told that the bug is already > > fixed in the overlay. Or when new packages are added to overlays > > instead of the tree. How are users expected to find them? > > Users have pre-conceived ideas about the contents of the Portage tree. > I've seen first-hand how badly users react when a hard-masked package > in the tree is withdrawn because it was an experimental approach that > ultimately failed. Users have unrealistic expectations about the > tree. 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. Unfortunately the options at the moment are to either reject the ebuild, leave it to rot in bugzilla, or recruit the user as a developer. Rejecting isn't very nice, the amount of effort and barriers to become a dev are too great, so we end up with good ebuilds not being added. 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. Maybe in the real world managing the relationships between overlays won't be as big a problem as it appears it could be. > [snip] You have good ideas. What are you doing to make them happen? Not much - time is a great constraint, and writing emails takes much less time than writing code... -- gentoo-dev@gentoo.org mailing list