On 01/03/2011 07:35 AM, ext Carsten Munk wrote:
2010/12/28 Tatu Lahtela<[email protected]>:
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.
I didn't make/edit these into the wiki, because I wasn't sure where all
that would fit in in the overall flow of things. For example, let's say
you you want to submit a new package for Meego. Google drops you here:
http://meego.com/about/contribution-guidelines . If I had started from
meego.com I probably wouldn't have found it, as I would've assumed it
would be under the developers page.. Anyway, you need an answer to a few
of those pretty much right away, e.g. accounts, where your package
belongs to, the fact your new package is called "a feature" etc..
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 :)
Something like a quick start guide would be good. Once the community
developers start creating packages in full force, we will be overwhelmed
with questions like this if they're not documented in an easy to follow
fashion. Especially the differences in The Process between "platform
package" and "community package" should be crystal clear starting from
page 1 (meego.com)
Cheers,
--
Tatu
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
