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 "David W. Van Couvering" <Da...@Sun.COM> on 2005/09/01 22:49:34 UTC
Re: Bugs and 10.1.2 release
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 "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.