[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
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
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, 8 Mar 2006, Karyn Ritter wrote: > Would something like the table I've just created at > http://www.opensolaris.org/os/bug_reports/oss_bite_size/ help? I need to > work out the answers to many additional questions surrounding this table > -- the least of which is how often I can reasonably update the table -- > soon, but wanted to get some early feedback on it. > The table is a much nicer way of looking at the bite sized bug list and can make a big impact on getting someone involved. As an outsider, the status column is the only thing that looks confusing to me. Just make sure it is clear what kind of status is open for a community member to work on. Bill rushmores.net
[request-sponsor] Re: [osol-discuss] Contributing Code
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? [1] http://www.perl.com/pub/a/2003/01/22/mechanize.html [2] http://htmlunit.sourceforge.net/ [2] http://wwwsearch.sourceforge.net/mechanize/ -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
[request-sponsor] CR 6368816: closed by integration of Intel ACPI CA update
Rob Benson reported CR 6368816, an issue in the Intel-maintained ACPI CA source. I forwarded the report to Bob Moore at Intel, and a subsequent release of ACPI CA source incorporates the suggested changes. CR 6368816 itself is technically a duplicate of CR 6354619 - update to the 20060217 release of Intel ACPI CA source, and has been closed as such. It was an oversight to not mention Rob in the putback email. However, Rob Benson deserves credit for reporting this issue, which has now been fixed for not only Solaris, but all Intel ACPI CA clients (FreeBSD, Linux and MacOS). Thanks - Dana
[request-sponsor] Re: [osol-discuss] Contributing Code
I'll figure out where to put the definitions. This the real status that is in Bugster, so we need to document it anyway Thanks, Karyn Bill Rushmore wrote: > > On Wed, 8 Mar 2006, Karyn Ritter wrote: > > >>Would something like the table I've just created at >>http://www.opensolaris.org/os/bug_reports/oss_bite_size/ help? I need to >>work out the answers to many additional questions surrounding this table >>-- the least of which is how often I can reasonably update the table -- >>soon, but wanted to get some early feedback on it. >> > > > The table is a much nicer way of looking at the bite sized bug list and > can make a big impact on getting someone involved. As an outsider, the > status column is the only thing that looks confusing to me. Just make > sure it is clear what kind of status is open for a community member to > work on. > > Bill > rushmores.net > ___ > opensolaris-discuss mailing list > opensolaris-discuss at opensolaris.org
[request-sponsor] Re: [osol-discuss] 1 new request-sponsor putback: 39 total
[Apologies if this has already been responded to... I'm catching up.] The code for bugs.opensolaris.org (and bugs.sun.com) are not sophisticated enough to be able to do this. The application we use currently shares the same code base as bugs.sun.com. Because Suggested Fix often contains code that isn't open sourced (at least for the Java bugs), this is not a field they ever want displayed. We could (potentially) do this if we split the code base, but that is a *significant* amount of work that we don't have the resources for right now. We're definitely still investigating having this done by the group that owns the application, but we're also focusing on the next-generation bug tracking functionality to address all of our needs. - Karyn Valerie Anne Bubb wrote: > On Thu, 2 Mar 2006, Artem Kachitchkine wrote: > >> >>> How would it determine which bugs those fields can be exported for? >>> We can't do it for all bugs, since some contain source which cannot >>> be disclosed publically. >> >> >> It's not an unsolvable problem. E.g. there could be a special field >> accessible only from Sun, that the sponsor would set. >> > > Why can't we just export the Suggested Fix field we have > internally? These are all oss-bitesize bugs, so the code is > out there already. (I know we can't present Suggested Fix > for *all* bugs). > > Valerie
[request-sponsor] Re: [osol-discuss] Contributing Code
Bill, Bill Rushmore wrote: > 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. > We've definitely been kicking around some ideas about making more oss-bite-size bugs available and providing better/clearer information about them on the site. Would something like the table I've just created at http://www.opensolaris.org/os/bug_reports/oss_bite_size/ help? I need to work out the answers to many additional questions surrounding this table -- the least of which is how often I can reasonably update the table -- soon, but wanted to get some early feedback on it. As we've already discussed, there are a number of features that are part of bugs.opensolaris.org that we want to change. In the meantime, I'd like to workaround some of them for oss-bite-size. Please provide comments ideas about this and other ways we can help make the community code contribution process better. Thanks, Karyn
