| 1 |
On Fri, 2006-04-07 at 14:43 +0100, Ciaran McCreesh wrote: |
| 2 |
> On Fri, 07 Apr 2006 15:19:35 +0100 Christel Dahlskjaer |
| 3 |
> <christel@g.o> wrote: |
| 4 |
> | So, from a developer pov Ciaran; if we could come up with some way of |
| 5 |
> | keeping up to date with what you guys do (without eating up any of |
| 6 |
> | your time or getting in your way) and then keep the masses informed, |
| 7 |
> | would that be more attractive? Obviously making sure that information |
| 8 |
> | is kept to a not exactly bare minimum, but presented in such a way |
| 9 |
> | that it doesn't in any way halt progress or potential change of |
| 10 |
> | direction? |
| 11 |
> |
| 12 |
> If it's information on things that are fine being public but aren't |
| 13 |
> simply because of lack of time to write them up, then that would be |
| 14 |
> great. If it's things that're being kept quiet purposefully, however, |
| 15 |
> then the last thing we want is to start telling people things. |
| 16 |
|
| 17 |
Yes, I agree with that entirely. If things are being kept quiet for a |
| 18 |
reason we will have no wish to attempt to push for these to be made |
| 19 |
public before the decision to do so is reached by the development teams |
| 20 |
in question. |
| 21 |
|
| 22 |
> |
| 23 |
> | > Hence why some of us don't announce non-trivial projects on public |
| 24 |
> | > mailing lists, and instead keep any discussion on -core and sekrit |
| 25 |
> | > IRC channels. That's how what's now known as eselect was developed, |
| 26 |
> | > and it turned out far nicer than the XML-laden aborted gentoo-config |
| 27 |
> | > project precisely because of the lack of end user 'input'. |
| 28 |
> | |
| 29 |
> | In more of a informative 'these are the exciting things we're doing' |
| 30 |
> | sort of way rather than a 'tell us why you disagree' sort of way |
| 31 |
> | maybe. |
| 32 |
> |
| 33 |
> See, that doesn't work. There's this strange notion that because we're |
| 34 |
> open source, users somehow have a right to a) see the code, b) make |
| 35 |
> suggestions, c) demand new features, d) get support and e) annoy other |
| 36 |
> developers or upstream when they break something that has a knock-on |
| 37 |
> effect of breaking an unrelated package. |
| 38 |
|
| 39 |
I was rather unclear, I think your previous passage had me rather spot |
| 40 |
on for what I was wanting to do. |
| 41 |
|
| 42 |
|
| 43 |
-- |
| 44 |
gentoo-dev@g.o mailing list |
Archives