Date: Tue, 11 Nov 2003 02:12:59 +0100 From: Clement Laforet <sheepkiller@cultdeadsheep.org> To: Sergey Matveychuk <sem@ciam.ru> Cc: eikemeier@fillmore-labs.com Subject: Re: Ability for maintainers to update own ports Message-ID: <20031111021259.03adac22.sheepkiller@cultdeadsheep.org> In-Reply-To: <3FB02AA6.6000803@ciam.ru> References: <1068458390.38101.19.camel@dirk.no.domain> <20031110152000.622db381.lehmann@ans-netz.de> <1068471598.38101.77.camel@dirk.no.domain> <20031110163623.GC93583@procyon.firepipe.net> <1068495958.690.72.camel@leguin> <53EC784E-13C5-11D8-AD24-003065ABFD92@mac.com> <3FB00E53.8060603@fillmore-labs.com> <3FB02AA6.6000803@ciam.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Nov 2003 03:17:42 +0300 Sergey Matveychuk <sem@ciam.ru> wrote: > > Yes. It's a good point to have two branches for ports. So many times I > > cvs'ed an old port version because found a new one unstable... Hey guys, it looks like debian packages management system :-) CVS branches, by-port-mentoring, etc. are pretty good ideas but are we able to deal with this ? Two branches implies two commits. If maintainer can commit on the "testing" branche, you have just push the dirt under the carpet, who will consider your port(s) stable enough ? Who will be responsible for massive changes (like gettext update) ? By-port-mentoring (I mean "when a committer add a ports, he's reponsible of it") is seducing, but committers have a real life too, so they can be AFK for a while, so PR will rot in GNATS too. Everyone who submits a port hopes his port will be committed quickly, to contribute with the project. It's quite hard to get a "minor port" committed if committers don't know you. Another approach of the problems: 1. insert more revelant informations in PR. We can add fields in PR bodies to simplify Mark Linimon works. i.e. PORTNAME: my-ports CATEGORY: what-I-want CLASS: [update|patch|fix] maintainer-update is no more efficiant nowadays and synopsises are overloaded with redundant informations to catch committers attention. 2. Encouraging committers to get involved in maintaining categories, like Joe Marcus Clarke for gnome related ports. I know it's not as easy at it seems: you can't ask a committer to deal with very specific port he don't know. If we "segment" (a little more) ports-bugs, new ports (and only new ports) can be routed to sublists which committers choose to subscribe or unsubscribe when they want, avoiding new ports to be lost in the mass. clem
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031111021259.03adac22.sheepkiller>