Alternative configuration directory

Would you mind changing it to

  os.environ.get('GTIMELOG_HOME') or '~/.gtimelog'

? I think setting $GTIMELOG_HOME to an empty value should be equivalent to not setting it at all, instead of using the current working directory.

I'm going to grant you write access to gtimelog trunk, so you can push this yourself -- assuming I figure out how to do that in Launchpad. I did it once for zodbbrowser, I should be able to figure the confusing UI again....

Barry, you should be able to push to lp:gtimelog now.

> Would you mind changing it to
> os.environ.get('GTIMELOG_HOME') or '~/.gtimelog'
> ? I think setting $GTIMELOG_HOME to an empty value should be equivalent to not setting it at all, instead of using the current
> working directory.

Good idea, done.

> I'm going to grant you write access to gtimelog trunk, so you can push this yourself -- assuming I figure out how to do that in
> Launchpad. I did it once for zodbbrowser, I should be able to figure the confusing UI again...

Done, and thanks! This branch pushed to trunk in r155.

What do you think about doing a release soon? I'd like to get updated versions into Debian and Ubuntu eventually. Both are in feature freeze, but I'd be happy to update the packaging and throw it into a PPA. Either mine or ~gtimelog-dev if we create one. If you give me upload rights to the cheeseshop project, I'm happy to take care of it all.

Oh, one other thing. I'd like to upgrade the trunk branch to 2a format. It'll make merges and other tasks *so* much easier. Again, happy to take care of it if you approve. It will mean that you'll have to re-branch the trunk, and any stacked branches will be broken, but I think the practical impact of that will be minimal.

On Thu, Sep 02, 2010 at 05:47:23PM -0000, Barry Warsaw wrote:
> What do you think about doing a release soon?

Sure. There's one minor outstanding issue that I'd like to get fixed
before releasing 0.4.0:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595280

> I'd like to get updated
> versions into Debian and Ubuntu eventually.

That would be awesome. The Debian package is currently orphaned. I
once tried to build an updated version, but it turned out to be more
difficult than I'd thought.

> Both are in feature freeze,
> but I'd be happy to update the packaging and throw it into a PPA.
> Either mine or ~gtimelog-dev if we create one.

Yay!

> If you give me upload
> rights to the cheeseshop project, I'm happy to take care of it all.

It's no big deal; 'make release' automates most of it.

What's your PyPI username?

On Thu, Sep 02, 2010 at 05:48:47PM -0000, Barry Warsaw wrote:
> Oh, one other thing. I'd like to upgrade the trunk branch to 2a format.

Upgraded.

> It'll make merges and other tasks *so* much easier. Again, happy to
> take care of it if you approve. It will mean that you'll have to re-
> branch the trunk,

Sounds ominous. I can still 'bzr pull' from lp:gtimelog, and 'bzr
upgrade' in my local tree removed on-the-fly conversion warnings.

> and any stacked branches will be broken, but I think
> the practical impact of that will be minimal.

I don't think there are any stacked branches created on top of
lp:~gtimelog-dev/gtimelog/trunk.

There are stacked branches on top of lp:~mgedmin/gtimelog/trunk. This
exposes an interesting bug/misfeature in Bazaar/Launchpad: When I
changed the owner of the lp:gtimelog branch, the real URL changed from
~mgedmin to ~gtimelog-dev, and all other branches that were stacked on
it became broken. I had to explicitly bzr push
lp:~mgedmin/gtimelog/trunk to make other branches work.

Anyway, lp:~mgedmin/gtimelog/trunk is still using the old format, and I
can still push to it.

Marius Gedminas
--
And yes, you'd be insane to consider C++ for a new project in 2007.
                -- Thomas Ptacek

I fixed the .desktop file and released 0.4.0 to PyPI.

On Sep 02, 2010, at 09:07 PM, Marius Gedminas wrote:

>On Thu, Sep 02, 2010 at 05:47:23PM -0000, Barry Warsaw wrote:
>> What do you think about doing a release soon?
>
>Sure. There's one minor outstanding issue that I'd like to get fixed
>before releasing 0.4.0:
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595280

Cool, thanks for fixing this. Actually, I think it will also help solve a
major confusion I had when I started using gtimelog. I use Gnome Do (the most
awesomest piece of software evar!) and I'd keep typing "gtimelog" and getting
no hits. It wasn't until someone mentioned to me that Do indexes the .desktop
Name that I realized I had to type "time tracker" for it to find gtimelog. I
think with this fix, either will work. \o/

>> I'd like to get updated
>> versions into Debian and Ubuntu eventually.
>
>That would be awesome. The Debian package is currently orphaned. I
>once tried to build an updated version, but it turned out to be more
>difficult than I'd thought.

Now that there's an upstream tarball, I'll give it a shot, first to my PPA and
then for Debian and Ubuntu. I'm considering throwing away the existing
packaging and starting fresh (well, keeping the changelog probably). Tools
like python-stdeb make this really easy.

>> Both are in feature freeze,
>> but I'd be happy to update the packaging and throw it into a PPA.
>> Either mine or ~gtimelog-dev if we create one.
>
>Yay!

Shall we do a ~gtimelog-dev PPA? I think you need to set that up or give me
admin on the team (you may have already done that).

>> If you give me upload
>> rights to the cheeseshop project, I'm happy to take care of it all.
>
>It's no big deal; 'make release' automates most of it.

Cool.

>What's your PyPI username?

It's the ultra-creative and hard to guess: barry

:)

>On Thu, Sep 02, 2010 at 05:48:47PM -0000, Barry Warsaw wrote:
>> Oh, one other thing. I'd like to upgrade the trunk branch to 2a
>> format.
>
>Upgraded.

Awesome.

>> It'll make merges and other tasks *so* much easier. Again, happy to
>> take care of it if you approve. It will mean that you'll have to re-
>> branch the trunk,
>
>Sounds ominous. I can still 'bzr pull' from lp:gtimelog, and 'bzr
>upgrade' in my local tree removed on-the-fly conversion warnings.

Yep, right. I forgot about local upgrade :).

>> and any stacked branches will be broken, but I think
>> the practical impact of that will be minimal.
>
>I don't think there are any stacked branches created on top of
>lp:~gtimelog-dev/gtimelog/trunk.
>
>There are stacked branches on top of lp:~mgedmin/gtimelog/trunk. This
>exposes an interesting bug/misfeature in Bazaar/Launchpad: When I
>changed the owner of the lp:gtimelog branch, the real URL changed from
>~mgedmin to ~gtimelog-dev, and all other branches that were stacked on
>it became broken. I had to explicitly bzr push
>lp:~mgedmin/gtimelog/trunk to make other branches work.

There might be a bug open on that. Yeah, it happens and should be fixed
though.

>Anyway, lp:~mgedmin/gtimelog/trunk is still using the old format, and I
>can still push to it.

Excellent. I'll branch off the ~gtimelog-dev trunk from now on and take care
of the above asap.