| 1 |
Hi Chris, |
| 2 |
|
| 3 |
On 3/23/06, Chris Bainbridge <chris.bainbridge@×××××.com> wrote: |
| 4 |
> I think that the |
| 5 |
> use of overlays is more a symptom of a problem with portage. Overlay |
| 6 |
> problems: |
| 7 |
|
| 8 |
[snip] |
| 9 |
|
| 10 |
Developers are already using overlays, and some teams (including ones |
| 11 |
I've been involved in) are actively and successfully using them to |
| 12 |
help with recruitment and to provide a way to access ebuilds that |
| 13 |
would otherwise still be rotting in Bugzilla. |
| 14 |
|
| 15 |
I'm not saying overlays are for everyone. It's one approach that some |
| 16 |
groups like. You don't have to use an overlay yourself for your work |
| 17 |
if it's an approach that doesn't work for you. Overlays are not about |
| 18 |
to become a mandatory way of working around here. |
| 19 |
|
| 20 |
> Surely the solution is to provide that safety net within the tree? |
| 21 |
|
| 22 |
I cannot imagine a day when non-devs are given commit access to the |
| 23 |
Portage tree. As long as that limitation remains in place, if we're |
| 24 |
going to reach out beyond our developer community, we have to reach |
| 25 |
out beyond the Portage tree too. |
| 26 |
|
| 27 |
> The current system of overlay usage is very annoying for users, |
| 28 |
> particularly when bugs are hanging around with packages in the tree, |
| 29 |
> and after filing bug reports the user is told that the bug is already |
| 30 |
> fixed in the overlay. Or when new packages are added to overlays |
| 31 |
> instead of the tree. How are users expected to find them? |
| 32 |
|
| 33 |
Users have pre-conceived ideas about the contents of the Portage tree. |
| 34 |
I've seen first-hand how badly users react when a hard-masked package |
| 35 |
in the tree is withdrawn because it was an experimental approach that |
| 36 |
ultimately failed. Users have unrealistic expectations about the |
| 37 |
tree. |
| 38 |
|
| 39 |
If developers are telling users in Bugzilla that bugs are fixed in the |
| 40 |
overlay, it's the responsibility of the developers to tell the users |
| 41 |
where to go to get those fixes. I'd have thought that was basic |
| 42 |
common sense. Establishing overlays.g.o as the usual place to go will |
| 43 |
help with this, as will promoting very helpful tools such as layman. |
| 44 |
|
| 45 |
> Another thing that needs fixing is the massive number of packages that |
| 46 |
> aren't really maintained. |
| 47 |
|
| 48 |
That's a very valid concern. Overlays can help here, as explained by |
| 49 |
the Haskell team, because they make it possible for more people to |
| 50 |
contribute. They're more than a technical solution ... they're a |
| 51 |
social tool to build a more sustainable team around. |
| 52 |
|
| 53 |
> What's |
| 54 |
> worse is that in a lot of these cases there will be a user on bugs.g.o |
| 55 |
> posting fixes and new ebuilds, and yet they never make it into the |
| 56 |
> tree. |
| 57 |
|
| 58 |
I'm finding that overlays address this specific scenario very |
| 59 |
successfully. I talk to those users and find out if they're willing |
| 60 |
to contribute to an overlay. More often than not, I find that the |
| 61 |
fixes and new ebuilds are coming from a personal overlay that the user |
| 62 |
is maintaining anyway. Being able to commit directly to a shared |
| 63 |
overlay means that they can get more involved ... and it gives me a |
| 64 |
good level of interaction to help decide whether the person is worth |
| 65 |
recruiting as a full-blown dev or not. |
| 66 |
|
| 67 |
> A system where developer ebuilds are kept in the tree, and users have |
| 68 |
> a way to automatically contribute ebuilds, either human reviewed, or |
| 69 |
> in some reputation based system, would be very useful. |
| 70 |
|
| 71 |
The overlays project doesn't prevent this system being developed or |
| 72 |
introduced at all. We're not looking to corner the market at all. |
| 73 |
We're only providing a resource which will be useful to some teams and |
| 74 |
developers. |
| 75 |
|
| 76 |
> Users also need feedback |
| 77 |
|
| 78 |
[snip] You have good ideas. What are you doing to make them happen? |
| 79 |
|
| 80 |
> I'm not sure whether the answer is more openness of the existing |
| 81 |
> system, some custom submission flow system, or a distributed SCM, but |
| 82 |
> I do think there's a lot that could be changed to make things better. |
| 83 |
|
| 84 |
I don't think that there is any one approach that will work for all |
| 85 |
devs, all non-devs, all the time. What I'm doing here is resourcing |
| 86 |
one specific approach, and working with Infra and User Relations to |
| 87 |
deliver something that provides one bridge between the developer and |
| 88 |
non-dev community. We will need other bridges to be built too. |
| 89 |
|
| 90 |
Best regards, |
| 91 |
Stu |
| 92 |
|
| 93 |
-- |
| 94 |
gentoo-dev@g.o mailing list |
Archives