RE: [PEAR-DEV] granting temporary permission for releasing packages that need a new release

> From: Pierre-Alain Joye [mailto:paj@pearfr.org] > Sent: Thursday, August 07, 2003 11:05 AM > > On Thu, 7 Aug 2003 10:53:53 +0200 > "Lukas Smith" <smith@backendmedia.com> wrote: > > > I don't full agree here. > > PEAR wants to leave the responsibilities in terms of decision making > > etc with the lead developer. This is the model we offer and this is > > the model we should pursue in the future. > > > > However we also claim to provide high quality packages to our user > > base. If open bug reports linger, if fixes to known issues are > > committed to CVS but no new releases are made then we have a problem. > > > Yes and no. One point is what Wez said in his recent post here (see Date > thread). Another is about "roadmaps", package status and such things. And I totally agree with what Wez said. Let me clarify what type of situations I am talking about. I am not talking about weeks, I am talking about months. I am talking about situations where the maintainer simply does not react to emails over a long period of time anymore. > I agree with you when you (Davey&you) say QA should change a package > status if the release is broken and/or does not fit stable requirements. > All other cases are not concerned. Relabeling a stable package to unstable is no solution. If you demote a package from stable to devel for example. Then people will just get confused. > > Therefore there must be sort of an implicit contract, that the > > sovereignty in decision making requires that the developer also > > maintain his package properly. For now I would like to keep the > > definition of"properly" a soft one, which is decided upon on a case by > > case basis. > > Contract? This is the kind of work I do not like in OS. Pay and I'll > sign a contract ;-). However stable packages should fit a mimimum set of > requirements, that's obvious. There is an implicit contract. PEAR provides infrastructure. Developers provide code. This is not a strict contract and certainly nobody will get their wrists slapped. But if developers don't uphold their part (maintaining their code) then we (PEAR) might decided to not uphold their part (sovereignty over a developer's code). The question is just when the maintainer is not upholding their part. I think this decision should not be made lightly and should certainly only come after months of absence. It should be discussed properly etc. Regards, Lukas