incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <glen.ma...@gmail.com>
Subject Re: two changelog files?
Date Sun, 31 Mar 2013 15:09:01 GMT
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<glen.mazza@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
>>>
>>>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message