You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kathey Marsden <km...@sbcglobal.net> on 2005/08/27 20:00:09 UTC
Bugs and 10.1.2 release
We are beginning to accumulate quite a bug backlog. There is a filter
available on Jira that shows the current open bug backlog, "Derby open
code bugs". Currently there are 108 bugs.
In order to avoid the mad dash at 10.2 release time and to make fixes
available to users, I was thinking it would be good to plan for a 10.1.2
release.
Here are my thoughts for developers...
1) Pick a bug and fix it.
Developers, look at the bug backlog and pick a bug
you would like to fix and fix it in the *trunk*.
2) Submit your patch for the trunk.
Indicate if you would like the fix to go into the 10.1 branch.
(Risky code changes or behavior change best stay in the trunk).
3) Merge the change to 10.1
After you patch has been committed, if no one has objected
to the patch going into 10.1, test your change on the 10.1 branch,
and submit either
a) the svn command to integrate your change to 10.1
b) a 10.1 patch if the merge was not automatic.
4) Repeat 1-3 many times.
5) Release.
Have a vote for release in October or potentially sooner if
we get a large number of fixes in the branch or there is a
show stopper along the way.
Related items:
I would send a mail to derby-user to encourage folks to start voting
for issues that they would like fixed. This will help us prioritize the
bugs we want to fix.
It would be great if we had more folks reviewing patches. Ideally
fixes will have already been through one review by another developer
before a committer looks at it.
Thoughts ?
Kathey
Re: Bugs and 10.1.2 release
Posted by Francois Orsini <fr...@gmail.com>.
I was wondering the same thing and wanted to know if there was any
kind of published plan or content thoughts for the next "major"
release (10.2)...I understand that due to the nature of the community,
it does make sense to release a "major" numbered release when
sufficient and significant features have been checked-in - this is one
approach which probably lead to a 6-month release cycle for "major"
releases...versus 2-3 months for the minor ones...
Thanks,
--francois
On 8/29/05, Rick Hillegas <Ri...@sun.com> wrote:
> Hi Kathey,
>
> This sounds like a reasonable plan. By the way, what happened to the
> discussions about having a regular release schedule? Sounds like you're
> targetting October for releasing 10.1.2. Do we have a release date for
> 10.2? Here are two possibilities:
>
> Scenario 1:
>
> October '05: Release 10.1.2
> January '06: Release 10.2
>
> Scenario 2:
>
> October '05: Release 10.1.2
> January '06: Release 10.1.3
> April '06: Release 10.2
>
> Cheers,
> -Rick
>
>
> Kathey Marsden wrote:
>
> >We are beginning to accumulate quite a bug backlog. There is a filter
> >available on Jira that shows the current open bug backlog, "Derby open
> >code bugs". Currently there are 108 bugs.
> >
> >In order to avoid the mad dash at 10.2 release time and to make fixes
> >available to users, I was thinking it would be good to plan for a 10.1.2
> >release.
> >
> >Here are my thoughts for developers...
> >
> > 1) Pick a bug and fix it.
> > Developers, look at the bug backlog and pick a bug
> > you would like to fix and fix it in the *trunk*.
> >
> > 2) Submit your patch for the trunk.
> > Indicate if you would like the fix to go into the 10.1 branch.
> > (Risky code changes or behavior change best stay in the trunk).
> >
> > 3) Merge the change to 10.1
> > After you patch has been committed, if no one has objected
> > to the patch going into 10.1, test your change on the 10.1 branch,
> >and submit either
> > a) the svn command to integrate your change to 10.1
> > b) a 10.1 patch if the merge was not automatic.
> >
> > 4) Repeat 1-3 many times.
> >
> > 5) Release.
> > Have a vote for release in October or potentially sooner if
> > we get a large number of fixes in the branch or there is a
> > show stopper along the way.
> >
> >Related items:
> >I would send a mail to derby-user to encourage folks to start voting
> >for issues that they would like fixed. This will help us prioritize the
> >bugs we want to fix.
> >
> > It would be great if we had more folks reviewing patches. Ideally
> >fixes will have already been through one review by another developer
> >before a committer looks at it.
> >
> >Thoughts ?
> >
> >
> >Kathey
> >
> >
> >
> >
>
>
Re: Bugs and 10.1.2 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
>
> This sounds like a reasonable plan. By the way, what happened to the
> discussions about having a regular release schedule?
I proposed October because it seemed like a reasonable amount of time to
get some bugs fixed.
I think in general anyone can propose a release at any time. If there
is consensus that there should be a release, someone volunteers to be
release manager, folks scramble to finish up, testing and votes ensue,
and we have a release.
That said, I think your proposed schedules both sound reasonable and
healthy for the project. It will just take volunteers to manage those
releases. So far Andrew has been kind enough to carry the torch, but I
am guessing he's getting tired #:)
A couple of links of interest on the topic:
DB Guidelines - http://db.apache.org/decisions.html
Sample project guidelines http://httpd.apache.org/dev/release.html
Kathey
Re: Bugs and 10.1.2 release
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Kathey,
This sounds like a reasonable plan. By the way, what happened to the
discussions about having a regular release schedule? Sounds like you're
targetting October for releasing 10.1.2. Do we have a release date for
10.2? Here are two possibilities:
Scenario 1:
October '05: Release 10.1.2
January '06: Release 10.2
Scenario 2:
October '05: Release 10.1.2
January '06: Release 10.1.3
April '06: Release 10.2
Cheers,
-Rick
Kathey Marsden wrote:
>We are beginning to accumulate quite a bug backlog. There is a filter
>available on Jira that shows the current open bug backlog, "Derby open
>code bugs". Currently there are 108 bugs.
>
>In order to avoid the mad dash at 10.2 release time and to make fixes
>available to users, I was thinking it would be good to plan for a 10.1.2
>release.
>
>Here are my thoughts for developers...
>
> 1) Pick a bug and fix it.
> Developers, look at the bug backlog and pick a bug
> you would like to fix and fix it in the *trunk*.
>
> 2) Submit your patch for the trunk.
> Indicate if you would like the fix to go into the 10.1 branch.
> (Risky code changes or behavior change best stay in the trunk).
>
> 3) Merge the change to 10.1
> After you patch has been committed, if no one has objected
> to the patch going into 10.1, test your change on the 10.1 branch,
>and submit either
> a) the svn command to integrate your change to 10.1
> b) a 10.1 patch if the merge was not automatic.
>
> 4) Repeat 1-3 many times.
>
> 5) Release.
> Have a vote for release in October or potentially sooner if
> we get a large number of fixes in the branch or there is a
> show stopper along the way.
>
>Related items:
>I would send a mail to derby-user to encourage folks to start voting
>for issues that they would like fixed. This will help us prioritize the
>bugs we want to fix.
>
> It would be great if we had more folks reviewing patches. Ideally
>fixes will have already been through one review by another developer
>before a committer looks at it.
>
>Thoughts ?
>
>
>Kathey
>
>
>
>
Re: Bugs and 10.1.2 release
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
This all sounds good. We can call it "recommended practice" rather than
"policy" I would agree that in general we can't require anything of
anyone, but it's also true that there is some level of peer pressure
involved here -- the "meritocracy" of the Apache Way. We shouldn't be
heavy-handed, but we also need to have some level of "process" in place
so that we can regularly deliver high-quality, high-performance releases
of Derby. Right?
David
Daniel John Debrunner wrote:
>Kathey Marsden wrote:
>
>
>
>>David W. Van Couvering wrote:
>>
>>
>>
>>
>>>I am not clear how this has been done in the past: what is the process
>>>for a contributor (who is not a committer) to get their patch into the
>>>appropriate branches? Do we depend upon the version that the bug was
>>>reported in? Should the contributor indicate what branches the patch
>>>should be applied? Is the contributor responsible for testing on each
>>>branch and providing a separate patch for each branch?
>>>
>>>
>>This was the process I proposed for 10.1.2
>>
>> -- Fixer fixes bug in the *trunk*
>> -- Fixer posts a patch and indicates if if they want the fix in 10.1.
>> -- Committer commits and objections to port can be raised based on risk.
>> -- Fixer tests change on 10,1 then posts svn merge command or 10.1 patch.
>> -- Committer applies the svn merge command and commits to 10.1
>>
>>
>
>While this is a good process, it should not be seen as exclusive. Maybe
>'recommended practice' would be a better term than 'process'?
>
>A fixer may only care about fixing the bug in the trunk, it could be
>someone else who cares about the fix being in a branch and thus performs
>the merge and testing.
>
>A fixer may only care about fixing a bug in a branch, because that's the
>version they are using. There should be nothing in Derby's site that
>prohibits such work. It's better to get the bug fixed somewhere than not
>at all.
>
>In the various recent questions/suggestions about process and other
>related items it is worth remembering this is open source and thus:
>
> 1) people do what 'scratches their itch'
> 2) In general, you cannot require anyone to do anything
>
>Dan.
>
>
>
Re: Bugs and 10.1.2 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/2/05, Rick Hillegas <Ri...@sun.com> wrote:
> However, methinks it's worth hammering out "rules of
> engagement" whenever we have to scratch a collective itch. A release,
> for instance, is a collective itch.
True, but eventually it is up to one person, the release manager, to
provide the distributions to the community for testing, ensure their
quality, gain community approval, sign the binaries, and publish them
to the world.
> I think it would be reasonable for the Release Coordinator to publish their "rules of
> engagement" soon after accepting the job.
The only rules that apply are the Apache rules for releases. See:
http://www.apache.org/dev/release.html
http://httpd.apache.org/dev/release.html
http://jakarta.apache.org/commons/releases/release.html - very
specific to Jakarta Commons but gives a good idea of the mechanics
involved.
(fyi, I'm putting together a Derby-specific page like that last one.)
Note that while there are a lot of mechanics to putting together a
release, there aren't really a whole lot of rules. All you really need
to do is announce to the list you plan on having a release. Marking
whatever bugs/features in JIRA you plan on including in the release is
a good idea, for tracking purposes (both for the release manager and
everyone else). Setting a rough date is also a good idea because at
some point you have to draw a line in the sand for getting
fixes/features into the release.
As for testing, there can never be enough testing, and any test
results that the community can provide are a good thing. :-)
People interested in contributing test results should work out what
sort of tests they think provide significant value amongst themselves
and just do the testing. A wiki for coordinating testing would be a
*very* good thing, to prevent unnecessary duplication of testing. We
can revisit that once we have a wiki set up.
In fact, I've noticed that a lot of people use their project's wiki to
track release-related issues. It's a great idea, since it's web
accessible and all, but it's a necessity to track release progress in
STATUS, because that's the officially accepted location for such
information.
> The community can debate and amend these rules
> and, if the Release Coordinator doesn't like the conclusion, they can
> resign the post. In fact, the Release Coordinator can resign at any
> point if they feel they aren't getting the community support they need.
Yes. It's important to note that the release manager can abandon the
release at any time for any reason, and also that any other member of
the community can put together a competing release if they don't like
the way things are being handled by the other release manager.
> It looks like Andrew is being volunteered as the 10.1.2 Release
> Coordinator. If he's willing to perform this task, he can tell us what
> kind of support he expects from the rest of us. We can discuss it.
Ok, here's my plan: let's say we'll do the 10.1.2 release around
October 28th. So, I'd like for everyone to find the bugs that they
think should be fixed in a 10.1.2 release, and mark them as such.
Then, peruse the bugs marked for 10.1.2 and assign yourself to the
bugs that make you feel itchy. Start work on those bugs. When we get
closer to the release date, we can tighten up the list of issues
assigned to the 10.1.2 release, moving items that are unlikely to make
it in to 10.1.2 out to future releases. A week or so before the 28th,
i'll put binaries together and we'll take a vote. Oh, and if anybody
can contribute testing resources, please let it be known.
Please let me know if you think there needs to be any modifications to
that plan.
(I think this is a good place to stop before I ramble any further. :-) )
andrew
Re: Bugs and 10.1.2 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> I appreciate the desire to be cautious about loaded words like
> "process". However, methinks it's worth hammering out "rules of
> engagement" whenever we have to scratch a collective itch. A release,
> for instance, is a collective itch. I think it would be reasonable for
> the Release Coordinator to publish their "rules of engagement" soon
> after accepting the job. The community can debate and amend these rules
> and, if the Release Coordinator doesn't like the conclusion, they can
> resign the post. In fact, the Release Coordinator can resign at any
> point if they feel they aren't getting the community support they need.
Apache release philosophy is not how you describe it, and is based upon
the http-server folks experience. The release is the itch of the Release
Manager and they did not accept a job that they can resign, they wanted
to be a Release Manager in order to produce a release. It's worth
reading their document, it forms the basis of the assumptions I make
when I've been replying to these discussions:
http://httpd.apache.org/dev/release.html
Of course, most time the community and the Release Manager are in
agreement so there's no issue.
Dan.
Re: Bugs and 10.1.2 release
Posted by Rick Hillegas <Ri...@Sun.COM>.
I appreciate the desire to be cautious about loaded words like
"process". However, methinks it's worth hammering out "rules of
engagement" whenever we have to scratch a collective itch. A release,
for instance, is a collective itch. I think it would be reasonable for
the Release Coordinator to publish their "rules of engagement" soon
after accepting the job. The community can debate and amend these rules
and, if the Release Coordinator doesn't like the conclusion, they can
resign the post. In fact, the Release Coordinator can resign at any
point if they feel they aren't getting the community support they need.
It looks like Andrew is being volunteered as the 10.1.2 Release
Coordinator. If he's willing to perform this task, he can tell us what
kind of support he expects from the rest of us. We can discuss it.
Cheers,
-Rick
Daniel John Debrunner wrote:
>Kathey Marsden wrote:
>
>
>
>>David W. Van Couvering wrote:
>>
>>
>>
>>
>>>I am not clear how this has been done in the past: what is the process
>>>for a contributor (who is not a committer) to get their patch into the
>>>appropriate branches? Do we depend upon the version that the bug was
>>>reported in? Should the contributor indicate what branches the patch
>>>should be applied? Is the contributor responsible for testing on each
>>>branch and providing a separate patch for each branch?
>>>
>>>
>>This was the process I proposed for 10.1.2
>>
>> -- Fixer fixes bug in the *trunk*
>> -- Fixer posts a patch and indicates if if they want the fix in 10.1.
>> -- Committer commits and objections to port can be raised based on risk.
>> -- Fixer tests change on 10,1 then posts svn merge command or 10.1 patch.
>> -- Committer applies the svn merge command and commits to 10.1
>>
>>
>
>While this is a good process, it should not be seen as exclusive. Maybe
>'recommended practice' would be a better term than 'process'?
>
>A fixer may only care about fixing the bug in the trunk, it could be
>someone else who cares about the fix being in a branch and thus performs
>the merge and testing.
>
>A fixer may only care about fixing a bug in a branch, because that's the
>version they are using. There should be nothing in Derby's site that
>prohibits such work. It's better to get the bug fixed somewhere than not
>at all.
>
>In the various recent questions/suggestions about process and other
>related items it is worth remembering this is open source and thus:
>
> 1) people do what 'scratches their itch'
> 2) In general, you cannot require anyone to do anything
>
>Dan.
>
>
>
Re: Bugs and 10.1.2 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>I am not clear how this has been done in the past: what is the process
>>for a contributor (who is not a committer) to get their patch into the
>>appropriate branches? Do we depend upon the version that the bug was
>>reported in? Should the contributor indicate what branches the patch
>>should be applied? Is the contributor responsible for testing on each
>>branch and providing a separate patch for each branch?
>
>
> This was the process I proposed for 10.1.2
>
> -- Fixer fixes bug in the *trunk*
> -- Fixer posts a patch and indicates if if they want the fix in 10.1.
> -- Committer commits and objections to port can be raised based on risk.
> -- Fixer tests change on 10,1 then posts svn merge command or 10.1 patch.
> -- Committer applies the svn merge command and commits to 10.1
While this is a good process, it should not be seen as exclusive. Maybe
'recommended practice' would be a better term than 'process'?
A fixer may only care about fixing the bug in the trunk, it could be
someone else who cares about the fix being in a branch and thus performs
the merge and testing.
A fixer may only care about fixing a bug in a branch, because that's the
version they are using. There should be nothing in Derby's site that
prohibits such work. It's better to get the bug fixed somewhere than not
at all.
In the various recent questions/suggestions about process and other
related items it is worth remembering this is open source and thus:
1) people do what 'scratches their itch'
2) In general, you cannot require anyone to do anything
Dan.
Re: Bugs and 10.1.2 release
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Kathey, thanks. My apologies if I didn't see this the first time
you sent it out, there's a lot of email on the list if you haven't
noticed :).
I think this makes a lot of sense. Awaiting others to comment, but
otherwise I'll post it (once I figure out where to post it).
David
Kathey Marsden wrote:
>David W. Van Couvering wrote:
>
>
>
>>I am not clear how this has been done in the past: what is the process
>>for a contributor (who is not a committer) to get their patch into the
>>appropriate branches? Do we depend upon the version that the bug was
>>reported in? Should the contributor indicate what branches the patch
>>should be applied? Is the contributor responsible for testing on each
>>branch and providing a separate patch for each branch?
>>
>>
>
>This was the process I proposed for 10.1.2
>
> -- Fixer fixes bug in the *trunk*
> -- Fixer posts a patch and indicates if if they want the fix in 10.1.
> -- Committer commits and objections to port can be raised based on risk.
> -- Fixer tests change on 10,1 then posts svn merge command or 10.1 patch.
> -- Committer applies the svn merge command and commits to 10.1
>
>More detail is in my original mail at:
>http://mail-archives.apache.org/mod_mbox/db-derby-dev/200508.mbox/%3C4310AA29.8000403@sbcglobal.net%3E
>
>My thoughts are that by encouraging folks to check into the trunk first and leaving risky changes there, we avoid potential regressions that can be caused by fixes never getting forward ported or inappropriate fixes going to the branch.
>
>
>
>
>>As a followon, is there a common place where we can put policies and
>>procedures like this? There is the Apache Way and the Apache DB
>>Project guidelines, but I think we need our own. All I see so far is
>>a link to an email thread about applying patches.
>>
>>Things I'd like to see described here include:
>>
>>- How to submit a patch
>>- How to test a patch
>>- The issue I'm discussing here about what branches to apply patches to
>>- Our recommended criteria for a release
>>- Architectural policies like how to create a new service, how to use
>>a service, how to work with shared code (if/when we do this), how to
>>throw exceptions, etc.
>>
>>If there are no objections, I'd be happy to get this started. I'd
>>love to do this on a Wiki so it's easy for anyone to contribute. How
>>do we feel about doing more stuff on our Wiki and not having to check
>>everything in through Forrest?
>>
>>
>>
>+1 to the Wiki and your offer to get it started. I have content I have
>not contributed simply because I have not yet gotten to the learning
>Forrest line item on my todo list. Also a Wiki is great for
>collaboration and correcting and updating content.
>
>Kathey
>
>
>
>
Re: Bugs and 10.1.2 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> I am not clear how this has been done in the past: what is the process
> for a contributor (who is not a committer) to get their patch into the
> appropriate branches? Do we depend upon the version that the bug was
> reported in? Should the contributor indicate what branches the patch
> should be applied? Is the contributor responsible for testing on each
> branch and providing a separate patch for each branch?
This was the process I proposed for 10.1.2
-- Fixer fixes bug in the *trunk*
-- Fixer posts a patch and indicates if if they want the fix in 10.1.
-- Committer commits and objections to port can be raised based on risk.
-- Fixer tests change on 10,1 then posts svn merge command or 10.1 patch.
-- Committer applies the svn merge command and commits to 10.1
More detail is in my original mail at:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200508.mbox/%3C4310AA29.8000403@sbcglobal.net%3E
My thoughts are that by encouraging folks to check into the trunk first and leaving risky changes there, we avoid potential regressions that can be caused by fixes never getting forward ported or inappropriate fixes going to the branch.
> As a followon, is there a common place where we can put policies and
> procedures like this? There is the Apache Way and the Apache DB
> Project guidelines, but I think we need our own. All I see so far is
> a link to an email thread about applying patches.
>
> Things I'd like to see described here include:
>
> - How to submit a patch
> - How to test a patch
> - The issue I'm discussing here about what branches to apply patches to
> - Our recommended criteria for a release
> - Architectural policies like how to create a new service, how to use
> a service, how to work with shared code (if/when we do this), how to
> throw exceptions, etc.
>
> If there are no objections, I'd be happy to get this started. I'd
> love to do this on a Wiki so it's easy for anyone to contribute. How
> do we feel about doing more stuff on our Wiki and not having to check
> everything in through Forrest?
>
+1 to the Wiki and your offer to get it started. I have content I have
not contributed simply because I have not yet gotten to the learning
Forrest line item on my todo list. Also a Wiki is great for
collaboration and correcting and updating content.
Kathey
Re: Bugs and 10.1.2 release
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Can someone who is good at this tell me how they search the mail
archives? I have tried gmane and nothing I do seems to actually give me
hits, whereas mod_mbox seems to have no search capabilities at all.
Thanks!
David
Daniel John Debrunner wrote:
>David W. Van Couvering wrote:
>
>
>
>
>>Things I'd like to see described here include:
>>
>>- How to submit a patch
>>- How to test a patch
>>- The issue I'm discussing here about what branches to apply patches to
>>- Our recommended criteria for a release
>>- Architectural policies like how to create a new service, how to use a
>>service, how to work with shared code (if/when we do this), how to throw
>>exceptions, etc.
>>
>>
>
>Sounds good, most of this has been covered in e-mail discussion, and
>thus is in the archives. The trick is finding someone willing to spend
>the time to extract it and format in some useful, readable format.
>
>Dan.
>
>
>
>
Re: Bugs and 10.1.2 release
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
OK, makes sense. Thanks, all, for your input on this.
David
Jean T. Anderson wrote:
> Satheesh Bandaram wrote:
>
>> I am not sure if we should put our general process info on a Wiki.. Are
>> you proposing effectively moving most of the website info to the Wiki? I
>> would rather have Jean or some PMC member control the process info and
>> changes to it. She has been very effective in managing the site so far.
>> For all other stuff, including coding and architectural ideas/tips, Wiki
>> is great. Can Wiki have pointers back to website for process info? :-)
>>
>
> Wikis are really great when the info is still fluid. Once it
> stabilizes, it's nice to catch that snapshot on the web site.
>
> Remember: content on the web site (including current content) does not
> have to be in forrest xml source files and you do not have to become
> knowledgeable about forrest unless you choose to. For more info, see:
>
> http://db.apache.org/derby/papers/index.html#How+to+Contribute+Papers
>
> -jean
Re: Bugs and 10.1.2 release
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Satheesh Bandaram wrote:
> I am not sure if we should put our general process info on a Wiki.. Are
> you proposing effectively moving most of the website info to the Wiki? I
> would rather have Jean or some PMC member control the process info and
> changes to it. She has been very effective in managing the site so far.
> For all other stuff, including coding and architectural ideas/tips, Wiki
> is great. Can Wiki have pointers back to website for process info? :-)
>
Wikis are really great when the info is still fluid. Once it stabilizes,
it's nice to catch that snapshot on the web site.
Remember: content on the web site (including current content) does not
have to be in forrest xml source files and you do not have to become
knowledgeable about forrest unless you choose to. For more info, see:
http://db.apache.org/derby/papers/index.html#How+to+Contribute+Papers
-jean
Re: Bugs and 10.1.2 release
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
I am not sure if we should put our general process info on a Wiki.. Are
you proposing effectively moving most of the website info to the Wiki? I
would rather have Jean or some PMC member control the process info and
changes to it. She has been very effective in managing the site so far.
For all other stuff, including coding and architectural ideas/tips, Wiki
is great. Can Wiki have pointers back to website for process info? :-)
Satheesh
David W. Van Couvering wrote:
> Hi, Satheesh. I don't think I understand the motivation for keeping
> things that don't change frequently on the website. Is it because the
> website is more readily accessible? Perhaps if we start using the
> Wiki more we should provide a link to it from the website so that it
> becomes more accessible too. All things being equal I'd like to keep
> all our processes and policies in a single place rather than divided
> between the Forrest web site and the Wiki, or at least keep what's on
> the web site to a minimum since it really is a more static and harder
> to update environment than a Wiki.
>
> David
>
> Satheesh Bandaram wrote:
>
>> Some of these questions are also answered in the website... like how
>> to submit a patch. May be we could use the WIKI to maintain
>> architectural/coding issues, while keeping the website upto date for
>> general process info that doesn't change frequently. Coding issues
>> could include how to add a new error message, adding new service, new
>> datatype, new builtin functions that can be updated easily in our WIKI.
>>
>> Satheesh
>>
>> Daniel John Debrunner wrote:
>>
>>> David W. Van Couvering wrote:
>>>
>>>
>>>
>>>
>>>> Things I'd like to see described here include:
>>>>
>>>> - How to submit a patch
>>>> - How to test a patch
>>>> - The issue I'm discussing here about what branches to apply
>>>> patches to
>>>> - Our recommended criteria for a release
>>>> - Architectural policies like how to create a new service, how to
>>>> use a
>>>> service, how to work with shared code (if/when we do this), how to
>>>> throw
>>>> exceptions, etc.
>>>>
>>>
>>>
>>> Sounds good, most of this has been covered in e-mail discussion, and
>>> thus is in the archives. The trick is finding someone willing to spend
>>> the time to extract it and format in some useful, readable format.
>>>
>>> Dan.
>>>
>>>
>>>
>>>
>>>
>>>
Re: Bugs and 10.1.2 release
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hi, Satheesh. I don't think I understand the motivation for keeping
things that don't change frequently on the website. Is it because the
website is more readily accessible? Perhaps if we start using the Wiki
more we should provide a link to it from the website so that it becomes
more accessible too. All things being equal I'd like to keep all our
processes and policies in a single place rather than divided between the
Forrest web site and the Wiki, or at least keep what's on the web site
to a minimum since it really is a more static and harder to update
environment than a Wiki.
David
Satheesh Bandaram wrote:
> Some of these questions are also answered in the website... like how
> to submit a patch. May be we could use the WIKI to maintain
> architectural/coding issues, while keeping the website upto date for
> general process info that doesn't change frequently. Coding issues
> could include how to add a new error message, adding new service, new
> datatype, new builtin functions that can be updated easily in our WIKI.
>
> Satheesh
>
> Daniel John Debrunner wrote:
>
>>David W. Van Couvering wrote:
>>
>>
>>
>>
>>>Things I'd like to see described here include:
>>>
>>>- How to submit a patch
>>>- How to test a patch
>>>- The issue I'm discussing here about what branches to apply patches to
>>>- Our recommended criteria for a release
>>>- Architectural policies like how to create a new service, how to use a
>>>service, how to work with shared code (if/when we do this), how to throw
>>>exceptions, etc.
>>>
>>>
>>
>>Sounds good, most of this has been covered in e-mail discussion, and
>>thus is in the archives. The trick is finding someone willing to spend
>>the time to extract it and format in some useful, readable format.
>>
>>Dan.
>>
>>
>>
>>
>>
>>
Re: Bugs and 10.1.2 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David W. Van Couvering wrote:
> Things I'd like to see described here include:
>
> - How to submit a patch
> - How to test a patch
> - The issue I'm discussing here about what branches to apply patches to
> - Our recommended criteria for a release
> - Architectural policies like how to create a new service, how to use a
> service, how to work with shared code (if/when we do this), how to throw
> exceptions, etc.
Sounds good, most of this has been covered in e-mail discussion, and
thus is in the archives. The trick is finding someone willing to spend
the time to extract it and format in some useful, readable format.
Dan.
Re: Bugs and 10.1.2 release
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I am not clear how this has been done in the past: what is the process
for a contributor (who is not a committer) to get their patch into the
appropriate branches? Do we depend upon the version that the bug was
reported in? Should the contributor indicate what branches the patch
should be applied? Is the contributor responsible for testing on each
branch and providing a separate patch for each branch?
As a followon, is there a common place where we can put policies and
procedures like this? There is the Apache Way and the Apache DB Project
guidelines, but I think we need our own. All I see so far is a link to
an email thread about applying patches.
Things I'd like to see described here include:
- How to submit a patch
- How to test a patch
- The issue I'm discussing here about what branches to apply patches to
- Our recommended criteria for a release
- Architectural policies like how to create a new service, how to use a
service, how to work with shared code (if/when we do this), how to throw
exceptions, etc.
If there are no objections, I'd be happy to get this started. I'd love
to do this on a Wiki so it's easy for anyone to contribute. How do we
feel about doing more stuff on our Wiki and not having to check
everything in through Forrest?
Thanks,
David
Daniel John Debrunner wrote:
>Kathey Marsden wrote:
>
>
>
>>We are beginning to accumulate quite a bug backlog. There is a filter
>>available on Jira that shows the current open bug backlog, "Derby open
>>code bugs". Currently there are 108 bugs.
>>
>>In order to avoid the mad dash at 10.2 release time and to make fixes
>>available to users, I was thinking it would be good to plan for a 10.1.2
>>release.
>>
>>
>
>+1
>
>I think we as a community need to do a better job of gettng fixes to
>reported bugs available to those that report them. Hardly any fixes went
>into the 10.0 codeline, thus people had to wait the 10.1 release to
>receive any fixes. Getting fixes in a 10.1 line to bugs reported against
>10.1 is the best approach. In addition to releases I would like us to
>get 10.1 snapshots posted more frequently to the downloads page, if not
>automatically. Most users do not want to make the effort of downloading
>and compling the source code.
>
>Dan.
>
>
>
Re: Bugs and 10.1.2 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>
> Funny you should ask, I'm in the middle of writing up a doc on the
> release process from end to end. This will be a good opportunity to
> test and review the instructions as you go along and we can make sure
> that nothing was missed.
>
> So yes, I'll certainly help out with it as the process goes along.
Thanks Andrew. My thought is that you would be official release manager
and I help mostly by tracking the bugs but performing other subtasks as
well. Is that ok? But yes, I can help test and review the
instructions. .
> The first thing to do would be to target the bugs you want fixed in
> the release in JIRA. I've created a 10.1.2 release in JIRA and moved
> all the 10.1.1.1 bugs to be targeted for 10.1.2.
>
Thanks for making the Jira updates.
Since this release is kind of date driven, would it not be up to the
individual fixers to mark the target fixin for 10.2, then in the end
game we resolve that with reality? How would we work the dates
backward if we wanted a release on the website say October 26?
When should fixers plan to have their bugs fixed?
When would we call a vote?
Could fixes still go into 10.1 during the testing/voting period?
> Speaking of versioning, this should probably be a separate mail,
> perhaps with a vote, but I like the idea that you proposed before:
> that a committer can bump the final version number if they are
> committing small fixes to the branch, and that larger bug-fix-rollup
> releases like 10.1.2 should be the level at which we are tracking
> versions in JIRA, in STATUS, and elsewhere. If there's consensus for
> that, I can work on writing ant targets for bumping the version
> number and automatically dealing with the associated test diffs, etc.
I think using the fourth digit would be good. Since we have it, we may
as well use it instead of the build number to identify fine grained fix
versions. It seems a little confusing though to have a bug fixed in say
10.1.1.12 and have the Jira Fixed In version be 10.1.2, but perhaps
that's more workable than having so many versions in Jira and trying to
mark them correctly.
Kathey
Re: Bugs and 10.1.2 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On Sep 1, 2005, at 3:14 PM, Kathey Marsden wrote:
> Regarding release manager, I'd be willing to post periodic metrics
> about bugs etc, and offer any support I can, but would rather be in a
> supporting role as the mechanics of making a release are a bit of a
> mystery to me. Andrew would you be willing to take on release
> manager
> job for 10.1.2? I'd be happy to help with subtasks. I could be
> sort of
> a release manager's apprentice.
Hi Kathey,
Funny you should ask, I'm in the middle of writing up a doc on the
release process from end to end. This will be a good opportunity to
test and review the instructions as you go along and we can make sure
that nothing was missed.
So yes, I'll certainly help out with it as the process goes along.
The first thing to do would be to target the bugs you want fixed in
the release in JIRA. I've created a 10.1.2 release in JIRA and moved
all the 10.1.1.1 bugs to be targeted for 10.1.2.
Speaking of versioning, this should probably be a separate mail,
perhaps with a vote, but I like the idea that you proposed before:
that a committer can bump the final version number if they are
committing small fixes to the branch, and that larger bug-fix-rollup
releases like 10.1.2 should be the level at which we are tracking
versions in JIRA, in STATUS, and elsewhere. If there's consensus for
that, I can work on writing ant targets for bumping the version
number and automatically dealing with the associated test diffs, etc.
andrew
Re: Bugs and 10.1.2 release
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>Kathey Marsden wrote:
>
>
>>In order to avoid the mad dash at 10.2 release time and to make fixes
>>available to users, I was thinking it would be good to plan for a 10.1.2
>>release.
>>
>>
>
>+1
>
>
>
I have heard no objections so let's shoot for an October 10.1.2 release!
Issues
-- When do we bump the version to 10.1.2? I think just before the
release.
-- Are there fixes in 10.2 already that maybe should be ported
to 10.1?
-- Dan suggested snapshots along the way, which sounds good to me.
I think even now is good since we have a lot of fixes in 10.1
already.
-- We will need a volunteer for release manager.
Regarding release manager, I'd be willing to post periodic metrics
about bugs etc, and offer any support I can, but would rather be in a
supporting role as the mechanics of making a release are a bit of a
mystery to me. Andrew would you be willing to take on release manager
job for 10.1.2? I'd be happy to help with subtasks. I could be sort of
a release manager's apprentice.
Kathey
Re: Bugs and 10.1.2 release
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Kathey Marsden wrote:
> We are beginning to accumulate quite a bug backlog. There is a filter
> available on Jira that shows the current open bug backlog, "Derby open
> code bugs". Currently there are 108 bugs.
>
> In order to avoid the mad dash at 10.2 release time and to make fixes
> available to users, I was thinking it would be good to plan for a 10.1.2
> release.
+1
I think we as a community need to do a better job of gettng fixes to
reported bugs available to those that report them. Hardly any fixes went
into the 10.0 codeline, thus people had to wait the 10.1 release to
receive any fixes. Getting fixes in a 10.1 line to bugs reported against
10.1 is the best approach. In addition to releases I would like us to
get 10.1 snapshots posted more frequently to the downloads page, if not
automatically. Most users do not want to make the effort of downloading
and compling the source code.
Dan.