From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25891 invoked by uid 1002); 7 Oct 2003 12:09:07 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 644 invoked from network); 7 Oct 2003 12:09:06 -0000 From: foser To: gentoo-dev@gentoo.org In-Reply-To: <200310071146.04769.pauldv@gentoo.org> References: <1065476836.4871.22.camel@Interimo.Intern.LAN> <1065478086.4139.38.camel@Interimo.Intern.LAN> <1065478098.2899.26.camel@rivendell> <200310071146.04769.pauldv@gentoo.org> Content-Type: text/plain Message-Id: <1065528430.21682.79.camel@rivendell> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 07 Oct 2003 14:07:11 +0200 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Three teir portage: stable, prestable, unstable? X-Archives-Salt: 5d74dbd6-1a67-4255-b905-2c6e422f0307 X-Archives-Hash: 231a798a0df206276d26ade8972b7ec5 On Tue, 2003-10-07 at 11:46, Paul de Vrieze wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 07 October 2003 00:08, foser wrote: > > On Tue, 2003-10-07 at 00:08, Ian Leitch wrote: > > > As I'm sure all devs know, ~arch is used for other things than just > > > testing ebuilds. > > > > > > "The purpose of ~arch is for testing new packages added to Portage. This > > > is not the equivalent of "testing" of "unstable" in other > > > distributions." - Development Policy > > > > Well then that is a violation of policy. Developers who do this should > > 'change their ways'. > > Or change the policy Yeah, change the policy whenever it fits and nobody follows it, you can drop policies altogether if you start reasoning like that. > > I think package.mask is indeed not the best solution for development > > versions of packages, but neither do i think we should have an official > > 'unstable branch'. We have trouble enough to keep 'stable' stable and > > up-to-date as it is, no need to add another official burden to it. > > > > I like the idea of adding this keyword. There are packages whose ebuilds are > stable, and are reasonably stable, but still release candidates etc. > Currently the status of such packages is unclear. Sometimes they are put into > stable, sometimes they stay masked, and sometimes they are marked testing > (which they should start out with, as then they are new). No their status is quite clear according to policy. That practice proves otherwise in some cases is in my opinion a developers mistake. > Take for example the openoffice-1.1_rc? series. Those from rc3 onwards have > been almost equal to the final release (what source is concerned, the build > procedure was fixed). Current policy required them to be masked as they are > unstable releases, while in fact being quite stable. We had various requests > to remove them from the package.mask file. That, however, would be a > violation of policy. An extra keyword could help in that respect. No, the policy states that in the end it is up to the maintainer to assess the stability of a package, in case of openoffice which is well maintained in portage -afaik- i can see a developer deciding to mark it stable, but this shouldn't become common use. In general packages are maintained on a more distant basis, where the developer is not too involved with the package and can't judge it properly, so leaving the decision to the upstream developers (who to judge better?). Here policy should be strictly followed. No need for an extra keyword, yet another USE flag, etc. : just don't add it. > > The only reason i see for adding an extra layer is for 'big' stuff that > > needs serious testing : KDE/GNOME development series maybe, arch > > additions to the tree (amd64 anyone), introduction of new eclasses, etc. > > Those should be entered to the tree in some special protected > > environment first, where they get proper testing (maybe by a selected > > few) and then when reaching stability can be added to the tree with > > relative ease (not one developer throwing in his local tree one night at > > once). > I think that is another discussion although I agree with it. I don't think so, i think that is exactly what this is about. My point is really that development releases shouldn't be in portage, but that we do need a way to test them to some extent to adapt to upcoming stable releases. As soon as we add them to portage they become a responsibility. Something we can't have, since the package just isn't officially stable. I see this in a bit broader perspective here than just development releases. Like people asking why the development releases of GNOME enter the tree so late in the development process. Well, it might be fairly stable and usable to the general home user, but there are still known bugs and things to work out. I just can't guarantee a safe,problem free upgrade for say a small company running GNOME desktops who rely on stability. You can see the same already with package.mask, which was meant as a way to mask packages not working/being worked on. Yet users install these packages at will as if they were normal packages (only slightly annoyed by the fact that it takes some extra effort). Yes we need the testing, but no, users shouldn't install those without knowing what they do (which in my opinion is what happens most of the time). Makes me think of the libiconv bugs we get every now and then, it shouldn't be used, but users install it anyway and are left with the pieces. I don't think most of the users ever read the p.mask comments why something is masked. - foser -- gentoo-dev@gentoo.org mailing list