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/01/25 03:29:53 UTC
retiring the changelog file
Hi team, we have a "ChangeLog" file in the root folder that is
apparently (?) updated whenever someone makes a commit. I don't see a
need for it, and none of the other Apache projects I'm aware of bothers
with such a file -- it's annoying needing to update it and it just seems
to be unnecessary overhead. Can we get rid of it?
So long as you make comments when you commit, here is a 100.0%
authoritative and chronological list of all commits made and what they
involve:
http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser
And of course the SVN repository details the changes made to each
specific file fully and accurately:
http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log
Finally, JIRA nicely provides us a list of commits per release:
https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel
That should be good enough for us. WDYT?
Regards,
Glen
Re: retiring the changelog file
Posted by Siegfried Goeschl <sg...@gmx.at>.
Hi Glen,
thanks for pointing out - I'm old-fashioned and magnetic tapes were
highly fashionable and punch cards still in use when I started coding
... :-).
Going back to the discussion - let's avoid mixing up intention and
tools. My intention is visibility of a casual committer who only adds
one or two bug fixes and I have the habit of honoring this small
contribution in changes.xml since it becomes part of the site. I don't
care how it's done ... ;-)
Cheers,
Siegfried Goeschl
Senile Software Engineer
On 29.01.13 03:10, Glen Mazza wrote:
> Oh--I haven't been bumping up the org.apache.wiki.Release number because
> I was unaware that we needed to do that (Sorry, wasn't paying
> attention--I always wondered where that "2.9.1-svn-XX" value came from
> in the ChangeLog file... :) Now if I understand correctly, I *don't*
> need to bump up that number and update the ChangeLog file with trivial
> commits such as typos being fixed or should I be doing that for every
> commit? I'm flexible here--I just need to know what to do. (Once we
> Mavenize, incidentally, the manual incrementing numbering system might
> no longer be needed because somehow the Jenkins/Maven combination
> automatically generates snapshot bundles every day with something like a
> YYYYMMDDHH24MISS format appended to the name of the generated
> JARs/WARs.--I'm unsure here though.)
>
> Earlier today I asked two of my coworkers, Dan Kulp and Olivier Lamy,
> who are each committers on approximately 10 Apache projects each
> (http://people.apache.org/committer-index.html , users dkulp and olamy),
> how many of their projects use manually updated change files -- Dan
> reported zero and Olivier just one (Apache Commons, as Siegfried noted
> earlier). So that's why I'm unaccustomed to maintaining such a
> file--I've never needed it and have never heard of people on these
> projects complaining about the lack of such a file. (Incidentally, if
> we want to highlight contributors without a change file, we can always
> add them manually to our web site page, like Apache Camel does here:
> http://camel.apache.org/team.html ) .
>
> One small concern to keep in mind about manually maintaining a change
> log, is that it may give an "old fashioned" image to the project,
> because such files were much more common 10-15 years ago before we had
> modern repository systems. To the point that sleekness, coolness and
> modernity in a code base drive adoption (and more committers :),
> maintaining a change log file might be furthering an older image harming
> that goal. (It would be perhaps akin to a teenage rockstar offering his
> music additionally on cassette and phonograph records, or Apple selling
> its MacBook Pro laptops with a 3 1/2-inch diskette drive slot. In both
> cases, you're harming the image of sleekness/modernity that drives a
> portion of sales.) Just food for thought!
>
> Regards,
> Glen
>
> PS: Oh, to answer your question, sure, we can switch to an mdtext format
> as you propose; or switch our website to Commons Email style and just
> have it use the changes.xml directly (although I kind of like the softer
> format of our website compared to theirs -- especially since our website
> already looks much like JSPWiki :)
>
>
> On 01/28/2013 03:00 PM, Juan Pablo Santos Rodríguez wrote:
>> Hi,
>>
>> the ChangeLog shows the lists of "versions", being a "version" something
>> similar to a (i.e.) Jenkins release (except that in Jenkins new release =
>> new war), that is, a bunch of new functionality, which may comprise
>> one or
>> several commits. In the latter case, the Changelog file comes in handy.
>>
>> If a new functionality is added, the release number in
>> org.apache.wiki.Release gets bumped and the ChangeLog file is updated
>> with
>> the appropiate info. Similarly a commit may not be itself worth a
>> "version", i.e.: a commit to omit some auto-generated files. What
>> constitutes a "version" and what not is left to the committer; as they're
>> cheap to generate it isn't a big deal.
>>
>> Related to ChangeLog, and having mentioned Jenkins, I've just noticed
>> that
>> the ChangeLog file is very close to Markdown syntax, so we could use
>> it to
>> generate a $svn/site/trunk/content/jspwiki/development/changelog.mdtext
>> That would make the contributors' names a lot more visible.
>>
>> A first step would have some kind of JUnit (or whatever), similar to
>> TranslationsCheck, to generate the appropiate file. Then this change
>> would
>> also be committed and then published (this could be done automatically
>> by a
>> Jenkins post-job @ builds.a.o). Hmmm and we could also refresh the
>> version
>> displayed @ i.a.o/jspwiki, and also publish another page with the
>> different
>> translation statuses..
>>
>> thoughts?
>>
>>
>> br,
>> juan pablo
>>
>> On Mon, Jan 28, 2013 at 3:16 AM, Ichiro Furusato
>> <ic...@gmail.com>wrote:
>>
>>> [-1]
>>>
>>> I'm not a committer so I don't get a vote, but FWIW I've always
>>> preferred
>>> human-managed change logs, since that means a human being is
>>> highlighting
>>> the more important changes, new or changed APIs, features, etc. whereas
>>> the machine-generated ones force me to slog through *all* of the
>>> changes.
>>>
>>> Yes, it does require some overhead but it's very helpful for
>>> co-developers.
>>>
>>> Ichiro
>>>
>>> On Sat, Jan 26, 2013 at 11:55 PM, Harry Metske <ha...@gmail.com>
>>> wrote:
>>>> -0.5
>>>>
>>>> I have always found this Changelog a very convenient mechanism of
>>> searching
>>>> for "what has changed when in what version".
>>>> You have it one file, easily searchable and scrollable.
>>>> The overhead is minimal, always cut/paste the Changelog update to the
>>>> commit log.
>>>> I agree that mentioned links provide all information (and more), but
>>>> not
>>> so
>>>> easy to search, you always have to click a hundred times before you
>>>> find
>>>> what you want.
>>>>
>>>> kind regards,
>>>> Harry
>>>>
>>>>
>>>> On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
>>>>
>>>>> Hi team, we have a "ChangeLog" file in the root folder that is
>>> apparently
>>>>> (?) updated whenever someone makes a commit. I don't see a need
>>>>> for it,
>>>>> and none of the other Apache projects I'm aware of bothers with such a
>>> file
>>>>> -- it's annoying needing to update it and it just seems to be
>>> unnecessary
>>>>> overhead. Can we get rid of it?
>>>>>
>>>>> So long as you make comments when you commit, here is a 100.0%
>>>>> authoritative and chronological list of all commits made and what they
>>>>> involve:
>>>>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>>>>> jspwiki-commits/201301.mbox/**browser<
>>> http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser
>>>
>>>>> And of course the SVN repository details the changes made to each
>>> specific
>>>>> file fully and accurately:
>>>>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
>>>>> webdocs/Error.jsp?view=log<
>>> http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log
>>>
>>>>> Finally, JIRA nicely provides us a list of commits per release:
>>>>> https://issues.apache.org/**jira/browse/JSPWIKI#**
>>>>>
>>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<
>>>
>>> https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel
>>>
>>>>> That should be good enough for us. WDYT?
>>>>>
>>>>> Regards,
>>>>> Glen
>>>>>
>
>
Re: retiring the changelog file
Posted by Glen Mazza <gl...@gmail.com>.
Oh--I haven't been bumping up the org.apache.wiki.Release number because
I was unaware that we needed to do that (Sorry, wasn't paying
attention--I always wondered where that "2.9.1-svn-XX" value came from
in the ChangeLog file... :) Now if I understand correctly, I *don't*
need to bump up that number and update the ChangeLog file with trivial
commits such as typos being fixed or should I be doing that for every
commit? I'm flexible here--I just need to know what to do. (Once we
Mavenize, incidentally, the manual incrementing numbering system might
no longer be needed because somehow the Jenkins/Maven combination
automatically generates snapshot bundles every day with something like a
YYYYMMDDHH24MISS format appended to the name of the generated
JARs/WARs.--I'm unsure here though.)
Earlier today I asked two of my coworkers, Dan Kulp and Olivier Lamy,
who are each committers on approximately 10 Apache projects each
(http://people.apache.org/committer-index.html , users dkulp and olamy),
how many of their projects use manually updated change files -- Dan
reported zero and Olivier just one (Apache Commons, as Siegfried noted
earlier). So that's why I'm unaccustomed to maintaining such a
file--I've never needed it and have never heard of people on these
projects complaining about the lack of such a file. (Incidentally, if
we want to highlight contributors without a change file, we can always
add them manually to our web site page, like Apache Camel does here:
http://camel.apache.org/team.html ) .
One small concern to keep in mind about manually maintaining a change
log, is that it may give an "old fashioned" image to the project,
because such files were much more common 10-15 years ago before we had
modern repository systems. To the point that sleekness, coolness and
modernity in a code base drive adoption (and more committers :),
maintaining a change log file might be furthering an older image harming
that goal. (It would be perhaps akin to a teenage rockstar offering his
music additionally on cassette and phonograph records, or Apple selling
its MacBook Pro laptops with a 3 1/2-inch diskette drive slot. In both
cases, you're harming the image of sleekness/modernity that drives a
portion of sales.) Just food for thought!
Regards,
Glen
PS: Oh, to answer your question, sure, we can switch to an mdtext format
as you propose; or switch our website to Commons Email style and just
have it use the changes.xml directly (although I kind of like the softer
format of our website compared to theirs -- especially since our website
already looks much like JSPWiki :)
On 01/28/2013 03:00 PM, Juan Pablo Santos Rodríguez wrote:
> Hi,
>
> the ChangeLog shows the lists of "versions", being a "version" something
> similar to a (i.e.) Jenkins release (except that in Jenkins new release =
> new war), that is, a bunch of new functionality, which may comprise one or
> several commits. In the latter case, the Changelog file comes in handy.
>
> If a new functionality is added, the release number in
> org.apache.wiki.Release gets bumped and the ChangeLog file is updated with
> the appropiate info. Similarly a commit may not be itself worth a
> "version", i.e.: a commit to omit some auto-generated files. What
> constitutes a "version" and what not is left to the committer; as they're
> cheap to generate it isn't a big deal.
>
> Related to ChangeLog, and having mentioned Jenkins, I've just noticed that
> the ChangeLog file is very close to Markdown syntax, so we could use it to
> generate a $svn/site/trunk/content/jspwiki/development/changelog.mdtext
> That would make the contributors' names a lot more visible.
>
> A first step would have some kind of JUnit (or whatever), similar to
> TranslationsCheck, to generate the appropiate file. Then this change would
> also be committed and then published (this could be done automatically by a
> Jenkins post-job @ builds.a.o). Hmmm and we could also refresh the version
> displayed @ i.a.o/jspwiki, and also publish another page with the different
> translation statuses..
>
> thoughts?
>
>
> br,
> juan pablo
>
> On Mon, Jan 28, 2013 at 3:16 AM, Ichiro Furusato
> <ic...@gmail.com>wrote:
>
>> [-1]
>>
>> I'm not a committer so I don't get a vote, but FWIW I've always preferred
>> human-managed change logs, since that means a human being is highlighting
>> the more important changes, new or changed APIs, features, etc. whereas
>> the machine-generated ones force me to slog through *all* of the changes.
>>
>> Yes, it does require some overhead but it's very helpful for co-developers.
>>
>> Ichiro
>>
>> On Sat, Jan 26, 2013 at 11:55 PM, Harry Metske <ha...@gmail.com>
>> wrote:
>>> -0.5
>>>
>>> I have always found this Changelog a very convenient mechanism of
>> searching
>>> for "what has changed when in what version".
>>> You have it one file, easily searchable and scrollable.
>>> The overhead is minimal, always cut/paste the Changelog update to the
>>> commit log.
>>> I agree that mentioned links provide all information (and more), but not
>> so
>>> easy to search, you always have to click a hundred times before you find
>>> what you want.
>>>
>>> kind regards,
>>> Harry
>>>
>>>
>>> On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
>>>
>>>> Hi team, we have a "ChangeLog" file in the root folder that is
>> apparently
>>>> (?) updated whenever someone makes a commit. I don't see a need for it,
>>>> and none of the other Apache projects I'm aware of bothers with such a
>> file
>>>> -- it's annoying needing to update it and it just seems to be
>> unnecessary
>>>> overhead. Can we get rid of it?
>>>>
>>>> So long as you make comments when you commit, here is a 100.0%
>>>> authoritative and chronological list of all commits made and what they
>>>> involve:
>>>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>>>> jspwiki-commits/201301.mbox/**browser<
>> http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser
>>>> And of course the SVN repository details the changes made to each
>> specific
>>>> file fully and accurately:
>>>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
>>>> webdocs/Error.jsp?view=log<
>> http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log
>>>> Finally, JIRA nicely provides us a list of commits per release:
>>>> https://issues.apache.org/**jira/browse/JSPWIKI#**
>>>>
>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<
>> https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel
>>>> That should be good enough for us. WDYT?
>>>>
>>>> Regards,
>>>> Glen
>>>>
Re: retiring the changelog file
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi,
the ChangeLog shows the lists of "versions", being a "version" something
similar to a (i.e.) Jenkins release (except that in Jenkins new release =
new war), that is, a bunch of new functionality, which may comprise one or
several commits. In the latter case, the Changelog file comes in handy.
If a new functionality is added, the release number in
org.apache.wiki.Release gets bumped and the ChangeLog file is updated with
the appropiate info. Similarly a commit may not be itself worth a
"version", i.e.: a commit to omit some auto-generated files. What
constitutes a "version" and what not is left to the committer; as they're
cheap to generate it isn't a big deal.
Related to ChangeLog, and having mentioned Jenkins, I've just noticed that
the ChangeLog file is very close to Markdown syntax, so we could use it to
generate a $svn/site/trunk/content/jspwiki/development/changelog.mdtext
That would make the contributors' names a lot more visible.
A first step would have some kind of JUnit (or whatever), similar to
TranslationsCheck, to generate the appropiate file. Then this change would
also be committed and then published (this could be done automatically by a
Jenkins post-job @ builds.a.o). Hmmm and we could also refresh the version
displayed @ i.a.o/jspwiki, and also publish another page with the different
translation statuses..
thoughts?
br,
juan pablo
On Mon, Jan 28, 2013 at 3:16 AM, Ichiro Furusato
<ic...@gmail.com>wrote:
> [-1]
>
> I'm not a committer so I don't get a vote, but FWIW I've always preferred
> human-managed change logs, since that means a human being is highlighting
> the more important changes, new or changed APIs, features, etc. whereas
> the machine-generated ones force me to slog through *all* of the changes.
>
> Yes, it does require some overhead but it's very helpful for co-developers.
>
> Ichiro
>
> On Sat, Jan 26, 2013 at 11:55 PM, Harry Metske <ha...@gmail.com>
> wrote:
> > -0.5
> >
> > I have always found this Changelog a very convenient mechanism of
> searching
> > for "what has changed when in what version".
> > You have it one file, easily searchable and scrollable.
> > The overhead is minimal, always cut/paste the Changelog update to the
> > commit log.
> > I agree that mentioned links provide all information (and more), but not
> so
> > easy to search, you always have to click a hundred times before you find
> > what you want.
> >
> > kind regards,
> > Harry
> >
> >
> > On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
> >
> >> Hi team, we have a "ChangeLog" file in the root folder that is
> apparently
> >> (?) updated whenever someone makes a commit. I don't see a need for it,
> >> and none of the other Apache projects I'm aware of bothers with such a
> file
> >> -- it's annoying needing to update it and it just seems to be
> unnecessary
> >> overhead. Can we get rid of it?
> >>
> >> So long as you make comments when you commit, here is a 100.0%
> >> authoritative and chronological list of all commits made and what they
> >> involve:
> >> http://mail-archives.apache.**org/mod_mbox/incubator-**
> >> jspwiki-commits/201301.mbox/**browser<
> http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser
> >
> >>
> >> And of course the SVN repository details the changes made to each
> specific
> >> file fully and accurately:
> >> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
> >> webdocs/Error.jsp?view=log<
> http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log
> >
> >>
> >> Finally, JIRA nicely provides us a list of commits per release:
> >> https://issues.apache.org/**jira/browse/JSPWIKI#**
> >>
> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<
> https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel
> >
> >>
> >> That should be good enough for us. WDYT?
> >>
> >> Regards,
> >> Glen
> >>
>
Re: retiring the changelog file
Posted by Ichiro Furusato <ic...@gmail.com>.
[-1]
I'm not a committer so I don't get a vote, but FWIW I've always preferred
human-managed change logs, since that means a human being is highlighting
the more important changes, new or changed APIs, features, etc. whereas
the machine-generated ones force me to slog through *all* of the changes.
Yes, it does require some overhead but it's very helpful for co-developers.
Ichiro
On Sat, Jan 26, 2013 at 11:55 PM, Harry Metske <ha...@gmail.com> wrote:
> -0.5
>
> I have always found this Changelog a very convenient mechanism of searching
> for "what has changed when in what version".
> You have it one file, easily searchable and scrollable.
> The overhead is minimal, always cut/paste the Changelog update to the
> commit log.
> I agree that mentioned links provide all information (and more), but not so
> easy to search, you always have to click a hundred times before you find
> what you want.
>
> kind regards,
> Harry
>
>
> On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
>
>> Hi team, we have a "ChangeLog" file in the root folder that is apparently
>> (?) updated whenever someone makes a commit. I don't see a need for it,
>> and none of the other Apache projects I'm aware of bothers with such a file
>> -- it's annoying needing to update it and it just seems to be unnecessary
>> overhead. Can we get rid of it?
>>
>> So long as you make comments when you commit, here is a 100.0%
>> authoritative and chronological list of all commits made and what they
>> involve:
>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>> jspwiki-commits/201301.mbox/**browser<http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser>
>>
>> And of course the SVN repository details the changes made to each specific
>> file fully and accurately:
>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
>> webdocs/Error.jsp?view=log<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log>
>>
>> Finally, JIRA nicely provides us a list of commits per release:
>> https://issues.apache.org/**jira/browse/JSPWIKI#**
>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel>
>>
>> That should be good enough for us. WDYT?
>>
>> Regards,
>> Glen
>>
Re: retiring the changelog file
Posted by Siegfried Goeschl <sg...@gmx.at>.
Hi Glen,
there are two different options
1) maintain changes.xml manually
2) create the changes.xml directly from JIRA
Unfortunately I never got 2) to work - having said that I would like to
re-ask the question - "how do I ensure that a contributor's name show up
on project?". I know it sounds a bit odd but I'm also helping out with
Hackergarden events and one thing I want to ensure is public visibility
of these events. Contributers are rightly proud if the helped out on an
ASF project ... ;-)
Cheers,
Siegfried Goeschl
On 26.01.13 21:51, Glen Mazza wrote:
> Hmm, I see:
> http://svn.apache.org/viewvc/commons/proper/email/trunk/src/changes/changes.xml?view=log
> and
> http://svn.apache.org/viewvc/commons/proper/email/trunk/pom.xml?revision=1434776&view=markup#l327
>
>
> I like changes.xml more because it has a structure to it--moving to this
> might be better after we Mavenize (however, might not help us so much
> because the technology we use to generate our website wouldn't directly
> create a website page for us like it does for Commons Email.) Still,
> most Apache projects AFAICT don't bother anymore with change files, but
> as long as it's useful for at least some team members I'm OK with it.
>
> Questions, Siegfried: how is the above changes.xml created, it is
> completely manual or partly autogenerated from JIRA (I'm assuming the
> former)? Also, is one required to open up a JIRA every time someone
> makes a change to the source code, or that's not a strict requirement?
>
> I know CXF relies on JIRA alone for the release notes: The website
> release notes link ( http://cxf.apache.org/cxf-272-release-notes.html)
> has people go directly to JIRA for a list:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&styleName=Html&Create=Create&version=12323604
>
>
> As for naming team members, Apache Syncope and Commons Email apparently
> both keep that info in their pom.xml (like they do the mailing address
> info):
> http://svn.apache.org/viewvc/syncope/trunk/pom.xml?revision=1438506&view=markup#l114
>
> http://svn.apache.org/viewvc/commons/proper/email/trunk/pom.xml?revision=1434776&view=markup
>
>
> ...which automatically populates their Team page (and mailing list page)
> when they generate their website:
> http://syncope.apache.org/team-list.html (out-of-sync right now as they
> are waiting for a new release before republishing their website).
> http://commons.apache.org/email/team-list.html
>
> However, this of course wouldn't be applicable for us yet because we're
> not yet on Maven (I'm trying, I'm trying... :) and we again use a
> different technology from Commons Email or Syncope in generating our
> website.
>
> Thanks for the info,
> Glen
>
>
> On 01/26/2013 03:07 PM, Siegfried Goeschl wrote:
>> Hi folks,
>>
>> I would suggest to move the content into a "changes.xml" which is the
>> input of a HTML report when the site is generated (using Maven). It is
>> also a good place to name contributors ... :-). It can be also used to
>> generate parts of the release notes.
>>
>> Check out
>>
>> http://commons.apache.org/email/changes-report.html
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>>
>> On 26.01.13 11:55, Harry Metske wrote:
>>> -0.5
>>>
>>> I have always found this Changelog a very convenient mechanism of
>>> searching
>>> for "what has changed when in what version".
>>> You have it one file, easily searchable and scrollable.
>>> The overhead is minimal, always cut/paste the Changelog update to the
>>> commit log.
>>> I agree that mentioned links provide all information (and more), but
>>> not so
>>> easy to search, you always have to click a hundred times before you find
>>> what you want.
>>>
>>> kind regards,
>>> Harry
>>>
>>>
>>> On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
>>>
>>>> Hi team, we have a "ChangeLog" file in the root folder that is
>>>> apparently
>>>> (?) updated whenever someone makes a commit. I don't see a need for
>>>> it,
>>>> and none of the other Apache projects I'm aware of bothers with such
>>>> a file
>>>> -- it's annoying needing to update it and it just seems to be
>>>> unnecessary
>>>> overhead. Can we get rid of it?
>>>>
>>>> So long as you make comments when you commit, here is a 100.0%
>>>> authoritative and chronological list of all commits made and what they
>>>> involve:
>>>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>>>> jspwiki-commits/201301.mbox/**browser<http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser>
>>>>
>>>>
>>>> And of course the SVN repository details the changes made to each
>>>> specific
>>>> file fully and accurately:
>>>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
>>>> webdocs/Error.jsp?view=log<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log>
>>>>
>>>>
>>>> Finally, JIRA nicely provides us a list of commits per release:
>>>> https://issues.apache.org/**jira/browse/JSPWIKI#**
>>>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel>
>>>>
>>>>
>>>> That should be good enough for us. WDYT?
>>>>
>>>> Regards,
>>>> Glen
>>>>
>>>
>
>
Re: retiring the changelog file
Posted by Glen Mazza <gl...@gmail.com>.
Hmm, I see:
http://svn.apache.org/viewvc/commons/proper/email/trunk/src/changes/changes.xml?view=log
and
http://svn.apache.org/viewvc/commons/proper/email/trunk/pom.xml?revision=1434776&view=markup#l327
I like changes.xml more because it has a structure to it--moving to this
might be better after we Mavenize (however, might not help us so much
because the technology we use to generate our website wouldn't directly
create a website page for us like it does for Commons Email.) Still,
most Apache projects AFAICT don't bother anymore with change files, but
as long as it's useful for at least some team members I'm OK with it.
Questions, Siegfried: how is the above changes.xml created, it is
completely manual or partly autogenerated from JIRA (I'm assuming the
former)? Also, is one required to open up a JIRA every time someone
makes a change to the source code, or that's not a strict requirement?
I know CXF relies on JIRA alone for the release notes: The website
release notes link ( http://cxf.apache.org/cxf-272-release-notes.html)
has people go directly to JIRA for a list:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&styleName=Html&Create=Create&version=12323604
As for naming team members, Apache Syncope and Commons Email apparently
both keep that info in their pom.xml (like they do the mailing address
info):
http://svn.apache.org/viewvc/syncope/trunk/pom.xml?revision=1438506&view=markup#l114
http://svn.apache.org/viewvc/commons/proper/email/trunk/pom.xml?revision=1434776&view=markup
...which automatically populates their Team page (and mailing list page)
when they generate their website:
http://syncope.apache.org/team-list.html (out-of-sync right now as they
are waiting for a new release before republishing their website).
http://commons.apache.org/email/team-list.html
However, this of course wouldn't be applicable for us yet because we're
not yet on Maven (I'm trying, I'm trying... :) and we again use a
different technology from Commons Email or Syncope in generating our
website.
Thanks for the info,
Glen
On 01/26/2013 03:07 PM, Siegfried Goeschl wrote:
> Hi folks,
>
> I would suggest to move the content into a "changes.xml" which is the
> input of a HTML report when the site is generated (using Maven). It is
> also a good place to name contributors ... :-). It can be also used to
> generate parts of the release notes.
>
> Check out
>
> http://commons.apache.org/email/changes-report.html
>
> Cheers,
>
> Siegfried Goeschl
>
>
>
> On 26.01.13 11:55, Harry Metske wrote:
>> -0.5
>>
>> I have always found this Changelog a very convenient mechanism of
>> searching
>> for "what has changed when in what version".
>> You have it one file, easily searchable and scrollable.
>> The overhead is minimal, always cut/paste the Changelog update to the
>> commit log.
>> I agree that mentioned links provide all information (and more), but
>> not so
>> easy to search, you always have to click a hundred times before you find
>> what you want.
>>
>> kind regards,
>> Harry
>>
>>
>> On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
>>
>>> Hi team, we have a "ChangeLog" file in the root folder that is
>>> apparently
>>> (?) updated whenever someone makes a commit. I don't see a need for
>>> it,
>>> and none of the other Apache projects I'm aware of bothers with such
>>> a file
>>> -- it's annoying needing to update it and it just seems to be
>>> unnecessary
>>> overhead. Can we get rid of it?
>>>
>>> So long as you make comments when you commit, here is a 100.0%
>>> authoritative and chronological list of all commits made and what they
>>> involve:
>>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>>> jspwiki-commits/201301.mbox/**browser<http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser>
>>>
>>>
>>> And of course the SVN repository details the changes made to each
>>> specific
>>> file fully and accurately:
>>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
>>> webdocs/Error.jsp?view=log<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log>
>>>
>>>
>>> Finally, JIRA nicely provides us a list of commits per release:
>>> https://issues.apache.org/**jira/browse/JSPWIKI#**
>>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel>
>>>
>>>
>>> That should be good enough for us. WDYT?
>>>
>>> Regards,
>>> Glen
>>>
>>
Re: retiring the changelog file
Posted by Siegfried Goeschl <sg...@gmx.at>.
Hi folks,
I would suggest to move the content into a "changes.xml" which is the
input of a HTML report when the site is generated (using Maven). It is
also a good place to name contributors ... :-). It can be also used to
generate parts of the release notes.
Check out
http://commons.apache.org/email/changes-report.html
Cheers,
Siegfried Goeschl
On 26.01.13 11:55, Harry Metske wrote:
> -0.5
>
> I have always found this Changelog a very convenient mechanism of searching
> for "what has changed when in what version".
> You have it one file, easily searchable and scrollable.
> The overhead is minimal, always cut/paste the Changelog update to the
> commit log.
> I agree that mentioned links provide all information (and more), but not so
> easy to search, you always have to click a hundred times before you find
> what you want.
>
> kind regards,
> Harry
>
>
> On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
>
>> Hi team, we have a "ChangeLog" file in the root folder that is apparently
>> (?) updated whenever someone makes a commit. I don't see a need for it,
>> and none of the other Apache projects I'm aware of bothers with such a file
>> -- it's annoying needing to update it and it just seems to be unnecessary
>> overhead. Can we get rid of it?
>>
>> So long as you make comments when you commit, here is a 100.0%
>> authoritative and chronological list of all commits made and what they
>> involve:
>> http://mail-archives.apache.**org/mod_mbox/incubator-**
>> jspwiki-commits/201301.mbox/**browser<http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser>
>>
>> And of course the SVN repository details the changes made to each specific
>> file fully and accurately:
>> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
>> webdocs/Error.jsp?view=log<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log>
>>
>> Finally, JIRA nicely provides us a list of commits per release:
>> https://issues.apache.org/**jira/browse/JSPWIKI#**
>> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel>
>>
>> That should be good enough for us. WDYT?
>>
>> Regards,
>> Glen
>>
>
Re: retiring the changelog file
Posted by Harry Metske <ha...@gmail.com>.
-0.5
I have always found this Changelog a very convenient mechanism of searching
for "what has changed when in what version".
You have it one file, easily searchable and scrollable.
The overhead is minimal, always cut/paste the Changelog update to the
commit log.
I agree that mentioned links provide all information (and more), but not so
easy to search, you always have to click a hundred times before you find
what you want.
kind regards,
Harry
On 25 January 2013 03:29, Glen Mazza <gl...@gmail.com> wrote:
> Hi team, we have a "ChangeLog" file in the root folder that is apparently
> (?) updated whenever someone makes a commit. I don't see a need for it,
> and none of the other Apache projects I'm aware of bothers with such a file
> -- it's annoying needing to update it and it just seems to be unnecessary
> overhead. Can we get rid of it?
>
> So long as you make comments when you commit, here is a 100.0%
> authoritative and chronological list of all commits made and what they
> involve:
> http://mail-archives.apache.**org/mod_mbox/incubator-**
> jspwiki-commits/201301.mbox/**browser<http://mail-archives.apache.org/mod_mbox/incubator-jspwiki-commits/201301.mbox/browser>
>
> And of course the SVN repository details the changes made to each specific
> file fully and accurately:
> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/src/**
> webdocs/Error.jsp?view=log<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/src/webdocs/Error.jsp?view=log>
>
> Finally, JIRA nicely provides us a list of commits per release:
> https://issues.apache.org/**jira/browse/JSPWIKI#**
> selectedTab=com.atlassian.**jira.plugin.system.project%**3Achangelog-panel<https://issues.apache.org/jira/browse/JSPWIKI#selectedTab=com.atlassian.jira.plugin.system.project%3Achangelog-panel>
>
> That should be good enough for us. WDYT?
>
> Regards,
> Glen
>