On Tue, 12 May 2009 11:08:29 +0200 Grammostola Rosea <rosea.grammost...@gmail.com> wrote:
> > And understanding what it means and why it is there is usually - > > and in this case, too - as simple as *reading* the output of > > "lintian -i", thinking about it a bit, then reading what people > > with similar issues have said and done on the -mentors list, > > and sometimes examining a couple of packages that are already in > > Debian to see how they deal with it. > > > > In this particular case, just reading the additional information > > that Lintian displays ought to be enough to understand it :) Exactly. > But I can't understand all those messages yet and I'm not gonna read > hundreds of difficult to read manual pages with at least 200 pages each.. You do need to read all the existing documentation and that includes a lot more than just 200 pages. If there is a single manpage with more than 200 screens, by all means let us know but you are exaggerating the workload. Every maintainer has had to read all that documentation, every DD has to read (and update) a whole load more. It is part of the role and you do just have to read it and get to understand it. There are no shortcuts. You are going to have to read all the manpages - this list is not a substitute for reading the documentation. > I hope this doesn't seem harsh ;) But in my experience, it works the > best at start to ask experienced people and learn bit by bit how things > work. That only works when the questions are not those already answered in the manpages. The "experienced people" on this list are busy and have other tasks to do, you have to put in the effort at your end and show that you can do something to help yourself. Being a maintainer for a package means doing the work yourself and that work involves reading and understanding the documentation already provided. The list can help clarify issues or fix problems but you must understand the basic documentation and be willing to read up on the issues yourself. You have to put in the time. > At first the manpages are mostly 'acadabra' but picking up some > bits from others will help you to be able to quickly understand the more > sophisticated issues. In my experience, when people tell me how to do it > and I succeeded once, I don't have to ask it again how it works (like > the install file thing). After a while I see other people do things > different and then I can ask and investigate why... Yet with the install file, it took many answers before you understood it - how much of that was because you hadn't read the documentation or taken enough time to understand it first? Do test builds of packages, work out what works and what doesn't, download source packages, fiddle about and see what breaks then read the manpages to work out why it broke - you should be doing all of that yourself, in your own time and off your own initiative. How do you propose to fix bugs if you don't understand how to test packages, identify problems and read manpages to look up the correct solution? > If you want to read all the different things at start at once, packaging > for Debian will cost you a fulltime job and that would in many cases not > be good. You need to read and understand all the existing documentation - there is no getting away from that. It isn't a full time job, don't exaggerate it. Reading the documentation is not optional. Read the New Maintainer Guide, the Developer Reference and Policy. Read the manpages for debhelper commands. You initially had problems understanding what CDBS was doing, to solve that problem you need to fully understand the debhelper manpages - all of them. CDBS relies heavily on such understanding - if you don't use CDBS, you still have to understand all the debhelper commands that your package uses - there really is no escape from reading and understanding *all* the relevant manpages. If you genuinely have problems understanding the documentation, fine, build some test packages for that particular problem, look up packages that have probably already solved those issues and work out how they do it yourself. If you still have issues, then post to the list with information on the section at issue, what you've done to try and work out what is going on and what is going wrong. Using syntax like "debian/$package.install" is commonplace and you need to become familiar with such substitution patterns. You need to understand concepts like that to be able to debug the package as well as the packaging. > I think the help is good on this list. thanks for that. But I don't > think 'read the manpages of that, that and that package' is a very > productive way to learn things. Manpages and other documentation has to be the foundation of all things discussed on the list. Asking repeated questions that are already answered in the relevant manpage is just going to frustrate those trying to help you. After a while, people will simply stop helping you. > It's like reading all the manuals for > the electric apparatus in your house... you wouldn't have time to work > on Debian if you did that... Then why should I trust that you can do a good enough job as a maintainer to consider sponsoring you? How can I be sure that you'll be able to fix bugs in the package if you refuse to read the manpages for the commands used in the package? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpXlbGK3rxOT.pgp
Description: PGP signature
