Re: Skytools committed without hackers discussion/review
От | Magnus Hagander |
---|---|
Тема | Re: Skytools committed without hackers discussion/review |
Дата | |
Msg-id | 200710100822300000@1086422496 обсуждение исходный текст |
Ответ на | Skytools committed without hackers discussion/review (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
> > > > > We allow /contrib to be more lax about beta changes. > > > > > > > > the postgresql ecosystem is growing and there is a lot of people like > > > > packagers that will be a quite irritated if we keep randomly adding > > > > completely new code and modules during BETA. > > > > > > Should packagers be concerned with /contrib at all ? > > > > Our users want it. Because we have important features that live there. > > Sure, but some features are also moved from /contrib to pgfoundry, and > users still may want these too. Sure. This is why Dave created stackbuilder. The point is users expect us to ship whatever isincluded in core postgresql, which includes contrib. > And sure there are features in contrib that "most" users don't want. Sure. There are features in the backend that most users don't even know about, much less use/want. > > > > > As noted before /contrib is a technical way of ensuring that something > > > gets updated together with core, not a recommendation to include it in a > > > "package". > > > > Then why did it get added there with the motivation that a lot of users will want it? > > I think that the main motivation was to ensure that a feature that a lot > of users will want will be "stable", that is, maintained together with > core postgres. IMSHO, this is far from enough motivation to put something in post beta. I could accept it *with* proper discussion, duringfeature freze. Where the argument of not putting it in contrib, but backend-actual instead, could've been properlymade. > exposing stable xid and snapshot to userspace is something needed by > more than one postgres add-on (Slony1 replication, Skytools universal > queueing and replication) makes it much easier to develop these packages > without need to have an extra package to maintain separately from these, > yet in sync with core postgres. So, it should be in the backend, not contrib. And since we're past beta, that means 8.4. If discussion had happened just a day or two before the comit, we could've delayed beta a day to get it in.... /Magnus
В списке pgsql-hackers по дате отправления: