[gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
Hello After seeing: https://bugs.gentoo.org/show_bug.cgi?id=440214 Looking to a lot of its blockers shows that we are using "elog" messages for informing people about configuration (like pointing people to external links to get proper way of configuring things, tell them to add to some system groups...). I thought that maybe this kind of information could be simply included in a canonical file under /usr/share/doc/ package dir called, for example, CONFIGURATION or SETUP. We would them point people (now with a news item, for the long term provably a note to handbook to newcomers would be nice) to that file to configure their setups. The main advantages I see: - We will flood less summary.log ;) - The information to configure the package is always present while package is installed, now, if we remove merge produced logs, people will need to reemerge the package or read directly the ebuild What do you think? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
Quoting Pacho Ramos (2012-12-22 10:26:40) > I thought that maybe this kind of information could be simply included > in a canonical file under /usr/share/doc/ package dir called, for > example, CONFIGURATION or SETUP. > > What do you think? At last! +100 -- Amadeusz Żołnowski signature.asc Description: signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing
On 2012.12.21 23:57, Greg KH wrote: > On Fri, Dec 21, 2012 at 12:01:00AM -0500, Rich Freeman wrote: > > On Thu, Dec 20, 2012 at 11:08 PM, Greg KH > wrote: > > > On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote: > > >> 1. Are you party to any *copyright assignment* (eg FSF copyright > assignment)? > > > > > > You need to rephrase this to be (in order for it to make any > sense): > > > Are you party to any *copyright assignment* that is not part of > your > > > employment agreement? > > > > > > Otherwise, everyone in the US, and most other countries, would > almost > > > always have to just say "yes" to this, as their employer owns the > > > copyright for their work no matter what it is done on (open > source > or > > > not.) > > > > Work done for hire is certainly owned by the employer, unless an > > agreement to the contrary is explicitly documented, but employment > > agreements that purport to assign copyright for works unrelated to > > employment to the employer are rare. Maybe they're not as rare in > the > > software industry, but most people aren't employed in the software > > industry (even if most Gentoo developers might be - though perhaps > not > > as a big a majority as you might expect). > > > > Certainly I haven't signed any kind of document that assigns > ownership > > of works created on my own time to my employer, and the legality of > > any contract I did sign to that effect would be dubious. > > That's not true in the US, in fact, it's the exact opposite. Your > employer has ownership of all of your work, even done on your own > time, > unless you explicitly have permission otherwise, if it is done in an > industry that is related to your employer. Read the traditional US > employment agreement for details about this. > > Yes, some states allow for exceptions to this rule, but those are the > exceptions (California has some unique changes here). > > You might have signed these types of agreements when you were hired > by > a > company, and didn't realize it, it's usually quite well hidden in the > agreement. > > Now this is all for the US, Europe has other types of laws, but they > still assign ownership/copyright of what you do while being paid by > those companies, to the company, and not to you. Again, there are > exceptions, but traditionally that is how they work. > > > > Remember, in the US, individuals who actually own the copyright > on > the > > > work they do is quite rare once they get out of college, and even > then, > > > while in college, the school does have the right to assert > copyright > > > ownership of the work, depending on what it was done on/for (who > > > provided the equipment, tasks, etc.) > > [snip] This is typical for the UK too. My present employer regards my role in the Gentoo Foundation as 'employment'. I had to show that there was no conflict of interests before I took up my paid job. General UK employment contracts go much further than copyright and normally extend to any and all inventions created by the employee, including inventions made in their own time with their own resources. > > thanks, > > greg k-h > > -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpom4yRBTmZ3.pgp Description: PGP signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Sat, 2012-12-22 at 10:26 +0100, Pacho Ramos wrote: > Hello > > After seeing: > https://bugs.gentoo.org/show_bug.cgi?id=440214 > > Looking to a lot of its blockers shows that we are using "elog" messages > for informing people about configuration (like pointing people to > external links to get proper way of configuring things, tell them to add > to some system groups...). I thought that maybe this kind of information > could be simply included in a canonical file under /usr/share/doc/ > package dir called, for example, CONFIGURATION or SETUP. We would them > point people (now with a news item, for the long term provably a note to > handbook to newcomers would be nice) to that file to configure their > setups. The main advantages I see: > - We will flood less summary.log ;) > - The information to configure the package is always present while > package is installed, now, if we remove merge produced logs, people will > need to reemerge the package or read directly the ebuild > > What do you think? I think that sounds like a perfectly acceptable solution for many of those. For layman, I ended up moving those elog messages to a layman-updater script (needed for something else) which was capable of knowing what messages were relevant to display. I run that layman-updater script in pkg_postinst(). -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Is /var/cache the right place for repositories?
On 12/20/2012 07:14 PM, Ciaran McCreesh wrote: > The tree is a database. It belongs in /var/db/. > That's a good point. lu
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 22 December 2012 09:26, Pacho Ramos wrote: > Hello > > After seeing: > https://bugs.gentoo.org/show_bug.cgi?id=440214 > > Looking to a lot of its blockers shows that we are using "elog" messages > for informing people about configuration (like pointing people to > external links to get proper way of configuring things, tell them to add > to some system groups...). I thought that maybe this kind of information > could be simply included in a canonical file under /usr/share/doc/ > package dir called, for example, CONFIGURATION or SETUP. We would them > point people (now with a news item, for the long term provably a note to > handbook to newcomers would be nice) to that file to configure their > setups. The main advantages I see: > - We will flood less summary.log ;) > - The information to configure the package is always present while > package is installed, now, if we remove merge produced logs, people will > need to reemerge the package or read directly the ebuild > > What do you think? Correct me if I am wrong but are you suggesting we drop the elog messages altogether? I still believe that having the elog messages at the end of an 'emerge -uDN world' is more convenient. Maybe it makes sense to have both, as in print the elog messages and create those CONFIGURATION or SETUP files at the same time. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 12/22/2012 01:46 PM, Markos Chandras wrote: > On 22 December 2012 09:26, Pacho Ramos wrote: >> Hello >> >> After seeing: >> https://bugs.gentoo.org/show_bug.cgi?id=440214 >> >> Looking to a lot of its blockers shows that we are using "elog" messages >> for informing people about configuration (like pointing people to >> external links to get proper way of configuring things, tell them to add >> to some system groups...). I thought that maybe this kind of information >> could be simply included in a canonical file under /usr/share/doc/ >> package dir called, for example, CONFIGURATION or SETUP. We would them >> point people (now with a news item, for the long term provably a note to >> handbook to newcomers would be nice) to that file to configure their >> setups. The main advantages I see: >> - We will flood less summary.log ;) >> - The information to configure the package is always present while >> package is installed, now, if we remove merge produced logs, people will >> need to reemerge the package or read directly the ebuild >> >> What do you think? > > Correct me if I am wrong but are you suggesting we drop the elog > messages altogether? I still believe that having the elog messages > at the end of an 'emerge -uDN world' is more convenient. Maybe it > makes sense to have both, as in print the elog messages and > create those CONFIGURATION or SETUP files at the same time. As a compromise, you could have the ebuild trigger the elog message only when there is not a previous version of the package installed. -- Thanks, Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 22 December 2012 21:53, Zac Medico wrote: > On 12/22/2012 01:46 PM, Markos Chandras wrote: >> On 22 December 2012 09:26, Pacho Ramos wrote: >>> Hello >>> >>> After seeing: >>> https://bugs.gentoo.org/show_bug.cgi?id=440214 >>> >>> Looking to a lot of its blockers shows that we are using "elog" messages >>> for informing people about configuration (like pointing people to >>> external links to get proper way of configuring things, tell them to add >>> to some system groups...). I thought that maybe this kind of information >>> could be simply included in a canonical file under /usr/share/doc/ >>> package dir called, for example, CONFIGURATION or SETUP. We would them >>> point people (now with a news item, for the long term provably a note to >>> handbook to newcomers would be nice) to that file to configure their >>> setups. The main advantages I see: >>> - We will flood less summary.log ;) >>> - The information to configure the package is always present while >>> package is installed, now, if we remove merge produced logs, people will >>> need to reemerge the package or read directly the ebuild >>> >>> What do you think? >> >> Correct me if I am wrong but are you suggesting we drop the elog >> messages altogether? I still believe that having the elog messages >> at the end of an 'emerge -uDN world' is more convenient. Maybe it >> makes sense to have both, as in print the elog messages and >> create those CONFIGURATION or SETUP files at the same time. > > As a compromise, you could have the ebuild trigger the elog message only > when there is not a previous version of the package installed. > -- > Thanks, > Zac > Well yeah, plus the elog messages are logged in /var/log/portage/elog so duplicating them in /usr/share/doc/$PF/SETUP does not make much sense to me :/ -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Time based retirements
On Fri, Dec 21, 2012 at 7:05 PM, Markos Chandras wrote: > > Finally, I am very proud with the work we are doing, especially Pacho > who has been doing most of the work lately. We have managed to "free" > many many packages and this was one of the reasons I formed the > proxy-maintainers project, so that non-dev contributors could step up > and take care of all these packages that inactive devs left > unattended. > I see "free" as "dump a lot of orthogonally related packages on to the herd that is listed but really the other herd members aren't interested in those packages. So over time we go from a herd that had decent number of semi-active developers that handled a large swath of the packages to only a handful of active devs who are only interested in a select few packages with no support for all those other packages. Because the result was you could prod the semi-active guys about the packages they maintained and they would fix something or they'd give you feedback on something you might do to test it. Once they're retired, the magical list of person X has knowledge of Y goes away (metadata.xml). If you're curious if I'm speaking about a specific herd, I am. It's media-tv. IMHO, if you're really after finding others to take care of packages that appear abandoned then you should contact the inactive people to see if there's any packages they'd be ok with giving up to the proxy-maintainers project or to another developer, but don't retire them. The reason I say ask them about packages is that they might appear to be inactive because they really are only maintaining one or two packages that infrequently get any activity, but when they package gets activity they jump on it and fix it right away. I know that was the case for me when I was busy with RL things for a while. But there were a number of packages my employer paid me to maintain and I did. All the other packages that had my name on them I just didn't have the time. If the goal here really is to ensure well maintained packages then retiring people is akin to treating a screw like a nail and banging it in with a hammer, wrong tool... wrong job. For some packages you may find another developer right away with interest to fix it, or a proxy maintainer but in some cases you might have just kicked the only person who had any inclination to fix the package. Some packages have 50 users and 49 of them are Gentoo developers or would step up and become Gentoo developers to fix the package should it become unmaintained and that's great. But some packages have 200 users and 1 person willing to be the developer to maintain it. You retire that person and you might have well just told those 200 people to pick a different distro because inevitably their package will be treecleaned. If you need a concrete example of a package, that would be MythTV. I've been hoping for the day that someone becomes a Gentoo developer with the goal of maintaining MythTV for nearly a decade but it hasn't happened. If I stop touching it, it languishes and I get e-mails and bugs, etc. I tell everyone they are more than welcome to maintain it and 99% of the time nothing comes of it, and 1% of the time someone does 1 bump for me and nothing more again. Regarding my use of the words "brain dead", notice I never said "Markos is brain dead". What I said was the policy of retiring people when what you really want is an active maintainer of packages is brain dead. Now I understand that you're involved with the enforcement of that policy and therefore identify with it, but I would have to encourage you to separate yourself from a policy. I unfortunately feel after reading all the comments in this whole thread that my original statement is still true. Well that felt like a Duncan e-mail so its time to wrap it up. -- Doug Goldstein
