General update question

[Roger Oberholtzer]

I have almost 60 extensions from TracHack installed on my Trac system.
Keeping them up-to-date is a bit of work. I am curious if anyone has
settled on a good way to (1) find out which installed things have
updates available and (2) install updates in some easy fashion.

The most interesting thing is #1. Just knowing that there is a update
available is the most time consuming part. I am not sure I would want
them to be upgraded just because an update is available. So #2 is
probably less interesting.

Just curious...


--
Roger Oberholtzer

[David Talmage]

On Apr 30, 3:44 am, Roger Oberholtzer <roger.oberholt...@gmail.com>
wrote:

> I have almost 60 extensions from TracHack installed on my Trac system.
> Keeping them up-to-date is a bit of work. I am curious if anyone has
> settled on a good way to (1) find out which installed things have
> updates available and (2) install updates in some easy fashion.

> ...

Roger, are you using Linux? Usually, the desktop package managers tell
you when an upgrade is available. On servers, where there is no
desktop, I've used apticron to learn about updated debian packages.

[Roger Oberholtzer]

I use openSUSE, which has an excellent package creation and maintenance
system. Of course that applies to things that are packaged for
installation. Trac Hack macros and all are not so packaged. They are in
a subversion repository on the Trac Hack site.

I has hoped to do something with easy_install. I will have to see if it
handles just telling if there is something newer than what is installed,
or if it always wants to install no matter.



--
Roger Oberholtzer

[Ed - 0x1b, Inc.]

Roger you might submit a ticket requesting Trac-Hacks publish a RPM
repository of the available hacks - it might make sense if there is
automated build process that it could be extended to build a yum or
zypper or deb repository.

I would expect an RSS feed on a hack's folder which would let you
follow progress on your plugins, but I couldn't find it (not logged
in)

[Roger Oberholtzer]

I would think it would have to be an RPM for each hack. I wonder if the
openSUSE Build Service could be used for this. It can build packages for
many distros. The trick would be triggering it to make a new RPM for
something.

> I would expect an RSS feed on a hack's folder which would let you
> follow progress on your plugins, but I couldn't find it (not logged
> in)

One thing that makes this a bit more of a moving target is that all
hacks are in the same repo. So, if you download one, the release in the
archive name increments even if there is no change to the hack actually
in the archive.


>

--
Roger Oberholtzer

[RjOllos]

On Monday, April 30, 2012 12:44:52 AM UTC-7, Roger Oberholtzer wrote:

I have almost 60 extensions from TracHack installed on my Trac system.
Keeping them up-to-date is a bit of work. I am curious if anyone has
settled on a good way to (1) find out which installed things have
updates available and (2) install updates in some easy fashion.

This has been an issue for me as well. Previously, I would setup a monitor for each plugin using a service. The one I've used most regularly is WatchThatPage (1).

Now, I just monitor the RSS feed on a daily basis, but unfortunately there isn't a way to get an RSS feed for an individual project (2,3).

I keep the source for each plugin on the server, and then run `svn up`, `python setup.py install` to update each plugin (first on a staging server to test, then on the main server). I've considered automating this more by:
 1. Writing a script that checks whether there are remote changes to the svn branch and echoes the changesets that are not part of my work copy.
 2. Running the check-for-updates script from cron and emailing the output to myself.
 3. Adding a simple `update <projectname>` script that runs the 3 or 4 steps necessary to update a plugin from the working copy (i.e., `setup.py`, `trac-admin deploy`, `apache restart`).

(1) http://watchthatpage.com/
(2) http://trac-hacks.org/ticket/1151
(3) http://trac-hacks.org/ticket/6168

[Roger Oberholtzer]

On Wed, 2012-05-02 at 10:47 -0700, RjOllos wrote:
> http://trac-hacks.org/ticket/1151

At first I thought that if Trac Hack had the AnnouncerPlugin installed,
this could solve much of the issue. That requires that there is a change
to the hack's page when an update is made. I suspect that the changes
listed at the bottom of the page are from a macro that queries this info
for the plugin. This means that the page itself (the wiki original text)
does not change. So in that case the AnnouncerPlugin would not be
activated.

I suspect that there is need of a subversion commit hook that could do
something when a change is checked in to the repository. It might (or
might not) need some smarts as all hacks are in one repo. But it could
start life rather dumb. Perhaps there is already a subversion add on
that does this?

Of course, I could probably live with a message of any changes in the
repo as a whole and then use my mail filter to establish order to the
messages...

--
Roger Oberholtzer

[RjOllos]

On Wednesday, May 2, 2012 11:06:48 PM UTC-7, Roger Oberholtzer wrote:

On Wed, 2012-05-02 at 10:47 -0700, RjOllos wrote:
> http://trac-hacks.org/ticket/1151

At first I thought that if Trac Hack had the AnnouncerPlugin installed,
this could solve much of the issue. That requires that there is a change
to the hack's page when an update is made. I suspect that the changes
listed at the bottom of the page are from a macro that queries this info
for the plugin. This means that the page itself (the wiki original text)
does not change. So in that case the AnnouncerPlugin would not be
activated.

Right, the change history at the bottom of the page is provided by the ChangeLogMacro.

What I think we need is a timeline, with the ability to selectably display wiki page change and/or SVN repository changes, filtered by project. This would probably have to be an extension to the TracHacksPlugin.

[Brettschneider Falk]

Hi,

Rj’s description is the most useful approach. I just want to add it’s not necessary to update every day. The current plugin system is quite stable and working well as it is, and development speed is slow. So I think it’s enough to update every 3 - 6 months. Certain plugins have a commit rush sometimes, and you may trac this on the Trac-hacks timeline page every 2 weeks. Well, this is just my experience…

CU, F@lk

 

 

Geschäftsführer: Marcel Seeber · Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE  189714583

[Brettschneider Falk]

For good survey, it would be cool if the timeline page also displays the name of the plugin for the listed tickets and commits.

 

 

Geschäftsführer: Marcel Seeber · Dr. Oliver Vietze
Sitz der Gesellschaft: Radeberg
Amtsgericht Dresden: HRB 15379
Ust. ID: DE  189714583

 

 

From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On Behalf Of RjOllos
Sent: Thursday, May 03, 2012 8:32 AM
To: trac-...@googlegroups.com
Subject: Re: [Trac] Re: General update question

 

What I think we need is a timeline, with the ability to selectably display wiki page change and/or SVN repository changes, filtered by project. This would probably have to be an extension to the TracHacksPlugin..