Re: [gentoo-dev] Resignation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: > To my former fellow Gentoo developers and users, > > On Thu, Jul 27, 2006 at 11:58:09PM +0200, Stefan Schweizer wrote: >> To my fellow Gentoo developers and users, >> >> In last weeks council meeting [1] it was decided that the Sunrise project is >> no longer suspended. I can give a short overview of the current status of >> the overlay: > > Seeing this I'd like to resign as a Gentoo developer. > > Thank you to all the developers and users who have made the last two > years a fun period of my life in OSS. You all know who you are. I'll > miss you guys and gals. > > I wish the remaining developers good luck with keeping Gentoo Linux > among the top GNU/Linux distributions out there. > > I can be reached at [EMAIL PROTECTED] should anybody have any > questions to the ebuilds, I used to maintain. Sorry about dumping the > ebuilds on the people who kindly took over when I announced my present > hiatus - but I'm sure you'll do a good job at maintaining them. > > I have an unfinished draft for a pcmcia-cs to pcmciautils migration > howto sitting in my home dir - I'd appreciate if someone would step > up and finish it. > > So long and thank you for all the fish, > Brix i'll miss you greatly, brix. You made my laptop and wireless (madwifi) worlds much much happier places. i'm on devaway, but when I'm back, if no one else has done it, i'll xmlify your pcmciautils doc -- you were the one who took the time to explain to me that -utils wouldn't bite this longterm -cs user. :) good luck in all your future endeavors. hope i see you around irc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEya7mrsJQqN81j74RAp9ZAKCWdFKPX11wlwHCjQV/eBZ1PtzkzACfTZk/ lXGQZS2wZq3NkZyvXpp1ZZw= =EozF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: > On Thu, 27 Jul 2006 22:19:14 -0400 > Luis Francisco Araujo <[EMAIL PROTECTED]> wrote: > >> The users explicitly compromise to (just to make it clear): [1,2,3,4] > > People who participate in open projects like Gentoo come and go. What > happens if/when the proxy maintainer decides to leave? Who will take > care of the package? Maybe the mailing list could also be used to find > users to proxy maintain abandoned packages? > Good point. Definitely, the mailing list could be used to address this case too. I see two possible situations in the best case: 1 - The developer sends the request to the mailing list asking for somebody interested to continue proxy-maintaining the packages. Any interested developer could step in. 2 - The proxy-user *could* be interested to become official developer to maintain this package too. As long as there exist an interested user to maintain the package i think it's a matter of time to find a proxy-developer. (Any mechanism to inform us which packages are in this state would be useful too, probably a monthly message to the list?) Now if the user isn't interested anymore , and i think this would be the 'worst' of the case, could be addressed in the following manner: 1- He could notify to the mailing list for any user interested to continue maintaining the package(s). 2- If no user steps in, the developer would still represent officially the package inside the tree. Now, this package _ideally_ shouldn't have any bug (the user should have taken care of all of them right?), so practically, this package shouldn't be any serious menace to the tree, and therefore, the developer doesn't need to update the package if he doesn't want to. If a bug appears , the developer can: a) Fix it , b) mask the package , c) After b, remove the package. This being the *worse* of the case as i said. Now, i also see an interesting problem here. I can notice we (as developers) make sort of an agreement when we become a developer, but not when we leave the project. This is the main cause we keep having so many packages unmaintained. I think that whatever we do, if we don't find a solution to this situation, gentoo will continue to suffer of this problem. And this idea is just an attempt to alleviate some of it. >> I know there already exist some developers working as proxy, well, i >> appreciate if they got any comment or observation about this idea. This >> is just a way of giving some organization to this kind of cooperative >> mechanism at some degree. And an 'official' representation inside Gentoo >> if we agree with it. > > I work with a user (Kai Huuhko) to maintain media-sound/quodlibet, > media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay > on overlays.gentoo.org where Kai and I both have commit access. We both > work on the ebuilds in the overylay and exchange ideas over e-mail. > After the ebuilds are complete and tested, I commit them to the official > tree. Kia helps with bugs too. So far it has worked very well for us > and we haven't had any problems with the arrangement. Having a helper > saves me time and energy, which allows me do other Gentoo related tasks. > > -Thomas Nice, we have something similar inside the Haskell herd. It looks like we are not the only ones doing good then. Probably making this mechanism more 'organized' and 'official', would encourage more developers to work with it. - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEyYr4dZ42PGEF17URAovbAKCwSlJ8657WQpLPhRamAZ4SRrUdSgCgvMS2 ZS8ybMME+hXrByoct5BQh8Y= =31YO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Thu, 27 Jul 2006 22:19:14 -0400 Luis Francisco Araujo <[EMAIL PROTECTED]> wrote: > The users explicitly compromise to (just to make it clear): [1,2,3,4] People who participate in open projects like Gentoo come and go. What happens if/when the proxy maintainer decides to leave? Who will take care of the package? Maybe the mailing list could also be used to find users to proxy maintain abandoned packages? > I know there already exist some developers working as proxy, well, i > appreciate if they got any comment or observation about this idea. This > is just a way of giving some organization to this kind of cooperative > mechanism at some degree. And an 'official' representation inside Gentoo > if we agree with it. I work with a user (Kai Huuhko) to maintain media-sound/quodlibet, media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay on overlays.gentoo.org where Kai and I both have commit access. We both work on the ebuilds in the overylay and exchange ideas over e-mail. After the ebuilds are complete and tested, I commit them to the official tree. Kia helps with bugs too. So far it has worked very well for us and we haven't had any problems with the arrangement. Having a helper saves me time and energy, which allows me do other Gentoo related tasks. -Thomas pgpXTAZUK3SsB.pgp Description: PGP signature
[gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone,
Here, with this email, i propose (after a brief discussion on irc with
gensteaf)an alternative or at least a new model to address a few issues
with our maintainers needs and the inclusion of new packages into the
tree. Probably an alternative (temporary?) as well to the sunrise
project as the subject of this email suggest.
The idea is very simple, i will generally describe it here.
In my opinion, most of the developers are usually afraid of taking care
of maintainer-{needed-wanted} packages because of the following reasons:
1 - To fix bugs of the package: this might be a very easy task, or a
whole nightmare. Many of these packages got bunch of open bugs, so, a
developer think twice before going after a package that probably he even
doesn't know what it is for, besides that, this task might become very
time-consuming , the developer might prefer to invest this time with the
packages/herd he already maintains instead.
2 - To keep track of upstream: Though it sounds as an easy task, it
might become tedious sometimes, mainly if the developer isn't interested
at all on the project, and, this is definitely, another important point
when maintaining a package.
3 - Interesting packages: Which packages should we pick? , There exist
interested users/developers to maintain/use such a package?. We don't
have an easy way to keep track of this either.
These are the main points i have personally faced when picking
maintainer-{needed,wanted} ebuilds from bugzilla. So, i am pretty much
assuming from a personal point-of-view that others developers might be
also finding these problems (sorry if it is not the case). I don't
believe we all are happy with the current status of packages in need of
maintainers, something must be happening, and i think these three points
are part of the problem.
Ok, after detecting the problem, we need to solve it right? , the idea
is to create a proxy developer structure/mechanism/model/project , where
the developers could let all these three points at the hands of the
user wanting to get the ebuild included into the tree.
The 'modus-operandi' would go like this:
1 - We setup a mailing list (yes, yet another one, but this one is gonna
be useful!) , call it , [EMAIL PROTECTED] , or [EMAIL PROTECTED]
2 - Developers interested to serve as a proxy , subscribe to the list.
3 - Users ask on this mailing list if there exist any developer
interested to include X, or Y ebuild into the tree. (Probably we could
create a template for this?)
4 - An interested developer says 'yes' on the list (so the rest of devel
can see him too) , and from there on, the developer and the user work
off-list.
Or a developer can say 'no'. Explaining the reason (if any) of why
this ebuild shouldn't be included into the tree.
I think this would be solving some bugzilla communication annoyances,
and opening the doors of another 'feedback' way between developers and
users.
This is pretty much the general behaviour , simple right?
Now .. most of you must already be thinking, "well .. isn't this the
same that going and picking maintainer-wanted ebuilds after all?"
Here it comes the trick or 'trap' ;-)
The user _has_ to compromise to take care of those previous commented
three points that some of us might be afraid of, besides of giving us a
centralized way of keeping informed about new ebuilds.
The users explicitly compromise to (just to make it clear):
1 - To fix *all* bugs and problems of the package: The user will need to
take care of all the bugs and problems of the specific package.
Including all dependencies if needed, in the case that the package need
dependencies that are not in the tree yet. (All these requirements
should of course be explicitly stated in the user request email)
2 - To keep track of upstream: The user needs to know the package's
project, and all the communication with upstream should be
responsibility of the user. we also sometimes find developers of a
specific project who would like to cooperate with gentoo , in my opinion
this model would give them an easy and organized opportunity to do so
either.
3 - This will give us a nice way to officially include into the tree
those packages that are more interesting for our users community. After
all they are the ones maintaining them.
4 - These users will need to keep constant and fluent communication with
the developers , you can even call it a 'team' , where the gentoo
developer is the official representation of the project. This also would
give a nice 'isolated' environment , where Gentoo as a project only
would see one developer , so we don't need any internal changes to our
current way of working. /me knock infra doors :-)
This evidently brings some developers responsibilities too, we will need
to review, and test the ebuilds. we sometimes will have to check with
upstream, and comment on the ebuild, or fixing some details. But it
should be a far minimimal effort than th
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
To my former fellow Gentoo developers and users, On Thu, Jul 27, 2006 at 11:58:09PM +0200, Stefan Schweizer wrote: > To my fellow Gentoo developers and users, > > In last weeks council meeting [1] it was decided that the Sunrise project is > no longer suspended. I can give a short overview of the current status of > the overlay: Seeing this I'd like to resign as a Gentoo developer. Thank you to all the developers and users who have made the last two years a fun period of my life in OSS. You all know who you are. I'll miss you guys and gals. I wish the remaining developers good luck with keeping Gentoo Linux among the top GNU/Linux distributions out there. I can be reached at [EMAIL PROTECTED] should anybody have any questions to the ebuilds, I used to maintain. Sorry about dumping the ebuilds on the people who kindly took over when I announced my present hiatus - but I'm sure you'll do a good job at maintaining them. I have an unfinished draft for a pcmcia-cs to pcmciautils migration howto sitting in my home dir - I'd appreciate if someone would step up and finish it. So long and thank you for all the fish, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpehjJjlZS3n.pgp Description: PGP signature
[gentoo-dev] Re: Project Sunrise resumed
Stephen P. Becker wrote: > Eso since when did we have the discussion where you actually > addressed all of the numerous concerns brought forth right before this > project was initially suspended? Do you have any concrete concerns that have not been dealt with yet? I would like to hear about them in that case. I have so far as good as possible implemented suggestions and answered concerns. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise resumed
Stefan Schweizer wrote: In last weeks council meeting [1] it was decided that the Sunrise project is no longer suspended. I can give a short overview of the current status of the overlay: - we currently have 154 ebuilds in 58 categories in the overlay not counting the ebuilds that got into portage and were removed again - we have 8 developers, 4 trusted committers who have taken the ebuild quiz and 26 users committing to the overlay The basic project concept of creating a social workspace has been reached. #gentoo-sunrise is an active IRC channel where users usually find help quickly and it also forms a friendly community. > [1] http://www.gentoo.org/proj/en/council/meeting-logs/20060720-summary.txt http://www.gentoo.org/proj/en/council/meeting-logs/20060720.txt Eso since when did we have the discussion where you actually addressed all of the numerous concerns brought forth right before this project was initially suspended? Looking at the meeting log, the council even noted that the concerns had not been addressed, yet still voted to un-suspend anyway. WTF? -Steve -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Proposed eclasses: vmware and vmware-mod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, The Gentoo vmware team have been developing new ebuilds for vmware-workstation, vmware-player and vmware-server (and vmware-server-console), to help ease the maintenance of the shared modules and shared patches between these products. Since they all have a similar shared installer, and many use the same modules, it was a felt eclasses would be the best system for reducing the shared code between them. The first eclass is for installing the video and network modules that most vmware products use, but should also be able to deploy the modules used in a guest vmware, for the various tools packages. The second eclass if for installing the products themselves, which all tend to follow a similar install process, putting the files in similar locations, and maintaining a pseudo-installation-database used by the vmware configuration and init scripts. So, please take a look through the following proposed eclasses: http://overlays.gentoo.org/svn/proj/vmware/trunk/eclass/vmware-mod.eclass http://overlays.gentoo.org/svn/proj/vmware/trunk/eclass/vmware.eclass and feel free to post any comments, questions or suggestions relating to them so that we can get them fixed up and put in the tree. Once that happens we'll being migrating over the packages from the overlay to the main tree, and we'll be halfway towards having easily maintained and mess free vmware installations for all! 5:) Thanks very much! Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEyTrsu7rWomwgFXoRAtGvAJ9yQMtjTgWYabA8cR0+ydrKI8UwugCbBpiP ua+Udbyc0jIiaOQkBSKJUE0= =UFup -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Project Sunrise resumed
To my fellow Gentoo developers and users, Sunrise is about contributing ebuilds and getting feedback and review while doing so. The main resource this currently happens for is the Gentoo User Overlay of Sunrise and second come ebuilds that get into portage afterwards In last weeks council meeting [1] it was decided that the Sunrise project is no longer suspended. I can give a short overview of the current status of the overlay: - we currently have 154 ebuilds in 58 categories in the overlay not counting the ebuilds that got into portage and were removed again - we have 8 developers, 4 trusted committers who have taken the ebuild quiz and 26 users committing to the overlay The basic project concept of creating a social workspace has been reached. #gentoo-sunrise is an active IRC channel where users usually find help quickly and it also forms a friendly community. Best regards, Stefan [1] http://www.gentoo.org/proj/en/council/meeting-logs/20060720-summary.txt http://www.gentoo.org/proj/en/council/meeting-logs/20060720.txt Other useful resources: Project page http://www.gentoo.org/proj/en/sunrise/ svn reviewed http://www.gentoo-sunrise.org/svn/reviewed/ cia page http://cia.navi.cx/stats/project/sunrise/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
(I subscribed to -dev only a while ago so I can use only this message to reply. So take this as more general reply. I used quotes from other mails also. Hopefully it is not too confusing.) On Thu, 27 Jul 2006 11:11:33 -0700 Richard Fish <[EMAIL PROTECTED]> wrote: > On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > testing. Sure, we could probably stabilize a bunch of the fringe > > packages that hardly anyone uses and it wouldn't affect anything. > > The majority of Aliz's database seems to be made up of these "fringe" > packages. Many of which are stable on at least one arch already, or > have only a single version in the tree anyway. Stabilizing these on > the remaining archs that they support should not have any significant > impact on the perceived overall quality of Gentoo. This sounds good. I agree. But the problem is probably: Chris Gianelloni wrote: > But, nobody likes doing the small stuff, and I can't blame them. I understand. I do not expect that these packages will have same attention by developers as major ones. I would understand if stabilisation or version bumping will be slower than normal. But at least it should be done somewhen. > > Seriously, folks. If you think that packages should be available > > faster, run ~arch. Test the packages. Report successes/failures > > to the maintainers. File stabilization bugs if your favorite > > package hasn't had another bug in 30 days and you've been using > > it. Yes, we (users) should help. But I can't have impression that when I don't ask for stabilisation/version bump it simply never happen. Moving of package (updating/stabilizing) is also my motivation to make and submit a new ebuild. If the package never moves without my further interaction why should I bother by making an ebuld? I'll rather take tar.gz, unpack & build it. It will be less work for now (I do not need to make ebuild) and also for future (I do not need to fill bugs that package should be included/keyworded/stabilized/bumped to new version+updating the ebuild). >From the user point of view it is simply lot of work, lot of maintaining a distribution to fill a bug for every action that should be made on package. Again, I agree that we should help, but if our busyness does not allow it for a while, the packages should move anyway. > > Basically, help out, rather than sitting back and complaining. > > Complaining helps nobody. But it is also good to know what users think about your work, how they feel when using Gentoo. It is not big complaint from me. I'm not saying that I'm unhappy with Gentoo. I'm happy with it, but there is a chance that I can be happier. ;-) Stefan Schweizer <[EMAIL PROTECTED]> wrote: > As a better system I would like to see packages stable automatically > after 30 days and no bugs. But this is probably not going to happen > with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS > in my make.conf I agree with others that this can cause a big quality drop. Maybe it should be done that way, that only _some_ packages will be allowed to stabilize automatically. And it could be just these "fringe" packages. It would solve doing that small suff that nobody likes. Robert -- Robert Cernansky E-mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: Honestly, they shouldn't be stable. In fact, likely, many shouldn't be in the tree. We have way too many packages that are used solely by a small group of people sitting around the tree. These would be better served in official overlays, where they can be maintained by the interested parties (including users), rather than in the tree. This might be a good idea. I think some additional tools support would be useful, so that things like esearch could find things in the official overlays that are not actually present on the user's system. The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. The majority of Aliz's database seems to be made up of these "fringe" packages. Many of which are stable on at least one arch already, or have only a single version in the tree anyway. Stabilizing these on the remaining archs that they support should not have any significant impact on the perceived overall quality of Gentoo. Another problem is that we don't *know* what is being run by our users. This is something that the Summer of Code project for a Gentoo Stats project should at least help with, as it will give us an insight into what is actually being used and what isn't. I hope that all users subscribe to this, it will only be useful with a large enough pool of people submitting their stats. It would also be great if Aliz's database incorporated this information when it becomes available. Seriously, folks. If you think that packages should be available faster, run ~arch. Test the packages. Report successes/failures to the maintainers. File stabilization bugs if your favorite package hasn't had another bug in 30 days and you've been using it. Basically, help out, rather than sitting back and complaining. Complaining helps nobody. Please don't interpret my original message as a complaint. It isn't. It is mostly a question of the process. My understanding of stabilization bugs was that they should be the exception, not the rule... that you might not be able to make a commitment, or even want to do so. However, every single bug report that you file *is* helping out... and every little bit helps. ...and I was wrong. Regards, -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: aging ebuilds with unstable keywords - how can we help?
Chris Gianelloni <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 27 Jul 2006 10:25:52 -0400: > Since the introduction of the x86 architecture team, we have had a > significant slowdown in the "stabilization" of packages in the tree. > However, we have also gotten numerous emails and messages from users who > have said that their systems are much more stable and are highly > appreciative of it[.] I tend to think that our quality has improved > dramatically on x86 due to this[.] I can attest that this extra testing, > as well as the increased efforts of the newly-energized QA project, have > made this release a much more smooth affair than any previous release. > I would definitely call this a success. =8^) I'm not on x86 but amd64, but of course amd64 pioneered the idea of AT, so we've been reaping the benefits for awhile, now. I too would consider an arch team, both arch-devs and arch-testers, a huge benefit. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
* Steve Dibb <[EMAIL PROTECTED]> schrieb: > That's actually how I read the first email, was that it's really the > majority of the _minor_ packages that get completely neglected, and > just sits in the tree for months or years marked unstable because > nobody cares. then the users probably didn't put enough preasure on the stabelizing teams ;-P As I suggested in my last mail: an tool which files stabelizing requests for installed packages after some time (semi-)automatically could help a lot. Once I've got some spare time, I'll sit down and code something. Anyone who likes to join me ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
* Chris Gianelloni <[EMAIL PROTECTED]> schrieb: > > 1) thousands of packages will never be marked stable > > Honestly, they shouldn't be stable. hmm, maybe we should have different groups of ports (*1) for a) quite stable: no bugs yet and enough votes) b) *proven* to be stable: has passed the whole bunch of qm tests. The quite stable category could be used for "normal" packages which are used in production but are not very critical. Maybe games and seldomly used stuff can be taken from here. Critical things (ie. base system, toolchain, critical apps) should only be taken from the proven/mature category. Maybe we could maintain several profiles which does the common masking. I'm not quite familar w/ overlays yet, but it seems wise to me to maintain overlays for several groups of b) ports. Individual overlays may have their own policies. For example one for critical server systems would require absolutely reliable, automatic remote updates, security fixes fast in but enhancements lazy, binary compatibility, etc. > In fact, likely, many shouldn't be in the tree. We have way too many > packages that are used solely by a small group of people sitting around > the tree. These would be better served in official overlays, where > they can be maintained by the interested parties (including users), > rather than in the tree. Those overlays seem good, if they represent an entire subtree (aka distinct from the main tree). For example there could be an KDE/Qt overlay, which contains the whole KDE stuff. People not interested in any of KDE (like me) don't need it. This would make syncing less resource intensive. But: please let's call them *Subtrees*. > > 2) Everyone running stable who wants some recent packages ends up with > > /etc/portage/package.keywords with hundreds of entries > > People don't seem to understand that you cannot have your cake and eat > it, too. I have no sympathy for these people. > > If you want *stable* then you're going to have to wait until the package > has passed QA and the bugs have been resolved. If you want *new* then > you simply have to deal with the bugs. Well, as I said, there're different views of "stable". One means "it is working", others mean "it has to be absolutely robust". Therefore we should differenciate between "stable" and "mature". For example bugzilla-2.22 (which is still masked ~x86 :(): I needed 2.22 for postgresql. This requires 2.22, which is ~x86, so I had to add it to package.keywords. It also requires DBD::Pg, also masked ~x86, also added to package.keywords. Fine so far, as long as I don't have to do it on many packages. Maybe we could handle the two cases installing vs. updating different. Again my bugzilla example: I installed bugzilla-2.22 and DBD::Pg, (both still masked ~x86). At this point I tried something new. Bugzilla + DBD::Pg work for me now, evrything's fine. Now it comes to an update. We've got a new Bugzilla version, which is considered at the same stability level as my current 2.22. I don't see any need for update, since I'm happy w/ current one. So emerge should leave it untouched. Some day we'll have an new version approved to be more stable than current or fixes some bugs. Now emerge should upgrade, but only to the point where it gets more stable. BTW: sometimes it will be good to maintain different branches, ie. there could come an quality enhanced 2.22.1 parallel to an not yet proven 2.23 from upstream. While 2.23 will bring new features, but is not yet properly tested, the 2.22.1 will only have - very carefully checked - bugfixes. This case should also be coped here. > People seem to think that there's some magical solution to this. There > is no solution other than more people actually *solving* the problems > that keep packages from making it to stable. The packages that are > complained about the most are invariably large sets of packages, like > GNOME or KDE, that have hundreds of dependencies and take quite some > time to get into a condition that can be considered "stable" at all. > > If you want things to make it to stable faster, then start supplying > patches. ACK, of course. Maybe we need some system to get users and latent contributors more informed about things to do. I imagine something which directly utilizes portage db (installed packages) to query for information. Ie: box:/ # equery-2do world [www-apps/bugilla-2.22 ~x86] (installed: 2.22 +postgres ...) * solve bug 12345 * test seamless upgrading from 2.20.2 ... [knollo/test-1.23 ~x86] (installed 1.20) * solve bug 1222 * try out new +postgres ... > > 4) The user experience sucks - see the forums/wiki... "to install > > this great sw you need the latest version of x, which depends on y,z, > > so copy paste this huge block in to /etc/portage/package.keywords."... > > then 2 weeks later some depend changes, and suddenly emerge -u world > > no longer works, and user has more problems to solve. > > Honest
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Chris Gianelloni wrote: I'd say no bugs, 30 days, passes internal tests, being run by users => stablise, for the majority of packages (obviously, there may be some exceptions...). Luckily, you're not making the call. ;] The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. That's actually how I read the first email, was that it's really the majority of the _minor_ packages that get completely neglected, and just sits in the tree for months or years marked unstable because nobody cares. The people that use it have marked it ~arch a long time ago in their package.keywords because they know it works just fine. THAT stuff I wouldn't mind going through and just bumping to stable myself. They don't need extensive testing, they don't need patches, they work, and have been working, and just need arches flagged and versions bumped. But, nobody likes doing the small stuff, and I can't blame them. Steve -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: sys-apps/hwdata
The sys-apps/hwdata package isn't marked stable on any architecture. It is the upstream Red Hat version of the package, and was the last version that would work successfully with "hwsetup" as we use on the releases. Since this won't be getting any updates from upstream (as they've moved onto an incompatible format) and it is 100% replaced with sys-apps/hwdata-gentoo, I recommend its removal from the tree in only a few days. There's really no point in keeping this package around, as we aren't using it, and it won't ever get updated with new hardware. If there's no objections in the next few days, I'm going to punt it and do a package move to hwdata-gentoo, just in case. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 12:19 +, Duncan wrote: > "Chris Bainbridge" <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted > below, on Thu, 27 Jul 2006 10:00:39 +0100: > > > The testing is supposed to be for the ebuild, not the package itself, > > so there's not much point in holding back packages with simple ebuilds > > from being stabilised. > > While ~arch is supposed to be stable upstream, testing the ebuild, in > practice there's more to it than that. "Ebuild" in this case is shorthand > for "Gentoo aspects of a package, including not only the ebuild script, > but how the build process functions and the interaction with the various > available Gentoo gcc/glibc/binutils/etc packages, and how it runs in a > Gentoo system, including not only file system layout, but how it actually > runs against the various current Gentoo versions of all its dependencies. Correct. If Gentoo had a third tree state, besides arch and ~arch, then *most* of the ~arch packages would truly belong in the new state. With the current tree, this would mean they would be masked in package.mask, rather than simply being in the tree under ~arch. > In fact, a specifically enumerated part of an arch-tester's job is to test > not only build-time success, but that it actually runs reasonably well > also. While an arch-tester can't be expected to always be familiar enough > with the app to test all the little corner cases, when they say it's ready > to stabilize, they are in effect reporting that it not only compiled, but > ran "as advertised" with no glaring issues or instabilities thru a > reasonable test of its runtime functionality as well, such that it should > be safe to keyword stable, and therefore be available to those that > actually depend on the app for "mission critical" functionality (whether > that mission is as a public server, or blasting the other team in an online > frag-fest). Well, the idea for the arch team is that the team is responsible for ensuring that the package works correctly on the given architecture, and does not interfere with other packages on the architecture. This is because not all developers have access to every architecture, and are also not required to run fully stable systems. As a side-effect of this process, the ebuild gets at least a second set of eyes and testing, and with the arch testers in place, sometimes several extra sets of eyes. Since the introduction of the x86 architecture team, we have had a significant slowdown in the "stabilization" of packages in the tree. However, we have also gotten numerous emails and messages from users who have said that their systems are much more stable and are highly appreciative of it. The thing with stabilization such as this, is it is a balancing act between the people who want "new" and the people who want it to "always work" once it is stable. I tend to think that our quality has improved dramatically on x86 due to this. Most of the other architectures already had this higher level of quality (and many times lagged behind x86 prior to the x86 arch team) that we have come to know and love. I can attest that this extra testing, as well as the increased efforts of the newly-energized QA project, have made this release a much more smooth affair than any previous release. I would definitely call this a success. Will it make all of our users happy? Of course not, but at this point, I don't think that is even a feasibly attainable goal, since our user base is so diverse. Our only sane course of action is to try to appease the majority, and do what we feel is best for them and for ourselves. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 10:34 +0100, Roy Bamford wrote: > Maybe this semi-automatic stabilisation by default could be adopted by > the tree cleaners project? I propose that we remove the name "project" from any "team" that really consists of only one or two people. I think part of the problem is that many people assume that because there is a project, there must be some kind of support structure behind it. Another thing that doesn't help is the number of people that "join" a project, but don't actually *do* anything for the project. I implore all developers to do the following. If you are listed as a member of a project, but aren't actively participating, remove yourself from the list. Perhaps if our tools showed the real state of things, rather than the utopian non-truth, we would get help in the places where it is really needed. A good example of this is the x86 team. There are currently 15 developers listed. At most, 5 of them are active on the team. This makes it look like the team has plenty of help, when the truth is that the team is barely managing to keep their heads above water. Users don't know that the team needs help, because the numbers look so large artificially. This problem gives everyone the wrong impression of the state of affairs within Gentoo and keeps us from being able to get help or provide help in the areas that need it most. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 10:00 +0100, Chris Bainbridge wrote: > I would also like to see that (though maybe with some automated > feedback from users systems as to which packages are installed / how > often they are run). All that the current process ensures is that: Any automated system will cause serious problems for the quality of the distribution without several orders of magnitude of more powerful hardware on our side. > 1) thousands of packages will never be marked stable Honestly, they shouldn't be stable. In fact, likely, many shouldn't be in the tree. We have way too many packages that are used solely by a small group of people sitting around the tree. These would be better served in official overlays, where they can be maintained by the interested parties (including users), rather than in the tree. > 2) Everyone running stable who wants some recent packages ends up with > /etc/portage/package.keywords with hundreds of entries People don't seem to understand that you cannot have your cake and eat it, too. I have no sympathy for these people. If you want *stable* then you're going to have to wait until the package has passed QA and the bugs have been resolved. If you want *new* then you simply have to deal with the bugs. People seem to think that there's some magical solution to this. There is no solution other than more people actually *solving* the problems that keep packages from making it to stable. The packages that are complained about the most are invariably large sets of packages, like GNOME or KDE, that have hundreds of dependencies and take quite some time to get into a condition that can be considered "stable" at all. If you want things to make it to stable faster, then start supplying patches. > 3) Debugging user bugs when users have a mixed x86/~x86 system is a > lot more complicated. Every system ends up being a unique combination > of different packages and versions. This isn't even an issue. Every Gentoo system is a unique combination of packages and versions, USE flags, CFLAGS, etc. > 4) The user experience sucks - see the forums/wiki... "to install > this great sw you need the latest version of x, which depends on y,z, > so copy paste this huge block in to /etc/portage/package.keywords."... > then 2 weeks later some depend changes, and suddenly emerge -u world > no longer works, and user has more problems to solve. Honestly, the number of people out there giving shit advice is part of the problem. Rather than telling people to do this sort of thing, a better solution would be to tell people how they can *help* instead of how they can bypass the system, which ends up with clueless users filing more bugs, which delays the stabilization longer. Every user that someone knowledgeable gets to use something they don't understand, is a potential bug report slowing stabilization even more. > The testing is supposed to be for the ebuild, not the package itself, > so there's not much point in holding back packages with simple ebuilds > from being stabilised. And the testing process isn't that extensive > anyway - all it ensures is that the package builds and can be run on > one particular arch testers system. No disrespect to the testers, but > they can't be experts in every particular piece of software. How much > code coverage does a typical ebuild really get when being tested? First off, we have a level of expectation of stability to maintain. If all packages were done "right" then 90% of the ~arch packages in the tree would be under package.mask, rather than ~arch. Only packages in ~arch would be ones with no bugs open, to test the ebuild, so that they can become stable. As we all know, this isn't the case. Developers all over the place, including myself, have put in tons of packages that aren't necessarily perfectly stable themselves. We do this because our users demand it. We have reached a critical mass of users, where no matter what we do, somebody is going to bitch and piss and moan because we don't do things the way they would like. There's nothing that we can do about this except decide collectively what the best course of action for our users would be and try to make things as high-quality as possible. Automatic stabilization is one of those things that would cause our quality to go to hell. Another thing is this. If you don't like it, fork. You've got the code. You're *more than welcome* to go around making your own overlay/tree and marking whatever rubbish you feel like as stable. There's *nobody* stopping you from doing so. However, many of the Gentoo developers feel a stronger sense of duty to the users, and would prefer not shove a bunch of crap down the pipe onto people's computers. There are a few of the developers that are followers of the "ricer" philosophy, claiming that they don't mind a few bugs here and there. Well, the number of bugs in bugzilla shows that our users simply don't agree. > I'd say no bugs, 30 days, passes interna
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Wed, 2006-07-05 at 18:28 +0200, Alexandre Buisse wrote: > On Wed, Jul 5, 2006 at 18:20:08 +0200, Patrick McLean wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > I would like to nominate: > > vapier/SpanKY > > flameeyes > > Kugelfang > > uberlord > > wolf31o2 > > seemant > > solar > > Mr_Bones_ > > KingTaco > > Please correct me if I am wrong, but there is no point in nominating > people multiple times, right? > Anyway, I would like to nominate: > > christel > tsunam > marienz I would like to thank nattfodd for nominating me, and although my curiosity makes me interested in the council and how it works, I feel I would need to refrain from accepting the nomination at this point. I don't believe I've been around quite long enough to get a good idea of all the ins and outs of Gentoo as of yet. Maybe next year. :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Re: aging ebuilds with unstable keywords - how can we help?
"Chris Bainbridge" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Thu, 27 Jul 2006 10:00:39 +0100: > The testing is supposed to be for the ebuild, not the package itself, > so there's not much point in holding back packages with simple ebuilds > from being stabilised. While ~arch is supposed to be stable upstream, testing the ebuild, in practice there's more to it than that. "Ebuild" in this case is shorthand for "Gentoo aspects of a package, including not only the ebuild script, but how the build process functions and the interaction with the various available Gentoo gcc/glibc/binutils/etc packages, and how it runs in a Gentoo system, including not only file system layout, but how it actually runs against the various current Gentoo versions of all its dependencies. In fact, a specifically enumerated part of an arch-tester's job is to test not only build-time success, but that it actually runs reasonably well also. While an arch-tester can't be expected to always be familiar enough with the app to test all the little corner cases, when they say it's ready to stabilize, they are in effect reporting that it not only compiled, but ran "as advertised" with no glaring issues or instabilities thru a reasonable test of its runtime functionality as well, such that it should be safe to keyword stable, and therefore be available to those that actually depend on the app for "mission critical" functionality (whether that mission is as a public server, or blasting the other team in an online frag-fest). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] seamonkey -> nss vs nspr
On Wed, 26 Jul 2006 10:04:11 +0200 Martin Schlemmer <[EMAIL PROTECTED]> wrote: > Anyhow, that is the whole issue with mozilla stuff in general - huge > hunk of code that is not really modular, and have to be rebuild for a > few to many projects. While I am all for getting the POS more modular > (which we at least did for nspr and nss), you will need to get > cooperation from upstream, as they used to give a rats ass about abi > compatibility when I was more involved with it, and loads of time if > you actually want to try and do it yourself (which is more than I have > currently), plus even more courage, as currently it will need to be > done for probably at least 6-12 projects (nss, nspr, suite, browser, > mail, minimo, composer, calendar, xulrunner, macbrowser, standalone, > maybe chat, etc). Not to mention replacing (dev/lang/)spidermonkey (which IMHO should be removed from the tree) with a current libjs... I see lots of room for improvement upstream. :) Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 2006.07.27 10:00, Chris Bainbridge wrote: On 27/07/06, Stefan Schweizer <[EMAIL PROTECTED]> wrote: [snip] As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf [snip] The testing is supposed to be for the ebuild, not the package itself, so there's not much point in holding back packages with simple ebuilds from being stabilised. And the testing process isn't that extensive anyway - all it ensures is that the package builds and can be run on one particular arch testers system. No disrespect to the testers, but they can't be experts in every particular piece of software. How much code coverage does a typical ebuild really get when being tested? I'd say no bugs, 30 days, passes internal tests, being run by users => stablise, for the majority of packages (obviously, there may be some exceptions...). -- gentoo-dev@gentoo.org mailing list Maybe this semi-automatic stabilisation by default could be adopted by the tree cleaners project? Maybe I'll get flamed for even thinking that. Regards, Roy Bamford -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo/Java staffing needs
On 27/07/06, Bartlomiej Szymczak <[EMAIL PROTECTED]> wrote: Hi. I've noticed Mozilla Foundation has a list of "good first bugs". Very useful when trying to get more developers. Could you list 2-3 "good first bugs" so that I could look at them and see if I can handle them? You are the best judge of your own skills and interests. Go to bugs.gentoo.org, search for bugs assigned to '[EMAIL PROTECTED]', and see if any looking interesting. Some already have ebuilds/fixes attached, but haven't been commited to the tree - you might like to make a list of trivial bugs like this, sifting out the ones that aren't relevant anymore (do leave a comment requesting bug closure and the reason). Some of the others, like out-of-memory build issues, are one line fixes. Find something that looks simple, see if you can reproduce the error, copy the ebuilds to your portage overlay, modify, test, repeat, and eventually the error will go away, now submit your patch and pester someone to look at it and commit it. That's all there is to it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On 27/07/06, Stefan Schweizer <[EMAIL PROTECTED]> wrote: The problem is in the system. Unless you are a developer _and_ part of the arch team you cannot do anything but file a bug and wait and wait and wait until a member of the arch team decides to test the package again for his own and mark it stable. So with the current system the arch teams cannot cover all the packages. I would say for your litle pet package to get stable you have little chances. And you would not want it stable anyway, because stable marking usually lacks behind the bugs of the package. That means you most certainly will hit the bugs and a month later when someone has filed a bug _and_ the package herd or developer has said yes _and_ a developer from the arch team has tested it the bug will be stable, too. As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf I would also like to see that (though maybe with some automated feedback from users systems as to which packages are installed / how often they are run). All that the current process ensures is that: 1) thousands of packages will never be marked stable 2) Everyone running stable who wants some recent packages ends up with /etc/portage/package.keywords with hundreds of entries 3) Debugging user bugs when users have a mixed x86/~x86 system is a lot more complicated. Every system ends up being a unique combination of different packages and versions. 4) The user experience sucks - see the forums/wiki... "to install this great sw you need the latest version of x, which depends on y,z, so copy paste this huge block in to /etc/portage/package.keywords."... then 2 weeks later some depend changes, and suddenly emerge -u world no longer works, and user has more problems to solve. The testing is supposed to be for the ebuild, not the package itself, so there's not much point in holding back packages with simple ebuilds from being stabilised. And the testing process isn't that extensive anyway - all it ensures is that the package builds and can be run on one particular arch testers system. No disrespect to the testers, but they can't be experts in every particular piece of software. How much code coverage does a typical ebuild really get when being tested? I'd say no bugs, 30 days, passes internal tests, being run by users => stablise, for the majority of packages (obviously, there may be some exceptions...). -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Richard Fish wrote: > On 7/2/06, Daniel Ahlberg <[EMAIL PROTECTED]> wrote: >> Hi, >> >> This is an automatically created email message. >> http://gentoo.tamperd.net/stable has just been updated with 15968 >> ebuilds. > > A question [1] has come up on -user about why some ebuilds take so > long to become stable for an arch. This isn't the old "when will we > have KDE yesterday.3am" type question. In reviewing the above > database, and the OP, it looks like a fair number of ebuilds that > could/should be stable are not. > > Of particular concern to me are packages that: > > a) have no open bugs. > b) are marked stable on some archs, but not others. > c) may have only a single version available in portage. > > As an example, consider net-analyzer/etherape, which is "~amd64 ppc > sparc x86", and has no open bugs (other than a version bump request), > and only a single version available in portage to begin with. > > So my question is: is there anything that interested users can do to > help here? I know we can file stabilization bugs, but I agree with > Robert [1] that this should not be necessary in the normal case. > Besides, do you _really_ want 16,000 new bug reports that say nothing > more than "blah/foo works for me, please stabilize"! Is the problem a > lack of time, devs, arch testers, or interested users? The problem is in the system. Unless you are a developer _and_ part of the arch team you cannot do anything but file a bug and wait and wait and wait until a member of the arch team decides to test the package again for his own and mark it stable. So with the current system the arch teams cannot cover all the packages. I would say for your litle pet package to get stable you have little chances. And you would not want it stable anyway, because stable marking usually lacks behind the bugs of the package. That means you most certainly will hit the bugs and a month later when someone has filed a bug _and_ the package herd or developer has said yes _and_ a developer from the arch team has tested it the bug will be stable, too. As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf Things you can do for stabilization to go better: - file a lot of bugs and wait - become an arch tester and test packages to recommend them for stabilization. Of course they still need testing by a developer in the team then. - look for developers and ask them to comment on stale bugs to get them solved To get involved the best way is maybe to show up in IRC in the arch team channel like #gentoo-x86. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo/Java staffing needs
Hi. I've noticed Mozilla Foundation has a list of "good first bugs". Very useful when trying to get more developers. Could you list 2-3 "good first bugs" so that I could look at them and see if I can handle them? In my opinion a good "good first bug" should have the following characteristics: - consider very low priority package (so no big pressure is put on newbies as to when it must be fixed) - be easy (obvious) - can require lots of work to fix (I don't have problem spending lots of time on a bug, as long as it is relatively easy) Please don't spend too much time looking for one. If you can find something, I will be happy to fix it (or at least I will try). Best regards, Rhywek. On 7/26/06, Josh Saddler <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Nichols wrote: > * JBoss maintainer > > JBoss is a pretty important app in the enterprise world of Java. It has > been pretty unmaintained for some time now, and could use some love. > Because of the nature of this beast, I would want someone that uses > JBoss on a daily basis, preferably in an enterprise setting, to be the > type of person to maintain this. I nominate SwifT! :p -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEx97drsJQqN81j74RAqi/AKCxRIVm4T7A9YeG80nP3Iv05f66bgCgpbBX qQXTaPSpfbvoKYZJgtysAAU= =oyoi -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
