Hi, great stuff here - 2010/12/28 Tatu Lahtela <[email protected]>: > Hi all, > > This email will be long so bear with me.. > <snip> > The biggest problems were visibility and the lack of information on my part. > Ignorance can be cured, as long as the information exists and you can find > it. I'll list some of the questions a new package maintainer will have. Some > of them have an answer in wiki, some of them don't. > > - Does my package belong in Trunk? Should it be in community OBS? Maybe > somewhere else (e.g. a test package)? Is there a difference in The Process > between the places? Will e.g. licensing make a difference? > - I don't have an account. How do I get one? > - I'm submitting a new package. I don't have my own Bugzilla entry. Do I > need one? If so, where and how do I get one? > - I'm submitting a new package. I need to create the Feature request. How do > I do that? What is the component/subcomponent I should use? How do I know > that I made it correctly,if for example the feature request just sits there > for weeks? > - I'm updating an upstream package to a new version. Do I need to create a > new bug or feature request? Does the feature request go under my package > Bugzilla entry or somewhere under the "MeeGo Features..."? > - I need a devel project before I can submit anything into Trunk. How do I > need a new one or do I use some existing one? > - Before I make the request, how do I make the package is compliant and all > the bug/featurezilla flags are right? Is there a way to (automatically) > verify this before bugging the maintainers? > - How do I actually submit a package request? > - How do I track what happens to the submit request? > > And this list doesn't have questions about the packaging itself (the > required commands, common problems etc..), Maybe someone else can list those > ;) I think we should try to gather this kind of information into a "step by > step" type of page that the maintainer can follow. >
I think the best thing you can do is to help create a skeleton wiki page or perhaps help make http://wiki.meego.com/Release_Engineering/Submission_Checklist more visible. Me and Sivan bounced around an idea for a quick start guide for MeeGo development for platform hackers, maybe this kind of page would be useful in such one? I mean, we're not going to get any lower on the level of incoming people needing to hack on MeeGo any time soon. Input for making training material, really :) BR Carsten Munk _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
