| 1 |
Kevin Lacquement wrote: |
| 2 |
> |
| 3 |
> I'm not sure about stuff in -core becoming publicly accessible. After |
| 4 |
> all, isn't it in the private list for a reason? Perhaps summaries of |
| 5 |
> -core discussions being forwarded to -dev would be a better option. |
| 6 |
> However, I'm new to -dev, so if this is what already happens I don't know. |
| 7 |
|
| 8 |
|
| 9 |
It's been a topic debated off and on on whether or not to keep -core locked away |
| 10 |
forever, but face it, even the CIA declassifies its dirty laundry every so |
| 11 |
often. Now I'm not saying we should hold onto -core material for 30+ years, but |
| 12 |
I see no point in forever locking up the information on -core. At minimum, it |
| 13 |
provides a historical look into how developers used to think. Equally, this is |
| 14 |
why we need a sufficient time gap to let a majority of topics die off on -core |
| 15 |
before they become fodder for public consumption. And why a marker being |
| 16 |
available to permanently lock certain threads/messages as needed. |
| 17 |
|
| 18 |
|
| 19 |
|
| 20 |
|
| 21 |
> Here's where we want the non-devs to get access. After all, not all |
| 22 |
> development and debugging is done by devs. All the current devs were, |
| 23 |
> at one point, users. Where did they get their start? My bet is they |
| 24 |
> entered via the -dev mailing list, learned the ropes here, and |
| 25 |
> eventually earned their dev status. If the -dev list is closed, where |
| 26 |
> do the new dev-wannabes learn the ropes and get their voices heard? |
| 27 |
|
| 28 |
You missed the small mention of "open" in my first sentence. I probably should |
| 29 |
have clarified what my definition of what "open" is, but it pretty much means no |
| 30 |
moderation on the -dev list so that users and developers could post. |
| 31 |
|
| 32 |
|
| 33 |
|
| 34 |
|
| 35 |
> Would it perhaps be better to send announcements to -dev-announce, and |
| 36 |
> have that list forward to -dev? That way we avoid issues if a subject |
| 37 |
> starts with [ANNONUCEMENT], for example |
| 38 |
|
| 39 |
|
| 40 |
-dev-announce is a list proposed by another developer, and it's got its own bug |
| 41 |
number someplace (don't have it on hand ATM, however). And technically, you |
| 42 |
wouldn't be forwarding the -dev-announce messages to -dev, because -dev-announce |
| 43 |
is essentially acting as a filter to -dev. -dev would, in theory, contain ALL |
| 44 |
technical discussion related to the project. -dev-announce would contain all |
| 45 |
announcements of certain, specific, technical things occurring within the |
| 46 |
project (and already talked about on -dev). As a result, someone posting to |
| 47 |
-dev and wishing that post to also be forwarded to -dev-announce would attach |
| 48 |
[ANNOUNCEMENT]: to their subject line. Not all devs are gonna wanna get into |
| 49 |
discussions, even technical ones. Thus they can still monitor -dev-announce to |
| 50 |
keep abreast of things. |
| 51 |
|
| 52 |
This method is no different really from the art of prefixing [PATCH]: to the |
| 53 |
subject line of an email on a kernel development list (or development list for |
| 54 |
any other software project) to indicate that the contents of the email includes |
| 55 |
a patch. Even for LKML and linux-mips, there are tools in git that can target |
| 56 |
emails marked at patches, and automatically perform various feats of magic on |
| 57 |
them (such as stuffing the patches into a git queue of sorts). |
| 58 |
|
| 59 |
This is why I don't think we could expect many problems from an announcement |
| 60 |
message. Presumably, an announcement message would not be put out unless it'd |
| 61 |
already been discussed. History, however, shows us that this is not always the |
| 62 |
case. Thus, if some kind of a discussion were to arise from some kind of |
| 63 |
announcement, it likely wouldn't get forwarded to -dev-announce anyways (since |
| 64 |
replying to a mail would read as "Re: [ANNOUNCEMENT]", and it wouldn't get |
| 65 |
picked up by the automated mailer). Furthermore, the -dev-announce list can |
| 66 |
probbaly be locked to only accept inbound mail from a specific host or address, |
| 67 |
itself tied to a script or bot of some kind. If someone accidentally sent a |
| 68 |
message to -dev-announce, they would get a bounce back of some kind. |
| 69 |
|
| 70 |
|
| 71 |
|
| 72 |
|
| 73 |
> If these messages will be machine-like, why not have them |
| 74 |
> machine-generated? When you become a dev, someone (you? the person |
| 75 |
> that -dev-ifie's you?) fills out a form, and the information from the |
| 76 |
> form is forwarded to the list. |
| 77 |
|
| 78 |
We could automate it possibly, pulling data from the LDAP system used to auth |
| 79 |
devs to a number of gentoo systems. Or someone in devrel could just take a few |
| 80 |
seconds to fill out a few fields in an email template and hit send. I said |
| 81 |
impersonal because my mind is thinking technical == dry, white-paper-like |
| 82 |
material. Either method works. but it's just a suggestion. The more personal, |
| 83 |
emotion-filled (and I don't mean negative emotion-filled either) ones could go |
| 84 |
elsewhere, like to -project or such. |
| 85 |
|
| 86 |
|
| 87 |
Cheers, |
| 88 |
|
| 89 |
|
| 90 |
--Kumba |
| 91 |
|
| 92 |
-- |
| 93 |
Gentoo/MIPS Team Lead |
| 94 |
|
| 95 |
"Such is oft the course of deeds that move the wheels of the world: small hands |
| 96 |
do them because they must, while the eyes of the great are elsewhere." --Elrond |
| 97 |
-- |
| 98 |
gentoo-dev@g.o mailing list |
Archives