gramps-addons/ gramps32

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

gramps-addons/ gramps32

robhealey1
Dear All:

I was wondering why should we  keep gramps32 in the gramps-addons repository?  We are no longer updating graps32...

I would suggest zipping that directory up and then storing it somewhere but certainly not in the gramps-addons repository???  What do you think?

I do not see any purpose in keeping it within the active repository if gramps32 has been deprecated already?

--
Sincerely yours,
Rob G. Healey



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: gramps-addons/ gramps32

Tim Lyons
Administrator
Is it considerations of disk space in sourceforge that are prompting this suggestion? Did I miss the memo about disk space no longer being essentially free these days?  :-)

If you are concerned about disk space (as suggested by your zip comment), then how do you know that sourceforge are not already zipping the files? How do you know whether they do something special with files that have not been accessed recently? (I don't particularly see why they would, given that disk space is so cheap now, but who knows).

If it is not disk space, then why do you want to make it more complicated to access older files in the repository. This smacks of your suggestion to handle older files in the main repository separately. The reason not to do so are the same here - who knows when one might want to access an older file, to compare with the current, or to check out a bug or functionality with some older version.

Perhaps your reasoning is to make it harder for users to access the wrong version of an add-on. However, now that add-on handling is largely automated, this is now pretty unlikely.

Since Jan 2012 there have been 264 downloads of 3.2.6 and 511 of 3.2.5 (I haven't checked other versions). I don't imagine that all those users have stopped using 3.2, so I imagine they would like to be able to download add-ons for their version.

If you have a good reason, then by all means let's hear it, but otherwise let's just leave the repositories as they are. "Why keep gramps32..." - why not?
Reply | Threaded
Open this post in threaded view
|

Re: gramps-addons/ gramps32

robhealey1
Tim:

Thank you for providing the statistics for Gramps32...

On Mon, Jun 4, 2012 at 4:44 PM, Tim Lyons <[hidden email]> wrote:
Is it considerations of disk space in sourceforge that are prompting this
suggestion? Did I miss the memo about disk space no longer being essentially
free these days?  :-)

If you are concerned about disk space (as suggested by your zip comment),
then how do you know that sourceforge are not already zipping the files? How do you know whether they do something special with files that have not been accessed recently? (I don't particularly see why they would, given that disk
space is so cheap now, but who knows).

I do not know what sourceforge does or not with unused and unaccessed files...

If it is not disk space, then why do you want to make it more complicated to access older files in the repository. This smacks of your suggestion to handle older files in the main repository separately. The reason not to do
so are the same here - who knows when one might want to access an older file, to compare with the current, or to check out a bug or functionality with some older version.

This is correct, but I must say that some people certainly upgrade their gramps software regularly and obsolete their older versions!

Perhaps your reasoning is to make it harder for users to access the wrong version of an add-on. However, now that add-on handling is largely automated, this is now pretty unlikely.

Not this at all!

Since Jan 2012 there have been 264 downloads of 3.2.6 and 511 of 3.2.5 (I
haven't checked other versions). I don't imagine that all those users have
stopped using 3.2, so I imagine they would like to be able to download add-ons for their version.

I had not known this information!

If you have a good reason, then by all means let's hear it, but otherwise let's just leave the repositories as they are. "Why keep  gramps32..." - why not?

It was just an idea!  I do not see the point of keeping such old files?  It has nothing to do with space!

I was just thinking that some software packages, obsolete their older versions when they make a huge non back portable  update/ database changes ...

Sincerely yours,
Rob G. Healey


--
View this message in context: http://gramps.1791082.n4.nabble.com/gramps-addons-gramps32-tp4655290p4655292.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



--
Sincerely yours,
Rob G. Healey



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel