Re: [gentoo-dev] first council meeting
Mike Frysinger wrote: On Monday 26 September 2005 12:01 am, Andrew Muraco wrote: 1) would ?arch become the old ~arch, if it was implemented? 2) would people actually try to run a full ?arch system? 3) #2, would it be possible without breakage? if we went with a testing mask it'd mean that users would be forced to select individual testing packages ... they wouldnt be able to globally accept all testing packages Not completely true (assuming testing.mask would work like package.mask), but I'd rather not say how it's possible. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Monday 26 September 2005 12:01 am, Andrew Muraco wrote: > 1) would ?arch become the old ~arch, if it was implemented? > 2) would people actually try to run a full ?arch system? > 3) #2, would it be possible without breakage? if we went with a testing mask it'd mean that users would be forced to select individual testing packages ... they wouldnt be able to globally accept all testing packages this is another advantage of going with a testing.mask instead of a ?arch system -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
In response to all replies Thus far, I as a User, I expect that arch works (no matter what) - no arguments there I assume that ~arch will work 95% of the time. I never ever touch anything in p.mask. Now, where do we put packages that could work for most users, but they might not work for the other 49% of users? p.mask seems to prevent that 49% of users from trying it, and reporting those bugs, but on the other hand ~arch means that 49% of users using ~arch will have problem x,y, or z. Now understand, this is the viewpoint of myself, and I have used a full ~arch system for a while, and i didn't ever run into anything more then the occasional package with a new config, or config update that i didnt do properly. (lazy-ness) things to consider 1) would ?arch become the old ~arch, if it was implemented? 2) would people actually try to run a full ?arch system? 3) #2, would it be possible without breakage? I personally like the idea of the UNSTABLE="" because to me, it changes nothing, but allows the AT and PM to communicate, on a per-ebuild basis. (comments welcome) just some thoughts, Andrew -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 23:51, Mike Frysinger wrote: > that's the problem, there's no way to flag which packages should be > consulted and which ones are a non-issue This indeed kind of sums up my point. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpUE5zyvN9HR.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
050918 Alec Warner wrote: > Personally I like Ciaran's wording of the levels. > ~arch - Canidate for Stable on Arch > arch - Stable on Arch As a mere user, that's how I read '~arch', ie 'not known to be defective, but use at your own risk for now', while 'arch' means 'the relevant dev(s) are satisfied this is bug-free: you can feel safe using it in your production system'. -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sun, 18 Sep 2005 15:01:13 +0200 Wernfried Haas <[EMAIL PROTECTED]> wrote: | On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote: | > Uhm. That's current policy and has been current policy for several | > years. No GLEP needed. | | If that's currenty policy, why does the handbook say something quite | different then? Does it need to be fixed? The deal with the handbook wording is... Originally, it was phrased very much in favour of ~arch, and suggesting that arch was the equivalent of Debian Stable. Many users who didn't know what they were doing would use ~arch and then complain when they encountered the occasional breakage. Certain developers complained, and the wording was changed. Here's the important part. What we tell the end user is not the same as what we tell the developer. Users should not use ~arch unless they're prepared to accept breakages. Developers should not put things into ~arch if they think there's a significant chance of it breaking things. That way, breakages will still sometimes occur in ~arch, and when they do users don't get to complain too much. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpggsVSawGW5.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wernfried Haas wrote: > On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote: > >>Uhm. That's current policy and has been current policy for several >>years. No GLEP needed. > > > If that's currenty policy, why does the handbook say something quite > different then? Does it need to be fixed? > > If so, i truly don't understand what ~arch should be about in the > first place - what use is a ~arch system for testing if everything in > there just works and stuff to be tested is p.masked? > > cheers, > Wernfried > The point being that ~arch is generally for EBUILD testing, not package testing. This is bad because some PACKAGES need lots of testing but don't get it because they are in p.mask ( because the PACKAGE is not stable ). Some people have begun putting unstable PACKAGES in ~arch, instead of in p.mask because p.mask does not get enough testing done, so things rot in p.mask forever. For larger packages ( apache, mysql, gnome ) this system works fine because upstream does a lot of testing. Since users shy away from p.mask ( things in there can have security issues for example ) a new PACKAGE testing area was proposed. Packages in this area would need PACKAGE testing. Users would know that packages with security issues would not be in this new testing area. Personally I like Ciaran's wording of the levels. ~arch - Canidate for Stable on Arch arch - Stable on Arch You wouldn't suggest a program you hadn't tested as a Canidate for Stable. That would be utterly retarded. You've tested it thoroughly(sp?) and it seems to work well for you. You have had other developers in your herd test it and they also encounter no problems. Thus it enters ~arch because you cannot find anything wrong with the package and you think it's stable. If the users find a huge bug you can regress the ~arch back to the testing layer ( be it p.mask or something new ) and fix the bug. If no one files a bug for 30 days have an AT test it and then mark it stable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQy10O2zglR5RwbyYAQLBcQ/9FPBNN6N2GmGvBpT1T2fnSnPTPiyFais5 4nSedhgi2uwROlCIOCdZevVEGLQbomwuOklWjjHhZK5TRYAmiqnqlSEscn881L10 KqRxTj7ctpBC7WExxvjpCOto4WYos+7jIe9n3mCXCeptv4R4/WBGTIXeHFqij8Mq ii7tL2fxKR1iCzPJ2Hf596Ip6FeMcL5HPpiZ9TEBrx4Bl47OH42USMKVHUODDV4G dDlGQKPuItubFsv8D4GwEIEFxWCxbIDj5gvTk3Y3g9gVc07sbFNzcO3RJKaN8zff msDGONSWXZ4dNuYbPwrIs8IC9VWEctVmHxy3iB/HzIlnAoRIq5+an3QDuy93JlCN TFmyWhf6MGkR4fovjo+zZ4FC4vGy8jYRuptRZpx2VLSX8fH4ishkZ/dJLOyZsRKC 5irvdz7l9y8q5Ge4ZEd/EkdOaYOAK7ZqxsbydKEImoYwY6yLRwnj+LbG3BO9ukUF 5jxyec+X1wWANaxwiWKZ2+WzXpt/QZUQo+r7tLNKUMOs9MZXIX5yTaaEqSNvCGhf QHTlRjKOX9Z1YxD2u/mhv9UNYmX/gb9LUz/q9rzVUjHXm7CFB4aQiyGhL+HgEqrW 0h/OCHyShYOzG418Dc1lrJff5vVz5O0u5caIhEzn5Z6iHr0EInaqzr0DCtoFUCKa uzurfVUN5lQ= =GI+1 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sun, Sep 18, 2005 at 01:32:32PM +0100, Ciaran McCreesh wrote: > Uhm. That's current policy and has been current policy for several > years. No GLEP needed. If that's currenty policy, why does the handbook say something quite different then? Does it need to be fixed? If so, i truly don't understand what ~arch should be about in the first place - what use is a ~arch system for testing if everything in there just works and stuff to be tested is p.masked? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Wernfried Haas <[EMAIL PROTECTED]> wrote: > Coming from the user side (forums) i fully agree. Common sense among > the users always used to be: > arch: stable > ~arch: testing > p.mask: broken And this is what it should be IMHO. The solutions so far seem to introduce only a new testing layer, already represented by ~arch and advertised as such: > http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml > --snip-- > The Testing Branch > [...] > Beware though, you might notice stability issues, imperfect package > handling (for instance wrong/missing dependencies), too frequent > updates (resulting in lots of building) or broken packages. If you do > not know how Gentoo works and how to solve problems, we recommend that > you stick with the stable and tested branch. > --snip-- > Doesn't exactly sound like packages in ~arch should be ready to enter > arch after 30 days (and or the other QA requirements). The rules for a package to go to arch were introduced to me as * >30 days ~arch * no open bugs * tested by AT|Dev and deemed stable And IMHO this is both flexible and quick enough. If anybody has a problem with the ebuild going stable, file a bug or bug a dev and explain that you think the ebuild needs more testing. That's about it. > I'd rather like to finally see proper QA applied and those who don't > beaten with a stick than making fundamental changes to existing common > sense just because it is written down somewhere _that_ way. Well, i think everybody's wants "proper QA". The problem was just "how to". And of course i agree with you on that stick part ;-) Regards, Matti -- pgpaw5VWunuop.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Sun, 18 Sep 2005 08:46:37 +0200 Wernfried Haas <[EMAIL PROTECTED]> wrote: | Doesn't exactly sound like packages in ~arch should be ready to enter | arch after 30 days (and or the other QA requirements). If someone | wants to change that, that would be a major change to Gentoo, | especially as it affects _every_ user. So it would at least require a | GLEP to do that. Uhm. That's current policy and has been current policy for several years. No GLEP needed. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpLa1EEMeJUC.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
Oh, and for the sake of completeness, also from http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml --snip-- 1.c. Using Masked Packages The package.unmask file The Gentoo developers do not support the use of these files. Please exercise due caution when doing so. Support requests related to package.unmask and/or package.mask will not be answered. You have been warned. When a package has been masked by the Gentoo developers and you still want to use it despite the reason mentioned in the package.mask file (situated in /usr/portage/profiles by default), add the exact same line in /etc/portage/package.unmask. --snip-- -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sat, Sep 17, 2005 at 04:17:10PM -0400, Mike Frysinger wrote: > i really want to get away from the idea of 'package.mask is for testing > packages' ... its current dual role as both masking 'testing' packages and > 'broken' packages is wrong imo > > we dont want to try reeducating our users to not be afraid of package.mask > because a lot of things in there they *should* be afraid of Coming from the user side (forums) i fully agree. Common sense among the users always used to be: arch: stable ~arch: testing p.mask: broken This is also covered in our current documentation, see http://www.gentoo.org/doc/en/handbook/hb-portage-branches.xml --snip-- The Testing Branch If you want to use more recent software, you can consider using the testing branch instead. To have Portage use the testing branch, add a ~ in front of your architecture. The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it. Beware though, you might notice stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. If you do not know how Gentoo works and how to solve problems, we recommend that you stick with the stable and tested branch. --snip-- Doesn't exactly sound like packages in ~arch should be ready to enter arch after 30 days (and or the other QA requirements). If someone wants to change that, that would be a major change to Gentoo, especially as it affects _every_ user. So it would at least require a GLEP to do that. I'd rather like to finally see proper QA applied and those who don't beaten with a stick than making fundamental changes to existing common sense just because it is written down somewhere _that_ way. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Saturday 17 September 2005 05:59 pm, Alec Warner wrote: > Mike Frysinger wrote: > > On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote: > >>How about if the maintainer wants wider testing, i.e. wants to move > >>it out of package.mask and into ~arch but isn't confident it's ready > >>yet for arch, adding a string variable to ebuilds indicating why the > >>maintainer considers the package unstable, eg: > > > > i really want to get away from the idea of 'package.mask is for testing > > packages' ... its current dual role as both masking 'testing' packages > > and 'broken' packages is wrong imo > > > > we dont want to try reeducating our users to not be afraid of > > package.mask because a lot of things in there they *should* be afraid of > > -mike > > Why not merely add an overlay to the main tree and put the testing > packages in the overlay. Then instruct users to add the overlay to > their portage settings. Testing overlay for testing, p.mask for broken > packages. that does sound like a pretty quick and clean solution ... the only problem i would have with it is that when we move from testing to normal portage tree, we lose cvs history ... and we'd have to merge ChangeLogs ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: > On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote: > >>How about if the maintainer wants wider testing, i.e. wants to move >>it out of package.mask and into ~arch but isn't confident it's ready >>yet for arch, adding a string variable to ebuilds indicating why the >>maintainer considers the package unstable, eg: > > > i really want to get away from the idea of 'package.mask is for testing > packages' ... its current dual role as both masking 'testing' packages and > 'broken' packages is wrong imo > > we dont want to try reeducating our users to not be afraid of package.mask > because a lot of things in there they *should* be afraid of > -mike Why not merely add an overlay to the main tree and put the testing packages in the overlay. Then instruct users to add the overlay to their portage settings. Testing overlay for testing, p.mask for broken packages. /usr/portage/overlay/cat/pkg/bla.ebuild or /usr/portage/testing/cat/pkg/bla.ebuild and so on... - -Alec Warner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQyyRwmzglR5RwbyYAQJzOg/9GtwWPrshqv+24mXpWzjyXJddH/dT2sHF WLf/BJOLJtsjsPuD/3V/R5RoiMhNAfXbmxsFDmp/Ny2LEJNue534+vMsiPFKRn3q zLN38ldGkDbRbx3mXkpWlc4SauRasl06Wv2IgoLc0fO37Evv1IzJVG0vMA8o2js7 ZMvGegiW+kfQ8cbQA3LShR92hBK5gZS1pvGUbr6tWv23ebfh7zzwhCVcRGF3Akb6 Kl71I/sDlqPJnTLRwEZZdoSp00JAbGDDEF425O1QRDWZfLT8gZbcBQJ/ouiP2wh2 yy07uMokUHz8dhvcJ44WhQx7QBG0Yjo5OxNnZRasROse9bmEpFp9uNvGgS0nnRgn PuWTnS2KBWCvfyd8eYY2PJB8rw3qmkgduBVO39XmUhCwD3kwR8wMcS1G2RXNnobc BU4RCJQmUmzWDN9w/kDY4BL7NZekiZfjb2CjYDM2Acu8BaHKGvWjlygypsyiwzYy B2pipj9S6Ad+itRFfvXZ+w1kbyp1yJmvXNIwYZC0ylyuYqpboQwKuEFKV/oUpbkX Z/CK6du7Ke8cD8IYXgkH45MRTl5kvWkd5jhzDGeX+sGnuuXzHAAdQl7+tQbM2Oey 2B0W1ddKNsbnZOhXRGh8sX6+A1j1ao6D33I+M5kj3EyURqCsRhrcqPdxBYKpJyGl y8wDdEb8Lpc= =syMf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Saturday 17 September 2005 05:28 am, Kevin F. Quinn wrote: > How about if the maintainer wants wider testing, i.e. wants to move > it out of package.mask and into ~arch but isn't confident it's ready > yet for arch, adding a string variable to ebuilds indicating why the > maintainer considers the package unstable, eg: i really want to get away from the idea of 'package.mask is for testing packages' ... its current dual role as both masking 'testing' packages and 'broken' packages is wrong imo we dont want to try reeducating our users to not be afraid of package.mask because a lot of things in there they *should* be afraid of -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On 17/9/2005 11:34:56, Brian Harring ([EMAIL PROTECTED]) wrote: > On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote: > > The 30-day could be calculated from the $Header: of ebuilds that have > > no UNSTABLE, or where it's empty. > > Doesn't work for N arches keywording, or ebuild dev doing minor > syntax touch ups. Good point. The minor touch-up issue could be resolved by setting the string to the date the last issue was cleared instead of deleting it: UNSTABLE="2005/10/04" but to handle N arches needs a different approach (the 'maint' keyword idea also falls down here). My favourite idea so far is mike's '?arch' on the understanding that we have: package.mask - 'alpha' Not suitable for mainstream testing ?arch - 'beta' Works on maintainers systems, worth testing Maintainer may not have tried it on arch. ~arch - 'release candidate' Maintainer & arch team happy that it's a good candidate for arch 30-day maturity phase, arch testing in progress arch - 'released' Arch team happy it's stable In particular it's worth noting that marking ?arch is not restricted the way marking ~arch is. Over time I expect the x86 arch team to impose more rigour on the use of ~x86, so that it behaves similarly to the other arches. In general, it would make sense for people to have arch or ~arch in make.conf, and use package.keywords to grab stuff from ?arch in a controlled fashion. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote: > The 30-day could be calculated from the $Header: of ebuilds that have > no UNSTABLE, or where it's empty. Doesn't work for N arches keywording, or ebuild dev doing minor syntax touch ups. ~harring pgp9GsjkqH1mC.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
How about if the maintainer wants wider testing, i.e. wants to move it out of package.mask and into ~arch but isn't confident it's ready yet for arch, adding a string variable to ebuilds indicating why the maintainer considers the package unstable, eg: UNSTABLE="#100435, #100345, unconfirmed break with foo" The maintainer would simply alter this line as bugs get confirmed or resolved. If a package wants to stay ~arch for longer than normal, even though there are as yet no reports of problems, the maintainer can just keep it set to something: UNSTABLE="gaining maturity" The arch team could consider an ebuild without an UNSTABLE line as a candidate for stable, and it provides an easy way for maintainers to communicate what issues are known with a package to the arch team (and anyone else who is interested). The 30-day could be calculated from the $Header: of ebuilds that have no UNSTABLE, or where it's empty. Kev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, Sep 16, 2005 at 04:16:22PM -0400, Aron Griffis wrote: > Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT] > > not really ... sometimes you want to keep a package in unstable > > forever (like the cvs snapshots i make of e17), or until you work > > some quirks/features out for a new revbump which you would want > > stable > > Why wouldn't you put these in package.mask? Why would you ? ;) If package foo isn't known to be broken, or known to break other packages, and generally just works(tm), why make it just that little bit harder for other people to test it ? Forgetting that it's just one extra step to take before emerging (adding an atom for package to /etc/portage/p.unmask), in addition to adding an atom for it to /etc/portage/p.keywords also, there's also the fact that package.mask is a dumping ground for packages that fit one (or more) of the following: * is vulnerable to exploitation and the like, or; * is broken on some level (crashes, munched goldfish, ..); or * requires extensive testing with the rest of the system i.e., could _completely_ break ones install. In other words, it's unstable, and many users (including myself) stay away from packages therein. So, the question is: when did ~arch and packake.mask become synonymous ? Best, Elfyn -- Elfyn McBratney beu/irc.freenode.nethttp://dev.gentoo.org/~beu/ +O.o- http://dev.gentoo.org/~beu/pubkey.asc PGP Key ID: 0x69DF17AD PGP Key Fingerprint: DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD pgpvyf6gdlxQn.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Saturday 17 September 2005 01:00, Ciaran McCreesh wrote: > Policy is rather specific about it. It's not a matter of interpretation > at all. That I disagree should prove that this is not a case. It's one thing to consider an application to "just work" for the user and another having e.g. the history of bug fix releases for previous versions in mind or knowing about minor but annoying bugs, which should be fixed before some version of it goes stable. Carsten pgpV8TNkyg3Vn.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 06:45 pm, Carsten Lohrke wrote: > On Friday 16 September 2005 23:50, Mike Frysinger wrote: > > actually, going with say 'testing.mask' instead of '?arch' may be better > > ... reinforce the fact that this is a package-level issue rather than > > arch-specific > > -mike > > That's nearly as bad as having to deal with package.mask all the time. > Keeping the maintainer's opinion on an ebuild outside of it doesn't make > any sense. maybe, but considering we're talking about testing on a package level and not an arch level, either solution has its failings i dont really care either way so long as we have a new level of control -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sat, 17 Sep 2005 00:43:02 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | > Good time for package maintainers to start following policy | > properly, eh? | | I'm sorry, not your idea of this policy. Policy is rather specific about it. It's not a matter of interpretation at all. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpWzMjPyBw6j.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 23:57, Martin Schlemmer wrote: > We still have KEYWORDS="-*". I'd appreciate, if we disallow that and all use package.mask. Carsten pgpanBD00AO4P.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 23:26, Ciaran McCreesh wrote: > No. You *can* ask the package maintainer, if you feel that such a move > would be useful and productive. No. There're lot of issues an arch maintainer not necessarily knows about. Without a way to indicate which ebuild is good, the whole "position" of a package maintainer is void. Carsten pgp1d23pqkLkk.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 23:50, Mike Frysinger wrote: > actually, going with say 'testing.mask' instead of '?arch' may be better > ... reinforce the fact that this is a package-level issue rather than > arch-specific > -mike That's nearly as bad as having to deal with package.mask all the time. Keeping the maintainer's opinion on an ebuild outside of it doesn't make any sense. Carsten pgpSbVWzSfada.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 23:34, Ciaran McCreesh wrote: > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 As I said - your interpretation doesn't match mine - or the policy is not good enough. > Good time for package maintainers to start following policy properly, > eh? I'm sorry, not your idea of this policy. Carsten pgpqzvyZIqfGJ.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, Sep 16, 2005 at 05:50:39PM -0400, Mike Frysinger wrote: > actually, going with say 'testing.mask' instead of '?arch' may be better ... > reinforce the fact that this is a package-level issue rather than > arch-specific Let me get things straight. We would want this because it's the least of two evils? On one hand ?arch isn't nice because it's package-level instead of arch-specific, so it doesn't belong among keywords. On the other hand testing.mask (if it's like package.mask) takes this (package-level) stuff and moves it out of the ebuilds it belongs to and dumps it all in one file. So we'd want this because we don't want to introduce something new in the ebuilds? Just getting things straight before expressing my opinion explicitly =] Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpdCM9aKrnq7.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 05:57 pm, Martin Schlemmer wrote: > On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote: > > On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote: > > > On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <[EMAIL PROTECTED]> > > > > > > wrote: > > > | ok, e17 packages dont count here. however, your hardcore view i > > > | still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x > > > | stabilization process ? are you telling me that arch teams should > > > | have had the power to move those into stable without talking to the > > > | maintainer ? baselayout may be a core package, but if you continue > > > | with your hard rule here, then it doesnt matter. > > > > > > I'm saying that arch teams should be allowed to mark it stable if they > > > think it's appropriate. Not that it must be moved to stable after $x > > > days, but that it can be at the arch team's discretion. And any arch > > > team which is silly enough to mark a broken baselayout stable has far > > > bigger problems anyway... > > > > baselayout is an example, any package can be used here (although not many > > are as critical) > > > > i'm saying that the maintainer may have a certain idea of when the > > package is ready for stable (a target feature set, working out certain > > quirks, etc...). your current hard view does not allow for that. for > > example, i had an arch maintainer one time mark bash-3 stable before > > base-system was ready for it (readline, baselayout, etc... were going to > > be stabilized together). i smacked them hard for it, but if we went with > > this hard view, it would have been perfectly acceptable behavior. > > We still have KEYWORDS="-*". Sure, I know many do not like it, and if > something was decided in regards to it, I missed it, but it is generally > seen as 'less severe' than a package.mask'd mask, and its local to the > package, so should not get stale. that would address the 'arch teams marking ahead of maintainer' issue, but in general, i think we need a testing mask of some sort separate from package.mask where we can put things like modular X, new KDE betas, new GNOME betas, e17 packages, etc... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Sep 16, 2005, at 4:50 PM, Mike Frysinger wrote: actually, going with say 'testing.mask' instead of '?arch' may be better ... reinforce the fact that this is a package-level issue rather than arch-specific I like that concept. A lot less communication overhead, and addresses most of the current problems AFAICT. --Kito -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote: > On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote: > > On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <[EMAIL PROTECTED]> > > > > wrote: > > | ok, e17 packages dont count here. however, your hardcore view i > > | still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x > > | stabilization process ? are you telling me that arch teams should > > | have had the power to move those into stable without talking to the > > | maintainer ? baselayout may be a core package, but if you continue > > | with your hard rule here, then it doesnt matter. > > > > I'm saying that arch teams should be allowed to mark it stable if they > > think it's appropriate. Not that it must be moved to stable after $x > > days, but that it can be at the arch team's discretion. And any arch > > team which is silly enough to mark a broken baselayout stable has far > > bigger problems anyway... > > baselayout is an example, any package can be used here (although not many are > as critical) > > i'm saying that the maintainer may have a certain idea of when the package is > ready for stable (a target feature set, working out certain quirks, etc...). > your current hard view does not allow for that. for example, i had an arch > maintainer one time mark bash-3 stable before base-system was ready for it > (readline, baselayout, etc... were going to be stabilized together). i > smacked them hard for it, but if we went with this hard view, it would have > been perfectly acceptable behavior. We still have KEYWORDS="-*". Sure, I know many do not like it, and if something was decided in regards to it, I missed it, but it is generally seen as 'less severe' than a package.mask'd mask, and its local to the package, so should not get stale. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 05:26 pm, Ciaran McCreesh wrote: > On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling <[EMAIL PROTECTED]> > > wrote: > | Ciaran McCreesh wrote: > | > There is nothing in this view that says "consulting the package > | > maintainer is not part of the stable decision-making process for > | > arch teams". > | > | So do I have to ask the maintainer first everytime I want mark a > | package stable? Is that what you are currently doing? > > No. You *can* ask the package maintainer, if you feel that such a move > would be useful and productive. that's the problem, there's no way to flag which packages should be consulted and which ones are a non-issue -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 04:43 pm, Mike Frysinger wrote: > On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote: > > His point (and it's an unfortunately valid one) as I understand it is > > that our user base has been (mis)educated to avoid packages in p.mask > > for fear of breaking things too badly. As such it gets an inherently far > > smaller test base then packages in ~arch do. > > arch stable > ~arch unstable > ?arch should work fine, but not 100% sure yet > package.mask known to be broken in some way actually, going with say 'testing.mask' instead of '?arch' may be better ... reinforce the fact that this is a package-level issue rather than arch-specific -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 23:41:21 +0200 Patrick Lauer <[EMAIL PROTECTED]> wrote: | > Good time for package maintainers to start following policy | > properly, eh? | Good time for policy to be adapted to match reality ;-) Reality is that most people do exactly what policy says. Most bumps don't warrant a package.mask entry anyway -- most upstreams for non-trivial apps know about change control. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpSQvLgb0bFc.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 22:34 +0100, Ciaran McCreesh wrote: > > There is a difference between using package.mask and ~arch for > > ebuilds. The use of ~arch denotes an ebuild requires testing. The use > > of package.mask denotes that the application or library itself is > > deemed unstable. > | Second: a) and b) doesn't match what's going on with large parts of > | the tree > > Good time for package maintainers to start following policy properly, > eh? Good time for policy to be adapted to match reality ;-) -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 23:23:35 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | On Friday 16 September 2005 22:38, Ciaran McCreesh wrote: | > That's not my idea. That's policy. I just happen to a) have actually | > read what policy says and b) agree with it. | | First: I know you're proposing this regularly, but please show me the | policy - I'm sure your interpretation doesn't match mine. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1 > There is a difference between using package.mask and ~arch for > ebuilds. The use of ~arch denotes an ebuild requires testing. The use > of package.mask denotes that the application or library itself is > deemed unstable. | Second: a) and b) doesn't match what's going on with large parts of | the tree Good time for package maintainers to start following policy properly, eh? -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpWkh8wb13nI.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 23:20:58 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > There is nothing in this view that says "consulting the package | > maintainer is not part of the stable decision-making process for | > arch teams". | | So do I have to ask the maintainer first everytime I want mark a | package stable? Is that what you are currently doing? No. You *can* ask the package maintainer, if you feel that such a move would be useful and productive. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpO5yI6AE5KF.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 22:38, Ciaran McCreesh wrote: > That's not my idea. That's policy. I just happen to a) have actually > read what policy says and b) agree with it. First: I know you're proposing this regularly, but please show me the policy - I'm sure your interpretation doesn't match mine. Second: a) and b) doesn't match what's going on with large parts of the tree and I refuse to constantly add and remove ebuilds from the package.mask file, that are not really broken. It's only extra work for me and confusing for users. Carsten pgpzWVdprzyGa.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
Ciaran McCreesh wrote: There is nothing in this view that says "consulting the package maintainer is not part of the stable decision-making process for arch teams". So do I have to ask the maintainer first everytime I want mark a package stable? Is that what you are currently doing? -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 16:59:56 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | baselayout is an example, any package can be used here (although not | many are as critical) | | i'm saying that the maintainer may have a certain idea of when the | package is ready for stable (a target feature set, working out | certain quirks, etc...). your current hard view does not allow for | that. for example, i had an arch maintainer one time mark bash-3 | stable before base-system was ready for it (readline, baselayout, | etc... were going to be stabilized together). i smacked them hard | for it, but if we went with this hard view, it would have been | perfectly acceptable behavior. -mike There is nothing in this view that says "consulting the package maintainer is not part of the stable decision-making process for arch teams". -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpZ2x7fCaSsi.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote: > On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <[EMAIL PROTECTED]> > > wrote: > | ok, e17 packages dont count here. however, your hardcore view i > | still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x > | stabilization process ? are you telling me that arch teams should > | have had the power to move those into stable without talking to the > | maintainer ? baselayout may be a core package, but if you continue > | with your hard rule here, then it doesnt matter. > > I'm saying that arch teams should be allowed to mark it stable if they > think it's appropriate. Not that it must be moved to stable after $x > days, but that it can be at the arch team's discretion. And any arch > team which is silly enough to mark a broken baselayout stable has far > bigger problems anyway... baselayout is an example, any package can be used here (although not many are as critical) i'm saying that the maintainer may have a certain idea of when the package is ready for stable (a target feature set, working out certain quirks, etc...). your current hard view does not allow for that. for example, i had an arch maintainer one time mark bash-3 stable before base-system was ready for it (readline, baselayout, etc... were going to be stabilized together). i smacked them hard for it, but if we went with this hard view, it would have been perfectly acceptable behavior. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Ciaran McCreesh wrote: Plus for stuff like gcc, it's very much an arch decision, not a package maintainer decision. gcc was just the first example which came to my mind -- you can replace it with every other big piece of software that needs more testing than just 30 days. Or the other way around: There might be a new, not very popular package, so the maintainer didn't get any bug reports (=it works fine), but there might be a too little user community that you really could claim it rock-solid stable. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | ok, e17 packages dont count here. however, your hardcore view i | still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x | stabilization process ? are you telling me that arch teams should | have had the power to move those into stable without talking to the | maintainer ? baselayout may be a core package, but if you continue | with your hard rule here, then it doesnt matter. I'm saying that arch teams should be allowed to mark it stable if they think it's appropriate. Not that it must be moved to stable after $x days, but that it can be at the arch team's discretion. And any arch team which is silly enough to mark a broken baselayout stable has far bigger problems anyway... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpoCDjgI3nFt.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 04:25 pm, Daniel Ostrow wrote: > His point (and it's an unfortunately valid one) as I understand it is > that our user base has been (mis)educated to avoid packages in p.mask > for fear of breaking things too badly. As such it gets an inherently far > smaller test base then packages in ~arch do. i [rightly] fear package.mask packages most of the time. we stick things in there that have security issues, or are known to be badly broken in some way, or wont work in subprofiles for archs (think glibc-specific packages masked in a uclibc profile). at the sametime, we use package.mask for things that *should* work fine, but we dont know yet. i wouldnt mind a restricted 4th level of masking here: arch stable ~arch unstable ?arch should work fine, but not 100% sure yet package.mask known to be broken in some way it's also a pita to maintain package.mask since we're storing information about specific ebuilds outside of the ebuild itself, and it tends to suffer badly from bitrot -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 22:17:20 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | On Friday 16 September 2005 21:34, Ciaran McCreesh wrote: | > Those should be in package.mask. ~arch is for candidates for arch | > that haven't yet proven themselves. | | No. Your idea how it should work simply doesn't match reality. That's not my idea. That's policy. I just happen to a) have actually read what policy says and b) agree with it. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpanIaLjyO98.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 2005-16-09 at 16:21 -0400, Aron Griffis wrote: > Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT] > > > Those should be in package.mask. ~arch is for candidates for arch that > > > haven't yet proven themselves. > > > > It's often the case that those ebuilds in principle work, but there > > are other reasons for not marking stable yet. Some packages for > > example can have upgrade problems for stable users while being > > stable for testing (by benefit of allready having passed such > > upgrade problems). Masking the ebuild is not really an option > > (causing testing users to go through unnecessary hoops again), while > > marking stable is also no option. > > You're saying there's four states: > > package.mask > ~arch > ~arch candidate for arch > arch [...] > So far I find myself agreeing with Ciaran's idea in this thread. > I don't see the point (yet) in more than three states. Well having the "~arch candidate for arch" makes the imlate script much easier to use.. I would find it a PITA to have to go through the changelog of every package to see if it has been in testing for 30 days.. Or we need to automate it, something like a imlate-because-the-package-hasnt-changed-in-30-days.py -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 03:34 pm, Ciaran McCreesh wrote: > On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger <[EMAIL PROTECTED]> > > wrote: > | not really ... sometimes you want to keep a package in unstable > | forever (like the cvs snapshots i make of e17), or until you work > | some quirks/features out for a new revbump which you would want stable > > Those should be in package.mask. ~arch is for candidates for arch that > haven't yet proven themselves. ok, e17 packages dont count here. however, your hardcore view i still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x stabilization process ? are you telling me that arch teams should have had the power to move those into stable without talking to the maintainer ? baselayout may be a core package, but if you continue with your hard rule here, then it doesnt matter. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 16:21 -0400, Aron Griffis wrote:
> Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
> > > Those should be in package.mask. ~arch is for candidates for arch that
> > > haven't yet proven themselves.
> >
> > It's often the case that those ebuilds in principle work, but there
> > are other reasons for not marking stable yet. Some packages for
> > example can have upgrade problems for stable users while being
> > stable for testing (by benefit of allready having passed such
> > upgrade problems). Masking the ebuild is not really an option
> > (causing testing users to go through unnecessary hoops again), while
> > marking stable is also no option.
>
> You're saying there's four states:
>
> package.mask
> ~arch
> ~arch candidate for arch
> arch
>
> Putting packages in package.mask isn't a hardship for testers. I'm
> not sure that's a good reason for the additional state. It's purely
> a matter of
>
> echo 'dev-util/mercurial' >> /etc/portage/package.unmask
>
> So far I find myself agreeing with Ciaran's idea in this thread.
> I don't see the point (yet) in more than three states.
His point (and it's an unfortunately valid one) as I understand it is
that our user base has been (mis)educated to avoid packages in p.mask
for fear of breaking things too badly. As such it gets an inherently far
smaller test base then packages in ~arch do.
Personally I am uncomfortable with people using ~arch as a "We didn't
get enough testing for package X, so we are putting it here for a wider
audience." mentality. That is the whole purpose of p.mask and released
independent overlays (such as fbsd and php use). Either way the use of
~arch for this purpose is really just wrong.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT] > > Those should be in package.mask. ~arch is for candidates for arch that > > haven't yet proven themselves. > > It's often the case that those ebuilds in principle work, but there > are other reasons for not marking stable yet. Some packages for > example can have upgrade problems for stable users while being > stable for testing (by benefit of allready having passed such > upgrade problems). Masking the ebuild is not really an option > (causing testing users to go through unnecessary hoops again), while > marking stable is also no option. You're saying there's four states: package.mask ~arch ~arch candidate for arch arch Putting packages in package.mask isn't a hardship for testers. I'm not sure that's a good reason for the additional state. It's purely a matter of echo 'dev-util/mercurial' >> /etc/portage/package.unmask So far I find myself agreeing with Ciaran's idea in this thread. I don't see the point (yet) in more than three states. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgppgsKoBkwrJ.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 21:34, Ciaran McCreesh wrote: > Those should be in package.mask. ~arch is for candidates for arch that > haven't yet proven themselves. No. Your idea how it should work simply doesn't match reality. When you e.g. have upstream devs following the maxim "release early and often", it happens that you don't want ebuilds go stable so easily, but still have a wide testing audience. Arch teams have to ask package maintainers when they want to stabilize an ebuild before it is indicated - be it by a "maint" keyword or what else. Carsten pgpKAHjAYdt5o.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
Vapier wrote:[Fri Sep 16 2005, 03:15:26PM EDT] > not really ... sometimes you want to keep a package in unstable > forever (like the cvs snapshots i make of e17), or until you work > some quirks/features out for a new revbump which you would want > stable Why wouldn't you put these in package.mask? Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp4V1gCmR7oy.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 21:34, Ciaran McCreesh wrote: > On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger <[EMAIL PROTECTED]> > > wrote: > | not really ... sometimes you want to keep a package in unstable > | forever (like the cvs snapshots i make of e17), or until you work > | some quirks/features out for a new revbump which you would want stable > > Those should be in package.mask. ~arch is for candidates for arch that > haven't yet proven themselves. It's often the case that those ebuilds in principle work, but there are other reasons for not marking stable yet. Some packages for example can have upgrade problems for stable users while being stable for testing (by benefit of allready having passed such upgrade problems). Masking the ebuild is not really an option (causing testing users to go through unnecessary hoops again), while marking stable is also no option. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpoS8zYyetNS.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 15:15:26 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | not really ... sometimes you want to keep a package in unstable | forever (like the cvs snapshots i make of e17), or until you work | some quirks/features out for a new revbump which you would want stable Those should be in package.mask. ~arch is for candidates for arch that haven't yet proven themselves. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpO2kheLRBls.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 21:12:56 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > Well, if it's in ~arch it's a candidate to go to stable after | > further testing. If a package maintainer isn't prepared to have a | > package moved to stable, they shouldn't take it out of package.mask. | | The 30 days are just a rule, there are enough packages which surely | need a longer testing period, even if they work flawlessly. Or would | you mark gcc 4.0 stable after 30 days? I think that's what Paul | wanted to say. For that, I'd point you at the devmanual version of keywording policy, which is a hell of a lot better written and includes an explicit remark about core system components needing a lot more than 30 days. http://dev.gentoo.org/~plasmaroo/devmanual/keywording/ Plus for stuff like gcc, it's very much an arch decision, not a package maintainer decision. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp54tvvRBLYy.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 03:02 pm, Ciaran McCreesh wrote: > On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > > wrote: > | > Take it out of package.mask and leave it for thirty > | > (package-dependent) days. If there is a pressing (eg security) > | > reason for it to go to stable sooner than would normally be > | > expected, file a bug and Cc: the relevant arch teams. > | > | I was thinking more like signalling that it shouldn't be stable yet, > | but shouldn't be masked either. > > Well, if it's in ~arch it's a candidate to go to stable after further > testing. If a package maintainer isn't prepared to have a package moved > to stable, they shouldn't take it out of package.mask. not really ... sometimes you want to keep a package in unstable forever (like the cvs snapshots i make of e17), or until you work some quirks/features out for a new revbump which you would want stable -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
Ciaran McCreesh wrote: Well, if it's in ~arch it's a candidate to go to stable after further testing. If a package maintainer isn't prepared to have a package moved to stable, they shouldn't take it out of package.mask. The 30 days are just a rule, there are enough packages which surely need a longer testing period, even if they work flawlessly. Or would you mark gcc 4.0 stable after 30 days? I think that's what Paul wanted to say. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 20:48 +0200, Paul de Vrieze wrote:
> On Friday 16 September 2005 20:38, Ciaran McCreesh wrote:
> > On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <[EMAIL PROTECTED]>
> >
> > wrote:
> > | Ok, I do think that we will need a way for the maintainer to indicate
> > | that the package is stable. I'd be happy to leave stabilizing out of
> > | my hands, but I wouldn't want my packages to be stabilized before I
> > | deem it stable.
> >
> > Take it out of package.mask and leave it for thirty (package-dependent)
> > days. If there is a pressing (eg security) reason for it to go to
> > stable sooner than would normally be expected, file a bug and Cc: the
> > relevant arch teams.
>
> I was thinking more like signalling that it shouldn't be stable yet, but
> shouldn't be masked either.
>
> Paul
Here's my 2 cents on this...the general rule of thumb for an arch
stabilizing a package has been 30 days in ~ with no open bugs. As far as
I am concerned this mean that if a package maintainer does not want a
package to follow these rules then indicating such is as easy as opening
a bug against the package assigned to him/herself stating so and mark it
for all arch's. That way when the arch team goes to look for bugs (and
we are all doing this right???) before marking a package stable they
will see the bug and know not to.
Hell the bug can be as simple as "Don't mark this package stable yet for
reasons x, y and z." Doing it this way has the added advantage of
letting arch maintainers know about the reasons why the package
shouldn't be marked stable so they know what they are getting into by
going ahead of the package maintainer.
Personally I like this outlook a lot better then the maint ~maint option
because it provides information and fits into present policy. All in all
it really isn't that hard to open a bug.
If the package is truly not stable then it should really be moved back
into p.mask anyway.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 20:48:45 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | > Take it out of package.mask and leave it for thirty | > (package-dependent) days. If there is a pressing (eg security) | > reason for it to go to stable sooner than would normally be | > expected, file a bug and Cc: the relevant arch teams. | | I was thinking more like signalling that it shouldn't be stable yet, | but shouldn't be masked either. Well, if it's in ~arch it's a candidate to go to stable after further testing. If a package maintainer isn't prepared to have a package moved to stable, they shouldn't take it out of package.mask. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpPAZRMgyiSL.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 20:38, Ciaran McCreesh wrote: > On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > > wrote: > | Ok, I do think that we will need a way for the maintainer to indicate > | that the package is stable. I'd be happy to leave stabilizing out of > | my hands, but I wouldn't want my packages to be stabilized before I > | deem it stable. > > Take it out of package.mask and leave it for thirty (package-dependent) > days. If there is a pressing (eg security) reason for it to go to > stable sooner than would normally be expected, file a bug and Cc: the > relevant arch teams. I was thinking more like signalling that it shouldn't be stable yet, but shouldn't be masked either. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpkotFik1Clk.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | Ok, I do think that we will need a way for the maintainer to indicate | that the package is stable. I'd be happy to leave stabilizing out of | my hands, but I wouldn't want my packages to be stabilized before I | deem it stable. Take it out of package.mask and leave it for thirty (package-dependent) days. If there is a pressing (eg security) reason for it to go to stable sooner than would normally be expected, file a bug and Cc: the relevant arch teams. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpi9rE5zIdCg.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
Paul de Vrieze wrote: Ok, I do think that we will need a way for the maintainer to indicate that the package is stable. I'd be happy to leave stabilizing out of my hands, but I wouldn't want my packages to be stabilized before I deem it stable. That's exactly what the maint keyword is for. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, Sep 16, 2005 at 08:14:08PM +0200, Martin Schlemmer wrote: > On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote: > > On Friday 16 September 2005 00:20, Mike Frysinger wrote: > > > actually this is came up in the meeting as something we would like to see > > > spelled out explicitly ... either as a GLEP itself or as a policy update > > > to > > > current stabilization practices > > > > > > the GLEP was approved on the grounds that we need an x86 team and that it > > > needs to be treated as any other arch ... arch team interaction with > > > maintainers should be spelled out clearly rather than part of a single > > > sentence '... or make individual arrangements with the x86 arch team.' > > > > Ok, I do think that we will need a way for the maintainer to indicate that > > the > > package is stable. I'd be happy to leave stabilizing out of my hands, but I > > wouldn't want my packages to be stabilized before I deem it stable. > > > > File a bug if the arches (or main ones at least) haven't picked it up > yet? Will make the problem of missing some or other keyword minimal > (especially for some obscure package not often used). I would prefer this route, personally. Jamming a maint keyword into the ebuild is kind of ugly from where I sit :) ~harring pgp1E2oHKfzdH.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 19:42 +0200, Paul de Vrieze wrote: > On Friday 16 September 2005 00:20, Mike Frysinger wrote: > > actually this is came up in the meeting as something we would like to see > > spelled out explicitly ... either as a GLEP itself or as a policy update to > > current stabilization practices > > > > the GLEP was approved on the grounds that we need an x86 team and that it > > needs to be treated as any other arch ... arch team interaction with > > maintainers should be spelled out clearly rather than part of a single > > sentence '... or make individual arrangements with the x86 arch team.' > > Ok, I do think that we will need a way for the maintainer to indicate that > the > package is stable. I'd be happy to leave stabilizing out of my hands, but I > wouldn't want my packages to be stabilized before I deem it stable. > File a bug if the arches (or main ones at least) haven't picked it up yet? Will make the problem of missing some or other keyword minimal (especially for some obscure package not often used). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 00:20, Mike Frysinger wrote: > actually this is came up in the meeting as something we would like to see > spelled out explicitly ... either as a GLEP itself or as a policy update to > current stabilization practices > > the GLEP was approved on the grounds that we need an x86 team and that it > needs to be treated as any other arch ... arch team interaction with > maintainers should be spelled out clearly rather than part of a single > sentence '... or make individual arrangements with the x86 arch team.' Ok, I do think that we will need a way for the maintainer to indicate that the package is stable. I'd be happy to leave stabilizing out of my hands, but I wouldn't want my packages to be stabilized before I deem it stable. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpXfO7Hi2DW6.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 05:51, Aron Griffis wrote: > Regarding GLEP 31, the council is in favor of enforcement ASAP, > provided nano is confirmed to be capable of compliance. That will set > the bar to require UTF-8 capable editors for portage work. Confirmed. -- Jason Stubbs pgpeTCg9uOJs8.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Thursday 15 September 2005 05:57 pm, Chris Gianelloni wrote: > On Thu, 2005-09-15 at 17:25 -0400, Olivier Crete wrote: > > - Does it mean that devs who are not part of the x86 team can't move > > packages from ~x86 to x86 ? > > Correct. They can, however, make previous arrangements with the x86 > arch team to allow them to stabilize their own packages. What this says > is "I acknowledge that anything that I break or that breaks on x86 with > my package, I get to fix and is not the responsibility of the x86 arch > team." The x86 team will keep a list of these developers. This is > similar (or identical) to how other arch teams work. For example, I'm > not a member of the amd64 arch team, but they know I have an amd64 and > use it as my primary development box, so I have made arrangements with > them so I can ~amd64 -> amd64 my own packages. If something breaks, I > pick up the pieces, not them. actually this is came up in the meeting as something we would like to see spelled out explicitly ... either as a GLEP itself or as a policy update to current stabilization practices the GLEP was approved on the grounds that we need an x86 team and that it needs to be treated as any other arch ... arch team interaction with maintainers should be spelled out clearly rather than part of a single sentence '... or make individual arrangements with the x86 arch team.' -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Thu, 2005-09-15 at 17:25 -0400, Olivier Crete wrote: > What does that glep mean anyways ? Appart from the creation of the x86 > team, is there any action to be taken? > - Is the maint keyword approved? No. It was a suggestion, but was never added to the GLEP. > - Does it mean that devs who are not part of the x86 team can't move > packages from ~x86 to x86 ? Correct. They can, however, make previous arrangements with the x86 arch team to allow them to stabilize their own packages. What this says is "I acknowledge that anything that I break or that breaks on x86 with my package, I get to fix and is not the responsibility of the x86 arch team." The x86 team will keep a list of these developers. This is similar (or identical) to how other arch teams work. For example, I'm not a member of the amd64 arch team, but they know I have an amd64 and use it as my primary development box, so I have made arrangements with them so I can ~amd64 -> amd64 my own packages. If something breaks, I pick up the pieces, not them. > - Is there something else I failed to read? Not that I'm aware of. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] first council meeting
On Thu, 2005-15-09 at 16:51 -0400, Aron Griffis wrote: > > 3. glep40: Standardizing "arch" keywording across all archs > >Vote asked by Grant Goodyear > > Approved. What does that glep mean anyways ? Appart from the creation of the x86 team, is there any action to be taken? - Is the maint keyword approved? - Does it mean that devs who are not part of the x86 team can't move packages from ~x86 to x86 ? - Is there something else I failed to read? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] first council meeting
The first council meeting happened today at 1900UTC. All council members attended. 1. Official confirmation that the council is inline with the already-defined roles of devrel and QA and its commitment to make already-approved GLEPs (including GLEP 31) respected (Clarification of position asked by many people including Ciaran McCreesh, Patrick Lauer and Lance Albertson) Confirmed with the caveat that the council is not taking on disciplinary responsibilities. The QA team should take complaints regarding unresolved technical violations to devrel to pursue displinary action. Regarding GLEP 31, the council is in favor of enforcement ASAP, provided nano is confirmed to be capable of compliance. That will set the bar to require UTF-8 capable editors for portage work. (note: agenda reordered per request) 3. glep40: Standardizing "arch" keywording across all archs Vote asked by Grant Goodyear Approved. 2. glep33: Eclass Restructure/Redesign Vote asked by Brian Harring Approved. 4. Discussion of the next meeting date(s) 2nd Thursday of each month, 1900UTC. Rain date of 3rd Thursday. 5. Open Q&A session Full meeting log available at http://gentoo.org/proj/en/council/meeting-logs/20050915.txt Please post follow-ups to gentoo-council ML (subscription required) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpFWsVRuq3Fp.pgp Description: PGP signature
