Talk:Http://fedoraproject.org/wiki/Eclipse How to Maintain Fedora Package User Guide

From FedoraProject

1 Creating a Bugzilla Account
2 Creating Review Request
3 Ready to Ship and Updating the SCM
4 Minor nits

Creating a Bugzilla Account

Not sure why this is there. If you are referring to Red Hat specific things, we should probably omit this.

Do not use your @fedoraproject.org address in bugzilla, because you will not get your bugzilla privileges once you are sponsored.
If you want to use your @fedoraproject.org address, you might try to request at the Fedora Infrastructure Ticket System for an administrator to manually override the bugzilla address connected with your fedora account.

I actually referred to this link: http://fedoraproject.org/wiki/PackageMaintainers/Join#Create_a_Bugzilla_Account , so do you think it's better to take it out?
--mziaei

Let's leave that for Andrew and Alex to decide. --jerboaa

I say let's drop these statements. I don't want to duplicate information that's posted elsewhere; let's just link to canonical sources where possible. --overholt

Creating Review Request

We should probably consider providing instructions as to how to do that using the eclipse-mylyn-tasks-bugzilla

In an ideal world, we could pre-fill things like bug title, etc. similar as the bugzilla-link does. Here is the user guide for setting this up: Eclipse/MylynRedHatBugzillaSetupGuide. More info as to how to create a bug, etc. is in the Mylyn user guide --jerboaa

So are you saying to add this as a part of this user guide? I mean having a part on working with mylyn..bugzilla? or we should just put a link? --mziaei

No, not really how to use Mylyn with Bugzilla, but how to do the required steps using Mylyn. I.e. set the flag from within Eclipse using Mylyn, adding the comment, etc. All this Bugzilla interaction should be possible using Mylyn instead of using the Browser. Most users may not know that's possible. --jerboaa

Prepared this temp page for now: mylyn-bugzilla, if this is close to first step for it..--mziaei

Ready to Ship and Updating the SCM

May also be applicable to providing Mylyn instructions. I.e. set the flag using Mylyn, providing the comment (TODO: Provide a template/link maybe, which fills things in already?)--jerboaa

Minor nits

the flowchart is nice but the branch to bugzilla/koji is a bit confusing ... also, rpmbuild output of binary RPMs doesn't go to koji. Try making it a flowchart just for new packagers so it's like Upstream -> Your .spec -> bugzilla (loop back for iterations of review) -> git -> koji (optional -> bodhi)

-- flowchart is updated -- mziaei1

it looks good! -- overholt

"Some features included in the Eclipse Fedora Packager are" -> "Some feature in Eclipse Fedora Packager are"
"RPM-spec-file" -> "RPM .spec file"
"changelog" -> "%changelog"
"<Ctrl>+<Alt>+C" -> "<Ctrl>+<Alt>+c"
"spec-file" -> ".spec file" (everywhere)
"source RPM files" -> "source RPMs"
"Execute local builds" -> "Perform local builds"
make "EGit documentation" a link to the EGit user guide (http://wiki.eclipse.org/EGit/User_Guide)
s/Bohdi/Bodhi in the flowchart
"If you haven't packaged software for Fedora before this guide will lead you through your first package submission." -> "If you haven't previously packaged software for Fedora, this guide will lead you through your first package submission.
"on Fedora Account System" -> "in Fedora Account System" (more than one occurrence)
"have required FAS certificates" -> "have the required FAS certificates"
Why is there a question mark at the end of "The following explains how to set up those ..."?
drop the "simply" in "Then run the following command and simply follow the instructions provided:"
"a RPM package" -> "an RPM package" (more than one occurrence)
make "package-review@..." be a link to the mailman page for that list
"Follow the following steps" -> "Perform the following steps"
"(e.g. for Perl and/or Java packages)" -> "(e.g. for Perl or Java packages)"
don't duplicate the "Joining the mailing lists" content if it's available elsewhere on the wiki

-- joining the Possible Fedora Mailing Lists -- mziaei1 (is this what you meant?)

-- https://fedoraproject.org/wiki/PackageMaintainers/Join#Join_the_important_Mailing_Lists is what I meant overholt

"Upload your SRPM and SPEC files" -> "Upload your SRPM and .spec files"
does the EGit import wizard offer a filesystem location in which one can clone? If so, the blurb on checking out into a "git" directory could probably be fleshed out a bit more.

-- Yes, it offers a filesystem location, but I'm not sure if I'm following you here. I'm actually not getting what you mean by blurb and flesh? Sorry, but too many expressions for me :) -- mziaei1

-- I just mean add some text stating that users can put their clones wherever they'd like since a top-level "git" directory is a personal choice -- overholt

"in the Eclipse project one switched to branch" -> not sure what this means

-- "For example, files for release Fedora 13 correspond to files present in the Eclipse project, once switched to branch f13/master" -- mziaei1 (do you think it's fine now?)

-- Yes, that's good -- User:overholt

"<CTRL>+<ALT>+C" -> "<CTRL>+<ALT>+c" (and not italics; more than one occurrence)
mention how to set the ChangeLog preferences in Eclipse
expand on "auto-completes localling installed packages"
"currently checked out" -> "currently checked-out"
is it "Prepare for local build" or "Prepare Sources for Build" like the screenshot shows?
"chroot'ed environment" -> "chroot environment"
"right-click on the spec-file Fedora Packager" -> "right-click on the .spec file and select Fedora Packager"
"Output of the RPM build will appear" -> "Output of the RPM build process will appear"
"Using mock-builds is a great way to test the Requires/BuildRequires" -> "Using mock to build your package is a great way to verify that you have the correct BuildRequires" (since Requires are used at installation time and mock just _builds_ the package)
"mock-build" -> "mock build" (more than one occurrence)
don't give a time estimate for a mock build since package build times vary
"he changes are ready to be pushed (or published) publicly when the locally committed changes are satisfying" -> "When you are satisfied with your locally-committed changes, you are read to publish them publicly"
the sentence about re-writing history is out of place without more information about rebase, etc.

-- Isn't it talking about this making mistake in commits? if it's about making mistakes, do you think this change to the sentence would make sense? "Remember, if you made any mistake in your commits, Git allows history to be rewritten before changes are made public by clicking on Team > Reset." mziaei1

-- It's easiest to just avoid talking specifically about rebases or resets. I think it's fine the way it is now (I made a small change) -- User:overholt

"To bring the local repository in sync with origin:" <-- this is the first time "origin" is used so we should either use "the Fedora repository" or define it

-- To bring the local repository in sync with remote repository (which is by default called origin): -- mziaei1

"Select the Git repository to be pushed to" -> "Select the Git repository to which you would like to push"
the instructions and the instructions with screenshots seem to duplicate themselves
the first sentence under "Pushing a Build to Koji" seems unnecessary
"right-clicking the spec-file =>" -> "right-clicking the .spec file and selecting"
"This should be enough information to track the builds." -> "If you click on this URL, a browser tab will open in Eclipse showing you the contents of the koji status page. Refresh it as you like to follow build progress."
between the two Bodhi steps, you should mention the need to have changes for that release committed and pushed on the corresponding branch

-- Here is new version for this. -- mziaei1