On 8/22/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
A behavior that both the Struts and Shale communities have adopted (albeit recently in the case of Shale :-) is to have a JIRA issue for pretty much any non-trivial change to the codebase. It's not necessarily that committers need to flow their proposed commits through attachments to those issues; it's more about being able to associate a commit with a particular issue (simply done by putting the appropriate MYFACES-xxxxx issue number somewhere in the text, and JIRA will notice that and add the commit log to the history of the issue). Whoever is release manager, and therefore is responsible for assembling the release notes, might actually get persuaded to do it for more than one release if this habit is followed, because JIRA will very nicely accumulate all the issues that have been tagged to be fixed in that release.
Separately, I think there's a couple of lessons here for how Apache projects interact with Google Summer of Code participants:
* Get the participants to sign an iCLA early on, so that their ultimate contributions won't have to go through
a bunch of bureaucratic red tape at the last minute.
* Develop a mini-guide to what is expected of GSoC code contributions (such as the license headers,
setting up SVN properties correctly, and the like).
* Make sure that new committers clearly understand the rules too.
Regarding sandbox code, I can sympathize with Mario's point that this is somehow different than "regular" commits. BUT ... even sandbox project commits are done with an ultimate goal in mind. Even if it's an omnibus issue like "add partial page refresh support to Tomahawk", it will help improve the overall discipline if we deal with sandbox commits according to the same process requirements as everything else. After all, the rest of the world might not understand the subtle differences that we (knowledgeable participants in the process) might take for granted.
Craig
One clarification: For external contributions, a jira-issue definitely
makes sense.
A behavior that both the Struts and Shale communities have adopted (albeit recently in the case of Shale :-) is to have a JIRA issue for pretty much any non-trivial change to the codebase. It's not necessarily that committers need to flow their proposed commits through attachments to those issues; it's more about being able to associate a commit with a particular issue (simply done by putting the appropriate MYFACES-xxxxx issue number somewhere in the text, and JIRA will notice that and add the commit log to the history of the issue). Whoever is release manager, and therefore is responsible for assembling the release notes, might actually get persuaded to do it for more than one release if this habit is followed, because JIRA will very nicely accumulate all the issues that have been tagged to be fixed in that release.
Separately, I think there's a couple of lessons here for how Apache projects interact with Google Summer of Code participants:
* Get the participants to sign an iCLA early on, so that their ultimate contributions won't have to go through
a bunch of bureaucratic red tape at the last minute.
* Develop a mini-guide to what is expected of GSoC code contributions (such as the license headers,
setting up SVN properties correctly, and the like).
* Make sure that new committers clearly understand the rules too.
Regarding sandbox code, I can sympathize with Mario's point that this is somehow different than "regular" commits. BUT ... even sandbox project commits are done with an ultimate goal in mind. Even if it's an omnibus issue like "add partial page refresh support to Tomahawk", it will help improve the overall discipline if we deal with sandbox commits according to the same process requirements as everything else. After all, the rest of the world might not understand the subtle differences that we (knowledgeable participants in the process) might take for granted.
regards,
Martin
Craig
On 8/23/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> I really don't see the necessity for MyFaces committers to do all
> extensions of MyFaces through jira, if sufficient communication has
> happened on the developer list first.
>
> Why do you think that opening a jira-issue and adding patches will
> make us more efficient in the development process?
>
> regards,
>
> Martin
>
> On 8/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > what about using Jira first.
> > for almost all commits ?
> > I mean this makes us more efficent to follow the development "process" ;)
> >
> > So each change to API, non trivial enhancement, etc must! go through jira.
> >
> > WDYT ?
> >
> > -Matthias
> >
> > On 8/22/06, Matthias Wessendorf < [EMAIL PROTECTED]> wrote:
> > > I am not concerned about the icla or not
> > > I am more concerned about the fact that patches sent offline
> > > and not through Jira.
> > >
> > > I mean, why ?
> > >
> > > On 8/22/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > For a substantial contribution like this, we'll need a CLA on file in
> > > > any case (even if the code came in through a jira-issue).
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 8/22/06, Wendy Smoak < [EMAIL PROTECTED]> wrote:
> > > > > On 8/22/06, Ernst Fastl <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Hello everyone,
> > > > > >
> > > > > > After verifying the patches I send him Catalin was so kind and commited the
> > > > > > new sandbox component called PPRPanelGroup to the sandbox.
> > > > >
> > > > > Hi there! I think that's the commit I just commented on. :)
> > > > >
> > > > > Matthias already asked if there was a JIRA issue open, which might
> > > > > address my concern about whether we have (or need) a contributor
> > > > > license agreement [1] for the new code.
> > > > >
> > > > > [1] http://www.apache.org/licenses/index.html#clas
> > > > >
> > > > > --
> > > > > Wendy
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
