You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2007/01/02 18:20:52 UTC
new site added to SVN and published
I created a simple website using my standard ant and velocity based
framework (easy to work with...) and checked that into SVN in /site.
I also staged it for the public webserver - should be out there at
http://incubator.apache.org/river
in a few hours at most.
All, please try to check it out (use https, please), and if there are
things you want changed, lets submit patches to JIRA for now.
geir
Re: new site added to SVN and published
Posted by Gianugo Rabellino <gi...@apache.org>.
On 1/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> All, please try to check it out (use https, please), and if there are
> things you want changed, lets submit patches to JIRA for now.
Ack, works here.
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2007, at 4:02 PM, Bob Scheifler wrote:
>> http://incubator.apache.org/river
>> All, please try to check it out (use https, please)
>
> Using https produces a Gateway Timeout for me, http works OK.
You are mixing up two things, and it's my fault for not being
clearer. I said :
On Jan 2, 2007, at 12:20 PM, Geir Magnusson Jr. wrote:
> I created a simple website using my standard ant and velocity based
> framework (easy to work with...) and checked that into SVN in /
> site. I also staged it for the public webserver - should be out
> there at
>
> http://incubator.apache.org/river
>
> in a few hours at most.
>
> All, please try to check it out (use https, please), and if there
> are things you want changed, lets submit patches to JIRA for now.
>
What I meant was "I published the site at ...." and second thought
was "try to check it out [of SVN] (use https...)". I wasn't clear
that I meant you should check the site source out of SVN (not 'check
out' the site as published). I always tell people who will probably
be committers to use https just so that they don't need to do an svn
switch to get their changes to be committed.
Sorry.
geir
Re: new site added to SVN and published
Posted by Jim Waldo <Ji...@sun.com>.
Got it. Very nice; thanks for the work.
Jim
On Jan 2, 2007, at 6:01 PM, Geir Magnusson Jr. wrote:
> Done - I created a simple "logo" for the top of the website, and
> published that..
>
> geir
>
> On Jan 2, 2007, at 5:39 PM, Geir Magnusson Jr. wrote:
>
>>
>> On Jan 2, 2007, at 4:12 PM, Craig L Russell wrote:
>>
>>> I get a broken link with http (apparently due to <a href="http://
>>> incubator.apache.org/river"><img src="./images/harmony-logo-
>>> new.png" alt="Apache River (we need a logo)" /></a>
>>> )
>>
>> Yah, I didn't know what to do w/ the logo at this point. I'll try
>> to throw something together as a placeholder, and hopefully no one
>> will hold a contest or anything yet :)
>>
>>>
>>> and gateway timeout using https (Gateway Timeout Processing of
>>> this request was delegated to a server that is not functioning
>>> properly.).
>>
>> See my other reply. I didn't mean "check out the site" as in look
>> at it, but rather "check the source out of SVN" if you wanted to
>> offer updates ...
>>
>> geir
>>
>>>
>>> Craig
>>>
>>> On Jan 2, 2007, at 1:02 PM, Bob Scheifler wrote:
>>>
>>>>> http://incubator.apache.org/river
>>>>> All, please try to check it out (use https, please)
>>>>
>>>> Using https produces a Gateway Timeout for me, http works OK.
>>>>
>>>> - Bob
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
> The reason why I would have had you submit another one is simply for
> clarity w/ minimum dependency on ephemeral institutional memory.
> Suppose we have some sort of IP issue in the future - say a lawsuit -
> and the ASF needs to show that it has ICLAs for all contributors. I've
> won the lottery and purchased and retired to the Principality of
> Sealand, and you've decided to corner the market on ice cube mines in
> antarctica.
>
> How do we defend the fact that we have no paperwork on file from you w/o
> us individuals having to be involved to resolve the ambiguity?
I think my handwriting was not *that* bad that with a printed name and
the fax next to each other there is a lot of dispute possible. I assume
for this exact reason the secretary corrected the records, for which I
thank you and the secretary.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Great!
On Jan 18, 2007, at 5:49 PM, Jim Waldo wrote:
> Hi Geir--
>
> I've been traveling myself (I'm in LA now; don't ask) but I will
> fax my CLA in no later than Monday (which is the first day I will
> be back in my office).
>
> Jim Waldo
>
> On Jan 18, 2007, at 8:52 AM, Geir Magnusson Jr. wrote:
>
>> The reason why I would have had you submit another one is simply
>> for clarity w/ minimum dependency on ephemeral institutional
>> memory. Suppose we have some sort of IP issue in the future - say
>> a lawsuit - and the ASF needs to show that it has ICLAs for all
>> contributors. I've won the lottery and purchased and retired to
>> the Principality of Sealand, and you've decided to corner the
>> market on ice cube mines in antarctica.
>>
>> How do we defend the fact that we have no paperwork on file from
>> you w/o us individuals having to be involved to resolve the
>> ambiguity?
>>
>> geir
>>
>>
>> On Jan 18, 2007, at 10:38 AM, Mark Brouwer wrote:
>>
>>> Geir Magnusson Jr. wrote:
>>>> On Jan 18, 2007, at 7:19 AM, Geir Magnusson Jr. wrote:
>>>>>
>>>>> On Jan 18, 2007, at 7:04 AM, Mark Brouwer wrote:
>>>>>> You mean faxing the CLA? I think that would result in the same
>>>>>> result
>>>>>> with my handwriting and if I have to write it again I have to
>>>>>> post it
>>>>>> first to somebody with access to a fax. Isn't it possible you
>>>>>> mail them
>>>>>> that the interpretation of my handwriting went slightly wrong
>>>>>> and that
>>>>>> the correct data is:
>>>>>>
>>>>>> Mark Brouwer mark.brouwer@cheiron.org
>>>>>
>>>>> If I were the ASF secretary, I'd make you do it again :)
>>>>> However, I'll leave it up to him. I informed him of the
>>>>> changes and we'll see what he says.
>>>> He made the fix - no need for another copy
>>>
>>> Cool, I'm so glad you are not the ASF secretary, probably for
>>> multiple
>>> reasons ;-)
>>> --
>>> Mark
>>
>
Re: new site added to SVN and published
Posted by Jim Waldo <Ji...@sun.com>.
Hi Geir--
I've been traveling myself (I'm in LA now; don't ask) but I will fax
my CLA in no later than Monday (which is the first day I will be back
in my office).
Jim Waldo
On Jan 18, 2007, at 8:52 AM, Geir Magnusson Jr. wrote:
> The reason why I would have had you submit another one is simply
> for clarity w/ minimum dependency on ephemeral institutional
> memory. Suppose we have some sort of IP issue in the future - say
> a lawsuit - and the ASF needs to show that it has ICLAs for all
> contributors. I've won the lottery and purchased and retired to
> the Principality of Sealand, and you've decided to corner the
> market on ice cube mines in antarctica.
>
> How do we defend the fact that we have no paperwork on file from
> you w/o us individuals having to be involved to resolve the ambiguity?
>
> geir
>
>
> On Jan 18, 2007, at 10:38 AM, Mark Brouwer wrote:
>
>> Geir Magnusson Jr. wrote:
>>> On Jan 18, 2007, at 7:19 AM, Geir Magnusson Jr. wrote:
>>>>
>>>> On Jan 18, 2007, at 7:04 AM, Mark Brouwer wrote:
>>>>> You mean faxing the CLA? I think that would result in the same
>>>>> result
>>>>> with my handwriting and if I have to write it again I have to
>>>>> post it
>>>>> first to somebody with access to a fax. Isn't it possible you
>>>>> mail them
>>>>> that the interpretation of my handwriting went slightly wrong
>>>>> and that
>>>>> the correct data is:
>>>>>
>>>>> Mark Brouwer mark.brouwer@cheiron.org
>>>>
>>>> If I were the ASF secretary, I'd make you do it again :)
>>>> However, I'll leave it up to him. I informed him of the changes
>>>> and we'll see what he says.
>>> He made the fix - no need for another copy
>>
>> Cool, I'm so glad you are not the ASF secretary, probably for
>> multiple
>> reasons ;-)
>> --
>> Mark
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
The reason why I would have had you submit another one is simply for
clarity w/ minimum dependency on ephemeral institutional memory.
Suppose we have some sort of IP issue in the future - say a lawsuit -
and the ASF needs to show that it has ICLAs for all contributors.
I've won the lottery and purchased and retired to the Principality of
Sealand, and you've decided to corner the market on ice cube mines in
antarctica.
How do we defend the fact that we have no paperwork on file from you
w/o us individuals having to be involved to resolve the ambiguity?
geir
On Jan 18, 2007, at 10:38 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>> On Jan 18, 2007, at 7:19 AM, Geir Magnusson Jr. wrote:
>>>
>>> On Jan 18, 2007, at 7:04 AM, Mark Brouwer wrote:
>>>> You mean faxing the CLA? I think that would result in the same
>>>> result
>>>> with my handwriting and if I have to write it again I have to
>>>> post it
>>>> first to somebody with access to a fax. Isn't it possible you
>>>> mail them
>>>> that the interpretation of my handwriting went slightly wrong
>>>> and that
>>>> the correct data is:
>>>>
>>>> Mark Brouwer mark.brouwer@cheiron.org
>>>
>>> If I were the ASF secretary, I'd make you do it again :)
>>> However, I'll leave it up to him. I informed him of the changes
>>> and we'll see what he says.
>> He made the fix - no need for another copy
>
> Cool, I'm so glad you are not the ASF secretary, probably for multiple
> reasons ;-)
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
>
> On Jan 18, 2007, at 7:19 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Jan 18, 2007, at 7:04 AM, Mark Brouwer wrote:
>>> You mean faxing the CLA? I think that would result in the same result
>>> with my handwriting and if I have to write it again I have to post it
>>> first to somebody with access to a fax. Isn't it possible you mail them
>>> that the interpretation of my handwriting went slightly wrong and that
>>> the correct data is:
>>>
>>> Mark Brouwer mark.brouwer@cheiron.org
>>
>> If I were the ASF secretary, I'd make you do it again :) However,
>> I'll leave it up to him. I informed him of the changes and we'll see
>> what he says.
>
> He made the fix - no need for another copy
Cool, I'm so glad you are not the ASF secretary, probably for multiple
reasons ;-)
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 18, 2007, at 7:19 AM, Geir Magnusson Jr. wrote:
>
> On Jan 18, 2007, at 7:04 AM, Mark Brouwer wrote:
>> You mean faxing the CLA? I think that would result in the same result
>> with my handwriting and if I have to write it again I have to post it
>> first to somebody with access to a fax. Isn't it possible you mail
>> them
>> that the interpretation of my handwriting went slightly wrong and
>> that
>> the correct data is:
>>
>> Mark Brouwer mark.brouwer@cheiron.org
>
> If I were the ASF secretary, I'd make you do it again :) However,
> I'll leave it up to him. I informed him of the changes and we'll
> see what he says.
He made the fix - no need for another copy
geir
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 18, 2007, at 7:04 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>> Yes, there is a "mark brommer" in the ICLA file :) The entry is
>> this :
>> notinavail:Mark Brommer:Mark
>> Brommer:mark.brommer@cheison.org:Signed CLA
>
> They couldn't even read the domain name ... I think I could become a
> doctor with my handwriting.
>
>> I guess the ".org" was clear enough to get right. :)
>> Any chance you could try again?
>
> You mean faxing the CLA? I think that would result in the same result
> with my handwriting and if I have to write it again I have to post it
> first to somebody with access to a fax. Isn't it possible you mail
> them
> that the interpretation of my handwriting went slightly wrong and that
> the correct data is:
>
> Mark Brouwer mark.brouwer@cheiron.org
If I were the ASF secretary, I'd make you do it again :) However,
I'll leave it up to him. I informed him of the changes and we'll see
what he says.
geir
>
>> Also, to get a good url to the archive, the way I've found is to
>> go to the message, then click on "Message View", which sould make
>> it easy to pick off the URL from the browser - for example :
>
> Thanks for the tip! Copying the link from the thread view resulted in
> some XML so I thought it was nearly impossible.
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
> Yes, there is a "mark brommer" in the ICLA file :) The entry is this :
>
> notinavail:Mark Brommer:Mark Brommer:mark.brommer@cheison.org:Signed CLA
>
They couldn't even read the domain name ... I think I could become a
doctor with my handwriting.
> I guess the ".org" was clear enough to get right. :)
>
> Any chance you could try again?
You mean faxing the CLA? I think that would result in the same result
with my handwriting and if I have to write it again I have to post it
first to somebody with access to a fax. Isn't it possible you mail them
that the interpretation of my handwriting went slightly wrong and that
the correct data is:
Mark Brouwer mark.brouwer@cheiron.org
> Also, to get a good url to the archive, the way I've found is to go to
> the message, then click on "Message View", which sould make it easy to
> pick off the URL from the browser - for example :
Thanks for the tip! Copying the link from the thread view resulted in
some XML so I thought it was nearly impossible.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Yes, there is a "mark brommer" in the ICLA file :) The entry is this :
notinavail:Mark Brommer:Mark Brommer:mark.brommer@cheison.org:Signed CLA
I guess the ".org" was clear enough to get right. :)
Any chance you could try again?
Also, to get a good url to the archive, the way I've found is to go
to the message, then click on "Message View", which sould make it
easy to pick off the URL from the browser - for example :
http://mail-archives.apache.org/mod_mbox/incubator-river-dev/
200701.mbox/%3c459A7EB9.8020301@cheiron.org%3e
On Jan 18, 2007, at 6:48 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>> On Jan 18, 2007, at 3:40 AM, Mark Brouwer wrote:
>>> Phil Steitz wrote:
>>>> On 1/16/07, Jim Hurley <Ji...@sun.com> wrote:
>>>>>
>>>>> I have fax'ed in what I think is the needed legal agreement
>>>>> from Sun. Not sure what ACK I should expect (if any), or what
>>>>> the next step is.
>>>> The CCLA has been recorded. The next logical step is a vote to
>>>> accept, but
>>>> that doesn't make much sense until the PPMC is set up and that
>>>> requires CLAs
>>>> all around. Are we all covered yet?
>>>
>>> Dunno, see
>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/
>>> 200701.mbox/browser,
>>> so far it has not been corrected.
>> I don't understand what you think needs to be corrected... It
>> looks ok...
>
> Sorry Geir, it seems that it ain't trivial to link to the archives. Is
> there a way one can refer to the archives that makes sense?
>
> I was referring to my statement that I've seen an unlisted CLA
> referring to "Mark Brommer" that arrived shortly after faxing the
> CLA at
> http://people.apache.org/~jim/committers.html which I think is due
> to my
> handwriting. I asked if somebody could correct that, so far no
> answer to
> that question, hence this posting. As I've no clue about any legal
> implications of me going forward as Mark Brommer the rest of my life I
> thought of it as worth mentioning.
> --
> Mark
>
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
>
> On Jan 18, 2007, at 3:40 AM, Mark Brouwer wrote:
>
>> Phil Steitz wrote:
>>> On 1/16/07, Jim Hurley <Ji...@sun.com> wrote:
>>>>
>>>> I have fax'ed in what I think is the needed legal agreement
>>>> from Sun. Not sure what ACK I should expect (if any), or what
>>>> the next step is.
>>> The CCLA has been recorded. The next logical step is a vote to
>>> accept, but
>>> that doesn't make much sense until the PPMC is set up and that
>>> requires CLAs
>>> all around. Are we all covered yet?
>>
>> Dunno, see
>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200701.mbox/browser,
>>
>> so far it has not been corrected.
>
> I don't understand what you think needs to be corrected... It looks ok...
Sorry Geir, it seems that it ain't trivial to link to the archives. Is
there a way one can refer to the archives that makes sense?
I was referring to my statement that I've seen an unlisted CLA
referring to "Mark Brommer" that arrived shortly after faxing the CLA at
http://people.apache.org/~jim/committers.html which I think is due to my
handwriting. I asked if somebody could correct that, so far no answer to
that question, hence this posting. As I've no clue about any legal
implications of me going forward as Mark Brommer the rest of my life I
thought of it as worth mentioning.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 18, 2007, at 3:40 AM, Mark Brouwer wrote:
> Phil Steitz wrote:
>> On 1/16/07, Jim Hurley <Ji...@sun.com> wrote:
>>>
>>> I have fax'ed in what I think is the needed legal agreement
>>> from Sun. Not sure what ACK I should expect (if any), or what
>>> the next step is.
>> The CCLA has been recorded. The next logical step is a vote to
>> accept, but
>> that doesn't make much sense until the PPMC is set up and that
>> requires CLAs
>> all around. Are we all covered yet?
>
> Dunno, see
> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/
> 200701.mbox/browser,
> so far it has not been corrected.
I don't understand what you think needs to be corrected... It looks
ok...
geir
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Phil Steitz wrote:
> On 1/16/07, Jim Hurley <Ji...@sun.com> wrote:
>>
>> I have fax'ed in what I think is the needed legal agreement
>> from Sun. Not sure what ACK I should expect (if any), or what
>> the next step is.
>
>
> The CCLA has been recorded. The next logical step is a vote to accept, but
> that doesn't make much sense until the PPMC is set up and that requires
> CLAs
> all around. Are we all covered yet?
Dunno, see
http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200701.mbox/browser,
so far it has not been corrected.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 16, 2007, at 7:01 PM, Jim Hurley wrote:
> I have fax'ed in what I think is the needed legal agreement
> from Sun. Not sure what ACK I should expect (if any), or what
> the next step is.
As Phil noted, a CCLA has been recorded from you for "Sun's
contributions to the River project" (That's nice and open-ended :)
>
> Geir- any guidance here?
Next step is simple - package the code as I noted in a response to
Bill, create and attach it to a JIRA.
Next step after that would be for the project to vote the
contribution into the project. Formally, that vote would be by the
PPMC as Phil noted, but I'd like to suggest that we don't really
partition the community that way - when we have a vote, we all vote,
and if it does come down to needing to count who the PPMC votes came
from to figure out the result, I'd suggest we have a problem (because
it means that the PPMC is voting one way, and the community another,
and the PPMC should actually be very concerned with such an outcome...)
To do this, the PPMC consists now of the mentors, so I think that not
having accounts yet isn't a hurdle. To keep things moving forward,
we'll propose a vote on a contribution (let one of us mentors do the
first one to include some common custom).
In parallel, we can get committer accounts created.
geir
>
> thanks much -Jim
>
>
> On Jan 15, 2007, at 3:07 PM, Bill Venners wrote:
>> Hi Geir,
>>
>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>
>>>
>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>
>> I've finally prepped these docs, but I'm afraid I need a bit of
>> hand-holding for submitting the code. How should I package
>> ServiceUI, and where do I submit it via JIRA? What should be
>> included in the package? Once I get it submitted, I can stick the
>> JIRA ID on the CCLA itself and fax or mail it (whichever is
>> preferred).
>>
>> Thanks.
>>
>> Bill
>>
>>>>
>>>>> 1) package and contribute via a JIRA
>>>>>
>>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>>> what later...)
>>>>>
>>>>> 3) when the paperwork is done, project votes to accept the
>>>>> contribution
>>>>>
>>>>> The last step is a way to clearly exercise active oversight on
>>>>> the codebase - it means that people other than the committer
>>>>> that eventually puts the code in SVN are paying attention to
>>>>> what is entering SVN.
>>>>>
>>>> Thanks.
>>>>
>>>> Bill
>>>>
>>>>
>>>>
>>>>
>>>>> geir
>>>>>
>>>>>
>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>
>>>>>> Hi Geir,
>>>>>>
>>>>>> What's will be the process for contributing ServiceUI? I am
>>>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>>>
>>>>>> Bill
>>>>>> ----
>>>>>> Bill Venners
>>>>>> President
>>>>>> Artima, Inc.
>>>>>> http://www.artima.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Bill
>>>> ----
>>>> Bill Venners
>>>> President
>>>> Artima, Inc.
>>>> http://www.artima.com
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> Bill
>> ----
>> Bill Venners
>> President
>> Artima, Inc.
>> http://www.artima.com
>>
>>
>>
>
Re: new site added to SVN and published
Posted by Phil Steitz <ph...@gmail.com>.
On 1/16/07, Jim Hurley <Ji...@sun.com> wrote:
>
> I have fax'ed in what I think is the needed legal agreement
> from Sun. Not sure what ACK I should expect (if any), or what
> the next step is.
The CCLA has been recorded. The next logical step is a vote to accept, but
that doesn't make much sense until the PPMC is set up and that requires CLAs
all around. Are we all covered yet?
Phil
Geir- any guidance here?
>
> thanks much -Jim
>
>
> On Jan 15, 2007, at 3:07 PM, Bill Venners wrote:
> > Hi Geir,
> >
> > On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
> >
> >>
> >> yep - through the CCLA, Artima can license a copy to the ASF.
> >>
> > I've finally prepped these docs, but I'm afraid I need a bit of
> > hand-holding for submitting the code. How should I package
> > ServiceUI, and where do I submit it via JIRA? What should be
> > included in the package? Once I get it submitted, I can stick the
> > JIRA ID on the CCLA itself and fax or mail it (whichever is
> > preferred).
> >
> > Thanks.
> >
> > Bill
> >
> >>>
> >>>> 1) package and contribute via a JIRA
> >>>>
> >>>> 2) submit an CCLA to the ASF Scty where the contribution is
> >>>> noted by JIRA ID (makes it much easier to figure out what is
> >>>> what later...)
> >>>>
> >>>> 3) when the paperwork is done, project votes to accept the
> >>>> contribution
> >>>>
> >>>> The last step is a way to clearly exercise active oversight on
> >>>> the codebase - it means that people other than the committer
> >>>> that eventually puts the code in SVN are paying attention to
> >>>> what is entering SVN.
> >>>>
> >>> Thanks.
> >>>
> >>> Bill
> >>>
> >>>
> >>>
> >>>
> >>>> geir
> >>>>
> >>>>
> >>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
> >>>>
> >>>>> Hi Geir,
> >>>>>
> >>>>> What's will be the process for contributing ServiceUI? I am
> >>>>> guessing I need to sign a Software Grant and CLA on behalf of
> >>>>> Artima, and then perhaps a CLA for myself as an individual too?
> >>>>>
> >>>>> Bill
> >>>>> ----
> >>>>> Bill Venners
> >>>>> President
> >>>>> Artima, Inc.
> >>>>> http://www.artima.com
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> Bill
> >>> ----
> >>> Bill Venners
> >>> President
> >>> Artima, Inc.
> >>> http://www.artima.com
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > Bill
> > ----
> > Bill Venners
> > President
> > Artima, Inc.
> > http://www.artima.com
> >
> >
> >
>
>
Re: new site added to SVN and published
Posted by Jim Hurley <Ji...@Sun.COM>.
I have fax'ed in what I think is the needed legal agreement
from Sun. Not sure what ACK I should expect (if any), or what
the next step is.
Geir- any guidance here?
thanks much -Jim
On Jan 15, 2007, at 3:07 PM, Bill Venners wrote:
> Hi Geir,
>
> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>
>>
>> yep - through the CCLA, Artima can license a copy to the ASF.
>>
> I've finally prepped these docs, but I'm afraid I need a bit of
> hand-holding for submitting the code. How should I package
> ServiceUI, and where do I submit it via JIRA? What should be
> included in the package? Once I get it submitted, I can stick the
> JIRA ID on the CCLA itself and fax or mail it (whichever is
> preferred).
>
> Thanks.
>
> Bill
>
>>>
>>>> 1) package and contribute via a JIRA
>>>>
>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>> what later...)
>>>>
>>>> 3) when the paperwork is done, project votes to accept the
>>>> contribution
>>>>
>>>> The last step is a way to clearly exercise active oversight on
>>>> the codebase - it means that people other than the committer
>>>> that eventually puts the code in SVN are paying attention to
>>>> what is entering SVN.
>>>>
>>> Thanks.
>>>
>>> Bill
>>>
>>>
>>>
>>>
>>>> geir
>>>>
>>>>
>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>
>>>>> Hi Geir,
>>>>>
>>>>> What's will be the process for contributing ServiceUI? I am
>>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>>
>>>>> Bill
>>>>> ----
>>>>> Bill Venners
>>>>> President
>>>>> Artima, Inc.
>>>>> http://www.artima.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> Bill
>>> ----
>>> Bill Venners
>>> President
>>> Artima, Inc.
>>> http://www.artima.com
>>>
>>>
>>>
>>
>>
>
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
>
> On Jan 18, 2007, at 5:15 AM, Mark Brouwer wrote:
>
>> Bill Venners wrote:
>>> Hello,
>>> Can someone point me to the JIRA instance where I'm supposed to
>>> submit ServiceUI? I haven't heard back from anyone on how to do this,
>>> or how to package it. According to Geir, I should first submit the
>>> code then fax in the signed agreement with the JIRA ID of the
>>> submission on it.
>>
>> Hi Bill,
>>
>> I think the best thing you can do is create an account (if you don't
>> already have one) by going to
>> https://issues.apache.org/jira/browse/RIVER . Submit your stuff in
>> component "Unknown", we can later change the component if we have
>> decided upon a few.
>>
>> I think a few suggestions have been made so far (such as JTSK,
>> ServiceUI, Contributions, just to get started), but for some reason some
>> things don't materialize.
>
> ?
I think it has been expressed we needed some JIRA components. I created
a posting with the title "[PROPOSAL] Components for JIRA" but nobody
voted on that so that raised a question mark with me as well.
Maybe a bit more greasing of the wheels would be helpful ;-)
>> Also a question I raised in the past but that didn't get answered "BTW
>> and for the mentors, what are the permissions a committer has with
>> regard to the various JIRA 'administration' tasks?"
>
> The comitter will have "developer" karma at first for JIRA, which should
> allow said committer to handle all project-related JIRA tasks. After
> some time, we can talk about JIRA admin privs.
Ok, clear.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 18, 2007, at 5:15 AM, Mark Brouwer wrote:
> Bill Venners wrote:
>> Hello,
>> Can someone point me to the JIRA instance where I'm supposed to
>> submit ServiceUI? I haven't heard back from anyone on how to do
>> this, or how to package it. According to Geir, I should first
>> submit the code then fax in the signed agreement with the JIRA ID
>> of the submission on it.
>
> Hi Bill,
>
> I think the best thing you can do is create an account (if you don't
> already have one) by going to
> https://issues.apache.org/jira/browse/RIVER . Submit your stuff in
> component "Unknown", we can later change the component if we have
> decided upon a few.
>
> I think a few suggestions have been made so far (such as JTSK,
> ServiceUI, Contributions, just to get started), but for some reason
> some
> things don't materialize.
?
>
> Also a question I raised in the past but that didn't get answered "BTW
> and for the mentors, what are the permissions a committer has with
> regard to the various JIRA 'administration' tasks?"
The comitter will have "developer" karma at first for JIRA, which
should allow said committer to handle all project-related JIRA
tasks. After some time, we can talk about JIRA admin privs.
geir
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Bill Venners wrote:
> Hello,
>
> Can someone point me to the JIRA instance where I'm supposed to submit
> ServiceUI? I haven't heard back from anyone on how to do this, or how to
> package it. According to Geir, I should first submit the code then fax
> in the signed agreement with the JIRA ID of the submission on it.
Hi Bill,
I think the best thing you can do is create an account (if you don't
already have one) by going to
https://issues.apache.org/jira/browse/RIVER . Submit your stuff in
component "Unknown", we can later change the component if we have
decided upon a few.
I think a few suggestions have been made so far (such as JTSK,
ServiceUI, Contributions, just to get started), but for some reason some
things don't materialize.
Also a question I raised in the past but that didn't get answered "BTW
and for the mentors, what are the permissions a committer has with
regard to the various JIRA 'administration' tasks?"
--
Mark
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hi Geir,
On Jan 18, 2007, at 1:13 PM, Geir Magnusson Jr. wrote:
>
> On Jan 18, 2007, at 5:23 PM, Bill Venners wrote:
>
>> Hi Geir,
>>
>> Well I tried twice to fax in the ICLA, and it aborted both times
>> due to bad line conditions. I faxed it to myself and that worked
>> fine.
>
> How do you fax to yourself? Isn't the line busy when you're
> dialing yourself?
>
I talk to myself too sometimes.
>> I can either mail it in via snail mail, or send you (or whomever
>> you point me to) a PDF of the fax that I sent to myself. What do
>> you recommend?
>
> Snail it, and also send me the PDF.
>
You got it.
Thanks.
Bill
>>
>> Sorry to need so much hand-holding at the start.
>
> No apology necessary - that's why we're here.
>
> geir
>
>>
>> Thanks.
>>
>> Bill
>>
>> On Jan 18, 2007, at 7:46 AM, Geir Magnusson Jr. wrote:
>>
>>> get he ICLA in sooner than later so we can do a group request for
>>> accounts...
>>>
>>> geir
>>>
>>> On Jan 18, 2007, at 12:42 PM, Bill Venners wrote:
>>>
>>>> Hi Geir,
>>>>
>>>> Great advice. Thanks. This is exciting. I'll get this in as soon
>>>> as I can, and then I'll fax the Corp CLA, and ICLA. I've got
>>>> them both signed here but I was waiting to fax them until after
>>>> I submit the ServiceUI code.
>>>>
>>>> Bill
>>>>
>>>> On Jan 18, 2007, at 1:29 AM, Geir Magnusson Jr. wrote:
>>>>
>>>>> Sorry Bill... traveling this week and behind...
>>>>>
>>>>> You don't *have* to do it in that order, but I've discovered
>>>>> that having that JIRA key makes it clearer in the records, but
>>>>> it can be in either order.
>>>>>
>>>>> So -
>>>>>
>>>>> 1) Add the license header to each file as described here :
>>>>>
>>>>> http://www.apache.org/legal/src-headers.html
>>>>>
>>>>> In particular, remove any (c) Artima if that happens to be in
>>>>> the code, or any of your own license headers or statements of
>>>>> ownership that may be in each file.
>>>>>
>>>>> 2) Put a copy of the Apache License (http://www.apache.org/
>>>>> licenses/LICENSE-2.0) into a file called LICENSE in the root of
>>>>> the distribution
>>>>>
>>>>> 3) If there are any pieces of software in the contribution that
>>>>> weren't created by you (came from elsewhere) and had any notice
>>>>> requirements in the license (such as a BSD notice requirement)
>>>>> then put those in a NOTICE file in the root of the distro.
>>>>>
>>>>> 4) If there were any (c) Artima, and you want that to persist
>>>>> somewhere, put a file COPYRIGHT in the root of the tree and put
>>>>> something like
>>>>>
>>>>> The following copyright notice(s) were affixed to portions
>>>>> of the
>>>>> code with which this file is now or was at one time
>>>>> distributed and
>>>>> are placed here unaltered.
>>>>>
>>>>> (C) Copyright XXXX Artima
>>>>>
>>>>> 5) Be sure that there is no code (c) anyone else - for example,
>>>>> one popular mistake is to submit schemas or such that may be
>>>>> (c) sun.
>>>>>
>>>>> 6) Bundle the tree into a tarball, create a new JIRA, then
>>>>> attach tarball to JIRA.
>>>>>
>>>>> 7) in the CCLA, where it has you list the contributions, put :
>>>>>
>>>>> <description> as submitted to the ASF via JIRA as RIVER-XXX
>>>>>
>>>>>
>>>>> geir
>>>>>
>>>>>
>>>>> On Jan 18, 2007, at 3:05 AM, Bill Venners wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Can someone point me to the JIRA instance where I'm supposed
>>>>>> to submit ServiceUI? I haven't heard back from anyone on how
>>>>>> to do this, or how to package it. According to Geir, I should
>>>>>> first submit the code then fax in the signed agreement with
>>>>>> the JIRA ID of the submission on it.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>> On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
>>>>>>
>>>>>>> Hi Geir,
>>>>>>>
>>>>>>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>>>>>>
>>>>>>> I've finally prepped these docs, but I'm afraid I need a bit
>>>>>>> of hand-holding for submitting the code. How should I package
>>>>>>> ServiceUI, and where do I submit it via JIRA? What should be
>>>>>>> included in the package? Once I get it submitted, I can stick
>>>>>>> the JIRA ID on the CCLA itself and fax or mail it (whichever
>>>>>>> is preferred).
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>>>>
>>>>>>>>>> 1) package and contribute via a JIRA
>>>>>>>>>>
>>>>>>>>>> 2) submit an CCLA to the ASF Scty where the contribution
>>>>>>>>>> is noted by JIRA ID (makes it much easier to figure out
>>>>>>>>>> what is what later...)
>>>>>>>>>>
>>>>>>>>>> 3) when the paperwork is done, project votes to accept the
>>>>>>>>>> contribution
>>>>>>>>>>
>>>>>>>>>> The last step is a way to clearly exercise active
>>>>>>>>>> oversight on the codebase - it means that people other
>>>>>>>>>> than the committer that eventually puts the code in SVN
>>>>>>>>>> are paying attention to what is entering SVN.
>>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> Bill
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> geir
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Geir,
>>>>>>>>>>>
>>>>>>>>>>> What's will be the process for contributing ServiceUI? I
>>>>>>>>>>> am guessing I need to sign a Software Grant and CLA on
>>>>>>>>>>> behalf of Artima, and then perhaps a CLA for myself as an
>>>>>>>>>>> individual too?
>>>>>>>>>>>
>>>>>>>>>>> Bill
>>>>>>>>>>> ----
>>>>>>>>>>> Bill Venners
>>>>>>>>>>> President
>>>>>>>>>>> Artima, Inc.
>>>>>>>>>>> http://www.artima.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bill
>>>>>>>>> ----
>>>>>>>>> Bill Venners
>>>>>>>>> President
>>>>>>>>> Artima, Inc.
>>>>>>>>> http://www.artima.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bill
>>>>>>> ----
>>>>>>> Bill Venners
>>>>>>> President
>>>>>>> Artima, Inc.
>>>>>>> http://www.artima.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 18, 2007, at 5:23 PM, Bill Venners wrote:
> Hi Geir,
>
> Well I tried twice to fax in the ICLA, and it aborted both times
> due to bad line conditions. I faxed it to myself and that worked fine.
How do you fax to yourself? Isn't the line busy when you're dialing
yourself?
> I can either mail it in via snail mail, or send you (or whomever
> you point me to) a PDF of the fax that I sent to myself. What do
> you recommend?
Snail it, and also send me the PDF.
>
> Sorry to need so much hand-holding at the start.
No apology necessary - that's why we're here.
geir
>
> Thanks.
>
> Bill
>
> On Jan 18, 2007, at 7:46 AM, Geir Magnusson Jr. wrote:
>
>> get he ICLA in sooner than later so we can do a group request for
>> accounts...
>>
>> geir
>>
>> On Jan 18, 2007, at 12:42 PM, Bill Venners wrote:
>>
>>> Hi Geir,
>>>
>>> Great advice. Thanks. This is exciting. I'll get this in as soon
>>> as I can, and then I'll fax the Corp CLA, and ICLA. I've got them
>>> both signed here but I was waiting to fax them until after I
>>> submit the ServiceUI code.
>>>
>>> Bill
>>>
>>> On Jan 18, 2007, at 1:29 AM, Geir Magnusson Jr. wrote:
>>>
>>>> Sorry Bill... traveling this week and behind...
>>>>
>>>> You don't *have* to do it in that order, but I've discovered
>>>> that having that JIRA key makes it clearer in the records, but
>>>> it can be in either order.
>>>>
>>>> So -
>>>>
>>>> 1) Add the license header to each file as described here :
>>>>
>>>> http://www.apache.org/legal/src-headers.html
>>>>
>>>> In particular, remove any (c) Artima if that happens to be in
>>>> the code, or any of your own license headers or statements of
>>>> ownership that may be in each file.
>>>>
>>>> 2) Put a copy of the Apache License (http://www.apache.org/
>>>> licenses/LICENSE-2.0) into a file called LICENSE in the root of
>>>> the distribution
>>>>
>>>> 3) If there are any pieces of software in the contribution that
>>>> weren't created by you (came from elsewhere) and had any notice
>>>> requirements in the license (such as a BSD notice requirement)
>>>> then put those in a NOTICE file in the root of the distro.
>>>>
>>>> 4) If there were any (c) Artima, and you want that to persist
>>>> somewhere, put a file COPYRIGHT in the root of the tree and put
>>>> something like
>>>>
>>>> The following copyright notice(s) were affixed to portions
>>>> of the
>>>> code with which this file is now or was at one time
>>>> distributed and
>>>> are placed here unaltered.
>>>>
>>>> (C) Copyright XXXX Artima
>>>>
>>>> 5) Be sure that there is no code (c) anyone else - for example,
>>>> one popular mistake is to submit schemas or such that may be (c)
>>>> sun.
>>>>
>>>> 6) Bundle the tree into a tarball, create a new JIRA, then
>>>> attach tarball to JIRA.
>>>>
>>>> 7) in the CCLA, where it has you list the contributions, put :
>>>>
>>>> <description> as submitted to the ASF via JIRA as RIVER-XXX
>>>>
>>>>
>>>> geir
>>>>
>>>>
>>>> On Jan 18, 2007, at 3:05 AM, Bill Venners wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Can someone point me to the JIRA instance where I'm supposed to
>>>>> submit ServiceUI? I haven't heard back from anyone on how to do
>>>>> this, or how to package it. According to Geir, I should first
>>>>> submit the code then fax in the signed agreement with the JIRA
>>>>> ID of the submission on it.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
>>>>>
>>>>>> Hi Geir,
>>>>>>
>>>>>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>>>>>
>>>>>>>
>>>>>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>>>>>
>>>>>> I've finally prepped these docs, but I'm afraid I need a bit
>>>>>> of hand-holding for submitting the code. How should I package
>>>>>> ServiceUI, and where do I submit it via JIRA? What should be
>>>>>> included in the package? Once I get it submitted, I can stick
>>>>>> the JIRA ID on the CCLA itself and fax or mail it (whichever
>>>>>> is preferred).
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>>>>
>>>>>>>>> 1) package and contribute via a JIRA
>>>>>>>>>
>>>>>>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>>>>>>> noted by JIRA ID (makes it much easier to figure out what
>>>>>>>>> is what later...)
>>>>>>>>>
>>>>>>>>> 3) when the paperwork is done, project votes to accept the
>>>>>>>>> contribution
>>>>>>>>>
>>>>>>>>> The last step is a way to clearly exercise active oversight
>>>>>>>>> on the codebase - it means that people other than the
>>>>>>>>> committer that eventually puts the code in SVN are paying
>>>>>>>>> attention to what is entering SVN.
>>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Bill
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> geir
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>>>>>
>>>>>>>>>> Hi Geir,
>>>>>>>>>>
>>>>>>>>>> What's will be the process for contributing ServiceUI? I
>>>>>>>>>> am guessing I need to sign a Software Grant and CLA on
>>>>>>>>>> behalf of Artima, and then perhaps a CLA for myself as an
>>>>>>>>>> individual too?
>>>>>>>>>>
>>>>>>>>>> Bill
>>>>>>>>>> ----
>>>>>>>>>> Bill Venners
>>>>>>>>>> President
>>>>>>>>>> Artima, Inc.
>>>>>>>>>> http://www.artima.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Bill
>>>>>>>> ----
>>>>>>>> Bill Venners
>>>>>>>> President
>>>>>>>> Artima, Inc.
>>>>>>>> http://www.artima.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Bill
>>>>>> ----
>>>>>> Bill Venners
>>>>>> President
>>>>>> Artima, Inc.
>>>>>> http://www.artima.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hi Geir,
Well I tried twice to fax in the ICLA, and it aborted both times due
to bad line conditions. I faxed it to myself and that worked fine. I
can either mail it in via snail mail, or send you (or whomever you
point me to) a PDF of the fax that I sent to myself. What do you
recommend?
Sorry to need so much hand-holding at the start.
Thanks.
Bill
On Jan 18, 2007, at 7:46 AM, Geir Magnusson Jr. wrote:
> get he ICLA in sooner than later so we can do a group request for
> accounts...
>
> geir
>
> On Jan 18, 2007, at 12:42 PM, Bill Venners wrote:
>
>> Hi Geir,
>>
>> Great advice. Thanks. This is exciting. I'll get this in as soon
>> as I can, and then I'll fax the Corp CLA, and ICLA. I've got them
>> both signed here but I was waiting to fax them until after I
>> submit the ServiceUI code.
>>
>> Bill
>>
>> On Jan 18, 2007, at 1:29 AM, Geir Magnusson Jr. wrote:
>>
>>> Sorry Bill... traveling this week and behind...
>>>
>>> You don't *have* to do it in that order, but I've discovered that
>>> having that JIRA key makes it clearer in the records, but it can
>>> be in either order.
>>>
>>> So -
>>>
>>> 1) Add the license header to each file as described here :
>>>
>>> http://www.apache.org/legal/src-headers.html
>>>
>>> In particular, remove any (c) Artima if that happens to be in the
>>> code, or any of your own license headers or statements of
>>> ownership that may be in each file.
>>>
>>> 2) Put a copy of the Apache License (http://www.apache.org/
>>> licenses/LICENSE-2.0) into a file called LICENSE in the root of
>>> the distribution
>>>
>>> 3) If there are any pieces of software in the contribution that
>>> weren't created by you (came from elsewhere) and had any notice
>>> requirements in the license (such as a BSD notice requirement)
>>> then put those in a NOTICE file in the root of the distro.
>>>
>>> 4) If there were any (c) Artima, and you want that to persist
>>> somewhere, put a file COPYRIGHT in the root of the tree and put
>>> something like
>>>
>>> The following copyright notice(s) were affixed to portions of
>>> the
>>> code with which this file is now or was at one time
>>> distributed and
>>> are placed here unaltered.
>>>
>>> (C) Copyright XXXX Artima
>>>
>>> 5) Be sure that there is no code (c) anyone else - for example,
>>> one popular mistake is to submit schemas or such that may be (c)
>>> sun.
>>>
>>> 6) Bundle the tree into a tarball, create a new JIRA, then attach
>>> tarball to JIRA.
>>>
>>> 7) in the CCLA, where it has you list the contributions, put :
>>>
>>> <description> as submitted to the ASF via JIRA as RIVER-XXX
>>>
>>>
>>> geir
>>>
>>>
>>> On Jan 18, 2007, at 3:05 AM, Bill Venners wrote:
>>>
>>>> Hello,
>>>>
>>>> Can someone point me to the JIRA instance where I'm supposed to
>>>> submit ServiceUI? I haven't heard back from anyone on how to do
>>>> this, or how to package it. According to Geir, I should first
>>>> submit the code then fax in the signed agreement with the JIRA
>>>> ID of the submission on it.
>>>>
>>>> Thanks.
>>>>
>>>> Bill
>>>>
>>>> On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
>>>>
>>>>> Hi Geir,
>>>>>
>>>>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>>>>
>>>>>>
>>>>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>>>>
>>>>> I've finally prepped these docs, but I'm afraid I need a bit of
>>>>> hand-holding for submitting the code. How should I package
>>>>> ServiceUI, and where do I submit it via JIRA? What should be
>>>>> included in the package? Once I get it submitted, I can stick
>>>>> the JIRA ID on the CCLA itself and fax or mail it (whichever is
>>>>> preferred).
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Bill
>>>>>
>>>>>>>
>>>>>>>> 1) package and contribute via a JIRA
>>>>>>>>
>>>>>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>>>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>>>>>> what later...)
>>>>>>>>
>>>>>>>> 3) when the paperwork is done, project votes to accept the
>>>>>>>> contribution
>>>>>>>>
>>>>>>>> The last step is a way to clearly exercise active oversight
>>>>>>>> on the codebase - it means that people other than the
>>>>>>>> committer that eventually puts the code in SVN are paying
>>>>>>>> attention to what is entering SVN.
>>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> geir
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>>>>
>>>>>>>>> Hi Geir,
>>>>>>>>>
>>>>>>>>> What's will be the process for contributing ServiceUI? I am
>>>>>>>>> guessing I need to sign a Software Grant and CLA on behalf
>>>>>>>>> of Artima, and then perhaps a CLA for myself as an
>>>>>>>>> individual too?
>>>>>>>>>
>>>>>>>>> Bill
>>>>>>>>> ----
>>>>>>>>> Bill Venners
>>>>>>>>> President
>>>>>>>>> Artima, Inc.
>>>>>>>>> http://www.artima.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bill
>>>>>>> ----
>>>>>>> Bill Venners
>>>>>>> President
>>>>>>> Artima, Inc.
>>>>>>> http://www.artima.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Bill
>>>>> ----
>>>>> Bill Venners
>>>>> President
>>>>> Artima, Inc.
>>>>> http://www.artima.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
get he ICLA in sooner than later so we can do a group request for
accounts...
geir
On Jan 18, 2007, at 12:42 PM, Bill Venners wrote:
> Hi Geir,
>
> Great advice. Thanks. This is exciting. I'll get this in as soon as
> I can, and then I'll fax the Corp CLA, and ICLA. I've got them both
> signed here but I was waiting to fax them until after I submit the
> ServiceUI code.
>
> Bill
>
> On Jan 18, 2007, at 1:29 AM, Geir Magnusson Jr. wrote:
>
>> Sorry Bill... traveling this week and behind...
>>
>> You don't *have* to do it in that order, but I've discovered that
>> having that JIRA key makes it clearer in the records, but it can
>> be in either order.
>>
>> So -
>>
>> 1) Add the license header to each file as described here :
>>
>> http://www.apache.org/legal/src-headers.html
>>
>> In particular, remove any (c) Artima if that happens to be in the
>> code, or any of your own license headers or statements of
>> ownership that may be in each file.
>>
>> 2) Put a copy of the Apache License (http://www.apache.org/
>> licenses/LICENSE-2.0) into a file called LICENSE in the root of
>> the distribution
>>
>> 3) If there are any pieces of software in the contribution that
>> weren't created by you (came from elsewhere) and had any notice
>> requirements in the license (such as a BSD notice requirement)
>> then put those in a NOTICE file in the root of the distro.
>>
>> 4) If there were any (c) Artima, and you want that to persist
>> somewhere, put a file COPYRIGHT in the root of the tree and put
>> something like
>>
>> The following copyright notice(s) were affixed to portions of the
>> code with which this file is now or was at one time
>> distributed and
>> are placed here unaltered.
>>
>> (C) Copyright XXXX Artima
>>
>> 5) Be sure that there is no code (c) anyone else - for example,
>> one popular mistake is to submit schemas or such that may be (c) sun.
>>
>> 6) Bundle the tree into a tarball, create a new JIRA, then attach
>> tarball to JIRA.
>>
>> 7) in the CCLA, where it has you list the contributions, put :
>>
>> <description> as submitted to the ASF via JIRA as RIVER-XXX
>>
>>
>> geir
>>
>>
>> On Jan 18, 2007, at 3:05 AM, Bill Venners wrote:
>>
>>> Hello,
>>>
>>> Can someone point me to the JIRA instance where I'm supposed to
>>> submit ServiceUI? I haven't heard back from anyone on how to do
>>> this, or how to package it. According to Geir, I should first
>>> submit the code then fax in the signed agreement with the JIRA ID
>>> of the submission on it.
>>>
>>> Thanks.
>>>
>>> Bill
>>>
>>> On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
>>>
>>>> Hi Geir,
>>>>
>>>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>>>
>>>>>
>>>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>>>
>>>> I've finally prepped these docs, but I'm afraid I need a bit of
>>>> hand-holding for submitting the code. How should I package
>>>> ServiceUI, and where do I submit it via JIRA? What should be
>>>> included in the package? Once I get it submitted, I can stick
>>>> the JIRA ID on the CCLA itself and fax or mail it (whichever is
>>>> preferred).
>>>>
>>>> Thanks.
>>>>
>>>> Bill
>>>>
>>>>>>
>>>>>>> 1) package and contribute via a JIRA
>>>>>>>
>>>>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>>>>> what later...)
>>>>>>>
>>>>>>> 3) when the paperwork is done, project votes to accept the
>>>>>>> contribution
>>>>>>>
>>>>>>> The last step is a way to clearly exercise active oversight
>>>>>>> on the codebase - it means that people other than the
>>>>>>> committer that eventually puts the code in SVN are paying
>>>>>>> attention to what is entering SVN.
>>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> geir
>>>>>>>
>>>>>>>
>>>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>>>
>>>>>>>> Hi Geir,
>>>>>>>>
>>>>>>>> What's will be the process for contributing ServiceUI? I am
>>>>>>>> guessing I need to sign a Software Grant and CLA on behalf
>>>>>>>> of Artima, and then perhaps a CLA for myself as an
>>>>>>>> individual too?
>>>>>>>>
>>>>>>>> Bill
>>>>>>>> ----
>>>>>>>> Bill Venners
>>>>>>>> President
>>>>>>>> Artima, Inc.
>>>>>>>> http://www.artima.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bill
>>>>>> ----
>>>>>> Bill Venners
>>>>>> President
>>>>>> Artima, Inc.
>>>>>> http://www.artima.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Bill
>>>> ----
>>>> Bill Venners
>>>> President
>>>> Artima, Inc.
>>>> http://www.artima.com
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hi Geir,
Great advice. Thanks. This is exciting. I'll get this in as soon as I
can, and then I'll fax the Corp CLA, and ICLA. I've got them both
signed here but I was waiting to fax them until after I submit the
ServiceUI code.
Bill
On Jan 18, 2007, at 1:29 AM, Geir Magnusson Jr. wrote:
> Sorry Bill... traveling this week and behind...
>
> You don't *have* to do it in that order, but I've discovered that
> having that JIRA key makes it clearer in the records, but it can be
> in either order.
>
> So -
>
> 1) Add the license header to each file as described here :
>
> http://www.apache.org/legal/src-headers.html
>
> In particular, remove any (c) Artima if that happens to be in the
> code, or any of your own license headers or statements of ownership
> that may be in each file.
>
> 2) Put a copy of the Apache License (http://www.apache.org/licenses/
> LICENSE-2.0) into a file called LICENSE in the root of the
> distribution
>
> 3) If there are any pieces of software in the contribution that
> weren't created by you (came from elsewhere) and had any notice
> requirements in the license (such as a BSD notice requirement) then
> put those in a NOTICE file in the root of the distro.
>
> 4) If there were any (c) Artima, and you want that to persist
> somewhere, put a file COPYRIGHT in the root of the tree and put
> something like
>
> The following copyright notice(s) were affixed to portions of the
> code with which this file is now or was at one time distributed
> and
> are placed here unaltered.
>
> (C) Copyright XXXX Artima
>
> 5) Be sure that there is no code (c) anyone else - for example, one
> popular mistake is to submit schemas or such that may be (c) sun.
>
> 6) Bundle the tree into a tarball, create a new JIRA, then attach
> tarball to JIRA.
>
> 7) in the CCLA, where it has you list the contributions, put :
>
> <description> as submitted to the ASF via JIRA as RIVER-XXX
>
>
> geir
>
>
> On Jan 18, 2007, at 3:05 AM, Bill Venners wrote:
>
>> Hello,
>>
>> Can someone point me to the JIRA instance where I'm supposed to
>> submit ServiceUI? I haven't heard back from anyone on how to do
>> this, or how to package it. According to Geir, I should first
>> submit the code then fax in the signed agreement with the JIRA ID
>> of the submission on it.
>>
>> Thanks.
>>
>> Bill
>>
>> On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
>>
>>> Hi Geir,
>>>
>>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>>
>>>>
>>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>>
>>> I've finally prepped these docs, but I'm afraid I need a bit of
>>> hand-holding for submitting the code. How should I package
>>> ServiceUI, and where do I submit it via JIRA? What should be
>>> included in the package? Once I get it submitted, I can stick the
>>> JIRA ID on the CCLA itself and fax or mail it (whichever is
>>> preferred).
>>>
>>> Thanks.
>>>
>>> Bill
>>>
>>>>>
>>>>>> 1) package and contribute via a JIRA
>>>>>>
>>>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>>>> what later...)
>>>>>>
>>>>>> 3) when the paperwork is done, project votes to accept the
>>>>>> contribution
>>>>>>
>>>>>> The last step is a way to clearly exercise active oversight on
>>>>>> the codebase - it means that people other than the committer
>>>>>> that eventually puts the code in SVN are paying attention to
>>>>>> what is entering SVN.
>>>>>>
>>>>> Thanks.
>>>>>
>>>>> Bill
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> geir
>>>>>>
>>>>>>
>>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>>
>>>>>>> Hi Geir,
>>>>>>>
>>>>>>> What's will be the process for contributing ServiceUI? I am
>>>>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>>>>
>>>>>>> Bill
>>>>>>> ----
>>>>>>> Bill Venners
>>>>>>> President
>>>>>>> Artima, Inc.
>>>>>>> http://www.artima.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bill
>>>>> ----
>>>>> Bill Venners
>>>>> President
>>>>> Artima, Inc.
>>>>> http://www.artima.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> Bill
>>> ----
>>> Bill Venners
>>> President
>>> Artima, Inc.
>>> http://www.artima.com
>>>
>>>
>>>
>>>
>>
>
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Sorry Bill... traveling this week and behind...
You don't *have* to do it in that order, but I've discovered that
having that JIRA key makes it clearer in the records, but it can be
in either order.
So -
1) Add the license header to each file as described here :
http://www.apache.org/legal/src-headers.html
In particular, remove any (c) Artima if that happens to be in the
code, or any of your own license headers or statements of ownership
that may be in each file.
2) Put a copy of the Apache License (http://www.apache.org/licenses/
LICENSE-2.0) into a file called LICENSE in the root of the distribution
3) If there are any pieces of software in the contribution that
weren't created by you (came from elsewhere) and had any notice
requirements in the license (such as a BSD notice requirement) then
put those in a NOTICE file in the root of the distro.
4) If there were any (c) Artima, and you want that to persist
somewhere, put a file COPYRIGHT in the root of the tree and put
something like
The following copyright notice(s) were affixed to portions of the
code with which this file is now or was at one time distributed and
are placed here unaltered.
(C) Copyright XXXX Artima
5) Be sure that there is no code (c) anyone else - for example, one
popular mistake is to submit schemas or such that may be (c) sun.
6) Bundle the tree into a tarball, create a new JIRA, then attach
tarball to JIRA.
7) in the CCLA, where it has you list the contributions, put :
<description> as submitted to the ASF via JIRA as RIVER-XXX
geir
On Jan 18, 2007, at 3:05 AM, Bill Venners wrote:
> Hello,
>
> Can someone point me to the JIRA instance where I'm supposed to
> submit ServiceUI? I haven't heard back from anyone on how to do
> this, or how to package it. According to Geir, I should first
> submit the code then fax in the signed agreement with the JIRA ID
> of the submission on it.
>
> Thanks.
>
> Bill
>
> On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
>
>> Hi Geir,
>>
>> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>>
>>>
>>> yep - through the CCLA, Artima can license a copy to the ASF.
>>>
>> I've finally prepped these docs, but I'm afraid I need a bit of
>> hand-holding for submitting the code. How should I package
>> ServiceUI, and where do I submit it via JIRA? What should be
>> included in the package? Once I get it submitted, I can stick the
>> JIRA ID on the CCLA itself and fax or mail it (whichever is
>> preferred).
>>
>> Thanks.
>>
>> Bill
>>
>>>>
>>>>> 1) package and contribute via a JIRA
>>>>>
>>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>>> what later...)
>>>>>
>>>>> 3) when the paperwork is done, project votes to accept the
>>>>> contribution
>>>>>
>>>>> The last step is a way to clearly exercise active oversight on
>>>>> the codebase - it means that people other than the committer
>>>>> that eventually puts the code in SVN are paying attention to
>>>>> what is entering SVN.
>>>>>
>>>> Thanks.
>>>>
>>>> Bill
>>>>
>>>>
>>>>
>>>>
>>>>> geir
>>>>>
>>>>>
>>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>>
>>>>>> Hi Geir,
>>>>>>
>>>>>> What's will be the process for contributing ServiceUI? I am
>>>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>>>
>>>>>> Bill
>>>>>> ----
>>>>>> Bill Venners
>>>>>> President
>>>>>> Artima, Inc.
>>>>>> http://www.artima.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Bill
>>>> ----
>>>> Bill Venners
>>>> President
>>>> Artima, Inc.
>>>> http://www.artima.com
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> Bill
>> ----
>> Bill Venners
>> President
>> Artima, Inc.
>> http://www.artima.com
>>
>>
>>
>>
>
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hello,
Can someone point me to the JIRA instance where I'm supposed to
submit ServiceUI? I haven't heard back from anyone on how to do this,
or how to package it. According to Geir, I should first submit the
code then fax in the signed agreement with the JIRA ID of the
submission on it.
Thanks.
Bill
On Jan 15, 2007, at 12:07 PM, Bill Venners wrote:
> Hi Geir,
>
> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>
>>
>> yep - through the CCLA, Artima can license a copy to the ASF.
>>
> I've finally prepped these docs, but I'm afraid I need a bit of
> hand-holding for submitting the code. How should I package
> ServiceUI, and where do I submit it via JIRA? What should be
> included in the package? Once I get it submitted, I can stick the
> JIRA ID on the CCLA itself and fax or mail it (whichever is
> preferred).
>
> Thanks.
>
> Bill
>
>>>
>>>> 1) package and contribute via a JIRA
>>>>
>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>> what later...)
>>>>
>>>> 3) when the paperwork is done, project votes to accept the
>>>> contribution
>>>>
>>>> The last step is a way to clearly exercise active oversight on
>>>> the codebase - it means that people other than the committer
>>>> that eventually puts the code in SVN are paying attention to
>>>> what is entering SVN.
>>>>
>>> Thanks.
>>>
>>> Bill
>>>
>>>
>>>
>>>
>>>> geir
>>>>
>>>>
>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>
>>>>> Hi Geir,
>>>>>
>>>>> What's will be the process for contributing ServiceUI? I am
>>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>>
>>>>> Bill
>>>>> ----
>>>>> Bill Venners
>>>>> President
>>>>> Artima, Inc.
>>>>> http://www.artima.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> Bill
>>> ----
>>> Bill Venners
>>> President
>>> Artima, Inc.
>>> http://www.artima.com
>>>
>>>
>>>
>>
>>
>
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
See my other reply. Faxing is fine.
On Jan 15, 2007, at 5:07 PM, Bill Venners wrote:
> Hi Geir,
>
> On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>
>>
>> yep - through the CCLA, Artima can license a copy to the ASF.
>>
> I've finally prepped these docs, but I'm afraid I need a bit of
> hand-holding for submitting the code. How should I package
> ServiceUI, and where do I submit it via JIRA? What should be
> included in the package? Once I get it submitted, I can stick the
> JIRA ID on the CCLA itself and fax or mail it (whichever is
> preferred).
>
> Thanks.
>
> Bill
>
>>>
>>>> 1) package and contribute via a JIRA
>>>>
>>>> 2) submit an CCLA to the ASF Scty where the contribution is
>>>> noted by JIRA ID (makes it much easier to figure out what is
>>>> what later...)
>>>>
>>>> 3) when the paperwork is done, project votes to accept the
>>>> contribution
>>>>
>>>> The last step is a way to clearly exercise active oversight on
>>>> the codebase - it means that people other than the committer
>>>> that eventually puts the code in SVN are paying attention to
>>>> what is entering SVN.
>>>>
>>> Thanks.
>>>
>>> Bill
>>>
>>>
>>>
>>>
>>>> geir
>>>>
>>>>
>>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>>
>>>>> Hi Geir,
>>>>>
>>>>> What's will be the process for contributing ServiceUI? I am
>>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>>
>>>>> Bill
>>>>> ----
>>>>> Bill Venners
>>>>> President
>>>>> Artima, Inc.
>>>>> http://www.artima.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> Bill
>>> ----
>>> Bill Venners
>>> President
>>> Artima, Inc.
>>> http://www.artima.com
>>>
>>>
>>>
>>
>>
>
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hi Geir,
On Jan 3, 2007, at 1:44 PM, Geir Magnusson Jr. wrote:
>
> yep - through the CCLA, Artima can license a copy to the ASF.
>
I've finally prepped these docs, but I'm afraid I need a bit of hand-
holding for submitting the code. How should I package ServiceUI, and
where do I submit it via JIRA? What should be included in the
package? Once I get it submitted, I can stick the JIRA ID on the CCLA
itself and fax or mail it (whichever is preferred).
Thanks.
Bill
>>
>>> 1) package and contribute via a JIRA
>>>
>>> 2) submit an CCLA to the ASF Scty where the contribution is noted
>>> by JIRA ID (makes it much easier to figure out what is what
>>> later...)
>>>
>>> 3) when the paperwork is done, project votes to accept the
>>> contribution
>>>
>>> The last step is a way to clearly exercise active oversight on
>>> the codebase - it means that people other than the committer that
>>> eventually puts the code in SVN are paying attention to what is
>>> entering SVN.
>>>
>> Thanks.
>>
>> Bill
>>
>>
>>
>>
>>> geir
>>>
>>>
>>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>>
>>>> Hi Geir,
>>>>
>>>> What's will be the process for contributing ServiceUI? I am
>>>> guessing I need to sign a Software Grant and CLA on behalf of
>>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>>
>>>> Bill
>>>> ----
>>>> Bill Venners
>>>> President
>>>> Artima, Inc.
>>>> http://www.artima.com
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> Bill
>> ----
>> Bill Venners
>> President
>> Artima, Inc.
>> http://www.artima.com
>>
>>
>>
>
>
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 3, 2007, at 12:46 PM, Bill Venners wrote:
> Hi Geir,
>
> On Jan 3, 2007, at 9:29 AM, Geir Magnusson Jr. wrote:
>
>> Everyone reading this would be well served submitting a ICLA
>> now. :) You can find it here :
>>
>> http://www.apache.org/licenses/
>>
>> After that, to contribute code...
>>
>> 1) Is it currently under the apache (or better) license?
>>
> Apache 2.
>
>> 2) Who is the copyright holder?
>>
> Artima, Inc.
>
>> Generally, if you have the right to re-license the codebase to the
>> ASF, then look at the CCLA (which has a software grant in it).
>> What I have had people do in the past is :
>>
> OK. I'll check out the CCLA.
yep - through the CCLA, Artima can license a copy to the ASF.
>
>> 1) package and contribute via a JIRA
>>
>> 2) submit an CCLA to the ASF Scty where the contribution is noted
>> by JIRA ID (makes it much easier to figure out what is what later...)
>>
>> 3) when the paperwork is done, project votes to accept the
>> contribution
>>
>> The last step is a way to clearly exercise active oversight on the
>> codebase - it means that people other than the committer that
>> eventually puts the code in SVN are paying attention to what is
>> entering SVN.
>>
> Thanks.
>
> Bill
>
>
>
>
>> geir
>>
>>
>> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>>
>>> Hi Geir,
>>>
>>> What's will be the process for contributing ServiceUI? I am
>>> guessing I need to sign a Software Grant and CLA on behalf of
>>> Artima, and then perhaps a CLA for myself as an individual too?
>>>
>>> Bill
>>> ----
>>> Bill Venners
>>> President
>>> Artima, Inc.
>>> http://www.artima.com
>>>
>>>
>>>
>>
>>
>
>
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hi Geir,
On Jan 3, 2007, at 9:29 AM, Geir Magnusson Jr. wrote:
> Everyone reading this would be well served submitting a ICLA
> now. :) You can find it here :
>
> http://www.apache.org/licenses/
>
> After that, to contribute code...
>
> 1) Is it currently under the apache (or better) license?
>
Apache 2.
> 2) Who is the copyright holder?
>
Artima, Inc.
> Generally, if you have the right to re-license the codebase to the
> ASF, then look at the CCLA (which has a software grant in it).
> What I have had people do in the past is :
>
OK. I'll check out the CCLA.
> 1) package and contribute via a JIRA
>
> 2) submit an CCLA to the ASF Scty where the contribution is noted
> by JIRA ID (makes it much easier to figure out what is what later...)
>
> 3) when the paperwork is done, project votes to accept the
> contribution
>
> The last step is a way to clearly exercise active oversight on the
> codebase - it means that people other than the committer that
> eventually puts the code in SVN are paying attention to what is
> entering SVN.
>
Thanks.
Bill
> geir
>
>
> On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
>
>> Hi Geir,
>>
>> What's will be the process for contributing ServiceUI? I am
>> guessing I need to sign a Software Grant and CLA on behalf of
>> Artima, and then perhaps a CLA for myself as an individual too?
>>
>> Bill
>> ----
>> Bill Venners
>> President
>> Artima, Inc.
>> http://www.artima.com
>>
>>
>>
>
>
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Everyone reading this would be well served submitting a ICLA now. :)
You can find it here :
http://www.apache.org/licenses/
After that, to contribute code...
1) Is it currently under the apache (or better) license?
2) Who is the copyright holder?
Generally, if you have the right to re-license the codebase to the
ASF, then look at the CCLA (which has a software grant in it). What
I have had people do in the past is :
1) package and contribute via a JIRA
2) submit an CCLA to the ASF Scty where the contribution is noted by
JIRA ID (makes it much easier to figure out what is what later...)
3) when the paperwork is done, project votes to accept the contribution
The last step is a way to clearly exercise active oversight on the
codebase - it means that people other than the committer that
eventually puts the code in SVN are paying attention to what is
entering SVN.
geir
On Jan 3, 2007, at 11:05 AM, Bill Venners wrote:
> Hi Geir,
>
> What's will be the process for contributing ServiceUI? I am
> guessing I need to sign a Software Grant and CLA on behalf of
> Artima, and then perhaps a CLA for myself as an individual too?
>
> Bill
> ----
> Bill Venners
> President
> Artima, Inc.
> http://www.artima.com
>
>
>
Re: new site added to SVN and published
Posted by Bill Venners <bv...@artima.com>.
Hi Geir,
What's will be the process for contributing ServiceUI? I am guessing
I need to sign a Software Grant and CLA on behalf of Artima, and then
perhaps a CLA for myself as an individual too?
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Done - I created a simple "logo" for the top of the website, and
published that..
geir
On Jan 2, 2007, at 5:39 PM, Geir Magnusson Jr. wrote:
>
> On Jan 2, 2007, at 4:12 PM, Craig L Russell wrote:
>
>> I get a broken link with http (apparently due to <a href="http://
>> incubator.apache.org/river"><img src="./images/harmony-logo-
>> new.png" alt="Apache River (we need a logo)" /></a>
>> )
>
> Yah, I didn't know what to do w/ the logo at this point. I'll try
> to throw something together as a placeholder, and hopefully no one
> will hold a contest or anything yet :)
>
>>
>> and gateway timeout using https (Gateway Timeout Processing of
>> this request was delegated to a server that is not functioning
>> properly.).
>
> See my other reply. I didn't mean "check out the site" as in look
> at it, but rather "check the source out of SVN" if you wanted to
> offer updates ...
>
> geir
>
>>
>> Craig
>>
>> On Jan 2, 2007, at 1:02 PM, Bob Scheifler wrote:
>>
>>>> http://incubator.apache.org/river
>>>> All, please try to check it out (use https, please)
>>>
>>> Using https produces a Gateway Timeout for me, http works OK.
>>>
>>> - Bob
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2007, at 7:04 PM, Craig L Russell wrote:
> Hi Geir,
>
> On Jan 2, 2007, at 2:39 PM, Geir Magnusson Jr. wrote:
>
>> ...snip
>
>> See my other reply. I didn't mean "check out the site" as in look
>> at it, but rather "check the source out of SVN" if you wanted to
>> offer updates ...
>
> Gack. I never thought you were suggesting the obvious...
Sorry - completely my fault for not being clear
> By the way, how many people have commit access to the river site?
Right now, only the mentors.
geir
>
> Craig
>>
>> geir
>>
>>>
>>> Craig
>>>
>>> On Jan 2, 2007, at 1:02 PM, Bob Scheifler wrote:
>>>
>>>>> http://incubator.apache.org/river
>>>>> All, please try to check it out (use https, please)
>>>>
>>>> Using https produces a Gateway Timeout for me, http works OK.
>>>>
>>>> - Bob
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/
>>> products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Geir,
On Jan 2, 2007, at 2:39 PM, Geir Magnusson Jr. wrote:
> ...snip
> See my other reply. I didn't mean "check out the site" as in look
> at it, but rather "check the source out of SVN" if you wanted to
> offer updates ...
Gack. I never thought you were suggesting the obvious... By the way,
how many people have commit access to the river site?
Craig
>
> geir
>
>>
>> Craig
>>
>> On Jan 2, 2007, at 1:02 PM, Bob Scheifler wrote:
>>
>>>> http://incubator.apache.org/river
>>>> All, please try to check it out (use https, please)
>>>
>>> Using https produces a Gateway Timeout for me, http works OK.
>>>
>>> - Bob
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2007, at 4:12 PM, Craig L Russell wrote:
> I get a broken link with http (apparently due to <a href="http://
> incubator.apache.org/river"><img src="./images/harmony-logo-
> new.png" alt="Apache River (we need a logo)" /></a>
> )
Yah, I didn't know what to do w/ the logo at this point. I'll try to
throw something together as a placeholder, and hopefully no one will
hold a contest or anything yet :)
>
> and gateway timeout using https (Gateway Timeout Processing of this
> request was delegated to a server that is not functioning properly.).
See my other reply. I didn't mean "check out the site" as in look at
it, but rather "check the source out of SVN" if you wanted to offer
updates ...
geir
>
> Craig
>
> On Jan 2, 2007, at 1:02 PM, Bob Scheifler wrote:
>
>>> http://incubator.apache.org/river
>>> All, please try to check it out (use https, please)
>>
>> Using https produces a Gateway Timeout for me, http works OK.
>>
>> - Bob
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
I get a broken link with http (apparently due to <a href="http://
incubator.apache.org/river"><img src="./images/harmony-logo-new.png"
alt="Apache River (we need a logo)" /></a>
)
and gateway timeout using https (Gateway Timeout Processing of this
request was delegated to a server that is not functioning properly.).
Craig
On Jan 2, 2007, at 1:02 PM, Bob Scheifler wrote:
>> http://incubator.apache.org/river
>> All, please try to check it out (use https, please)
>
> Using https produces a Gateway Timeout for me, http works OK.
>
> - Bob
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by Bob Scheifler <Bo...@Sun.COM>.
> http://incubator.apache.org/river
>
> All, please try to check it out (use https, please)
Using https produces a Gateway Timeout for me, http works OK.
- Bob
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I added you to the incubator group - give it a whirl...
On Jan 3, 2007, at 5:28 PM, Phil Steitz wrote:
> On 1/3/07, Craig L Russell <Cr...@sun.com> wrote:
>>
>> It didn't take very long this time. It's live.
>
>
> Thanks!
>
> Phil
>
> Craig
>>
>> On Jan 3, 2007, at 1:52 PM, Craig L Russell wrote:
>>
>> > I still have incubator privs, and I just did the svn update. The
>> > site will be pushed in the fullness of time.
>> >
>> > Craig
>> >
>> > On Jan 3, 2007, at 10:31 AM, Phil Steitz wrote:
>> >
>> >>> > Sorry, I did not read that last line carefully and committed
>> some
>> >>> > typo fixes
>> >>> > directly. I assume that was OK, since the changes were only to
>> >>> fix
>> >>> > typos /
>> >>> > references to Harmony, etc.
>> >>>
>> >>> It's ok, but unless you changed the typos in both docs and xdocs,
>> >>> the
>> >>> changes in docs will be overwritten by the next build of the same
>> >>> page from the xdocs sources. The xdocs and docs content appear
>> to be
>> >>> in sync as of now...
>> >>> >
>> >>
>> >>
>> >> Yes, I committed both, per Geir's most excellent instructions in
>> >> the README
>> >> (though I had real trouble with step 4 ;-)
>> >>
>> >> Unfortunately, I am not (yet) in the incubator unix group, so was
>> >> unable to
>> >> do the svn up to "publish" the changes. Things should be fine for
>> >> subsequent updates/patches - just make sure to svn up local copies
>> >> before
>> >> making changes.
>> >
>> > Craig Russell
>> > Architect, Sun Java Enterprise System http://java.sun.com/
>> products/jdo
>> > 408 276-5638 mailto:Craig.Russell@sun.com
>> > P.S. A good JDO? O, Gasp!
>> >
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
Re: new site added to SVN and published
Posted by Phil Steitz <ph...@gmail.com>.
On 1/3/07, Craig L Russell <Cr...@sun.com> wrote:
>
> It didn't take very long this time. It's live.
Thanks!
Phil
Craig
>
> On Jan 3, 2007, at 1:52 PM, Craig L Russell wrote:
>
> > I still have incubator privs, and I just did the svn update. The
> > site will be pushed in the fullness of time.
> >
> > Craig
> >
> > On Jan 3, 2007, at 10:31 AM, Phil Steitz wrote:
> >
> >>> > Sorry, I did not read that last line carefully and committed some
> >>> > typo fixes
> >>> > directly. I assume that was OK, since the changes were only to
> >>> fix
> >>> > typos /
> >>> > references to Harmony, etc.
> >>>
> >>> It's ok, but unless you changed the typos in both docs and xdocs,
> >>> the
> >>> changes in docs will be overwritten by the next build of the same
> >>> page from the xdocs sources. The xdocs and docs content appear to be
> >>> in sync as of now...
> >>> >
> >>
> >>
> >> Yes, I committed both, per Geir's most excellent instructions in
> >> the README
> >> (though I had real trouble with step 4 ;-)
> >>
> >> Unfortunately, I am not (yet) in the incubator unix group, so was
> >> unable to
> >> do the svn up to "publish" the changes. Things should be fine for
> >> subsequent updates/patches - just make sure to svn up local copies
> >> before
> >> making changes.
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
It didn't take very long this time. It's live.
Craig
On Jan 3, 2007, at 1:52 PM, Craig L Russell wrote:
> I still have incubator privs, and I just did the svn update. The
> site will be pushed in the fullness of time.
>
> Craig
>
> On Jan 3, 2007, at 10:31 AM, Phil Steitz wrote:
>
>>> > Sorry, I did not read that last line carefully and committed some
>>> > typo fixes
>>> > directly. I assume that was OK, since the changes were only to
>>> fix
>>> > typos /
>>> > references to Harmony, etc.
>>>
>>> It's ok, but unless you changed the typos in both docs and xdocs,
>>> the
>>> changes in docs will be overwritten by the next build of the same
>>> page from the xdocs sources. The xdocs and docs content appear to be
>>> in sync as of now...
>>> >
>>
>>
>> Yes, I committed both, per Geir's most excellent instructions in
>> the README
>> (though I had real trouble with step 4 ;-)
>>
>> Unfortunately, I am not (yet) in the incubator unix group, so was
>> unable to
>> do the svn up to "publish" the changes. Things should be fine for
>> subsequent updates/patches - just make sure to svn up local copies
>> before
>> making changes.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
I still have incubator privs, and I just did the svn update. The site
will be pushed in the fullness of time.
Craig
On Jan 3, 2007, at 10:31 AM, Phil Steitz wrote:
>> > Sorry, I did not read that last line carefully and committed some
>> > typo fixes
>> > directly. I assume that was OK, since the changes were only to fix
>> > typos /
>> > references to Harmony, etc.
>>
>> It's ok, but unless you changed the typos in both docs and xdocs, the
>> changes in docs will be overwritten by the next build of the same
>> page from the xdocs sources. The xdocs and docs content appear to be
>> in sync as of now...
>> >
>
>
> Yes, I committed both, per Geir's most excellent instructions in
> the README
> (though I had real trouble with step 4 ;-)
>
> Unfortunately, I am not (yet) in the incubator unix group, so was
> unable to
> do the svn up to "publish" the changes. Things should be fine for
> subsequent updates/patches - just make sure to svn up local copies
> before
> making changes.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by Phil Steitz <ph...@gmail.com>.
On 1/3/07, Craig L Russell <Cr...@sun.com> wrote:
>
> Hi Phil,
>
> On Jan 2, 2007, at 8:37 PM, Phil Steitz wrote:
>
> > On 1/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >> I created a simple website using my standard ant and velocity based
> >> framework (easy to work with...) and checked that into SVN in /site.
> >> I also staged it for the public webserver - should be out there at
> >>
> >> http://incubator.apache.org/river
> >>
> >> in a few hours at most.
> >>
> >> All, please try to check it out (use https, please), and if there are
> >> things you want changed, lets submit patches to JIRA for now.
> >
> >
> > Sorry, I did not read that last line carefully and committed some
> > typo fixes
> > directly. I assume that was OK, since the changes were only to fix
> > typos /
> > references to Harmony, etc.
>
> It's ok, but unless you changed the typos in both docs and xdocs, the
> changes in docs will be overwritten by the next build of the same
> page from the xdocs sources. The xdocs and docs content appear to be
> in sync as of now...
> >
Yes, I committed both, per Geir's most excellent instructions in the README
(though I had real trouble with step 4 ;-)
Unfortunately, I am not (yet) in the incubator unix group, so was unable to
do the svn up to "publish" the changes. Things should be fine for
subsequent updates/patches - just make sure to svn up local copies before
making changes.
> Something that I would like to discuss is whether we are really
> > going to use
> > STATUS as described on the guidelines page. Some of the verbiage
> > there
> > makes it look like we will be using the STATUS file + dev list as
> > a sort of
> > surrogate for JIRA. For example,
> >
> > "When a specific change to the software is proposed for discussion
> > or voting
> > on the mailing list, it should be presented in the form of input to
> > the
> > patch command. When sent to the mailing list, the message should
> > contain a
> > Subject beginning with [PATCH] and a distinctive one-line summary
> > corresponding to the action item for that patch. Afterwards, the patch
> > summary in the STATUS file should be updated to point to the
> > Message-ID of
> > that message."
> >
> > I would expect to see the process here 1) discuss idea on the list
> > 2) open
> > JIRA ticket 3) add patch to ticket and subsequently refer to the
> > ticket
> > number in discussion.
>
> Yes, I agree. If the project is going to use JIRA, this process
> should be changed to specify how to use JIRA.
>
> As Geir said, this is a first cut at a pretty big job, and one of the
> good things about the volume of the site that Geir set up is that
> there is lots of stuff to discuss on the alias. Like the governance
> model including how to submit changes.
> >
> > I know that we *must* maintain a STATUS file to track incubation-
> > related
> > tasks, but I don't see the value in tracking all development tasks
> > in this
> > file, when we have JIRA available. What am I missing here?
>
> Maybe you could update the patch process paragraph above and propose
> it to the community as a substitute. Then update the xdocs site with
> the results of the discussion.
Looks like the discussion has started. I will consolidate and update.
A good discussion might be whether to use JIRA for site updates. For
> trivial updates like you mentioned, it's probably more trouble than
> it's worth.
>
> By the way, the process to update the web site is documented at river/
> site/README.txt. Terse but well worth reading.
Craig
> >
> > Phil
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 3, 2007, at 3:24 AM, Mark Brouwer wrote:
> Craig L Russell wrote:
>
>> It's ok, but unless you changed the typos in both docs and xdocs,
>> the changes in docs will be overwritten by the next build of the
>> same page from the xdocs sources. The xdocs and docs content
>> appear to be in sync as of now...
>
> Is there a particular reason why the generated site must be checked in
> as well, besides how it works right now?
The rationale is that
1) you can do QA - you can always be sure that the bits that are
being published are the same bits that you checked with your browser
locally on your system.
2) In the event of loss o a machine, it's easy to simply pull the
site out of SVN and deploy, w/o having to get all the tooling in
place to regen (if you are ASF infra, for example)
It also makes it easy to add the site to any distributions of the
software (which I think is useful, especially if you get the docs on
the website)
>
> I haven't a full understanding of modifying the content of the
> site, but
> if the xdocs are the sources to be converted in the content to be
> served
> by the web server to me it seems that only the source should be in the
> repository as this seems to be asking for troubles. People
> modifying the
> wrong content, forgetting to check in newly generated pages, etc.
>
> Maybe I'm worrying about nothing, but no doubt I will be told ;-)
It's really not a problem in practice. The only time it bites is
when you forget to add new pages, but that can happen for source too
just as easily.
Usual work pattern is :
$ svn update
<make modifications>
$ ant
<check mods>
$ svn commit
with an optional $svn add xxxxx if there are new things to add and
to be sure, follow with $svn stat to make sure you got everything.
>
>>> I would expect to see the process here 1) discuss idea on the
>>> list 2) open
>>> JIRA ticket 3) add patch to ticket and subsequently refer to the
>>> ticket
>>> number in discussion.
>
> Agreed, but for rather trivial things such as "correct typos in ...",
> "clean formatting ..." I hope we can skip 1) and if it is really
> trivial and can be done as part of another piece of work even 2)
>
>> Yes, I agree. If the project is going to use JIRA, this process
>> should be changed to specify how to use JIRA.
>
> +1 for JIRA
>
>> A good discussion might be whether to use JIRA for site updates.
>> For trivial updates like you mentioned, it's probably more trouble
>> than it's worth.
>
> +1 for JIRA for site updates, in fact I hope to have the same
> process as
> you suggested with the same exceptions I mentioned before. As long as
> the site is a separate component in JIRA.
>
>> By the way, the process to update the web site is documented at
>> river/site/README.txt. Terse but well worth reading.
>
> Next thing for me to do.
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Craig L Russell wrote:
> It's ok, but unless you changed the typos in both docs and xdocs, the
> changes in docs will be overwritten by the next build of the same page
> from the xdocs sources. The xdocs and docs content appear to be in sync
> as of now...
Is there a particular reason why the generated site must be checked in
as well, besides how it works right now?
I haven't a full understanding of modifying the content of the site, but
if the xdocs are the sources to be converted in the content to be served
by the web server to me it seems that only the source should be in the
repository as this seems to be asking for troubles. People modifying the
wrong content, forgetting to check in newly generated pages, etc.
Maybe I'm worrying about nothing, but no doubt I will be told ;-)
>> I would expect to see the process here 1) discuss idea on the list 2)
>> open
>> JIRA ticket 3) add patch to ticket and subsequently refer to the ticket
>> number in discussion.
Agreed, but for rather trivial things such as "correct typos in ...",
"clean formatting ..." I hope we can skip 1) and if it is really
trivial and can be done as part of another piece of work even 2)
> Yes, I agree. If the project is going to use JIRA, this process should
> be changed to specify how to use JIRA.
+1 for JIRA
> A good discussion might be whether to use JIRA for site updates. For
> trivial updates like you mentioned, it's probably more trouble than it's
> worth.
+1 for JIRA for site updates, in fact I hope to have the same process as
you suggested with the same exceptions I mentioned before. As long as
the site is a separate component in JIRA.
> By the way, the process to update the web site is documented at
> river/site/README.txt. Terse but well worth reading.
Next thing for me to do.
--
Mark
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Phil,
On Jan 2, 2007, at 8:37 PM, Phil Steitz wrote:
> On 1/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> I created a simple website using my standard ant and velocity based
>> framework (easy to work with...) and checked that into SVN in /site.
>> I also staged it for the public webserver - should be out there at
>>
>> http://incubator.apache.org/river
>>
>> in a few hours at most.
>>
>> All, please try to check it out (use https, please), and if there are
>> things you want changed, lets submit patches to JIRA for now.
>
>
> Sorry, I did not read that last line carefully and committed some
> typo fixes
> directly. I assume that was OK, since the changes were only to fix
> typos /
> references to Harmony, etc.
It's ok, but unless you changed the typos in both docs and xdocs, the
changes in docs will be overwritten by the next build of the same
page from the xdocs sources. The xdocs and docs content appear to be
in sync as of now...
>
> Something that I would like to discuss is whether we are really
> going to use
> STATUS as described on the guidelines page. Some of the verbiage
> there
> makes it look like we will be using the STATUS file + dev list as
> a sort of
> surrogate for JIRA. For example,
>
> "When a specific change to the software is proposed for discussion
> or voting
> on the mailing list, it should be presented in the form of input to
> the
> patch command. When sent to the mailing list, the message should
> contain a
> Subject beginning with [PATCH] and a distinctive one-line summary
> corresponding to the action item for that patch. Afterwards, the patch
> summary in the STATUS file should be updated to point to the
> Message-ID of
> that message."
>
> I would expect to see the process here 1) discuss idea on the list
> 2) open
> JIRA ticket 3) add patch to ticket and subsequently refer to the
> ticket
> number in discussion.
Yes, I agree. If the project is going to use JIRA, this process
should be changed to specify how to use JIRA.
As Geir said, this is a first cut at a pretty big job, and one of the
good things about the volume of the site that Geir set up is that
there is lots of stuff to discuss on the alias. Like the governance
model including how to submit changes.
>
> I know that we *must* maintain a STATUS file to track incubation-
> related
> tasks, but I don't see the value in tracking all development tasks
> in this
> file, when we have JIRA available. What am I missing here?
Maybe you could update the patch process paragraph above and propose
it to the community as a substitute. Then update the xdocs site with
the results of the discussion.
A good discussion might be whether to use JIRA for site updates. For
trivial updates like you mentioned, it's probably more trouble than
it's worth.
By the way, the process to update the web site is documented at river/
site/README.txt. Terse but well worth reading.
Craig
>
> Phil
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 3, 2007, at 9:25 AM, Geir Magnusson Jr. wrote:
>
> On Jan 3, 2007, at 10:28 AM, Mark Brouwer wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>>> I disagree. For cheiron.org I do most of the work myself, but
>>>> nevertheless anything substantial is going through JIRA if it
>>>> was only
>>>> to keep track of things done for the release notes. Especially
>>>> when you
>>>> already have a stable codebase gradually improving and getting
>>>> bug-fixed. But I admit with complete new projects I tend to be less
>>>> bureaucratic.
>>> Do you mean
>>> a) you make all the changes, make a patch, submit it to JIRA,
>>> download the patch, apply the patch to a fresh tree, and then commit
>>
>> Not exactly. I work either on the main codeline or in some version
>> branch, but not before there is an JIRA issue created for the
>> task, bug
>> or improvement at hand. The JIRA issue is sent to the developer
>> mailing
>> list (no seperate list for generated artifacts) so other interested
>> people can see whether they think the issue is relevant or not.
>
> I see
>
>>
>> When I start working on it, JIRA sends a message to the dev list so
>> people know I'm about to start coding.
JIRA is nice in that any change of status of an issue gets sent to
the distribution. It's a matter of discipline that committers
actually use JIRA to "start an issue" so the notices get sent.
>> After I check in my code
>> directly into the repository I resolve the issue which leads to a
>> post
>> from JIRA to the dev list. In case of commit before review I
>> suggest one
>> waits a while with resolving the issue.
Both JIRA and svn will generate notices to the rest of the team.
>>
>> No patches are submitted to JIRA, for those that have no commit
>> rights I
>> also think that sending the patch to the dev list is the best
>> thing to
>> do. No need to attach that one to the isse. When the patch is
>> accepted
>> and committed by one of the committers the issue can be resolved.
>
> That's one thing you may want to modify - ask that patches are
> posted to the JIRA, as it requires the submitter to explicitly
> acknowledge that the stuff is contributed under the terms of the
> Apache License. Keeps any questions about what's a contribution to
> a minimum...
This is a very important part of the Apache Way. Contributors really
should sign CLAs which legally binds contributions. The tick box on
JIRA attachments also reminds folks that the patch is in fact a
contribution.
>
>>
>> I realize this won't work exactly the same way as for the projects
>> I'm
>> working on, but still hope to see maybe a somewhat more formal way of
>> working or at least for some parts of the project.
>
> It's up to you guys.
>
>>
>>> b) note changes in JIRA afterwards
>>
>> Or during the process of receiving patches, discussing and
>> committing them.
>>
>>> c) something else?
>>> I think b) is fine, if you are simply looking for a change
>>> tracking tool, although if you build a decent commit message
>>> discipline into the community, you can also just ask SVN what
>>> changed between releases... and that should be far more accurate.
>>
>> Often it requires multiple changes to the code for the same issue
>> before
>> everybody is happy (I think/hope this will be a very picky
>> community :-)
JIRA works well for this case as well. I like to have code uploaded
to JIRA instead of scouring emails for patches. JIRA allows you to
replace a patch with "the latest" code in progress, and it's easy for
reviewers to apply the patch and comment, iterating on the proposed
fix before svn commit.
>> and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
>> report generated by SVN contain a lot of clutter in that case.
>> Also for
>> release notes I really like the issue description instead of the
>> comments people in general use for their commit.
I agree. Once an issue has been beaten to death on JIRA, the commit
message can be relatively brief. commit -m "RIVER-123 added
snarfgargle to mediation requests" src/java
>>
>> If I recall correctly the Jini team didn't write a single character
>> before there was an issue in their tracking system. I adopted this
>> style
>> and found it worth while on a rather stable codebase. I'm curious to
>> know what the others think of this.
I like this approach as well. I've seen both discuss on the dev alias
and discuss on the JIRA issue work well, so this is a matter for the
team to work on. It might not even be necessary to formalize where
the discussion takes place. Some people like having it all on the
JIRA issue; some prefer to follow threaded discussions on aliases.
But basically having a JIRA to track all code changes is a statement
of formality that should be agreed by the community.
>>
>> And maybe I'm completely out of bounds here but I think that even
>> some
>> form of issue planning (in what version to expect what) can be
>> beneficial as well, JIRA is great for that too.
>
> Yep. It is. But be careful to keep things as open and welcoming
> to volunteers. Rigid process is off-putting to some people.
>>
>>>>> JIRA is great for tracking, but there are things to be cautious
>>>>> of - I've experienced technical discussion moving into the
>>>>> JIRA itself, which I think is not good, because it loses the
>>>>> bigger audience (IMO). I hate having to read JIRA discussions
>>>>> on the JIRA-generated emails, and it makes it hard to
>>>>> participate offline (unlike email) or search (unlike email...)
>>>>
>>>> I'm aware of that but in case of tasks to be implemented
>>>> somewhere in
>>>> the future I like to see any conclusions of discussion in JIRA
>>>> versus
>>>> digging them from my email archive.
>>> That's fine - that's a good use of JIRA. But you can simply just
>>> put a URL to the mail archive in the JIRA... easy to find later.
>>
>> That is possible, but I'm inclined to describe the summary of such an
>> issue neatly in JIRA. But as I've not that much experience with
>> working
>> in an ASF style project opposed to playing a dictator I really don't
>> know what will work the best.
Well, this should be interesting. There are a wide range of working
styles in Apache projects that depends a lot on the community who are
actively working on the project. It might be good to propose some of
the guidelines as updates to the site and see what people think. That
way, it's not just talk; it's proposed action.
Craig
>> --
>> Mark
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mark,
On Jan 4, 2007, at 3:04 AM, Mark Brouwer wrote:
> Phil Steitz wrote:
>
>>> > And maybe I'm completely out of bounds here but I think that
>>> even some
>>> > form of issue planning (in what version to expect what) can be
>>> > beneficial as well, JIRA is great for that too.
>>>
>>> Yep. It is. But be careful to keep things as open and welcoming to
>>> volunteers. Rigid process is off-putting to some people.
>> +1
>> There is a balance here to be struck. The process that I outlined
>> was for
>> submissions by non-committers, which requires that patches be
>> submitted and
>> I think it is in general much better to have the patches attached
>> to Jira
>> tickets than to have them arrive in emails.
>
> I personally favor a uniform way of working between committers and
> non-committers, the only difference is that committers have checkin
> permissions, the ability to resolve issues in JIRA [1] and assuming we
> want all committers to be part of the PMC a binding vote if that turns
> out to be valuable.
>
> [1] as the ASF runs the Enterprise edition of JIRA I assume we can
> setup our own permission schemes, etc. for the project?
Yes, it is possible, although recently the permission schemes were
mostly reset to the standard permission scheme, including river. Many
projects had trivial (but not meaningless) differences among each
other, and now most projects have the same permission scheme. Of
course, all projects have different notification schemes that refer
to their own aliases...
>
> Also can somebody show me a good project where they use JIRA for
> submitting the patches by (non-)committers, I have the tendency to
> always pick the wrong ones for my samples.
I don't know how good it is, but JDO http://issues.apache.org/jira/
secure/BrowseProject.jspa?id=10630 encourages patches to be posted
for review on the JIRA issue before being checked in. I don't have a
good example of a patch posted by a non-committer, but see http://
issues.apache.org/jira/browse/JDO-445 for how it works in practice.
>
>> That's a great practice (discuss on list, summarize in ticket);
>> but hard to
>> get volunteers to do uniformly. Good examples tend to get
>> followed, though
>> ;-)
Probably my biggest frustration with this is having significant
discussion happening simultaneously on the JIRA issue and on the
email aliases. What I try to do is to start the discussion on email
until there is some consensus that "somebody ought to do something"
at which point a JIRA is created, the email discussion is summarized
as the starting description for the JIRA and the discussion continues
on the JIRA.
But each community at Apache is encouraged to find their own working
style.
Craig
>
> In general they do ... :-)
> --
> Mark
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: new site added to SVN and published
Posted by Nigel Daley <nd...@mac.com>.
On Jan 4, 2007, at 3:04 AM, Mark Brouwer wrote:
> Phil Steitz wrote:
>
>>> > And maybe I'm completely out of bounds here but I think that
>>> even some
>>> > form of issue planning (in what version to expect what) can be
>>> > beneficial as well, JIRA is great for that too.
>>>
>>> Yep. It is. But be careful to keep things as open and welcoming to
>>> volunteers. Rigid process is off-putting to some people.
>> +1
>> There is a balance here to be struck. The process that I outlined
>> was for
>> submissions by non-committers, which requires that patches be
>> submitted and
>> I think it is in general much better to have the patches attached
>> to Jira
>> tickets than to have them arrive in emails.
>
> I personally favor a uniform way of working between committers and
> non-committers, the only difference is that committers have checkin
> permissions, the ability to resolve issues in JIRA [1] and assuming we
> want all committers to be part of the PMC a binding vote if that turns
> out to be valuable.
+1
> [1] as the ASF runs the Enterprise edition of JIRA I assume we can
> setup our own permission schemes, etc. for the project?
>
> Also can somebody show me a good project where they use JIRA for
> submitting the patches by (non-)committers, I have the tendency to
> always pick the wrong ones for my samples.
The majority of the patches submitted in the Hadoop community (http://
lucene.apache.org/hadoop) are submitted by non-committers: http://
issues.apache.org/jira/browse/HADOOP
The submitter marks a patch as "Patch Available" when it has been
code review and tested. Those with commit rights can then look over
and commit patches that are in this state. From my short experience
with this community, it seems to work well.
Cheers,
Nige
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Phil Steitz wrote:
>> > And maybe I'm completely out of bounds here but I think that even some
>> > form of issue planning (in what version to expect what) can be
>> > beneficial as well, JIRA is great for that too.
>>
>> Yep. It is. But be careful to keep things as open and welcoming to
>> volunteers. Rigid process is off-putting to some people.
>
>
> +1
>
> There is a balance here to be struck. The process that I outlined was for
> submissions by non-committers, which requires that patches be submitted and
> I think it is in general much better to have the patches attached to Jira
> tickets than to have them arrive in emails.
I personally favor a uniform way of working between committers and
non-committers, the only difference is that committers have checkin
permissions, the ability to resolve issues in JIRA [1] and assuming we
want all committers to be part of the PMC a binding vote if that turns
out to be valuable.
[1] as the ASF runs the Enterprise edition of JIRA I assume we can
setup our own permission schemes, etc. for the project?
Also can somebody show me a good project where they use JIRA for
submitting the patches by (non-)committers, I have the tendency to
always pick the wrong ones for my samples.
> That's a great practice (discuss on list, summarize in ticket); but hard to
> get volunteers to do uniformly. Good examples tend to get followed, though
> ;-)
In general they do ... :-)
--
Mark
Re: new site added to SVN and published
Posted by Phil Steitz <ph...@gmail.com>.
On 1/3/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> On Jan 3, 2007, at 10:28 AM, Mark Brouwer wrote:
>
> > Geir Magnusson Jr. wrote:
> >
> >>> I disagree. For cheiron.org I do most of the work myself, but
> >>> nevertheless anything substantial is going through JIRA if it was
> >>> only
> >>> to keep track of things done for the release notes. Especially
> >>> when you
> >>> already have a stable codebase gradually improving and getting
> >>> bug-fixed. But I admit with complete new projects I tend to be less
> >>> bureaucratic.
> >> Do you mean
> >> a) you make all the changes, make a patch, submit it to JIRA,
> >> download the patch, apply the patch to a fresh tree, and then commit
> >
> > Not exactly. I work either on the main codeline or in some version
> > branch, but not before there is an JIRA issue created for the task,
> > bug
> > or improvement at hand. The JIRA issue is sent to the developer
> > mailing
> > list (no seperate list for generated artifacts) so other interested
> > people can see whether they think the issue is relevant or not.
>
> I see
>
> >
> > When I start working on it, JIRA sends a message to the dev list so
> > people know I'm about the start coding. After I check in my code
> > directly into the repository I resolve the issue which leads to a post
> > from JIRA to the dev list. In case of commit before review I
> > suggest one
> > waits a while with resolving the issue.
> >
> > No patches are submitted to JIRA, for those that have no commit
> > rights I
> > also think that sending the patch to the dev list is the best thing to
> > do. No need to attach that one to the isse. When the patch is accepted
> > and committed by one of the committers the issue can be resolved.
>
> That's one thing you may want to modify - ask that patches are posted
> to the JIRA, as it requires the submitter to explicitly acknowledge
> that the stuff is contributed under the terms of the Apache License.
> Keeps any questions about what's a contribution to a minimum...
>
> >
> > I realize this won't work exactly the same way as for the projects I'm
> > working on, but still hope to see maybe a somewhat more formal way of
> > working or at least for some parts of the project.
>
> It's up to you guys.
+1 (its up to you guys) and it doesn't have to be written in stone
>
> >> b) note changes in JIRA afterwards
> >
> > Or during the process of receiving patches, discussing and
> > committing them.
> >
> >> c) something else?
> >> I think b) is fine, if you are simply looking for a change
> >> tracking tool, although if you build a decent commit message
> >> discipline into the community, you can also just ask SVN what
> >> changed between releases... and that should be far more accurate.
> >
> > Often it requires multiple changes to the code for the same issue
> > before
> > everybody is happy (I think/hope this will be a very picky
> > community :-)
> > and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
> > report generated by SVN contain a lot of clutter in that case. Also
> > for
> > release notes I really like the issue description instead of the
> > comments people in general use for their commit.
> >
> > If I recall correctly the Jini team didn't write a single character
> > before there was an issue in their tracking system. I adopted this
> > style
> > and found it worth while on a rather stable codebase. I'm curious to
> > know what the others think of this.
> >
> > And maybe I'm completely out of bounds here but I think that even some
> > form of issue planning (in what version to expect what) can be
> > beneficial as well, JIRA is great for that too.
>
> Yep. It is. But be careful to keep things as open and welcoming to
> volunteers. Rigid process is off-putting to some people.
+1
There is a balance here to be struck. The process that I outlined was for
submissions by non-committers, which requires that patches be submitted and
I think it is in general much better to have the patches attached to Jira
tickets than to have them arrive in emails.
Different apache projects use Jira differently and the benefits of always
opening tickets for non-trivial changes that Mark describes make life easier
for release managers and some would argue for volunteers looking for things
to work on. I personally favor creating tickets for all significant
changes. Others don't want so much process. Its really up to you the
community to decide. We just need to remember to be open and patient with
new contributors learning whatever process we agree on and not feel
compelled to formalize everything immediately (or ever, actually ;-)
>
> >>>> JIRA is great for tracking, but there are things to be cautious
> >>>> of - I've experienced technical discussion moving into the JIRA
> >>>> itself, which I think is not good, because it loses the bigger
> >>>> audience (IMO). I hate having to read JIRA discussions on the
> >>>> JIRA-generated emails, and it makes it hard to participate
> >>>> offline (unlike email) or search (unlike email...)
> >>>
> >>> I'm aware of that but in case of tasks to be implemented
> >>> somewhere in
> >>> the future I like to see any conclusions of discussion in JIRA
> >>> versus
> >>> digging them from my email archive.
> >> That's fine - that's a good use of JIRA. But you can simply just
> >> put a URL to the mail archive in the JIRA... easy to find later.
> >
> > That is possible, but I'm inclined to describe the summary of such an
> > issue neatly in JIRA. But as I've not that much experience with
> > working
> > in an ASF style project opposed to playing a dictator I really don't
> > know what will work the best.
That's a great practice (discuss on list, summarize in ticket); but hard to
get volunteers to do uniformly. Good examples tend to get followed, though
;-)
Phil
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 3, 2007, at 10:28 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>
>>> I disagree. For cheiron.org I do most of the work myself, but
>>> nevertheless anything substantial is going through JIRA if it was
>>> only
>>> to keep track of things done for the release notes. Especially
>>> when you
>>> already have a stable codebase gradually improving and getting
>>> bug-fixed. But I admit with complete new projects I tend to be less
>>> bureaucratic.
>> Do you mean
>> a) you make all the changes, make a patch, submit it to JIRA,
>> download the patch, apply the patch to a fresh tree, and then commit
>
> Not exactly. I work either on the main codeline or in some version
> branch, but not before there is an JIRA issue created for the task,
> bug
> or improvement at hand. The JIRA issue is sent to the developer
> mailing
> list (no seperate list for generated artifacts) so other interested
> people can see whether they think the issue is relevant or not.
I see
>
> When I start working on it, JIRA sends a message to the dev list so
> people know I'm about the start coding. After I check in my code
> directly into the repository I resolve the issue which leads to a post
> from JIRA to the dev list. In case of commit before review I
> suggest one
> waits a while with resolving the issue.
>
> No patches are submitted to JIRA, for those that have no commit
> rights I
> also think that sending the patch to the dev list is the best thing to
> do. No need to attach that one to the isse. When the patch is accepted
> and committed by one of the committers the issue can be resolved.
That's one thing you may want to modify - ask that patches are posted
to the JIRA, as it requires the submitter to explicitly acknowledge
that the stuff is contributed under the terms of the Apache License.
Keeps any questions about what's a contribution to a minimum...
>
> I realize this won't work exactly the same way as for the projects I'm
> working on, but still hope to see maybe a somewhat more formal way of
> working or at least for some parts of the project.
It's up to you guys.
>
>> b) note changes in JIRA afterwards
>
> Or during the process of receiving patches, discussing and
> committing them.
>
>> c) something else?
>> I think b) is fine, if you are simply looking for a change
>> tracking tool, although if you build a decent commit message
>> discipline into the community, you can also just ask SVN what
>> changed between releases... and that should be far more accurate.
>
> Often it requires multiple changes to the code for the same issue
> before
> everybody is happy (I think/hope this will be a very picky
> community :-)
> and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
> report generated by SVN contain a lot of clutter in that case. Also
> for
> release notes I really like the issue description instead of the
> comments people in general use for their commit.
>
> If I recall correctly the Jini team didn't write a single character
> before there was an issue in their tracking system. I adopted this
> style
> and found it worth while on a rather stable codebase. I'm curious to
> know what the others think of this.
>
> And maybe I'm completely out of bounds here but I think that even some
> form of issue planning (in what version to expect what) can be
> beneficial as well, JIRA is great for that too.
Yep. It is. But be careful to keep things as open and welcoming to
volunteers. Rigid process is off-putting to some people.
>
>>>> JIRA is great for tracking, but there are things to be cautious
>>>> of - I've experienced technical discussion moving into the JIRA
>>>> itself, which I think is not good, because it loses the bigger
>>>> audience (IMO). I hate having to read JIRA discussions on the
>>>> JIRA-generated emails, and it makes it hard to participate
>>>> offline (unlike email) or search (unlike email...)
>>>
>>> I'm aware of that but in case of tasks to be implemented
>>> somewhere in
>>> the future I like to see any conclusions of discussion in JIRA
>>> versus
>>> digging them from my email archive.
>> That's fine - that's a good use of JIRA. But you can simply just
>> put a URL to the mail archive in the JIRA... easy to find later.
>
> That is possible, but I'm inclined to describe the summary of such an
> issue neatly in JIRA. But as I've not that much experience with
> working
> in an ASF style project opposed to playing a dictator I really don't
> know what will work the best.
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Nigel,
Nigel Daley wrote:
>> Often it requires multiple changes to the code for the same issue before
>> everybody is happy (I think/hope this will be a very picky community :-)
>> and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
>> report generated by SVN contain a lot of clutter in that case. Also for
>> release notes I really like the issue description instead of the
>> comments people in general use for their commit.
>
> +1. I suspect a CHANGES.txt file that is hand maintained by committers
> may be more useful at release time.
I always create a RELNOTES file in which I copy the JIRA generated
release notes, and provide a link to JIRA where everybody can generate
the release notes himself against a given version.
Look at
http://scm.cheiron.org:1665/@md=d&cd=//cheiron/seven/version/0.1/&cdf=//cheiron/seven/version/0.1/RELNOTES&sr=189&c=5uP@//cheiron/seven/version/0.1/RELNOTES
for an example.
>> If I recall correctly the Jini team didn't write a single character
>> before there was an issue in their tracking system. I adopted this style
>> and found it worth while on a rather stable codebase. I'm curious to
>> know what the others think of this.
>
> In my (limited) experience with an ASF project, occasionally a JIRA is
> created and a patch is attached to it all within a minute. Clearly the
> person had completed the patch before creating a JIRA. Are you saying
> to want to preclude this? I don't see a reason to.
I don't want to preclude that when it is only occasionally, I do that
sometimes too. But I must admit I only do it for the task that just
pop-up and can be solved in the minute (those highly rewarding ones).
Anything else has the smell of secretly working on some stuff and sneak
in with good hopes nobody notices ;-)
--
Mark
Re: new site added to SVN and published
Posted by Nigel Daley <nd...@mac.com>.
On Jan 3, 2007, at 7:28 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>
>>> I disagree. For cheiron.org I do most of the work myself, but
>>> nevertheless anything substantial is going through JIRA if it was
>>> only
>>> to keep track of things done for the release notes. Especially
>>> when you
>>> already have a stable codebase gradually improving and getting
>>> bug-fixed. But I admit with complete new projects I tend to be less
>>> bureaucratic.
>> Do you mean
>> a) you make all the changes, make a patch, submit it to JIRA,
>> download the patch, apply the patch to a fresh tree, and then commit
>
> Not exactly. I work either on the main codeline or in some version
> branch, but not before there is an JIRA issue created for the task,
> bug
> or improvement at hand. The JIRA issue is sent to the developer
> mailing
> list (no seperate list for generated artifacts) so other interested
> people can see whether they think the issue is relevant or not.
>
> When I start working on it, JIRA sends a message to the dev list so
> people know I'm about the start coding. After I check in my code
> directly into the repository I resolve the issue which leads to a post
> from JIRA to the dev list. In case of commit before review I
> suggest one
> waits a while with resolving the issue.
>
> No patches are submitted to JIRA, for those that have no commit
> rights I
> also think that sending the patch to the dev list is the best thing to
> do. No need to attach that one to the isse. When the patch is accepted
> and committed by one of the committers the issue can be resolved.
>
> I realize this won't work exactly the same way as for the projects I'm
> working on, but still hope to see maybe a somewhat more formal way of
> working or at least for some parts of the project.
>
>> b) note changes in JIRA afterwards
>
> Or during the process of receiving patches, discussing and
> committing them.
>
>> c) something else?
>> I think b) is fine, if you are simply looking for a change
>> tracking tool, although if you build a decent commit message
>> discipline into the community, you can also just ask SVN what
>> changed between releases... and that should be far more accurate.
>
> Often it requires multiple changes to the code for the same issue
> before
> everybody is happy (I think/hope this will be a very picky
> community :-)
> and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
> report generated by SVN contain a lot of clutter in that case. Also
> for
> release notes I really like the issue description instead of the
> comments people in general use for their commit.
+1. I suspect a CHANGES.txt file that is hand maintained by
committers may be more useful at release time.
> If I recall correctly the Jini team didn't write a single character
> before there was an issue in their tracking system. I adopted this
> style
> and found it worth while on a rather stable codebase. I'm curious to
> know what the others think of this.
In my (limited) experience with an ASF project, occasionally a JIRA
is created and a patch is attached to it all within a minute.
Clearly the person had completed the patch before creating a JIRA.
Are you saying to want to preclude this? I don't see a reason to.
> And maybe I'm completely out of bounds here but I think that even some
> form of issue planning (in what version to expect what) can be
> beneficial as well, JIRA is great for that too.
>
>>>> JIRA is great for tracking, but there are things to be cautious
>>>> of - I've experienced technical discussion moving into the JIRA
>>>> itself, which I think is not good, because it loses the bigger
>>>> audience (IMO). I hate having to read JIRA discussions on the
>>>> JIRA-generated emails, and it makes it hard to participate
>>>> offline (unlike email) or search (unlike email...)
>>>
>>> I'm aware of that but in case of tasks to be implemented
>>> somewhere in
>>> the future I like to see any conclusions of discussion in JIRA
>>> versus
>>> digging them from my email archive.
>> That's fine - that's a good use of JIRA. But you can simply just
>> put a URL to the mail archive in the JIRA... easy to find later.
>
> That is possible, but I'm inclined to describe the summary of such an
> issue neatly in JIRA. But as I've not that much experience with
> working
> in an ASF style project opposed to playing a dictator I really don't
> know what will work the best.
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
>> I disagree. For cheiron.org I do most of the work myself, but
>> nevertheless anything substantial is going through JIRA if it was only
>> to keep track of things done for the release notes. Especially when you
>> already have a stable codebase gradually improving and getting
>> bug-fixed. But I admit with complete new projects I tend to be less
>> bureaucratic.
>
> Do you mean
>
> a) you make all the changes, make a patch, submit it to JIRA, download
> the patch, apply the patch to a fresh tree, and then commit
Not exactly. I work either on the main codeline or in some version
branch, but not before there is an JIRA issue created for the task, bug
or improvement at hand. The JIRA issue is sent to the developer mailing
list (no seperate list for generated artifacts) so other interested
people can see whether they think the issue is relevant or not.
When I start working on it, JIRA sends a message to the dev list so
people know I'm about the start coding. After I check in my code
directly into the repository I resolve the issue which leads to a post
from JIRA to the dev list. In case of commit before review I suggest one
waits a while with resolving the issue.
No patches are submitted to JIRA, for those that have no commit rights I
also think that sending the patch to the dev list is the best thing to
do. No need to attach that one to the isse. When the patch is accepted
and committed by one of the committers the issue can be resolved.
I realize this won't work exactly the same way as for the projects I'm
working on, but still hope to see maybe a somewhat more formal way of
working or at least for some parts of the project.
> b) note changes in JIRA afterwards
Or during the process of receiving patches, discussing and committing them.
> c) something else?
>
> I think b) is fine, if you are simply looking for a change tracking
> tool, although if you build a decent commit message discipline into the
> community, you can also just ask SVN what changed between releases...
> and that should be far more accurate.
Often it requires multiple changes to the code for the same issue before
everybody is happy (I think/hope this will be a very picky community :-)
and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
report generated by SVN contain a lot of clutter in that case. Also for
release notes I really like the issue description instead of the
comments people in general use for their commit.
If I recall correctly the Jini team didn't write a single character
before there was an issue in their tracking system. I adopted this style
and found it worth while on a rather stable codebase. I'm curious to
know what the others think of this.
And maybe I'm completely out of bounds here but I think that even some
form of issue planning (in what version to expect what) can be
beneficial as well, JIRA is great for that too.
>>> JIRA is great for tracking, but there are things to be cautious of -
>>> I've experienced technical discussion moving into the JIRA itself,
>>> which I think is not good, because it loses the bigger audience
>>> (IMO). I hate having to read JIRA discussions on the JIRA-generated
>>> emails, and it makes it hard to participate offline (unlike email) or
>>> search (unlike email...)
>>
>> I'm aware of that but in case of tasks to be implemented somewhere in
>> the future I like to see any conclusions of discussion in JIRA versus
>> digging them from my email archive.
>
> That's fine - that's a good use of JIRA. But you can simply just put a
> URL to the mail archive in the JIRA... easy to find later.
That is possible, but I'm inclined to describe the summary of such an
issue neatly in JIRA. But as I've not that much experience with working
in an ASF style project opposed to playing a dictator I really don't
know what will work the best.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 3, 2007, at 8:51 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>> On Jan 3, 2007, at 7:41 AM, Mark Brouwer wrote:
>>> Geir Magnusson Jr. wrote:
>>>
>>>>> I would expect to see the process here 1) discuss idea on the
>>>>> list 2) open
>>>>> JIRA ticket 3) add patch to ticket and subsequently refer to
>>>>> the ticket
>>>>> number in discussion.
>>>> Yes. And I think that there's no requirement for a committer to
>>>> open the JIRA, really.
>>>
>>> Maybe it is because I have to get acquainted with your way of
>>> writing
>>> Geir ;-), but from the above I can't make up whether you think
>>> committers can hack around without opening a JIRA issue,
>> yes, committers can commit code w/o opening a JIRA issue.
>
> I disagree. For cheiron.org I do most of the work myself, but
> nevertheless anything substantial is going through JIRA if it was only
> to keep track of things done for the release notes. Especially when
> you
> already have a stable codebase gradually improving and getting
> bug-fixed. But I admit with complete new projects I tend to be less
> bureaucratic.
Do you mean
a) you make all the changes, make a patch, submit it to JIRA,
download the patch, apply the patch to a fresh tree, and then commit
b) note changes in JIRA afterwards
c) something else?
I think b) is fine, if you are simply looking for a change tracking
tool, although if you build a decent commit message discipline into
the community, you can also just ask SVN what changed between
releases... and that should be far more accurate.
>
>> JIRA is great for tracking, but there are things to be cautious of
>> - I've experienced technical discussion moving into the JIRA
>> itself, which I think is not good, because it loses the bigger
>> audience (IMO). I hate having to read JIRA discussions on the
>> JIRA-generated emails, and it makes it hard to participate offline
>> (unlike email) or search (unlike email...)
>
> I'm aware of that but in case of tasks to be implemented somewhere in
> the future I like to see any conclusions of discussion in JIRA versus
> digging them from my email archive.
That's fine - that's a good use of JIRA. But you can simply just put
a URL to the mail archive in the JIRA... easy to find later.
geir
> --
> Mark
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
>
> On Jan 3, 2007, at 7:41 AM, Mark Brouwer wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>>> I would expect to see the process here 1) discuss idea on the list
>>>> 2) open
>>>> JIRA ticket 3) add patch to ticket and subsequently refer to the ticket
>>>> number in discussion.
>>> Yes. And I think that there's no requirement for a committer to open
>>> the JIRA, really.
>>
>> Maybe it is because I have to get acquainted with your way of writing
>> Geir ;-), but from the above I can't make up whether you think
>> committers can hack around without opening a JIRA issue,
>
> yes, committers can commit code w/o opening a JIRA issue.
I disagree. For cheiron.org I do most of the work myself, but
nevertheless anything substantial is going through JIRA if it was only
to keep track of things done for the release notes. Especially when you
already have a stable codebase gradually improving and getting
bug-fixed. But I admit with complete new projects I tend to be less
bureaucratic.
> JIRA is great for tracking, but there are things to be cautious of -
> I've experienced technical discussion moving into the JIRA itself, which
> I think is not good, because it loses the bigger audience (IMO). I hate
> having to read JIRA discussions on the JIRA-generated emails, and it
> makes it hard to participate offline (unlike email) or search (unlike
> email...)
I'm aware of that but in case of tasks to be implemented somewhere in
the future I like to see any conclusions of discussion in JIRA versus
digging them from my email archive.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 3, 2007, at 7:41 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>
>>> I would expect to see the process here 1) discuss idea on the
>>> list 2) open
>>> JIRA ticket 3) add patch to ticket and subsequently refer to the
>>> ticket
>>> number in discussion.
>> Yes. And I think that there's no requirement for a committer to
>> open the JIRA, really.
>
> Maybe it is because I have to get acquainted with your way of writing
> Geir ;-), but from the above I can't make up whether you think
> committers can hack around without opening a JIRA issue,
yes, committers can commit code w/o opening a JIRA issue.
> or that you
> think that in most/many case the process lined out by Phil should be
> followed.
I think it's a good start to talk about, and expect this community
will work out it's own working style.
I think the key thing is finding a balance between :
1) communication and transparency (e.g. discussion on the dev list)
2) few roadblocks for getting things done (e.g. commit then review
(CTR))
IOW, you don't want to serialize all changes through discussion on
the dev list, but by letting your fellow community members know what
you are up to ("Hey, I'm working on refactoring the
frobnosticator...") it gives them a chance to engage with you ("hey,
I have some ideas too, let me help") or raise a flag for discussion
("You can't - we've committed to that interface last version....").
Thats the communication side. On the CTR side, you have a safety net
for cases where you didn't tell people what you were doing (you were
heads down on a project and modified some related things...) or did,
and people weren't paying attention.
I think of it as optimistic locking on the code...
JIRA is great for tracking, but there are things to be cautious of -
I've experienced technical discussion moving into the JIRA itself,
which I think is not good, because it loses the bigger audience
(IMO). I hate having to read JIRA discussions on the JIRA-generated
emails, and it makes it hard to participate offline (unlike email) or
search (unlike email...)
geir
Re: new site added to SVN and published
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
>> I would expect to see the process here 1) discuss idea on the list 2)
>> open
>> JIRA ticket 3) add patch to ticket and subsequently refer to the ticket
>> number in discussion.
>
> Yes. And I think that there's no requirement for a committer to open
> the JIRA, really.
Maybe it is because I have to get acquainted with your way of writing
Geir ;-), but from the above I can't make up whether you think
committers can hack around without opening a JIRA issue, or that you
think that in most/many case the process lined out by Phil should be
followed.
--
Mark
Re: new site added to SVN and published
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2007, at 11:37 PM, Phil Steitz wrote:
> On 1/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> I created a simple website using my standard ant and velocity based
>> framework (easy to work with...) and checked that into SVN in /site.
>> I also staged it for the public webserver - should be out there at
>>
>> http://incubator.apache.org/river
>>
>> in a few hours at most.
>>
>> All, please try to check it out (use https, please), and if there are
>> things you want changed, lets submit patches to JIRA for now.
>
>
> Sorry, I did not read that last line carefully and committed some
> typo fixes
> directly. I assume that was OK, since the changes were only to fix
> typos /
> references to Harmony, etc.
That's fine. I actually meant people that didn't have commit :)
>
> Something that I would like to discuss is whether we are really
> going to use
> STATUS as described on the guidelines page. Some of the verbiage
> there
> makes it look like we will be using the STATUS file + dev list as
> a sort of
> surrogate for JIRA. For example,
>
> "When a specific change to the software is proposed for discussion
> or voting
> on the mailing list, it should be presented in the form of input to
> the
> patch command. When sent to the mailing list, the message should
> contain a
> Subject beginning with [PATCH] and a distinctive one-line summary
> corresponding to the action item for that patch. Afterwards, the patch
> summary in the STATUS file should be updated to point to the
> Message-ID of
> that message."
No - that was just boilerplate I stole from httpd. :) Lets frag
that. Basically I was just trying to seed discussion, not dictate
anything.
>
> I would expect to see the process here 1) discuss idea on the list
> 2) open
> JIRA ticket 3) add patch to ticket and subsequently refer to the
> ticket
> number in discussion.
Yes. And I think that there's no requirement for a committer to open
the JIRA, really.
>
> I know that we *must* maintain a STATUS file to track incubation-
> related
> tasks, but I don't see the value in tracking all development tasks
> in this
> file, when we have JIRA available. What am I missing here?
Yes, the status file is in place :
http://incubator.apache.org/projects/river.html
(ok, will be when the next site sync happens... I forgot to commit it
yesterday)
Again, the STATUS stuff was just boilerplate in my "seed site for a
podling", so we should kill it.
geir
>
> Phil
Re: new site added to SVN and published
Posted by Phil Steitz <ph...@gmail.com>.
On 1/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> I created a simple website using my standard ant and velocity based
> framework (easy to work with...) and checked that into SVN in /site.
> I also staged it for the public webserver - should be out there at
>
> http://incubator.apache.org/river
>
> in a few hours at most.
>
> All, please try to check it out (use https, please), and if there are
> things you want changed, lets submit patches to JIRA for now.
Sorry, I did not read that last line carefully and committed some typo fixes
directly. I assume that was OK, since the changes were only to fix typos /
references to Harmony, etc.
Something that I would like to discuss is whether we are really going to use
STATUS as described on the guidelines page. Some of the verbiage there
makes it look like we will be using the STATUS file + dev list as a sort of
surrogate for JIRA. For example,
"When a specific change to the software is proposed for discussion or voting
on the mailing list, it should be presented in the form of input to the
patch command. When sent to the mailing list, the message should contain a
Subject beginning with [PATCH] and a distinctive one-line summary
corresponding to the action item for that patch. Afterwards, the patch
summary in the STATUS file should be updated to point to the Message-ID of
that message."
I would expect to see the process here 1) discuss idea on the list 2) open
JIRA ticket 3) add patch to ticket and subsequently refer to the ticket
number in discussion.
I know that we *must* maintain a STATUS file to track incubation-related
tasks, but I don't see the value in tracking all development tasks in this
file, when we have JIRA available. What am I missing here?
Phil