Date: Wed, 28 Jun 1995 08:35:44 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: FreeBSD-hackers@FreeBSD.Org (FreeBSD hackers) Subject: Re: cvs commit: src/usr.bin/killall - Imported sources Message-ID: <199506281535.IAA09465@gndrsh.aac.dev.com> In-Reply-To: <199506280855.BAA07819@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Jun 28, 95 01:55:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
[Okay, so I moved this to -hackers, probably should have cc:-ed -current :-) ] > * Your understandings are not complete. -current is for talking about > * anything that has to do with the -current sources. Changing them > * has something to do with them. > > Of course, but those changes are eventually going into the release so > it's not only those who are running -current that will be interested. Agreed, others may be interested, but the first users to see it will be the -current users. The people who run -current tend to be the more technically prepared to mount an argument one way or the other as to what should or should not go in the main distribution. > Otherwise, we'll have to discuss everything that has to do with > changing code in -current. :) Where else do you think we should discuss changing code? I see from below -hackers seems appropriate, but read my comments below about the .info files. > * Hackers is never for setting ``policy'', we don't have any official > * policy nor an official place to discuss it. > > Well, then maybe it's time to make it. In the past, I've seen lots of > "policy" discussions in -hackers, and judging from this: I think policy discussion has happened in every list, but yet we still don't have a FreeBSD.policy document :-(. Wait, actually we do have some written policy some place. Jordan (who is probably not going to see this) wrote up a thing about -current and supping and such that was done to sqelch a lot of the noise caused by users trying to run -current who should not have been trying to do so. > >> cat freebsd-hackers.info > This is the mailing list for people actively involved in working on FreeBSD. This needs revised. That is the original .info file from when that mailling lists was created, and at that time -current did not exists. There where only about 10 or 15 people on that list when it was created, now it is well into the serveral 100's and S/N is getting pretty bad. I don't have a new good definition, it has kinda become the dumping ground mailling list. > >> cat freebsd-current.info > This is the mailing list for users of freebsd-current. Needs revised to read ``This is the mailling list for communications between the developers and users of freebsd-current.'' I think that describes it role a little better. All committers should read this list, and all people running -current should read this list. > > it seems to me that -hackers is a better place than -current to > discuss additions of code. (Note the info for -current says "users".) All developers(committers) are also users by automatic decree, they must be running -current to be developeing -current. (Note my revised definition :-). > * -core is some times > * used for talking about and setting policy, but not for acting upon > * that policy. Realize -core is unarchived, and invisible to the > * outside world. Decissions to incorporate or not incorporate some > * piece of code need to have publically visible discussion, otherwise > * people won't like us because we make decissions behind here backs. > > That's why I said "a short note to -core AFTER discussing it in > -hackers or -current" in the first place.... ;< Core team members are required to read -current, so there is no need to send the short note. If they ignored it on -current, they will probably just ignore it in -core. -core is getting way way to much usage lately :-(. There is no freebsd-core.info :-(, we need to write one just for reference. [The core mailling list is not under majordomo control, and should not be anyway, but we do need to keep some form of policy some place on what this list is for.] > I'm afraid I'm not getting my point across at all. If we can't agree > on a rule, that's ok, as long as people be a little more careful about > adding stuff to the main source tree as a result of this > discussion.... I think that goal has been accomplished, even without a written policy for the time being. Problem is as the folks in -committers change over time this problem well resurface unless we have written policy to hand folks when they are given commit access. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506281535.IAA09465>