We have a team bug-stomping scheduled for this coming weekend -- Saturday March 6, core hours from 1500-2100 UTC (that's 10:00am to 4:00pm US/Eastern). We can certainly move beyond those core hours depending on people's energy and availability.
I didn't see any notes on the list earlier about an approach to take, so here's my suggestion for how to prioritize our work. Feel free to suggest tweaks or different approaches, but let's have it settled before we start working on Saturday.
Priority list:
1. Triage bugs marked as NEW
2. Attack each ancient ASSIGNED bug (with a number less than 500000)
a. Decide what to do with the bug
b. Either close or note fix in the bug report
3. Attack each EasyFix bug, assigning in round-robin form
These bugs are marked with the "EasyFix" keyword and you don't need to be highly skilled to fix them.[1]
4. Attack each Release notes bug similarly.
One final note -- I have to take my daughter to skate lessons which start at 9:45am on Saturday morning. I will *try* to be online via my 3G phone, but connections are shoddy from the skate rink and it will be difficult for me to do anything substantial. I can be online by about 11:30am Eastern.
To wit... it would help any new folks if we have a "Step 0," a 15-20 minute introduction to using Bugzilla, and how to use it effectively. However, I can't do that instruction myself if I'm not there! :-) If anyone's up for doing it Friday night, I can make that happen.
On Thu, 2010-03-04 at 10:05 -0500, Paul W. Frields wrote:
We have a team bug-stomping scheduled for this coming weekend --
In working with some new contributors, I was noticing that we have very few sponsors on some of the guides. We might want to either make sure quaid is available (I think he is on most of them), or perhaps assign some sponsors ahead of time to make things go a little easier.
I will try to look through the bugs and see where we might have some holes, but I have a pretty full dance card these next couple days so I'm not so sure I'll get to it. If someone else wants to take that on I would appreciate it.
I guess all we really need is someone who can commit to the guides where there are a lot of bugs, but it would be helpful if we had someone who could add commiters where appropriate.
Or maybe Paul as the grand poobah has super privs on all the docs and it won't be a problem.
--McD
On Thu, Mar 04, 2010 at 10:20:35AM -0500, John J. McDonough wrote:
On Thu, 2010-03-04 at 10:05 -0500, Paul W. Frields wrote:
We have a team bug-stomping scheduled for this coming weekend --
In working with some new contributors, I was noticing that we have very few sponsors on some of the guides. We might want to either make sure quaid is available (I think he is on most of them), or perhaps assign some sponsors ahead of time to make things go a little easier.
I will try to look through the bugs and see where we might have some holes, but I have a pretty full dance card these next couple days so I'm not so sure I'll get to it. If someone else wants to take that on I would appreciate it.
I guess all we really need is someone who can commit to the guides where there are a lot of bugs, but it would be helpful if we had someone who could add commiters where appropriate.
So how many of the guides are using git? From my look at fedorahosted.org, it's the majority. That's good because git makes it dead-simple to make fixes, generate a patch, and then email it to the list where it can be used.
There are some good setup hints for git here: https://fedoraproject.org/wiki/Git_Quickref
By the way, for people using Subversion repos, there is a git-svn utility that allows you to use a good portion of git coolness with these legacy style repositories.
So at worst, without access people can still make their fixes, and send them to this list for inclusion by the owners.
Or maybe Paul as the grand poobah has super privs on all the docs and it won't be a problem.
Well... I do have admin access on the FAS that allows me to arbitrarily assign group access levels but it's frowned upon to use that as a substitute for sponsorship from within the group itself. It might look like I'm tampering with the will of the group owners, even if the intentions are good. :-)
It would be best if guide owners could make sure they have several sponsors in addition to themselves who can grant user access.
On Thu, 2010-03-04 at 10:52 -0500, Paul W. Frields wrote:
So how many of the guides are using git? From my look at fedorahosted.org, it's the majority. That's good because git makes it dead-simple to make fixes, generate a patch, and then email it to the list where it can be used.
I do believe that is correct, and I was aware of being able to generate patches. That is really good from the standpoint of a new contributor who would likely be a little squeamish about making changes directly to the repo.
However, if the guide owner isn't around and we queue up a bunch of patches, it could get pretty messy. But then, I suppose that serves as penance for not being available :-)
There are some good setup hints for git here: https://fedoraproject.org/wiki/Git_Quickref
Everybody should put a shortcut to that in their browser, but I do have mixed feelings about it. There is a lot to git, but for 99% of the things you do, that page goes into way more detail than you need, even though it probably only covers 10% of what you might do.
It would be best if guide owners could make sure they have several sponsors in addition to themselves who can grant user access.
Absolutely it would, and not just for this weekend. I think it is good practice to have some backup.
--McD
On Thu, Mar 04, 2010 at 11:04:04AM -0500, John J. McDonough wrote:
On Thu, 2010-03-04 at 10:52 -0500, Paul W. Frields wrote:
So how many of the guides are using git? From my look at fedorahosted.org, it's the majority. That's good because git makes it dead-simple to make fixes, generate a patch, and then email it to the list where it can be used.
I do believe that is correct, and I was aware of being able to generate patches. That is really good from the standpoint of a new contributor who would likely be a little squeamish about making changes directly to the repo.
However, if the guide owner isn't around and we queue up a bunch of patches, it could get pretty messy. But then, I suppose that serves as penance for not being available :-)
There are some good setup hints for git here: https://fedoraproject.org/wiki/Git_Quickref
Everybody should put a shortcut to that in their browser, but I do have mixed feelings about it. There is a lot to git, but for 99% of the things you do, that page goes into way more detail than you need, even though it probably only covers 10% of what you might do.
Yeah, I think you're right. I looked mostly at the setup hints at the top, but there are probably other choices one could make about what people need to know. Maybe we should adopt and fix that page. :-)
The basic information that a newbie needs to know to install and configure git, clone a repository, and make/send a patch are the most important things to show at the top, IMHO. Everything else can be shown in escalating degrees of difficulty below.
It would be best if guide owners could make sure they have several sponsors in addition to themselves who can grant user access.
Absolutely it would, and not just for this weekend. I think it is good practice to have some backup.
On Thu, 2010-03-04 at 16:01 +0000, Nathan Thomas wrote:
However, I'm having problems pushing directly to the git repo: I keep getting the error message 'fatal: The remote end hung up unexpectedly'.
Nathan
There seem to be a hundred ways to get that message, but one popular one is to have done your initial clone with git:// instead of ssh://
You can tweak your .git/config by making sure you have:
[remote "origin"] url = ssh://fedorahosted.org/git/docs ... rest of the path
--McD
On Thu, Mar 04, 2010 at 06:10:00PM +0000, Nathan Thomas wrote:
Thanks for the reply - you were right about the git:// vs. ssh:// thing, but even after fixing that I still get a 'Permission denied (publickey)' error. My page on admin.fedoraproject.org lists my User Guide Git Commit Group status as 'approved'. I'm happy to continue submitting patches by email, as suggested by Paul - should I send them to the docs list?
Have you uploaded your RSA-type SSH key (~/.ssh/id-rsa.pub) to your Fedora account, through https://admin.fedoraproject.org/accounts/user/edit ?
As for the second question, I think that would be fine. I hope the User Guide maintainer agrees; I expect it wouldn't be a problem.
On Thu, Mar 04, 2010 at 04:01:54PM +0000, Nathan Thomas wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/03/10 15:05, Paul W. Frields wrote:
We have a team bug-stomping
scheduled for this coming weekend --
Unfortunately I'm not around this weekend, but I'm up for more bug-squashing, so send me some left-overs if there are any! I'm particularly interested in the User Guide, I've already submitted one or two patches for this (thanks to Rudi's kind help) and would like to do more.
However, I'm having problems pushing directly to the git repo: I keep getting the error message 'fatal: The remote end hung up unexpectedly'. I've uploaded my public SSH key to my Fedora Account, I've been granted access to the User Guide git repository by Karsten, and I've downloaded a client side certificate and saved it as ~/.fedora.cert. I'm new to remote git, and I'm not sure what I'm doing wrong! Any ideas?
Have a good weekend!
Two ideas come to mind:
1. If you're having problems, feel free to use 'git format-patch' and 'git send-email' to mail patches directly here.
2. When you cloned the repository originally, did you use the 'ssh://' method? If not, or if you're unsure, look at the .git/config file in your local copy, and you can edit the url for the remote 'origin' there.
-
John J. McDonough -
Nathan Thomas -
Paul W. Frields