Re: [gentoo-dev] Resignation
On Thu, Jul 27, 2006 at 11:31:28PM -0700, Josh Saddler wrote: 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. :) It's already XMLified - it just needs someone to write a few sentences :) good luck in all your future endeavors. hope i see you around irc. Thank you. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpzKq4Bzi1Z8.pgp Description: PGP signature
[gentoo-dev] webdav global use flag and default
Hi we currently have both webdav and nowebdav ueflags, this is confusing: # grep webdav /usr/portage/profiles/use.local.desc dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV dev-util/subversion:nowebdav - Disables WebDAV support via neon library net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. This system allows users to collaborate on websites using a web based interface. See the ebuild for an FAQ page. Enables neon as well to handle webdav support. www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. www-servers/lighttpd:webdav - Enables webdev properties The proposed solution is to make webdav a global useflag and set it as a default use flag to have the same effect as the current nowebdav use flag in subversion. Comments? Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
Luis Francisco Araujo wrote: 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?) The user should send the ebuild changes together with the mail. Make it look like on LKML including diffstat and the actual diff. This way you can quote and give review comments on the mailing list - visible for everyone. Of course diffing needs a good script so that the user does not have to generate the diff and the stat manually 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,2,3,4]: How are we going to reach this? Currently the bugs for ebuilds which have both developer and user in metadata get assigned to the developer and then the developer puts the user on CC. The proposed solution is to put in metadata: maintainer-needed as herd and the user as maintainer. Thus the user can take care of the package but when he leaves or is unavailable it is still considered maintainer-neeeded which means that every developer can take it over or fix bugs. In my opinion it does not matter which developer reviews a specific version bug for a package - so the developer should not be noted in metadata.xml. Of course developers can personally commit themselves to take care of the package and add themselves to metadata too. 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 the developer taking care of the package(s) by his own, in the better of the cases, he even shouldn't do anything but to test, review and commit, from there on, the ebuild will be under the standard procedures of maintenance (arch testing to stabilize, bug reports to notify problems, etc). The developer should also take care of any internal developer communication if needed. internal developer communication turns out to be CCing arches on stable bugs. Giving ok to stabilize some new version. This should be done by the maintaining user since he knows the package best. What exactly do you mean with internal developer communication? - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] webdav global use flag and default
On Friday 28 July 2006 10:18, Stefan Schweizer wrote: Hi we currently have both webdav and nowebdav ueflags, this is confusing: # grep webdav /usr/portage/profiles/use.local.desc dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV dev-util/subversion:nowebdav - Disables WebDAV support via neon library net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. This system allows users to collaborate on websites using a web based interface. See the ebuild for an FAQ page. Enables neon as well to handle webdav support. www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. www-servers/lighttpd:webdav - Enables webdev properties The proposed solution is to make webdav a global useflag and set it as a default use flag to have the same effect as the current nowebdav use flag in subversion. I'd like to explain why subversion has a nowebdav useflag. Basically one of the features of subversion is its ability to work over the http protocol. Many subversion installations use the apache module to serve subversion (even our own overlay project does). To disable webdav support would cripple the subversion client. It is something one should only do when aware of the consequences. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplBDFU7dRLt.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise resumed
On Thu, 2006-07-27 at 18:21 -0400, Stephen P. Becker wrote: 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? I don't seem to remember this. I do though seem to remember that I noted that there was complaints, but died away after Mike asked to actually give some concrete feedback. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Schweizer wrote: Luis Francisco Araujo wrote: 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?) The user should send the ebuild changes together with the mail. Make it look like on LKML including diffstat and the actual diff. This way you can quote and give review comments on the mailing list - visible for everyone. Of course diffing needs a good script so that the user does not have to generate the diff and the stat manually You mean, when the user initially submit the request to the mailing list? , or this one should always be used for the maintenance of the package? 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,2,3,4]: How are we going to reach this? Currently the bugs for ebuilds which have both developer and user in metadata get assigned to the developer and then the developer puts the user on CC. The proposed solution is to put in metadata: maintainer-needed as herd and the user as maintainer. Thus the user can take care of the package but when he leaves or is unavailable it is still considered maintainer-neeeded which means that every developer can take it over or fix bugs. In my opinion it does not matter which developer reviews a specific version bug for a package - so the developer should not be noted in metadata.xml. Of course developers can personally commit themselves to take care of the package and add themselves to metadata too. Well, my idea is more focused on getting closer the developer with the user, in the sense that they would be like a team (as i already said) , where the developer is the official figure in the group. So, at some degree, it does matter who is the proxy-developer in this case. The main idea is that he _indeed_ would be maintaining the package from a Gentoo perspective, and that is where the user will need to compromise with the developer. We could even create a new herd (proxy), so we can differentiate between these ebuilds inside maintainer-needed and those under the control of a specific proxy developer. This idea is heavily based on 'trust' and 'constant' communication between the user and the developer. And that is the way we can get the 'isolation' effect i commented earlier on. 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 the developer taking care of the package(s) by his own, in the better of the cases, he even shouldn't do anything but to test, review and commit, from there on, the ebuild will be under the standard procedures of maintenance (arch testing to stabilize, bug reports to notify problems, etc). The developer should also take care of any internal developer communication if needed. internal developer communication turns out to be CCing arches on stable bugs. Giving ok to stabilize some new version. This should be done by the maintaining user since he knows the package best. What exactly do you mean with internal developer communication? - Stefan Many things, for example, if one of the package affects other(s) herd(s) (for example, some package dependency), i think that the right person to coordinate this work with the rest of the developers would be the proxy-developer. And yes, the proxy-devel also would file stabilization bugs , CCing the user too, so he can keep track of the process. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEydx/dZ42PGEF17URAtQXAKDTfcHhXthFw7cRS4Ko9p00mTYCkgCg2omJ JaoyxDew0HETTJxZ8ZrLrvk= =lfn9 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On Fri, Jul 28, 2006 at 11:35:24AM +0200, Martin Schlemmer wrote: Mike asked you repeatedly to voice your issues or concerns in relation to Project Sunrise, which you failed to reply to. How many times are we supposed to raise our concerns about a project whose founders already agreed to run their project as an unofficial project on non-gentoo infrastructure? Did you miss the logs from the devrel + sunrise meeting where genstef and jokey agreed to this? I simply had no idea the Gentoo Council even remotely considered taking Project Sunrise on as an official project. Also, I do not remember you even attending the meeting or asking to speak there, so this really seems a tad unreasonable or impulsive. Same as above - had I known that you guys actually intended to revert your own ruling from the previous meeting along with the consensus reached on the devrel + sunrise meeting I would have been there to raise my concerns. No big deal, though. Best of luck to all of you, including the people behind Project Sunrise. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp0KqzyafX8t.pgp Description: PGP signature
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On Fri, 2006-07-28 at 12:02 +0200, Henrik Brix Andersen wrote: On Fri, Jul 28, 2006 at 11:35:24AM +0200, Martin Schlemmer wrote: Mike asked you repeatedly to voice your issues or concerns in relation to Project Sunrise, which you failed to reply to. How many times are we supposed to raise our concerns about a project whose founders already agreed to run their project as an unofficial project on non-gentoo infrastructure? Did you miss the logs from the devrel + sunrise meeting where genstef and jokey agreed to this? Apparently they changed their minds, as Mike did state (as well as genstef) in that thread. I simply had no idea the Gentoo Council even remotely considered taking Project Sunrise on as an official project. Err, I miss to comprehend above??? You saw the item on the meeting agenda, made vague complaints, but yet did not know about this? Also, I do not remember you even attending the meeting or asking to speak there, so this really seems a tad unreasonable or impulsive. Same as above - had I known that you guys actually intended to revert your own ruling from the previous meeting along with the consensus reached on the devrel + sunrise meeting I would have been there to raise my concerns. Ditto, same again as above. I cannot see how you can state you did not know about it when you did actually complain about re-evaluating it. No big deal, though. Best of luck to all of you, including the people behind Project Sunrise. Do not get me wrong, the little I worked with you was not unpleasant or anything, and I really have no need or want to see you go, but your reasoning just do not add up. Anyhow, good luck whichever way you choose to go. Regards, -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: webdav global use flag and default
Paul de Vrieze wrote: I'd like to explain why subversion has a nowebdav useflag. Basically one of the features of subversion is its ability to work over the http protocol. Many subversion installations use the apache module to serve subversion (even our own overlay project does). To disable webdav support would cripple the subversion client. It is something one should only do when aware of the consequences. right you are. Putting the default useflag into base/make.defaults has the same effect as a nowebdav useflag without being a no* useflag and confusing with other useflags that do not have the no* bit. If there are no objections and you agree with the solution I will make webdav global and default after a week from now and you can remove the old nowebdav useflag. If there are any problems with putting it in base/ for example neon does not work on hardened, embedded or anything else I would like to know about it. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
On Thu, 2006-07-27 at 09:24 -0600, Steve Dibb wrote: 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. Well, we would hope that people using the package would file a bug, but this obviously doesn't always happen. 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. I'd have no problem with that so long as it was done by a person. I just don't trust that anything like this should ever be automated. Now, we could have an automated system to send out *alerts* on packages that have been in testing for more than 30 (or 60) days. We could even make it searchable by architecture and put it on a web page. We could probably also make it give some information about QA problems. We could even make it searchable by herd. That would be cool. I propose that we put up such a page and we call it http://gentoo.tamperd.net/stable/ and make it publicly available. ;] But, nobody likes doing the small stuff, and I can't blame them. True that. -- 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 11:11 -0700, Richard Fish wrote: On 7/27/06, Chris Gianelloni [EMAIL PROTECTED] wrote: 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. The x86 architecture team (as well as some others) do not mark packages stable unless there is a bug. In the case of the x86 team, it is simply due to a lack of manpower and also due to our feelings that we should not mark things stable without the maintainer requesting it. Of course, we don't *require* a bug report be made. If the maintainer asks (via email, IRC, etc.) us, then we will do it. Also, we don't require that requests originate from the maintainer, only that the maintainer approves. For example, I, as a user, could file a request to have a package marked stable, this would be assigned to the maintainer. If the maintainer agrees, then the arch teams are added to CC on the bug and they mark the package stable. Many packages do not get marked stable simply because most developers maintain a very large number of packages, and simply forget. This is why bug reports from the users is definitely helpful in getting things stable. -- 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: proxy-dev (an alternative to sunrise?)
* Luis Francisco Araujo [EMAIL PROTECTED] schrieb: Hi, Well, my idea is more focused on getting closer the developer with the user, in the sense that they would be like a team (as i already said) , where the developer is the official figure in the group. So, at some so far okay, but we probably suffer an different problem: The gentoo devs currently do much of the upstream's work. Fixing bugs or even adding new stuff which does not directly have to do w/ gentoo should be done exlusively by the upstream. The problem is: many projects have quite long release cycles and don't do separate bugfix releases. For example expat: it took very long to get some little makefile fixes into the release - the upstream team collected quite much until they did the next release (and then they released an direct, just bugfixing, sucessor of 1.98.x as 2.0.x ...). Some projects are quite strange about such things and its like fighting against windmills trying to change their minds. So I founded an project which maintains such bugfixes and releases hotfix patches against many versions of many patches and also stays in contact w/ upstream to get them in the tree: http://wiki.metux.de/public/OpenSource_QM_Taskforce This project is meant to concentrate QM efforts more generally (instead of each distro for its own) and prevent double works, so many distros (and also self-compiling people) can benefit from it. I'd like to invite you all to join this project and use it for your dev works @ gentoo. For an oss-qm + gentoo connection I imagine the following workflow: (should also work w/ other distros this way) * gentoo user files an bug - gets assigned to the devs. * dev inspects the bug whether its gentoo-specific or general @ general: * dev pushes the bug to oss-qm (files a bug there), * oss-qm tries to solve this bug and releases a new hotfix * the gentoo dev then takes in the hotfix and gives the patched package into the QM cycle. @ gentoo: * works as currently As for the suggested user contribution: The users willing to contribute simply join the oss-qm team and do their works there. This at least would cope evrything that's not gentoo specific. What remains to gentoo would be just the contents of the ebuild file (ie. useflags and dependencies okay, etc). At the moment some ebuilds contain much logic for doing the actual build, ie. generating makefiles, etc. This should go completely to oss-qm - the (hotfixed) packages should all supply one of the semi- standard interfaces like autoconf-style ./configure, package imports should be done entirely via pkg-config, etc. In the last few days I did much of such fixing works, ie. on mpd and libao, mainly fixing configure.in + makefiles. Some of those works are currently hanging on the devs feet, but shouldn't. The gentoo devs should only have to take some (maybe hotfixed) package, pull it through the QM cycle and look if its good enough to get it into the tree. 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: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: The gentoo devs currently do much of the upstream's work. Fixing bugs or even adding new stuff which does not directly have to do w/ gentoo should be done exlusively by the upstream. Not true at all. We (as developers) won't be able to avoid helping upstream (it is actually in our social contract). For example, we have dealt with packages inside our herd where we are able to reproduce and detect a bug before upstream does; or even found a better way of doing something, and upstream (lucky for us) has always been happy of receiving our suggestions/fixes , included even patches. I personally think there is nothing wrong with this, i see it actually as one of the goal of gentoo. For an oss-qm + gentoo connection I imagine the following workflow: (should also work w/ other distros this way) * gentoo user files an bug - gets assigned to the devs. * dev inspects the bug whether its gentoo-specific or general @ general: * dev pushes the bug to oss-qm (files a bug there), * oss-qm tries to solve this bug and releases a new hotfix * the gentoo dev then takes in the hotfix and gives the patched package into the QM cycle. @ gentoo: * works as currently As for the suggested user contribution: The users willing to contribute simply join the oss-qm team and do their works there. This at least would cope evrything that's not gentoo specific. What remains to gentoo would be just the contents of the ebuild file (ie. useflags and dependencies okay, etc). I fail to see a border line between what you call 'gentoo specific' problems, and upstream problems. Really, it is not _that_ simple. Also, i don't see how this might be an alternative to my current proposal. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEykgrdZ42PGEF17URAhleAKDgRx+zMNomW+UUUbg3dCvJmHdtggCbB25s hGHkKFzMQmA6q9tMIaz3IhU= =y4MH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Cernansky wrote: Oh, if I can speak for me as a user I'll not like it. One of the major advantage of Gentoo is easy maintenace (not mindless, but easy if you know what you are doing) thanks to portage system. Another is availability of large number of software in distribution. These two together gives easily maintanable operating system - because of portage and because I do not need to maintain lot of packages by myself. I don't know what it is your point here. But i guess, yes, as an user you shouldn't be worried about it. This is just another way for cooperating with the project for those interested in doing so. If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Dependencies are not 'magically' solved. Somebody needs to initially takes care of them. Sorry for being such a bad user. But I'm pretty busy mostly so I'm glad If I find time to make an initial ebuild and submit. In that case, I see no problem to submit right to bugzilla and dicuss/fix/test the ebuild there. That is a different way to cooperate with us. I would agree with your points of user responsibilty to solve bugs, dependencies and so on, but only until package is accepted and included to portage. We need to know before committing this stuff to the tree that the user will compromise at some degree. And this kind of work is a good sign of it. We already have too many unmaintained stuff. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEylbXdZ42PGEF17URAiJ8AJ4hhP8DN5W6eRa9MTBA5md+qaLyRQCfW2Oe jhsfuMDxntw7okoD4qI1Zrg= =4ms8 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] webdav global use flag and default
Am Freitag, 28. Juli 2006 10:18 schrieb Stefan Schweizer: Hi we currently have both webdav and nowebdav ueflags, this is confusing: # grep webdav /usr/portage/profiles/use.local.desc dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV dev-util/subversion:nowebdav - Disables WebDAV support via neon library net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. This system allows users to collaborate on websites using a web based interface. See the ebuild for an FAQ page. Enables neon as well to handle webdav support. www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. www-servers/lighttpd:webdav - Enables webdev properties The proposed solution is to make webdav a global useflag and set it as a default use flag to have the same effect as the current nowebdav use flag in subversion. 5 packages, and only one has nowebdav, and you want to make it a default USE flag? I strongly disagree here. Make it a plain useflag and notify users of subversion that the behaviour changed. Much better than informing users of the other 4 packages that the behaviour changed. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 28 Jul 2006 14:26:31 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: Robert Cernansky wrote: Oh, if I can speak for me as a user I'll not like it. One of the major advantage of Gentoo is easy maintenace (not mindless, but easy if you know what you are doing) thanks to portage system. Another is availability of large number of software in distribution. These two together gives easily maintanable operating system - because of portage and because I do not need to maintain lot of packages by myself. I don't know what it is your point here. But i guess, yes, as an user you shouldn't be worried about it. This is just another way for cooperating with the project for those interested in doing so. I just understand it so, that if a user submits a new ebuild he has to in fact maintain it. So overall maintenance time required by his operating system will be pretty high. Because besides the 'emerge --sync' and 'emerge -u world', he needs take care of his ebuilds. In that paragraph I'm saying that Gentoo have lot of packages so there is a little chance that users have to maintain some packages by themselves (outside the portage tree). But this will break if users have to maintain ebuilds which they submit. thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Dependencies are not 'magically' solved. Somebody needs to initially takes care of them. Yes, _initially_. This is what I agree with. That the points that you propose will be applied only for initial import of ebuild. Until the ebuild gets to portage tree. Then the developers take care of it. Of course the note/recommendation can exist that user who submitted an ebuild will help to maintain it also in future. But if not, (if the user is mostly only a _user_ for whatever reason) the package will be still maintained by developers. Robert -- Robert Cernansky E-mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 28 Jul 2006 11:51:46 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. Yes, it have sense for a larger set of packages (maybe) with complicated depenencies. But I'm talking about few single packages. OK, maybe I'd do some dirty ebuild but it will certainly not be ready for any publication. Robert -- Robert Cernansky E-mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Cernansky wrote: On Fri, 28 Jul 2006 11:51:46 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. Yes, it have sense for a larger set of packages (maybe) with complicated depenencies. But I'm talking about few single packages. An ebuild offer several advantages even for tiny packages. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEymTtdZ42PGEF17URAnCRAJ0VD++qAN6/ivZAsaMFvdbuibelJwCfSus1 H9CeyZgw3G36Mfedej1hOrU= =rPeN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, Jul 28, 2006 at 21:27:31 +0200, Robert Cernansky wrote: On Fri, 28 Jul 2006 14:26:31 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: Robert Cernansky wrote: Oh, if I can speak for me as a user I'll not like it. One of the major advantage of Gentoo is easy maintenace (not mindless, but easy if you know what you are doing) thanks to portage system. Another is availability of large number of software in distribution. These two together gives easily maintanable operating system - because of portage and because I do not need to maintain lot of packages by myself. I don't know what it is your point here. But i guess, yes, as an user you shouldn't be worried about it. This is just another way for cooperating with the project for those interested in doing so. I just understand it so, that if a user submits a new ebuild he has to in fact maintain it. So overall maintenance time required by his operating system will be pretty high. Because besides the 'emerge --sync' and 'emerge -u world', he needs take care of his ebuilds. I think you misunderstood luis' proposition. Everything would go on as now, including users submitting ebuilds on bugzilla and not maintainaing them anymore, but there would also be the solution of asking to do more and being a user_maintaining_an_ebuild_through_a_proxy_dev. If you don't want to do that or don't have the time, and I expect it will be the case of 99.9% of the users, it's fine. This project is only here for the remaining 0.1 %. /Alexandre -- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpDJY1b3s3g5.pgp Description: PGP signature
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 28 Jul 2006 15:26:37 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: An ebuild offer several advantages even for tiny packages. If it is self-maintained ebuild, it depends on complexity of it. Currently I have one application outside the portage tree and I found out to easier/less time consuming to just install it directly from .tar.gz rather then maintaining an ebuild. I plan to make an ebuild for it and submit, but probably I'll not have time to maintain it. Robert -- Robert Cernansky E-mail: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 28 Jul 2006 21:49:02 +0200 Alexandre Buisse [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006 at 21:27:31 +0200, Robert Cernansky wrote: I just understand it so, that if a user submits a new ebuild he has to in fact maintain it. So overall maintenance time required by his operating system will be pretty high. Because besides the 'emerge --sync' and 'emerge -u world', he needs take care of his ebuilds. I think you misunderstood luis' proposition. Everything would go on as now, including users submitting ebuilds on bugzilla and not maintainaing them anymore, but there would also be the solution of asking to do more and being a user_maintaining_an_ebuild_through_a_proxy_dev. If you don't want to do that or don't have the time, and I expect it will be the case of 99.9% of the users, it's fine. This project is only here for the remaining 0.1 %. So it is something like communication channel between developers and users willing to maintain some ebuild? If yes, it is great. I see no problem then. 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?
Hi Chris, on Friday, 2006-07-28 at 09:41:09, you wrote: Well, we would hope that people using the package would file a bug, but this obviously doesn't always happen. Even if it happens that doesn't mean anything is gonna change :) I'd like to get involved and help out with stuff like this but frankly I don't know where to start ATM. The thing is, I maintain net-misc/hsc, upstream that is. The latest stable version in portage is two years old, the unstable one is almost 1yo and buggy. Now there's been a fix for about 5 months now, even comes with an ebuild, maybe not a very good one but it works on various platforms. I notified the developer that made the last ChangeLog entry in March, and again in June, copied to some others devs from the log when there was no reply, opened a bug (#140242) some two weeks ago---still nothing. Seems I'm not following some arcane protocol. I mean, I'd be fine with any comment. Your ebuild sucks, read $DOC and fix it---Cool. We don't have time for the three-and-a-half users of this package, just submit it for an overlay at $FOO---Fine, I know what to do. Mail $DEV and see to it that you get dev status yourself---OK. Hum. Well, I've been subscribed here for a while to get a feeling for the dev process, and this seemed like a good opportunity. Maybe someone else can tell me where to start? cheers! Matthias -- I prefer encrypted and signed messages. KeyID: FAC37665 Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665 pgpUA1DhAtkLp.pgp Description: PGP signature
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 2006-07-28 at 22:09 +0200, Robert Cernansky wrote: On Fri, 28 Jul 2006 21:49:02 +0200 Alexandre Buisse [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006 at 21:27:31 +0200, Robert Cernansky wrote: I just understand it so, that if a user submits a new ebuild he has to in fact maintain it. So overall maintenance time required by his operating system will be pretty high. Because besides the 'emerge --sync' and 'emerge -u world', he needs take care of his ebuilds. I think you misunderstood luis' proposition. Everything would go on as now, including users submitting ebuilds on bugzilla and not maintainaing them anymore, but there would also be the solution of asking to do more and being a user_maintaining_an_ebuild_through_a_proxy_dev. If you don't want to do that or don't have the time, and I expect it will be the case of 99.9% of the users, it's fine. This project is only here for the remaining 0.1 %. So it is something like communication channel between developers and users willing to maintain some ebuild? If yes, it is great. I see no problem then. Robert Not only for communication but to help developers too. I'm a proxy/sponsor for a few packages and i'm very happy with the procedure. Users maintain the best they can and we review their work and commit. This is very good because we can teach anything users need and it's a good thing too increase communication as long as everybody follow the policies. -- Gentoo Linux Developer http://dev.gentoo.org/~metalgod -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: webdav global use flag and default
Danny van Dyk wrote: 5 packages, and only one has nowebdav, and you want to make it a default USE flag? I strongly disagree here. Make it a plain useflag and notify users of subversion that the behaviour changed. Much better than informing users of the other 4 packages that the behaviour changed. We have no statistics on this so I cannot prove but I can argue that subversion is used most of all 4 packages. And I can also argue that having webdav on by default will not cause any harm for the other packages, because it just adds and does not remove functionality. It does no harm. Thus having users informed is not crucial here However doing the change in subversion will break current useage cases by reducing functionality. Most users do not read elog messages and just will get broken. I see your problem and maybe there are ways of solving the problem: - change all other 4 useflags to nowebdav, then make the webdav useflag default, then change them all back to webdav. Maybe you are more happy with such a gradual change. - leave everything as is: it does work but I do not particularly like the nowebdav useflag tho it is better than having subversion broken. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 2006-07-28 at 11:51 -0700, Donnie Berkholz wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. I have to say I agree with Donnie here on this. I've been using private ebuilds for certain things that are installed on my work systems that will never be applicable to anyone except for 4 people on this planet. Yet I use these because then I'm able to take this simple single file, plonk it into another Gentoo machine and recreate the same installation. Maybe it is just because making ebuilds is now just second nature to me. Look at my overlay at the moment, half the stuff there have a less than 30% chance of ever making it into the main portage tree. But I still make those ebuilds in the off chance that either (a) I do decide to put them in, or (b) someone else might stumble across them and find it, and (c) there are just things that I cannot test because I don't have the hardware. Proxy-dev and sunrise are completely different things. But both are trying to decrease the steps needed to contribute to open source, so in my book, that is a good thing. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-java] Gentoo/Java staffing needs
Miroslav Šulc wrote: I would also appreciate more information on Java ebuilds development. I don't remember I've seen somewhere slotting howto for Java ebuilds, but I may miss something. For Java specific information, check out the developer guide: http://www.gentoo.org/proj/en/java/java-devel.xml For general ebuild information: http://devmanual.gentoo.org/ http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml Hope that gives you somewhere to start. -- Joshua Nichols Gentoo/Java - Project Lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] I'm frilled to present to you, a new Gentoo developer
Sven Vermeulen wrote: [...] You get a good 'old welcome from me, Wolf. Welcome. From me as well. Welcome aboard, Wolf! :D -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
