From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=DATE_IN_PAST_12_24,DMARC_NONE, INVALID_DATE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from mailgw1.netvision.net.il ([194.90.1.14]) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15ShcP-0007ed-00 for gentoo-dev@cvs.gentoo.org; Fri, 03 Aug 2001 10:16:10 -0600 Received: from localhost (ras9-p111.rlz.netvision.net.il [62.0.91.111]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with SMTP id TAA13828 for ; Fri, 3 Aug 2001 19:15:48 +0300 (IDT) Content-Type: text/plain; charset="iso-8859-1" From: Dan Armak To: gentoo-dev@cvs.gentoo.org Subject: Re: [gentoo-dev] Maintainership and commit policy X-Mailer: KMail [version 1.2] References: <20010801215315.A14504@prosalg.no> <3B6AA15B.3050603@acm.org> <878zh16v1d.fsf_-_@codefactory.se> In-Reply-To: <878zh16v1d.fsf_-_@codefactory.se> MIME-Version: 1.0 Message-Id: <01080319164001.00614@localhost> Content-Transfer-Encoding: 8bit Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Fri Aug 3 10:17:01 2001 X-Original-Date: Fri, 3 Aug 2001 19:16:40 +0300 X-Archives-Salt: ae18b5c6-06d2-4c8d-90f4-02899884073e X-Archives-Hash: 8d67c3dc4f788eab809ad347555dce6b AFAIK, we could manage the entire thing via cvs - no incoming dir, no commit-request emails. We would have several 'trees' in cvs: stable, unstable (=devel), external (any better names?), incoming (=user-submitted), trees for past releases which could get bugfixes, etc. A developer who wanted to change another developer's ebuild would have to commit a new revision of that ebuild to the 'external' tree. (That's what he'd have permissions to do.) The maintaining developer could then look over his changes (and the commit log message), and if he accepted them, merge the changes into his main devel tree. Once in there, the changes needed to be proven stable and good (like the maintainer's own work) and would then be merged into the stable tree. Non-developers who did 'emere rsync' could only get things from the stable tree. A similar procedure wuold be used for 'incoming' user ebuilds, with another cvs tree. What do you think? On Friday 03 August 2001 18:08, you wrote: > Hi! > > I renamed the thread since it's not about xchat 1.8.2 anymore. > > > I think if we choose to do this, then we had better rethink the > > incoming directory right now. While it may be okay for a few > > outstanding user-submitted ebuilds, this scheme has the potential to > > cause a lot problems. What we really need is an unstable cvs tree; > > then user-submitted ebuilds and non-team developer-hacked ebuilds can > > go there until they are verified by team members. > > If we have maintainer of ebuilds (which I think we shall have) I don't > think that other people should commit into the CVS tree without his > aproval (neither unstable nor stable). It will be very hard for a > maintainer of many packages to keep track of what's happening if > people just commit at will. > > > I think all we need is maintainer. This is the guy who "puts his rep > > on the line." cvs log keeps all the other information. The person > > you really want to complain to about a bad ebuild is the maintainer > > anyway. Then he can do a cvs log to see who the culprit is and get in > > touch. > > This will not be a problem if only the maintainer are allowed to > commit (or aprove commits). I think this is the best way to do it. > > If you want to make a commit to an ebuild that you are not maintainer > of: > > If you are a developer: > 1) Send the patch to the maintainer asking if you may commit. > 2) The maintainer might commit or aprove of you commiting or tell you > why it won't go in (and perhaps what you need to fix first). > > Otherwise: > 1) Send the patch to the maintainer which will either commit or tell > you to change the patch in some way. > > This will make it harder for people to commit to all kinds of ebuilds > but I think that this is the way we have to do it in the future. > > Of course a maintainer might give a certain person commit rights if he > trusts the other developer to do it right. > > Regards, > Mikael Hallendal -- Dan Armak Gentoo Linux Developer, Desktop Team Matan, Israel