You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Glen Mazza <gl...@gmail.com> on 2013/03/16 13:01:15 UTC
two changelog files?
I noticed we're presently maintaining two changelog files (two more than
the vast majority of other Apache projects ;-) with the same info in both:
(1)
http://svn.apache.org/viewvc/incubator/jspwiki/site/trunk/content/jspwiki/development/changelog.mdtext?view=markup
(2)
http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=markup
Why don't we just have the website hyperlink to (2) (or
http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=co)
and we're done? People do open source for technical development, to
keep their skills sharp. Most have enough secretarial headaches in
their day jobs without needing more on their volunteer jobs, and the
more busywork we insist upon the more they will go to other projects.
Glen
Re: two changelog files?
Posted by Glen Mazza <gl...@gmail.com>.
Sorry Juan Pablo, I missed that you had already suggested below
discontinuing the ChangeLog in trunk and just modifying the one on the
website directly instead. Probably not advisable (as we'd have to
remember to commit on two branches--code and sites), given that you've
already created an automated script to read the ChangeLog file in trunk
for us. I would still be fine with just linking to the ChangeLog file
on the SVN repository on our website or just adding each new contributor
to the People page. However, if we're going to continue to use an
automated script, it might be good if we could add a special symbol in
the trunk ChangeLog file that the script can read so that only external
community patches get listed. Right now, maybe 80% of the changes are
from JSPWiki committers anyway and not the external community, so
printing all updates on the website is causing the contributor patches
to be watered-down/less visible.
Regards,
Glen
On 03/16/2013 10:29 AM, Glen Mazza wrote:
> Hi Juan, I didn't read 764 the way you did. I guessed you were just
> going to provide a hyperlink to the changelog file in SVN and we're
> done. Granted the results might be 15% less attractive, but I can't
> see it worth all that extra effort to grab that remaining 15%. (
> http://en.wikipedia.org/wiki/Opportunity_cost) But if you do, so be
> it. But anyway, I will just update the changelog file in the root
> (which is one more changelog file than I want to do anyway :), if your
> process automatically updates the changelog on the website as you say,
> great, but if not, someone else will have to do it, it's too much to
> ask to maintain two changelog files.
>
> Remember, most other Apache projects just create a listing of
> contributors below the committer list and they're done. Beyond
> visibility, reduction of B.S. secretarial work is most helpful in
> attracting people. In terms of grabbing committers, JSPWiki's best
> selling point is that it's a web application and hence the skills one
> learns on it are very useful and immediately applicable to most
> developer jobs. Many/most Apache projects are fun and absorbing to
> work on (FOP, Batik, Xalan immediately come to mind) but the internal
> coding within them does not translate nearly as readily to a
> marketable skill; such developers also need to be on projects like
> JSPWiki for their "continuing education units" (i.e., maintenance of
> basic knowledge that all developers should have) while they are
> working on their specialities.
>
> Regards,
> Glen
>
> On 03/16/2013 09:33 AM, Juan Pablo Santos Rodríguez wrote:
>> Hi Glen,
>>
>> the first file is generated from the second one via
>> org.apache.wiki.site.SiteGeneratorTest [cfr. JSPWIKI-764]. The idea behind
>> that was to give more visibility to external contributions. The test only
>> tidies up a little the ChangeLog file (does some clean up to nest lists
>> properly and links to the relevant JIRA issue when appropiate). My idea
>> was, on a second step:
>>
>> - get INFRA-5943 done (linked in JSPWIKI-764)
>> - get a proper maven layout
>> - move the site as a build submodule
>> - clean install should then update the (site's) ChangeLog
>>
>> In the end, a commit should update the site's ChangeLog page automatically.
>> In the meantime, we've to manually execute the test & commit the appropiate
>> files. There're some pointers at
>> http://incubator.apache.org/jspwiki/development/edit_website.html but I
>> don't know if they're enough..
>>
>> Another approach we could take is to directly edit the site's ChangeLog
>> file, dismissing the original one. I took the test approach because, on the
>> same run, the translation status page and the latest version on trunk are
>> also generated, and it seemed easier to me. However, if we decide to
>> mantain the ChangeLog file in another way I'm open to it
>>
>> WDYT?
>>
>>
>> cheers,
>> juan pablo
>>
>> On Sat, Mar 16, 2013 at 1:01 PM, Glen Mazza<gl...@gmail.com> wrote:
>>
>>> I noticed we're presently maintaining two changelog files (two more than
>>> the vast majority of other Apache projects ;-) with the same info in both:
>>>
>>> (1)http://svn.apache.org/viewvc/**incubator/jspwiki/site/trunk/**
>>> content/jspwiki/development/**changelog.mdtext?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/site/trunk/content/jspwiki/development/changelog.mdtext?view=markup>
>>>
>>> (2)http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
>>> ChangeLog?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=markup>
>>>
>>> Why don't we just have the website hyperlink to (2) (or
>>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**ChangeLog?view=co<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=co>)
>>> and we're done? People do open source for technical development, to keep
>>> their skills sharp. Most have enough secretarial headaches in their day
>>> jobs without needing more on their volunteer jobs, and the more busywork we
>>> insist upon the more they will go to other projects.
>>>
>>> Glen
>>>
>>>
>
Re: two changelog files?
Posted by Glen Mazza <gl...@gmail.com>.
Hi Juan, I didn't read 764 the way you did. I guessed you were just
going to provide a hyperlink to the changelog file in SVN and we're
done. Granted the results might be 15% less attractive, but I can't see
it worth all that extra effort to grab that remaining 15%. (
http://en.wikipedia.org/wiki/Opportunity_cost) But if you do, so be it.
But anyway, I will just update the changelog file in the root (which is
one more changelog file than I want to do anyway :), if your process
automatically updates the changelog on the website as you say, great,
but if not, someone else will have to do it, it's too much to ask to
maintain two changelog files.
Remember, most other Apache projects just create a listing of
contributors below the committer list and they're done. Beyond
visibility, reduction of B.S. secretarial work is most helpful in
attracting people. In terms of grabbing committers, JSPWiki's best
selling point is that it's a web application and hence the skills one
learns on it are very useful and immediately applicable to most
developer jobs. Many/most Apache projects are fun and absorbing to work
on (FOP, Batik, Xalan immediately come to mind) but the internal coding
within them does not translate nearly as readily to a marketable skill;
such developers also need to be on projects like JSPWiki for their
"continuing education units" (i.e., maintenance of basic knowledge that
all developers should have) while they are working on their specialities.
Regards,
Glen
On 03/16/2013 09:33 AM, Juan Pablo Santos Rodríguez wrote:
> Hi Glen,
>
> the first file is generated from the second one via
> org.apache.wiki.site.SiteGeneratorTest [cfr. JSPWIKI-764]. The idea behind
> that was to give more visibility to external contributions. The test only
> tidies up a little the ChangeLog file (does some clean up to nest lists
> properly and links to the relevant JIRA issue when appropiate). My idea
> was, on a second step:
>
> - get INFRA-5943 done (linked in JSPWIKI-764)
> - get a proper maven layout
> - move the site as a build submodule
> - clean install should then update the (site's) ChangeLog
>
> In the end, a commit should update the site's ChangeLog page automatically.
> In the meantime, we've to manually execute the test & commit the appropiate
> files. There're some pointers at
> http://incubator.apache.org/jspwiki/development/edit_website.html but I
> don't know if they're enough..
>
> Another approach we could take is to directly edit the site's ChangeLog
> file, dismissing the original one. I took the test approach because, on the
> same run, the translation status page and the latest version on trunk are
> also generated, and it seemed easier to me. However, if we decide to
> mantain the ChangeLog file in another way I'm open to it
>
> WDYT?
>
>
> cheers,
> juan pablo
>
> On Sat, Mar 16, 2013 at 1:01 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>> I noticed we're presently maintaining two changelog files (two more than
>> the vast majority of other Apache projects ;-) with the same info in both:
>>
>> (1) http://svn.apache.org/viewvc/**incubator/jspwiki/site/trunk/**
>> content/jspwiki/development/**changelog.mdtext?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/site/trunk/content/jspwiki/development/changelog.mdtext?view=markup>
>>
>> (2) http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
>> ChangeLog?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=markup>
>>
>> Why don't we just have the website hyperlink to (2) (or
>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**ChangeLog?view=co<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=co>)
>> and we're done? People do open source for technical development, to keep
>> their skills sharp. Most have enough secretarial headaches in their day
>> jobs without needing more on their volunteer jobs, and the more busywork we
>> insist upon the more they will go to other projects.
>>
>> Glen
>>
>>
Re: two changelog files?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Glen,
the first file is generated from the second one via
org.apache.wiki.site.SiteGeneratorTest [cfr. JSPWIKI-764]. The idea behind
that was to give more visibility to external contributions. The test only
tidies up a little the ChangeLog file (does some clean up to nest lists
properly and links to the relevant JIRA issue when appropiate). My idea
was, on a second step:
- get INFRA-5943 done (linked in JSPWIKI-764)
- get a proper maven layout
- move the site as a build submodule
- clean install should then update the (site's) ChangeLog
In the end, a commit should update the site's ChangeLog page automatically.
In the meantime, we've to manually execute the test & commit the appropiate
files. There're some pointers at
http://incubator.apache.org/jspwiki/development/edit_website.html but I
don't know if they're enough..
Another approach we could take is to directly edit the site's ChangeLog
file, dismissing the original one. I took the test approach because, on the
same run, the translation status page and the latest version on trunk are
also generated, and it seemed easier to me. However, if we decide to
mantain the ChangeLog file in another way I'm open to it
WDYT?
cheers,
juan pablo
On Sat, Mar 16, 2013 at 1:01 PM, Glen Mazza <gl...@gmail.com> wrote:
> I noticed we're presently maintaining two changelog files (two more than
> the vast majority of other Apache projects ;-) with the same info in both:
>
> (1) http://svn.apache.org/viewvc/**incubator/jspwiki/site/trunk/**
> content/jspwiki/development/**changelog.mdtext?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/site/trunk/content/jspwiki/development/changelog.mdtext?view=markup>
>
> (2) http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
> ChangeLog?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=markup>
>
> Why don't we just have the website hyperlink to (2) (or
> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**ChangeLog?view=co<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/ChangeLog?view=co>)
> and we're done? People do open source for technical development, to keep
> their skills sharp. Most have enough secretarial headaches in their day
> jobs without needing more on their volunteer jobs, and the more busywork we
> insist upon the more they will go to other projects.
>
> Glen
>
>