| View previous topic :: View next topic |
| Author |
Message |
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
 Posted: Mon Aug 04, 2008 9:59 pm Post subject: |
 |
|
| AllenJB wrote: | | Other overlays are used to keep rarely used packages available. ... |
Could you explain this use case a little more in detail? An example would be helpful. Do the packages in these overlays have a maintainer or are they "maintainer-needed"? |
|
| Back to top |
|
 |
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Wed Aug 06, 2008 8:12 am Post subject: |
|
|
| AllenJB wrote: | | The problem I forsee with a "monster.g.o" ... In the end, while the idea isn't totally bad, I think the signal-to-noise ratio would mean that most developers won't use it. |
Unfortunate. If Bugzilla had some way of designating non-developers who are willing to work on stuff then developers could easily distinguish the casual contributor from one that is actively trying, and maybe direct efforts towards certain goals better somehow. Ad-hoc fixing could be doing just as good of a job too I guess.
If anyone has tips on better Bugzilla usage, please post them here. But I should probably just RTFM.
You may have also seen this article:
LinuxWorld: Growing the open-source community
I think parts of it are relevant to this discussion so I am linking it in case people might not have seen it. |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Thu Aug 07, 2008 4:08 am Post subject: |
|
|
| node_one wrote: | | If Bugzilla had some way of designating non-developers who are willing to work on stuff then developers could easily distinguish the casual contributor from one that is actively trying, and maybe direct efforts towards certain goals better somehow. Ad-hoc fixing could be doing just as good of a job too I guess. |
There is an upgrade pending for bugzilla, while there is no specific timetable for it to be completed any feature requests are likely to be postponed at least until the upgrade is in use and stable.
| node_one wrote: | | If anyone has tips on better Bugzilla usage, please post them here. But I should probably just RTFM. |
Perhaps. |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Thu Aug 07, 2008 9:22 am Post subject: |
|
|
Thanks desultory, I have read the Reporting Guide before, maybe not as carefully as I should have. I see at the bottom that the author welcomes suggestions etc. I think some parts of Bugzilla's manual should be adapted or linked in the Reporting Guide so I may send him an email.
EDIT: Email sent, dev is currently away.
Last edited by node_one on Mon Aug 11, 2008 12:11 pm; edited 1 time in total |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Fri Aug 08, 2008 4:32 am Post subject: |
|
|
| node_one wrote: | | Could you explain this use case a little more in detail? |
When packages are removed from the tree they can be placed in an overlay to keep them in a place where they are slightly easier to access than the attic of the tree, deciding whether to so is generally left to package maintainers as guided by project policies.
| node_one wrote: | | An example would be helpful. |
The Java Junkyard overlay, note that it is not intended to be used intact.
| node_one wrote: | | Do the packages in these overlays have a maintainer or are they "maintainer-needed"? |
Their state would correspond more directly to maintainer-wanted, as they are no longer in the tree and no longer maintained. |
|
| Back to top |
|
|
alistair
Retired Dev
Joined: 15 Jul 2005
Posts: 869
|
| Posted: Mon Aug 11, 2008 4:10 am Post subject: |
|
|
This is purely from the java teams perspective, so it probably doesn't necessarily apply to teams that have very big releases ( aka kde ) in which inexperienced ppl trying to help out with a release may actually slow the team down.
The java team likes ppl to contribute by joining us on our irc channel, introducing themselves and asking intelligent questions ( and providing intelligent answers ). By intelligent I mean your questions demonstrate that you have at least attempted the problem and read our projects documentation ( which covers enough to get someone started on simple ebuilds ).
Basically we have a process where after seeing some of "your" work, which we are happy with, we grant access to our java-expermental overlay. In here you can play around, break things ( to a certain extent ), etc, etc. From their there is the possibility to grant access to the public (layman supported) java-overlay. After that we usually start talking about becoming a dev.
Without defining any standard timelengths or "contribution messures" to this, I would expect someone who is consistent and produces a reasonable amount of ebuilds (new or bumps) to be asked about devship after 2-3 months. It may take a few more months before we actually offer a devship depending on what that person is contributing.
As an example we had a contributor who was attempting to package maven for us ( and was doing a good job ). This was several months of work and if he had completed it would have certainly been offered a devship. Sadly ( very sadly in-fact ), life situatons changed and his contributions dropped away. Which is in a way a good thing, it is better to find out before rather than after....
_________________
______________
Help the gentoo-java project. Visit Gentoo Java Project
what good are admin powers if you don't abuse them for personal gain - mark_alec |
|
| Back to top |
|
|
Dagger
Retired Dev
Joined: 11 Jun 2003
Posts: 765
Location: UK
|
| Posted: Mon Aug 11, 2008 12:32 pm Post subject: |
|
|
There is a great power in the overlays. The overlay status is a bit unclear in gentoo community. They aren't officially supported by gentoo, but they are listed in the layman (official gentoo tool). Many devs are bitching about them, and ebuild requests on bugzilla are closed with "in overlay" response.
There are plenty of great ebuilds there, and quite a few not that good ones. It would be really great if we could have a few devs who would constantly check the status of the overlays and import more and more ebuilds to the official portage tree. If the ebuild is not "good enough" for the official tree, they could give some hints to the author what needs to be corrected before it can be included. The same really comes to bugzilla. There are plenty of bugs fixed there just waiting to be included as well as plenty of new ebuilds.
If we can change the attitude - "we will do everything by ourselves" - to have official experienced developers more like a mentors, who are willing to accept other people's work and give an advice when they feel ebuilds are not up to the gentoo standards, we wouldn't have a situations like we do now. Users are angry because they expect gentoo to be bleeding edge distro and some ebuilds hit the tree very late (much later than in other distros), and devs are complaining they don't have manpower to support everything. We need more cooperation between devs and community.
_________________
95% of all computer errors occur between chair and keyboard (TM)
Join the FSF as an Associate Member!
Post under CC license. |
|
| Back to top |
|
|
AllenJB
Veteran
Joined: 02 Sep 2005
Posts: 1285
|
| Posted: Mon Aug 11, 2008 3:32 pm Post subject: |
|
|
| Dagger wrote: | There is a great power in the overlays. The overlay status is a bit unclear in gentoo community. They aren't officially supported by gentoo, but they are listed in the layman (official gentoo tool). Many devs are bitching about them, and ebuild requests on bugzilla are closed with "in overlay" response.
There are plenty of great ebuilds there, and quite a few not that good ones. It would be really great if we could have a few devs who would constantly check the status of the overlays and import more and more ebuilds to the official portage tree. If the ebuild is not "good enough" for the official tree, they could give some hints to the author what needs to be corrected before it can be included. The same really comes to bugzilla. There are plenty of bugs fixed there just waiting to be included as well as plenty of new ebuilds.
If we can change the attitude - "we will do everything by ourselves" - to have official experienced developers more like a mentors, who are willing to accept other people's work and give an advice when they feel ebuilds are not up to the gentoo standards, we wouldn't have a situations like we do now. Users are angry because they expect gentoo to be bleeding edge distro and some ebuilds hit the tree very late (much later than in other distros), and devs are complaining they don't have manpower to support everything. We need more cooperation between devs and community. |
You can't just add more packages to the official tree - there isn't the developer base there to support them. It's easy to say "just import packages", but packages in the main tree are expected to be fully tested and supported, and there just aren't enough devs for the packages already in the main tree, never mind about adding more.
I don't know where you lot get this idea that there's some "we will do everything by ourselves" attitude from - it does not exist, for the most part, in my experience.
There are already plenty of official avenues for users to help out - most devs I've talked to are only too happy to help with any queries regarding creating and modifying packages or getting involved in development generally - there's a dev-help mailing list, a dev-help irc channel (which is never very busy when I look at it) and atleast 2 official documents (dev guide and dev manual). I believe we have plenty of devs who will happily mentor users who want to get involved.
The problem, in my opinion, is that there just aren't enough users stepping up and wanting to get involved. Now is that because there aren't enough users wanting to get involved, or because there are users wanting to get involved but they don't know how to start? For fixing the latter, in addition to the suggestions already made in this thread, perhaps we need to run more "recruitment" and "getting started with development" style articles in GMN. I would consider attempting to write a couple of such articles, from a users point of view, but I just don't have the time right now and probably won't until I've finished my final year at uni.
But, my suspicion is that the reality is that there just aren't enough users who actually want / have the time to get involved with development. |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Mon Aug 11, 2008 6:00 pm Post subject: |
|
|
An umbrella problem that I am seeing from all of these posts is a signal-to-noise issue in using all of these great tools like overlays, Bugzilla, Forums, etc. A lot of noise seems to have a negative effect on the community IMHO.
- For overlays, having too many of them makes it less likely that good ebuilds are in the ones you are looking at. On the other hand, if you start putting everybody together you get Sunrise-alikes. While there is some de-facto structure in ebuild development (see alistair's post) a lot of it seems not clearly documented. I understand that every project is autonomous, but some minimal, clearly defined conventions/protocols about development are needed, again IHMO. Is this potential GLEP material?
- For Bugzilla, I agree with Dagger about most things. I think there are good ebuilds there. I do not see a problem with getting the "in overlay" response, depending on the said overlay
 . At least the ebuild was good enough to be included somewhere. After an ebuild makes it out of Bugzilla we should deal with getting it into the main tree, separately.
I think we might be able to improve Bugzilla's signal-to-noise by using one of its controversial features, voting. Instead of voting on wants/needs we could rate bugs with proposed solutions. The higher rated the bug, the better the proposed solution/ebuild.
There should also be a way to clean up Bugzilla from outdated, no longer relevant, open bugs. I do not know if that would involve joining Bug Wranglers or maybe we need Bug Cleaners (like TreeCleaners, but for Bugzilla). Users should be able to do this since as far as I see it does not break anything.
- For the forum, I have nothing new except what I posted above.
| AllenJB wrote: | | ... most devs I've talked to are only too happy to help with any queries regarding creating and modifying packages or getting involved in development generally - there's a dev-help mailing list ... |
If that is true, I may try one of the email-in methods of getting some help. By the way, the list name is gentoo-devhelp
| AllenJB wrote: | | ... perhaps we need to run more "recruitment" and "getting started with development" style articles in GMN ... |
I think articles/news that demonstrate the acceptance of user contributions are needed as well. Maybe some statistics on accepted user solutions from Bugzilla could be generated.
| yngwin wrote: | | Then there is also the possibility of proxy maintainers. That means finding a gentoo developer willing to commit your ebuilds, but you keeping up with maintenance and bugs. This should be more widely advertised. |
| Dagger wrote: | | ... have official experienced developers more like a mentors, who are willing to accept other people's work and give an advice when they feel ebuilds are not up to the gentoo standards ... |
I agree. Does something like this need its own project/overlay? |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Tue Aug 12, 2008 7:08 am Post subject: |
|
|
| node_one wrote: | | For overlays, having too many of them makes it less likely that good ebuilds are in the ones you are looking at. On the other hand, if you start putting everybody together you get Sunrise-alikes. While there is some de-facto structure in ebuild development (see alistair's post) a lot of it seems not clearly documented. I understand that every project is autonomous, but some minimal, clearly defined conventions/protocols about development are needed, again IHMO. Is this potential GLEP material? |
If you can get the GLEP editors to accept it, then it could be, though there are some things to consider before making the effort to write and submit a GLEP. One such consideration is that there is a search engine available which allows users to find packages in overlays by name.
As for protocols for determining which overlay should contain a given ebuild, it could be argued that such protocols are presently informally in place. Furthermore, trying to enforce a set of placement protocols on overlays would likely result either in such protocols being largely ignored (rendering them useless), reduced interest in maintaining overlays (thereby reducing the variety of packages available in overlays) or both.
| node_one wrote: | | I think we might be able to improve Bugzilla's signal-to-noise by using one of its controversial features, voting. Instead of voting on wants/needs we could rate bugs with proposed solutions. The higher rated the bug, the better the proposed solution/ebuild. |
Without restricting the pool of eligible voters, this would be prone to both false positives and false negatives.
| node_one wrote: | | There should also be a way to clean up Bugzilla from outdated, no longer relevant, open bugs. I do not know if that would involve joining Bug Wranglers or maybe we need Bug Cleaners (like TreeCleaners, but for Bugzilla). Users should be able to do this since as far as I see it does not break anything. |
One way in which such a project could potentially break things, at least in the logical sense, is that bugs could be improperly considered to be outdated and thus invalid. |
|
| Back to top |
|
|
Dagger
Retired Dev
Joined: 11 Jun 2003
Posts: 765
Location: UK
|
| Posted: Tue Aug 12, 2008 8:54 am Post subject: |
|
|
| AllenJB wrote: |
You can't just add more packages to the official tree - there isn't the developer base there to support them. It's easy to say "just import packages", but packages in the main tree are expected to be fully tested and supported, and there just aren't enough devs for the packages already in the main tree, never mind about adding more. |
I can fully understand that. Do you know how many people are willing to maintain 5 of their most favourite packages themselves? If we can have 1 dev (mentor) who has 10 users and each one of them maintain 5 packages, than dev can only check, test and correct ebuilds when needed.
| AllenJB wrote: |
I don't know where you lot get this idea that there's some "we will do everything by ourselves" attitude from - it does not exist, for the most part, in my experience. |
The most recent example - KDE 4.1. It's been in overlay for ages (beta/rc). It would be so much faster to go through it, clean it up, bring it up to the "official" standards that rewrite it. Because of that attitude Gentoo is probably the last distro I know, which will have it available (official way).
| AllenJB wrote: |
There are already plenty of official avenues for users to help out - most devs I've talked to are only too happy to help with any queries regarding creating and modifying packages or getting involved in development generally - there's a dev-help mailing list, a dev-help irc channel (which is never very busy when I look at it) and atleast 2 official documents (dev guide and dev manual). I believe we have plenty of devs who will happily mentor users who want to get involved. |
We've got plenty of power users who want to be devs and plenty of users who just want to maintain 5 packages they like. They send their ebuilds to bugzilla or to overlays and they stuck there, never finding it's way to the tree. And tell me how many "average" users search overlays and bugzilla for new ebuilds? Only a few. Most of them want to have it in portage tree (even hard masked or keyworded)
| AllenJB wrote: |
The problem, in my opinion, is that there just aren't enough users stepping up and wanting to get involved. Now is that because there aren't enough users wanting to get involved, or because there are users wanting to get involved but they don't know how to start? For fixing the latter, in addition to the suggestions already made in this thread, perhaps we need to run more "recruitment" and "getting started with development" style articles in GMN. I would consider attempting to write a couple of such articles, from a users point of view, but I just don't have the time right now and probably won't until I've finished my final year at uni.
|
I agree with you on "don't know how to start" part. Gentoo doesn't have "WE NEED YOUR HELP" banner on the main website. Check out fedora's website. On the main site you got a link JOIN FEDORA
| http://fedoraproject.org/en/join-fedora wrote: |
If you want to take an active hand in making Fedora even better, there are many ways to help. What role do you want to fill?
Click on a role below to learn more about how you can help the Fedora Project.
|
I think Gentoo could use that too. You don't need to be programmer or sys admin to help the project.
| AllenJB wrote: | | But, my suspicion is that the reality is that there just aren't enough users who actually want / have the time to get involved with development. |
You would be surprised.
I think threads like this will raise the awareness that more devs-users communication and cooperation is needed.
_________________
95% of all computer errors occur between chair and keyboard (TM)
Join the FSF as an Associate Member!
Post under CC license. |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Tue Aug 12, 2008 12:54 pm Post subject: |
|
|
| desultory wrote: | | ... One such consideration is that there is a search engine available which allows users to find packages in overlays by name. |
On my first search I found an ebuild that was removed from portage a couple of months ago, but still shows up as available from the main tree. I think the index of the search might be out of date. This tool is also unofficial. How can I consider it when trying to decide whether a GLEP should be written?
| desultory wrote: | | As for protocols for determining which overlay should contain a given ebuild, it could be argued that such protocols are presently informally in place. Furthermore, trying to enforce a set of placement protocols on overlays would likely result either in such protocols being largely ignored (rendering them useless), reduced interest in maintaining overlays (thereby reducing the variety of packages available in overlays) or both. |
So what I understand from this is that unless ebuilds are in the main tree, overlays should remain a free-for-all, anything goes extensions of the main tree. You are saying that any formal, published, development plan/strategy/coordination is unnecessary and may even impede development? Maybe I am unclear in what I am trying to say? 
| desultory wrote: | | Without restricting the pool of eligible voters, this would be prone to both false positives and false negatives. |
No, this idea is far from perfect, but without any feature requests there is a chance to make some good use of the voting feature. This seems like it has to be user-initiated anyways.
| Dagger wrote: | | ... Do you know how many people are willing to maintain 5 of their most favorite packages themselves? ... |
We need to find out how many. But everything else is valid.
| Dagger wrote: | | ... And tell me how many "average" users search overlays and Bugzilla for new ebuilds? Only a few. ... |
There are no numbers for Bugzilla, yet, but there are some numbers for overlays. The question is not formulated exactly like that, but it should be close enough.
| Dagger wrote: | | Check out fedora's website. On the main site you got a link JOIN FEDORA |
That is well put together. 
| Dagger wrote: | | AllenJB wrote: | | But, my suspicion is that the reality is that there just aren't enough users who actually want / have the time to get involved with development. |
You would be surprised. |
I cannot really disagree with AllenJB. There are not a lot of us in this thread and I do not know if/how we can mine Bugzilla to get some numbers on user contributions from there.  However nothing definite can be said. Likely there are MANY users who simply are not aware that this thread exists. |
|
| Back to top |
|
|
AllenJB
Veteran
Joined: 02 Sep 2005
Posts: 1285
|
| Posted: Tue Aug 12, 2008 1:44 pm Post subject: |
|
|
| Will people please stop pointing to KDE 4.1 as an example. I know it's a hot issue currently, but it's also an extreme example. KDE is probably one of the largest sets of packages in the tree. Seriously, if it's so easy to just take the packages from the overlay and clean them up and use them as a basis for KDE packages for the next who knows how many years, why haven't YOU done it already? |
|
| Back to top |
|
|
cctsurf
Tux's lil' helper
Joined: 12 Oct 2006
Posts: 123
|
| Posted: Tue Aug 12, 2008 5:10 pm Post subject: |
|
|
| AllenJB wrote: | | Will people please stop pointing to KDE 4.1 as an example. I know it's a hot issue currently, but it's also an extreme example. KDE is probably one of the largest sets of packages in the tree. Seriously, if it's so easy to just take the packages from the overlay and clean them up and use them as a basis for KDE packages for the next who knows how many years, why haven't YOU done it already? |
I'm sorry, but I have to disagree, kde 4.1 may be the straw that broke the camel's back (or the match that illuminated the 900 pound gorilla)... but enough with the clichés. I think it is something that is important to look at.
We have a STABLE desktop environment (which I am using just fine with an overlay) that is not in the official tree. Those of us who use KVM fought for months to get it into the tree, but there were VERY usable packages available in overlays. We have a new init system, which is keyworded, as it well should be, because I still haven't figured out what advantages it has... and I've personally put 5 or 6 ebuilds on bugs.gentoo.org which haven't seen the light of day. We have a replacement for portage -- paludis -- in the main tree causing a split in the labors of developers...
I smell a rat... oops. sorry, another cliché.
So how about putting some of the working central ebuilds from overlays into hard masked, especially when there isn't a package in sight for the official tree. I mean, that's how they are going to arrive (hard masked) anyway, isn't it? How about a method that those ebuilds which are being heavily used could be pushed to the front of the line (I mean we have records of how often a package is requested/downloaded from the servers, don't we?)
I guess I'm just frusterated, I really love Gentoo, if I didn't, I'd probably already have switched distros. I want to help, I know I'm not up to ebuilds for kde, but obviously other people are, and maybe I can help in other ways. Cut down the standards for hard-masked, or even keyword masked ebuilds. Use that as a filter to get good ebuilds to the tree. Let in some of the overlay maintainers as devs, and allow some of us who have the desire to help to help.
Thanks to all
cctsurf |
|
| Back to top |
|
|
AllenJB
Veteran
Joined: 02 Sep 2005
Posts: 1285
|
| Posted: Tue Aug 12, 2008 9:14 pm Post subject: |
|
|
If you want to help, start talking to the developers and reading the documentation. Find out what needs to be done to get the packages you want in the tree up to scratch. You sit here and complain about the problems, but what are you doing to fix them?
No voting system is going to work without the manpower. No slacking of standards is going to work without the manpower. (And in my opinion a slacking of standard would do more to work against Gentoo than for it).
Ebuild and eclass development is not hard. It's bash scripting - you need only a basic grasp of programming to work on ebuilds. You can learn most of what you need from working through the bash guides in my first post in this thread.
Don't be afraid of getting things wrong - that's how you learn. Don't be afraid to ask the developers for help - they want it.
Submitting a couple of ebuilds you created because you wanted the packages on your system is easy. I can do that in my sleep. Stepping up to do some actual, unpaid work is a bigger step. |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Wed Aug 13, 2008 8:08 am Post subject: |
|
|
| node_one wrote: | | On my first search I found an ebuild that was removed from portage a couple of months ago, but still shows up as available from the main tree. I think the index of the search might be out of date. This tool is also unofficial. How can I consider it when trying to decide whether a GLEP should be written? |
It is unofficial, I had not implied otherwise, but it is an available working system which, if kept up to date in regards to the package database, would address some of the concerns you had raised. It might be worth contacting the author regarding outdated packages being presented on the site.
| node_one wrote: | | So what I understand from this is that unless ebuilds are in the main tree, overlays should remain a free-for-all, anything goes extensions of the main tree. |
Overlays should be allowed to include whatever the maintainer of the packages in that overlay has any interest in, experimental overlays and those with arbitrary scope are useful and trying to enforce categorization of every overlay would impede such uses. The overhead would vary by overlay and in some cases would likely be minor but why add obstacles which need not exist?
| node_one wrote: | | You are saying that any formal, published, development plan/strategy/coordination is unnecessary and may even impede development? |
Yes. Not all overlays are intended to have a formal mission statement, trying to force all overlays to have a formal acceptance and rejection policy or an explicitly defined scope would be counterproductive. Having a voluntary system to register the scope and define policies of an overlay might be worth doing, but unless it is voluntary it will almost certainly be more trouble than it is worth especially for smaller or less formal overlays. As such, extensions to layman could well suit your purposes.
| node_one wrote: | | No, this idea is far from perfect, but without any feature requests there is a chance to make some good use of the voting feature. This seems like it has to be user-initiated anyways. |
Voting in the bug tracker is certainly user driven, as it is the user who votes, though you should be aware that some developers specifically ignore votes on bugs.
| node_one wrote: | | We need to find out how many. But everything else is valid. |
You could try polling, once you have some data you could present that to the developers. If you can find users who are willing and able to maintain packages which are presently maintainer-needed, you will probably find that there are developers willing to proxy for those maintainers. |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Wed Aug 13, 2008 3:15 pm Post subject: |
|
|
| cctsurf wrote: | | I guess I'm just frusterated, I really love Gentoo, if I didn't, I'd probably already have switched distros. |
I am not as "frustrated." I am new to Gentoo and have not experienced any of the extensive flame-wars I keep reading about. Hopefully, I will not.
| desultory wrote: | | It is unofficial, I had not implied otherwise, ... contacting the author regarding outdated packages being presented on the site. |
That was clear to me. I was simply curious about official/unofficial status and the implications of that on any possible GLEP. I am curious why the people who created that search make it unofficial instead of trying to expand http://packages.gentoo.org. I am sure there are valid reasons for that. Anyway, I may contact them.
Actually, this brings up an interesting point. Some of these unofficial solutions are quite good, yet the only place they can advertise their efforts seems to be the forum and mailing lists. Maybe PR should shed some light on them without officially backing them up (in a GMN?). I understand that can be politically complicated.
| desultory wrote: | Overlays should be allowed to include whatever ... The overhead would vary by overlay and in some cases would likely be minor but why add obstacles which need not exist?
...
Yes. Not all overlays are intended to have a formal mission statement, trying to force ... As such, extensions to layman could well suit your purposes. |
Package choice is package choice, no question there. I am mainly concerned with issues like:
- Proper masking/keywording
- Overriding by overlays
- Namespace discrepancies across the many overlays out there
- Eclass issues
- "The path to the main tree" unless there are plans for that (main tree) to fracture in the future
- Proper retirement of ebuilds to "junk" overlays so some may be resurrected if so desired. Maybe a Sunset counterpart to Sunrise.
- Possibly others that I am not remembering
All of this is voluntary; the overlay maintainers would volunteer to be in compliance with some established standard, for lack of a better word, or part of an overall development plan. In addition, there should be a way to define some kind of friend overlays or something similar. For example "experimental/developer overlay A" is friends with "testing overlay B" and "testing overlay B" friends with "production/project overlay C" or the main tree or something like that. Just a simplified way to look at collaborative relationships. I think something like this would be helpful and would complement an overlay search engine for example.
Portage and layman improvements could definitely help in some cases and I am not saying that these tools are not great already. I can imagine something like "layman -L project", "layman -L developer", "layman -L upstream" , "layman -L third-party", but someone still has to write the XML on the other end and define these classes/categories.
| desultory wrote: | | Voting in the bug tracker is certainly user driven, as it is the user who votes, though you should be aware that some developers specifically ignore votes on bugs. |
I am hoping there are users out there who can change their (developer's) minds, but I understand it may be futile.
| desultory wrote: | | You could try polling, ... you will probably find that there are developers willing to proxy for those maintainers. |
I will try to see if I can get a show of hands on the user's side. Someone with more experience could do this better. Now, you only mentioned maintainer-needed, what about those maintainer-wanted packages? I understand maintainer-needed are a priority. |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Wed Aug 13, 2008 6:51 pm Post subject: |
|
|
I saw this well written document today and I am now reassured that what I have been suggesting is not unreasonable. I am going to quote the beginning...
| Quote: | | The purpose of this document is to help developers (and their managers) work with the development community with a minimum of frustration. It is an attempt to document how this community works in a way which is accessible to those who are not intimately familiar with Linux kernel development (or, indeed, free software development in general). While there is some technical material here, this is very much a process-oriented discussion which does not require a deep knowledge of kernel programming to understand. |
If the Linux Foundation thinks such a document is important maybe Gentoo should consider creating something like this. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Aug 14, 2008 5:57 am Post subject: |
|
|
| node_one wrote: | | maybe Gentoo should consider creating something like this. |
++ |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Thu Aug 14, 2008 8:32 am Post subject: |
|
|
This post is intended to make note of potential concerns which might need to be addressed in attempting to implement the ideas being discussed, not to discourage their development.
| node_one wrote: | | Actually, this brings up an interesting point. Some of these unofficial solutions are quite good, yet the only place they can advertise their efforts seems to be the forum and mailing lists. Maybe PR should shed some light on them without officially backing them up (in a GMN?). I understand that can be politically complicated. |
The editors of the newsletter regularly solicit articles, you could try submitting one.
| node_one wrote: | | Proper masking/keywording |
There is presently no general mechanism to accept or reject packages based on the overlay from which they originate, though this has been discussed previously on the gentoo-dev mailing list.
| node_one wrote: | | Overriding by overlays |
This can be either a bug or a deliberate layout for testing purposes.
| node_one wrote: | | Namespace discrepancies across the many overlays out there |
Have you found any sets of overlays which provide the same package in multiple categories or under multiple names? Either way, generating a list of collisions between overlays available via layman would not be difficult.
| node_one wrote: | | Eclass issues |
As with specific package versions being overlain, this can be either a bug or a deliberate layout for testing purposes.
| node_one wrote: | | "The path to the main tree" unless there are plans for that (main tree) to fracture in the future |
Some overlays deliberately have no defined path to inclusion in the tree, others range from testing prior to inclusion through to it might be included given certain conditions are satisfied in the tree or given sufficient interest.
| node_one wrote: | | Proper retirement of ebuilds to "junk" overlays so some may be resurrected if so desired. Maybe a Sunset counterpart to Sunrise. |
There was some discussion of such an overlay, though nothing appears to have been implemented.
| node_one wrote: | | In addition, there should be a way to define some kind of friend overlays or something similar. For example "experimental/developer overlay A" is friends with "testing overlay B" and "testing overlay B" friends with "production/project overlay C" or the main tree or something like that. Just a simplified way to look at collaborative relationships. |
Perhaps more useful would be a listing of overlays which are known to not function well together.
| node_one wrote: | | Portage and layman improvements could definitely help in some cases and I am not saying that these tools are not great already. I can imagine something like "layman -L project", "layman -L developer", "layman -L upstream" , "layman -L third-party", but someone still has to write the XML on the other end and define these classes/categories. |
Inter-overlay dependencies are also a subject which has been discussed previously without any implementation having been produced.
| node_one wrote: | | Now, you only mentioned maintainer-needed, what about those maintainer-wanted packages? I understand maintainer-needed are a priority. |
That is largely the reason to target maintainer-needed packages before targeting maintainer-wanted packages. They have greater priority due to actually being in the tree hence there is greater interest in having a maintainer for them, as such it should be less difficult to find someone willing to act as a proxy for the maintainer. |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Thu Aug 14, 2008 2:01 pm Post subject: |
|
|
Thanks desultory,
I am only going to reply to a few of these. I think there has been enough discussion and now it is time to do something, at least I plan to.
| desultory wrote: | | The editors of the newsletter regularly solicit articles, you could try submitting one. |
Writing is not one one my well-developed skills, plus I did not make those tools; I would be a bad candidate to write about them. I will see what happens with GMN this month and maybe some of my sub-standard writing might make it to the editors.
| desultory wrote: | | ... generating a list of collisions between overlays available via layman would not be difficult. <and other layman related stuff> |
I probably can look at layman. I do not know anything about it, what it is written in etc. I will see if there is something I can do. If someone wants to colab, there is PM and this thread.
| desultory wrote: | | node_one wrote: | | Proper retirement of ebuilds to "junk" overlays so some may be resurrected if so desired. Maybe a Sunset counterpart to Sunrise. |
There was some discussion of such an overlay, though nothing appears to have been implemented. |
This is something I cannot do, even if I wanted to. I do not have the capabilities. I would love to see a Sunset (the overlay ), which I can check for discarded ebuilds that I, or others, may want to resurrect. I recently pulled the 2007.0 release snapshot so I can look at some removals. So any work between that snapshot and the actual removal appears to be lost. Along these lines, if you want to have a more aggressive policy on dumping maintainer-needed ebuilds from the main tree, maybe put them in Sunset or an overlay of their own. Sunrise already has maintainer-wanted covered, at least to some extent.
| desultory wrote: | | That is largely the reason to target maintainer-needed packages before targeting maintainer-wanted packages. |
When I am crawling Bugzilla, I try to focus on maintainer needed.
Finally, I have not forgotten about proxy maintainership. At least a poll or something will be up very soon.
steveL, thanks for backing me up. |
|
| Back to top |
|
|
zyko
l33t
Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany
|
| Posted: Tue Aug 19, 2008 11:59 am Post subject: |
|
|
There are two points that I don't like about the way things work in Gentoo (and that discourage me from getting too involved). Remember, this is only my personal, subjective point of view. I'll keep it short:
1. Communication and information flow is too difficult and time consuming. Gentoo's organisation is too complex. There are way too many separate pathways of communication (mailing lists, bugs, irc channels, blogs). I can't keep up with all that stuff without sacrificing inappropriate amounts of time.
2. Apart from that, communication within the Gentoo project is also very inefficient at times. Discussions often get tangled up in pointless conflict. Faulty arguing strategies seem to be deeply rooted in Gentoo's culture.
I could think of some suggestions to ameliorate #1, but that's for the people in the Gentoo project to work out. #2 is a challenge... |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Tue Aug 19, 2008 7:50 pm Post subject: |
|
|
| zyko wrote: | | ... 1. Communication and information flow is too difficult and time consuming. ... |
I agree. I find it difficult to follow what is going on as well. But there is not much I can do about it. [1] [2] I cannot code fixes for these.
| zyko wrote: | | ... Gentoo's organisation is too complex. There are way too many separate pathways of communication (mailing lists, bugs, irc channels, blogs). I can't keep up with all that stuff without sacrificing inappropriate amounts of time. ... |
Separate channels are good, if information flows on all of them consistently and simultaneously. I am sure I am missing tons of stuff not following all of them.
| zyko wrote: | | ... I could think of some suggestions to ameliorate #1, but that's for the people in the Gentoo project to work out. #2 is a challenge... |
Gentoo is a community project; at least that is what everyone keeps saying. If you do not contribute your suggestions I do not see how any progress can be made. |
|
| Back to top |
|
|
zyko
l33t
Joined: 01 Jun 2008
Posts: 620
Location: Munich, Germany
|
| Posted: Wed Aug 20, 2008 9:26 am Post subject: |
|
|
| node_one wrote: | | zyko wrote: | | ... I could think of some suggestions to ameliorate #1, but that's for the people in the Gentoo project to work out. #2 is a challenge... |
Gentoo is a community project; at least that is what everyone keeps saying. If you do not contribute your suggestions I do not see how any progress can be made. |
I'm unfit to contribute any sensible suggestions for #1, since I'm sure there are many (technical) considerations to take into account that I (as a user without insight into the inner circles) am unaware of.
/edit: Duh! Strike that, I overlooked the obvious. There is a way of keeping users somewhat informed about what goes on in the Gentoo world: Someone who keeps track with Gentoo's development could write summaries and publish them on gentoo.org's front page. I've heard rumors of other websites doing things like that. 
There's always at least "somewhat" interesting stuff going on, like a hot new package coming out (portage, openrc, gcc,...) or something like that. It would spice up the rather inactive front page and keep the userbase up to date.
The GMN already does a good job in this specific area, however it only seems to reports on the big stuff (like decisions made by the Council).
Before someone reminds me that Gentoo's a community project and asks why I don't volunteer: I'll try to come up with something and find a dev who's willing and able to post it. |
|
| Back to top |
|
|
AllenJB
Veteran
Joined: 02 Sep 2005
Posts: 1285
|
| Posted: Wed Aug 20, 2008 11:10 pm Post subject: |
|
|
A though I head while reading the Proxy Maintainers thread, which expands on what I've already said I think:
I think in many areas there's a communication deadlock between users and developers. The developers are waiting for the users to come to them, but the users don't know who to talk to about anything. I decided to do a google search for "gentoo proxy maintain" and randomly came across this page on antarus' dev space. The page appears to have some excellent content, but it's 2 years old and kept in a developers own webspace. I currently have no idea whether this is linked from the main gentoo.org website or not - I suspect not.
Personally I think there should be much more documentation like this for users to read about things - it should also take load off of developers who do a lot of explaining to users who do start to become interested in development work.
The security project have an excellect padawans page. While most projects work isn't as clear cut as this, I do think that there's room for some similar form of documentation on other aspects - or even some thorough documentation on levels / methods of contributing with necessarily becoming a full developer. I think at the moment, in many users minds, there's a rather large gulf between "user" and "full developer" and they haven't got a clue what comes inbetween. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
