[request-sponsor] Re: [osol-discuss] Contributing Code
On Wed 08 Mar 2006 at 11:42AM, Dan Price wrote:
On Wed 08 Mar 2006 at 10:49AM, Karyn Ritter wrote:
I'll figure out where to put the definitions. This the real status that
is in Bugster, so we need to document it anyway
So, I wonder if we could use Perl's WWW::Mechanize [1] or something
equivalent to automate the updating of pages. Then, Karyn, we could
write you something which would gather up this info and post it
every 2 hours, or whatever.
Maybe we could have a Java package [2] (as well as any other languages
[3]) that manipulates the website as well-- I personally don't like the
endless CPAN machinations one must go through to get a useful perl.
So this is a fun and challenging project for someone. Any takers?
Nobody ever takes my challenges :(
Anyway, I've completed a prototype of a tool which can do this; for
those interested, it is attached below. You'll need WWW::Mechanize and
either IO::Socket::SSL or Crypt::SSLeay installed, available from
CPAN.
Here's how to use it:
$ cat ~/.osauth
my_opensolaris_username my_opensolaris_password
^D
$ chmod 600 ~/.osauth
$ ./bender.pl
./bender.pl: you must specify -u url
Usage: ./bender.pl [-v] -u url -f filename -x authfile
- Authfile should contain one line with your
OpenSolaris.org username and password.
- Note that you must have permission to edit
the page you are updating, and it must exist already.
$ date | ./bender.pl -u community/zones/moop -f - -x ~/.osauth -v
Get file contents...ok
Get authentication info...ok
Visit http://www.opensolaris.org/os/...ok
Click 'Sign in'...ok
Click 'Login'...ok
Visit http://www.opensolaris.org/os/community/zones/moop ...ok
Open edit...ok
Complete edit...Done.
n.b., for those at Sun, I can't get this to work through the corporate
web proxies (and would love help to do so). You can use a machine with a
transparent proxy, though, and it'll work fine. 'webhop.sfbay' is available
for this purpose upon request (to me). Note also that the script tries
to respect the $http_proxy, etc. environment variables, so you may
need to clear those.
Happy cronjob-ing.
-dp
--
#!/bin/perl
#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License (the License).
# You may not use this file except in compliance with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# or http://www.opensolaris.org/os/licensing.
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
# If applicable, add the following below this CDDL HEADER, with the
# fields enclosed by brackets [] replaced with your own identifying
# information: Portions Copyright [] [name of copyright owner]
#
# CDDL HEADER END
#
#
# Copyright 2006 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident %Z%%M% %I% %E% SMI
use LWP::UserAgent;
#use LWP::Debug qw(+);
use WWW::Mechanize;
use Getopt::Std;
my $verbose;
$| = 1;
sub vprint(@) {
my (@msg) = @_;
return if (!$verbose);
print @msg if (@msg);
}
sub usage(@) {
my (@msg) = @_;
print $0: @msg\n if (@msg);
print Usage: $0 [-v] -u url -f filename -x authfile\n;
print \t- Authfile should contain one line with your\n;
print \t OpenSolaris.org username and password.\n;
print \t- Note that you must have permission to edit\n;
print \t the page you are updating, and it must exist already.\n;
exit 2;
}
$starturl = 'http://www.opensolaris.org/os/';
getopts('vf:u:x:');
usage(you must specify -u url) unless defined($opt_u);
usage(you must specify -f filename) unless defined($opt_f);
usage(you must specify -x authfile) unless defined($opt_x);
$myurl = $opt_u;
$myfile = $opt_f;
$myauth = $opt_x;
if (defined($opt_v)) { $verbose = 1; }
vprint(Get file contents...);
$buffer = ;
open CONTENTS, $myfile or die could not open $myfile;
while (CONTENTS) {
$buffer .= $_;
}
vprint(ok\n);
vprint(Get authentication info...);
$username = ;
$passwd = ;
open CONTENTS, $myauth or die could not open $myauth;
($username, $passwd) = split( , CONTENTS);
vprint(ok\n);
#
# Log ourselves in.
#
$mech = WWW::Mechanize-new();
$mech-env_proxy();
vprint(Visit $starturl...);
$mech-get($starturl);
die Can't get $starturl: , $mech-response-status_line
unless $mech-success;
vprint(ok\n);
vprint(Click 'Sign in'...);
$mech-follow_link(text = Sign in);
die Can't follow sign in link: , $mech-response-status_line
unless $mech-success;
vprint(ok\n);
vprint(Click 'Login'...);
$mech-submit_form(
[request-sponsor] Re: [osol-discuss] Contributing Code
On 3/8/06, Karyn Ritter Karyn.Ritter at sun.com wrote: snip Would something like the table I've just created at http://www.opensolaris.org/os/bug_reports/oss_bite_size/ help? I need to Very nice view of what is out there. Please provide comments ideas about this and other ways we can help make the community code contribution process better. My initial reactions are: 1) Presumably a responsible engineer means that something is happening. This should probably be made clear that the ones that are not being worked are those without a responsible engineer. Also, if there is some correlation between this and the status column, that would be good to know. 2) A column saying which community member(s) are working on it may be nice. 3) Ability to filter - a person wanting to learn about smf may want to filter just on SMF bugs. So far I have tried to work on a couple different items but by the time that I hit request-sponsor (each time less than a day after starting work on the bug/rfe) I have found that someone within Sun was already working on what I had taken up. Generally, the things that I will pick up will be a weekend passtime when an immediate response on request-sponsor is least likely. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
[request-sponsor] Re: [osol-discuss] Contributing Code
On Mon, Mar 06, 2006 at 02:40:39PM -0700, Sanjay Nadkarni wrote: I will back this up from the request sponser POV. In my case an RPE engineer had already fixed the bug and putback into Nevada. However we don't require people to update the fixed in bugster. People have suggested that we make this mandatory, rather than optional. Another suggestion is to have the gate do it automatically -- I can do this pretty trivially, if people feel it would be useful (in whatever context -- inside or outside Sun). The fixed, committed and integrated fields get updated only when the build closes. So during that 2 week period one has to grep through the putback list to figure out which is really non optimal. Furthermore the comment from the same engieer was that they don't have any visibility if any one from the community is working on a bug. So adding that info would be nice. I would suggest, though, that keying off the status field to find out whether it's useful to be working on a particular bug is not particularly accurate. I believe that it would be more accurate to use the presence of a responsible engineer to know whether it's being worked on (because what you *really* want to know, I think, is that a bug is being worked on, not that it's finished). Of course, the RE field may not be available outside. If not, perhaps the presence of a value there could be indicated. Regardless, I'm happy to make the change I mentioned above. Danek
[request-sponsor] Re: [osol-discuss] Contributing Code
On Wed, Mar 08, 2006 at 03:06:46PM -0800, Danek Duvall wrote: On Mon, Mar 06, 2006 at 02:40:39PM -0700, Sanjay Nadkarni wrote: I will back this up from the request sponser POV. In my case an RPE engineer had already fixed the bug and putback into Nevada. However we don't require people to update the fixed in bugster. People have suggested that we make this mandatory, rather than optional. Another suggestion is to have the gate do it automatically -- I can do this pretty trivially, if people feel it would be useful (in whatever context -- inside or outside Sun). And you could mark them Fix Failed if they got backed out. I personally think this would be a good thing to do. - jonathan -- Jonathan Adams, Solaris Kernel Development
[request-sponsor] Re: [osol-discuss] Contributing Code
Danek Duvall wrote: On Mon, Mar 06, 2006 at 02:40:39PM -0700, Sanjay Nadkarni wrote: I will back this up from the request sponser POV. In my case an RPE engineer had already fixed the bug and putback into Nevada. However we don't require people to update the fixed in bugster. People have suggested that we make this mandatory, rather than optional. Another suggestion is to have the gate do it automatically -- I can do this pretty trivially, if people feel it would be useful (in whatever context -- inside or outside Sun). I'd just as soon you did it automatically. The fixed, committed and integrated fields get updated only when the build closes. So during that 2 week period one has to grep through the putback list to figure out which is really non optimal. Furthermore the comment from the same engieer was that they don't have any visibility if any one from the community is working on a bug. So adding that info would be nice. I would suggest, though, that keying off the status field to find out whether it's useful to be working on a particular bug is not particularly accurate. I believe that it would be more accurate to use the presence of a responsible engineer to know whether it's being worked on (because what you *really* want to know, I think, is that a bug is being worked on, not that it's finished). Of course, the RE field may not be available outside. If not, perhaps the presence of a value there could be indicated. Though there's the problem that bugs occasionally get parked on RE's who aren't actively working on them (guilty, your honor). Dave
[request-sponsor] Re: [osol-discuss] Contributing Code
Alan Coopersmith wrote: James Carlson wrote: Having engineers rather than gatekeepers marking bugs as integrated, as Alan describes for non-ON gates, seems broken to me. Well, it is admittedly for gates with no gatekeepers. When you have a fraction of the developers ON does, you get by with a fraction of theoverhead too. I manage a consolidation with a total of 2 developers. Even with this size the gatekeeper role is intact. I would suggest the wording be explicitly stated for the gatekeeper. Then describe the role the gatekeeper conducts as part of the product release process. Although not staffed with a specific gatekeeper, the consolidation I work on leaves the integrated status change to the one conducting the gatekeeper role at product release time. Joel. -- next part -- A non-text attachment was scrubbed... Name: Joel.Buckley.vcf Type: text/x-vcard Size: 348 bytes Desc: Card for Joel Buckley Joel.Buckley at Sun.COM URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20060307/74ff00b8/attachment.vcf
[request-sponsor] Re: [osol-discuss] Contributing Code
Joel Buckley wrote: I manage a consolidation with a total of 2 developers. Even with this size the gatekeeper role is intact. I would suggest the wording be explicitly stated for the gatekeeper. Then describe the role the gatekeeper conducts as part of the product release process. Perhaps that would help - since none of the Desktop consolidations I've worked with have ever used the gatekeeper term, my knowledge is third hand from hearing ON people talk about what theirs does. We have release engineers who do the biweekly builds, deliver them to QA, and then to the WOS integration dock, but that's the closest equivalent to what I'm aware of the gatekeeper doing. They are also a permanent, full time job, not one of the development engineers who rotate in for each release, and work on all releases (right now, that's Solaris 8, 9, 10, Nevada), not just one release. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[request-sponsor] Re: [osol-discuss] Contributing Code
On Mon, 6 Mar 2006, Jim Grisanzio wrote: * For those who are thinking about contributing code, what can we do to help you get started? Would more oss-bite-size bugs help? More oss-bite-size would be nice. I also have a couple of suggestions for the bug list. One is to make sure the bug status is accurate. I worked on a bite size bug only to find after I submited it that it is was already taken care of. I would also like to see a way to search on bugs by skill needed since the code base is so large and diverse. For example, I would like to work on Java stuff since that is my background and I certainly wouldn't mind working on things like smc, etc. Bill rushmores.net
[request-sponsor] Re: [osol-discuss] Contributing Code
On Mon, Mar 06, 2006 at 02:47:26PM -0800, Alan Coopersmith wrote: That seems broken, but I suppose that's my non-ON point of view, coming from consolidations where the engineer marks the bug fix available when they submit the fix for code review and integrated when they putback to the master gate. Perhaps ON needs to reconsider how it uses the fields. (Of course, having the bugs.o.o website show Fix in progress for anything from Bug filed, but being ignored to Fixed but not yet integrated makes this doubly hard for external contributors.) The ON integration message tells you to optionally mark your bugs Fix Available as soon as you putback. The gatekeepers mark them Fix Delivered when the build is closed. So if the first part of that became mandatory, confusion over open bugs would be substantially reduced. -- Keith M Wesolowski Sir, we're surrounded! Solaris Kernel Team Excellent; we can attack in any direction!
[request-sponsor] Re: [osol-discuss] Contributing Code
Sanjay ... we don't require people to update the fixed in bugster. The Sanjay fixed, committed and integrated fields get updated only when the build Sanjay closes. Alan That seems broken, but I suppose that's my non-ON point of view, coming Alan from consolidations where the engineer marks the bug fix available Alan when they submit the fix for code review and integrated when they Alan putback to the master gate. Perhaps ON needs to reconsider how it Alan uses the fields... I disagree, and suggest that your usage does not match the terms; part of the reason ON works the way it does w/rt these fields is to match the terms. In particular, the term fix available corresponds to putback: the point at which the fix is available to anyone who cares to bring over from the gate w/s. Engineers are allowed to mark a bug fix available immediately after putback. The term integrated is old; the new term is fix delivered, but it does not correspond to when a putback occurs; rather, it corresponds to when the new packages have been delivered to the WOS. -- John
