Menu
▾
▴
pyblosxom-devel
|
From: Hauke F. <ha...@Es...> - 2012-07-16 20:27:10
|
Hi, a late "Thank you" to Will for all his work on PyBlosxom, and another "Thank you" to Akai for taking over! I maintain the NetBSD pkgsrc pyblosxom package. Trying to update the package, I found that http://pyblosxom.github.com/downloads/ is dangling. Would it be possible to set up the release source tarballs under the same path as on pyblosxom.bluesock.org? Thanks, hauke -- "It's never straight up and down" (DEVO) |
|
From: Tim G. <tg...@pr...> - 2012-07-16 21:02:56
|
On Jul 16, 2012 at 10:10 PM +0200, Hauke Fath wrote: >Would it be possible to set up the release source tarballs under the same >path as on pyblosxom.bluesock.org? I don't know if it is possible or not, hopefully others will chime in, but tarballs of the various releases should be available here: https://github.com/pyblosxom/pyblosxom/tags |
|
From: will kahn-g. <wi...@bl...> - 2012-07-16 21:11:22
|
I'm fairly sure that those are tarballs generated from whatever was
tagged at that point. That's not the same thing as a release tarball
where a release tarball is generated by running:
python setup.py sdist
and possibly some other things. I don't remember offhand what I did for
Pyblosxom releases, but I know other projects I've worked on had very
different release tarballs from the tag tarballs that Github hosts.
/will
On 07/16/2012 04:45 PM, Tim Gray wrote:
> On Jul 16, 2012 at 10:10 PM +0200, Hauke Fath wrote:
>> Would it be possible to set up the release source tarballs under the same
>> path as on pyblosxom.bluesock.org?
>
> I don't know if it is possible or not, hopefully others will chime in,
> but tarballs of the various releases should be available here:
>
> https://github.com/pyblosxom/pyblosxom/tags
|
|
From: Akai K. <ope...@gm...> - 2012-08-06 13:40:14
|
Hi PyBlosxom devs! I've been travelling in the US so I haven't been able to address issues as quickly as I'd like. I'd like to assure the community that I've been working hard and am available by email if you don't see me on IRC. If you see any issues that you feel like fixing, feel free! -Akai |
|
From: Akai <ope...@gm...> - 2012-07-18 00:47:03
|
I just realized my emails never reached the list: I've fixed the issue (apparently GitHub doesn't like PHP very much) enjoy: http://pyblosxom.github.com/download/ Originally, the files were there just github didn't show the directory contents Get them from the active site: https://github.com/pyblosxom/pyblosxom.github.com/tree/master/download Get them from the site's source github: https://github.com/pyblosxom/pyblosxom-web/tree/master/htdocs/download Even the old links work http://pyblosxom.github.com/download/pyblosxom-1.5rc3.tar.gz for example just the index page wasn't up. -Akai |
|
From: Akai K. <ope...@gm...> - 2012-12-04 01:04:40
|
Hi! By request, I've created a plugin repo (https://github.com/pyblosxom/plugins.git) for 3rd party plugins and I hope to make another for flavours as soon as I have the time. The idea is to make it easier for people to contribute to existing 3rd party plugins and to build up a library of updated plugins (which was difficult when they were hosted on other people's githubs/servers) Feel free to tell me why this is a great/horrible idea and/or to add and update plugins. I plan on adding the existing plugins as soon as I test them for compatibility with the latest version of Pyblosxom. The core plugins will (with the exception of the "sample" plugin) stay out of the 3rd party repo. -akai |
|
From: <wa...@ho...> - 2012-12-04 02:27:11
|
Well, if its actually hosted in other git repos, why not link to it as a git submodule within the plugins.git project? At least the pointers are there, and the original maintainers can update as they please. > Hi! > > By request, I've created a plugin repo > (https://github.com/pyblosxom/plugins.git) for 3rd party plugins and I > hope to make another for flavours as soon as I have the time. > > The idea is to make it easier for people to contribute to existing 3rd > party plugins and to build up a library of updated plugins (which was > difficult when they were hosted on other people's githubs/servers) > > Feel free to tell me why this is a great/horrible idea and/or to add and > update plugins. > I plan on adding the existing plugins as soon as I test them for > compatibility with the latest version of Pyblosxom. > > The core plugins will (with the exception of the "sample" plugin) stay > out of the 3rd party repo. > > -akai > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > pyblosxom-users mailing list > pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-users > > |
|
From: Akai K. <ope...@gm...> - 2012-12-04 02:12:36
|
Because its not just other git repos, its all over the place. Also - While I'm not sure how the git submodule process would work, in any case, publishing to the repo should be akin to a "release" of your plugin, while the versions in people's personal repos would be the development versions. I hope that it will always be possible to pull a working version of a 3rd party plugin from the repo. On 12/04/2012 03:54 AM, wa...@ho... wrote: > Well, if its actually hosted in other git repos, why not link to it as a > git submodule within the plugins.git project? At least the pointers are > there, and the original maintainers can update as they please. > >> Hi! >> >> By request, I've created a plugin repo >> (https://github.com/pyblosxom/plugins.git) for 3rd party plugins and I >> hope to make another for flavours as soon as I have the time. >> >> The idea is to make it easier for people to contribute to existing 3rd >> party plugins and to build up a library of updated plugins (which was >> difficult when they were hosted on other people's githubs/servers) >> >> Feel free to tell me why this is a great/horrible idea and/or to add and >> update plugins. >> I plan on adding the existing plugins as soon as I test them for >> compatibility with the latest version of Pyblosxom. >> >> The core plugins will (with the exception of the "sample" plugin) stay >> out of the 3rd party repo. >> >> -akai >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> pyblosxom-users mailing list >> pyb...@li... >> https://lists.sourceforge.net/lists/listinfo/pyblosxom-users >> >> > > > |
|
From: Asheesh L. <as...@as...> - 2012-12-04 02:51:55
|
On Tue, 4 Dec 2012, Akai Kistune wrote: > Because its not just other git repos, its all over the place. Also - > While I'm not sure how the git submodule process would work, in any > case, publishing to the repo should be akin to a "release" of your > plugin, while the versions in people's personal repos would be the > development versions. > I hope that it will always be possible to pull a working version of a > 3rd party plugin from the repo. I'd just like to say, as a user of pyblosxom: In my opinion this is *amazing*. Sincerely, Asheesh. |
|
From: Wari W. <wa...@ho...> - 2012-12-04 03:20:22
|
Git submodules are really pointers to commits of a particular repos. Therefore a release of a plugin would mean a specific commit at the original site. Publishing it together with the plugins.git (instead of submodules) would mean that all historical logs regarding to a particular version is lost. Anyway, there are pros and cons of both approaches, but I have a feeling that putting it all in to the plugins.git would lead to the contrib situation where plugins get stale after a while. At least with pointers/submodules, one can look up the original maintainer, and provide updates if needed instead of updating plugins.git, and you then have to go back to the original maintainer to update their copy. Anyway, it's all up to you what you think best, I still think the submodule idea is great, but I guess there are others out there using CVS or Subversion, in which case, submodules don't work for them. On 04/12/2012 10:36, Asheesh Laroia wrote: > On Tue, 4 Dec 2012, Akai Kistune wrote: > >> Because its not just other git repos, its all over the place. Also - >> While I'm not sure how the git submodule process would work, in any >> case, publishing to the repo should be akin to a "release" of your >> plugin, while the versions in people's personal repos would be the >> development versions. >> I hope that it will always be possible to pull a working version of a >> 3rd party plugin from the repo. |
|
From: Akai K. <ope...@gm...> - 2012-12-04 09:28:15
|
Wari - Thats why I ask people put contact information with the plugin. While there really is nothing I can do about stagnation, I feel this is a good solution for all the people running non-git setups or people who frequently break their build. Also, there is the URL field in the plugin docstring which should be the git/svn/server where one can find the 3rd party plugins repos or download which should also help counter the issue. Asheesh - Thanks! On 12/04/2012 05:20 AM, Wari Wahab wrote: > Git submodules are really pointers to commits of a particular repos. > Therefore a release of a plugin would mean a specific commit at the > original site. Publishing it together with the plugins.git (instead of > submodules) would mean that all historical logs regarding to a > particular version is lost. > > Anyway, there are pros and cons of both approaches, but I have a feeling > that putting it all in to the plugins.git would lead to the contrib > situation where plugins get stale after a while. At least with > pointers/submodules, one can look up the original maintainer, and > provide updates if needed instead of updating plugins.git, and you then > have to go back to the original maintainer to update their copy. > > Anyway, it's all up to you what you think best, I still think the > submodule idea is great, but I guess there are others out there using > CVS or Subversion, in which case, submodules don't work for them. > > On 04/12/2012 10:36, Asheesh Laroia wrote: >> On Tue, 4 Dec 2012, Akai Kistune wrote: >> >>> Because its not just other git repos, its all over the place. Also - >>> While I'm not sure how the git submodule process would work, in any >>> case, publishing to the repo should be akin to a "release" of your >>> plugin, while the versions in people's personal repos would be the >>> development versions. >>> I hope that it will always be possible to pull a working version of a >>> 3rd party plugin from the repo. > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > |
|
From: Florian B. <flo...@gm...> - 2012-12-04 11:30:50
|
I just did a pull-request (breadcrumb-plugin) - first time i've been using git and/or github. I hope I did not mess up anything. Anyway, great idea, keep it up! Regards, Flo Am Dienstag, den 04.12.2012, 11:28 +0200 schrieb Akai Kistune: > Wari - > > Thats why I ask people put contact information with the plugin. While > there really is nothing I can do about stagnation, I feel this is a good > solution for all the people running non-git setups or people who > frequently break their build. > > Also, there is the URL field in the plugin docstring which should be the > git/svn/server where one can find the 3rd party plugins repos or > download which should also help counter the issue. > > > Asheesh - > Thanks! > > > > > On 12/04/2012 05:20 AM, Wari Wahab wrote: > > Git submodules are really pointers to commits of a particular repos. > > Therefore a release of a plugin would mean a specific commit at the > > original site. Publishing it together with the plugins.git (instead of > > submodules) would mean that all historical logs regarding to a > > particular version is lost. > > > > Anyway, there are pros and cons of both approaches, but I have a feeling > > that putting it all in to the plugins.git would lead to the contrib > > situation where plugins get stale after a while. At least with > > pointers/submodules, one can look up the original maintainer, and > > provide updates if needed instead of updating plugins.git, and you then > > have to go back to the original maintainer to update their copy. > > > > Anyway, it's all up to you what you think best, I still think the > > submodule idea is great, but I guess there are others out there using > > CVS or Subversion, in which case, submodules don't work for them. > > > > On 04/12/2012 10:36, Asheesh Laroia wrote: > >> On Tue, 4 Dec 2012, Akai Kistune wrote: > >> > >>> Because its not just other git repos, its all over the place. Also - > >>> While I'm not sure how the git submodule process would work, in any > >>> case, publishing to the repo should be akin to a "release" of your > >>> plugin, while the versions in people's personal repos would be the > >>> development versions. > >>> I hope that it will always be possible to pull a working version of a > >>> 3rd party plugin from the repo. > > > > ------------------------------------------------------------------------------ > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > Remotely access PCs and mobile devices and provide instant support > > Improve your efficiency, and focus on delivering more value-add services > > Discover what IT Professionals Know. Rescue delivers > > http://p.sf.net/sfu/logmein_12329d2d > > _______________________________________________ > > Pyblosxom-devel mailing list > > Pyb...@li... > > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel |
|
From: Dieter P. <di...@pl...> - 2012-12-04 15:18:42
|
why not just allow both? depending on the preference of the original plugin creator, he should be able to choose whether his pull request includes the plugin directory itself, or a submodule definition. personally i think submodules are the better option, you can ask people to include a lot of info in their files and/or README's, but it will never be as complete as a submodule using the original git repository itself. but i would just allow both... as long as you end up with a subdirectory containing the plugin and maybe some documentation On Tue, 04 Dec 2012 12:30:21 +0100 Florian Bäuerle <flo...@gm...> wrote: > I just did a pull-request (breadcrumb-plugin) - first time i've been > using git and/or github. I hope I did not mess up anything. > > Anyway, great idea, keep it up! > > Regards, > Flo > Am Dienstag, den 04.12.2012, 11:28 +0200 schrieb Akai Kistune: > > Wari - > > > > Thats why I ask people put contact information with the plugin. While > > there really is nothing I can do about stagnation, I feel this is a good > > solution for all the people running non-git setups or people who > > frequently break their build. > > > > Also, there is the URL field in the plugin docstring which should be the > > git/svn/server where one can find the 3rd party plugins repos or > > download which should also help counter the issue. > > > > > > Asheesh - > > Thanks! > > > > > > > > > > On 12/04/2012 05:20 AM, Wari Wahab wrote: > > > Git submodules are really pointers to commits of a particular repos. > > > Therefore a release of a plugin would mean a specific commit at the > > > original site. Publishing it together with the plugins.git (instead of > > > submodules) would mean that all historical logs regarding to a > > > particular version is lost. > > > > > > Anyway, there are pros and cons of both approaches, but I have a feeling > > > that putting it all in to the plugins.git would lead to the contrib > > > situation where plugins get stale after a while. At least with > > > pointers/submodules, one can look up the original maintainer, and > > > provide updates if needed instead of updating plugins.git, and you then > > > have to go back to the original maintainer to update their copy. > > > > > > Anyway, it's all up to you what you think best, I still think the > > > submodule idea is great, but I guess there are others out there using > > > CVS or Subversion, in which case, submodules don't work for them. > > > > > > On 04/12/2012 10:36, Asheesh Laroia wrote: > > >> On Tue, 4 Dec 2012, Akai Kistune wrote: > > >> > > >>> Because its not just other git repos, its all over the place. Also - > > >>> While I'm not sure how the git submodule process would work, in any > > >>> case, publishing to the repo should be akin to a "release" of your > > >>> plugin, while the versions in people's personal repos would be the > > >>> development versions. > > >>> I hope that it will always be possible to pull a working version of a > > >>> 3rd party plugin from the repo. > > > > > > ------------------------------------------------------------------------------ > > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > > Remotely access PCs and mobile devices and provide instant support > > > Improve your efficiency, and focus on delivering more value-add services > > > Discover what IT Professionals Know. Rescue delivers > > > http://p.sf.net/sfu/logmein_12329d2d > > > _______________________________________________ > > > Pyblosxom-devel mailing list > > > Pyb...@li... > > > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > > > > > > > > > ------------------------------------------------------------------------------ > > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > > Remotely access PCs and mobile devices and provide instant support > > Improve your efficiency, and focus on delivering more value-add services > > Discover what IT Professionals Know. Rescue delivers > > http://p.sf.net/sfu/logmein_12329d2d > > _______________________________________________ > > Pyblosxom-devel mailing list > > Pyb...@li... > > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel |
|
From: Akai <ope...@gm...> - 2012-12-04 22:41:41
|
Dieter, I'll learn up about it and see if its possible to seamlessly offer both. On 12/4/2012 4:06 PM, Dieter Plaetinck wrote: > why not just allow both? > depending on the preference of the original plugin creator, he should be able to choose > whether his pull request includes the plugin directory itself, or a submodule definition. > > personally i think submodules are the better option, you can ask people to include a lot of info > in their files and/or README's, but it will never be as complete as a submodule using the original > git repository itself. > but i would just allow both... as long as you end up with a subdirectory containing the plugin and maybe some documentation > > On Tue, 04 Dec 2012 12:30:21 +0100 > Florian Bäuerle <flo...@gm...> wrote: > >> I just did a pull-request (breadcrumb-plugin) - first time i've been >> using git and/or github. I hope I did not mess up anything. >> >> Anyway, great idea, keep it up! >> >> Regards, >> Flo >> Am Dienstag, den 04.12.2012, 11:28 +0200 schrieb Akai Kistune: >>> Wari - >>> >>> Thats why I ask people put contact information with the plugin. While >>> there really is nothing I can do about stagnation, I feel this is a good >>> solution for all the people running non-git setups or people who >>> frequently break their build. >>> >>> Also, there is the URL field in the plugin docstring which should be the >>> git/svn/server where one can find the 3rd party plugins repos or >>> download which should also help counter the issue. >>> >>> >>> Asheesh - >>> Thanks! >>> >>> >>> >>> >>> On 12/04/2012 05:20 AM, Wari Wahab wrote: >>>> Git submodules are really pointers to commits of a particular repos. >>>> Therefore a release of a plugin would mean a specific commit at the >>>> original site. Publishing it together with the plugins.git (instead of >>>> submodules) would mean that all historical logs regarding to a >>>> particular version is lost. >>>> >>>> Anyway, there are pros and cons of both approaches, but I have a feeling >>>> that putting it all in to the plugins.git would lead to the contrib >>>> situation where plugins get stale after a while. At least with >>>> pointers/submodules, one can look up the original maintainer, and >>>> provide updates if needed instead of updating plugins.git, and you then >>>> have to go back to the original maintainer to update their copy. >>>> >>>> Anyway, it's all up to you what you think best, I still think the >>>> submodule idea is great, but I guess there are others out there using >>>> CVS or Subversion, in which case, submodules don't work for them. >>>> >>>> On 04/12/2012 10:36, Asheesh Laroia wrote: >>>>> On Tue, 4 Dec 2012, Akai Kistune wrote: >>>>> >>>>>> Because its not just other git repos, its all over the place. Also - >>>>>> While I'm not sure how the git submodule process would work, in any >>>>>> case, publishing to the repo should be akin to a "release" of your >>>>>> plugin, while the versions in people's personal repos would be the >>>>>> development versions. >>>>>> I hope that it will always be possible to pull a working version of a >>>>>> 3rd party plugin from the repo. >>>> ------------------------------------------------------------------------------ >>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>>> Remotely access PCs and mobile devices and provide instant support >>>> Improve your efficiency, and focus on delivering more value-add services >>>> Discover what IT Professionals Know. Rescue delivers >>>> http://p.sf.net/sfu/logmein_12329d2d >>>> _______________________________________________ >>>> Pyblosxom-devel mailing list >>>> Pyb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel >>>> >>> >>> ------------------------------------------------------------------------------ >>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >>> Remotely access PCs and mobile devices and provide instant support >>> Improve your efficiency, and focus on delivering more value-add services >>> Discover what IT Professionals Know. Rescue delivers >>> http://p.sf.net/sfu/logmein_12329d2d >>> _______________________________________________ >>> Pyblosxom-devel mailing list >>> Pyb...@li... >>> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial >> Remotely access PCs and mobile devices and provide instant support >> Improve your efficiency, and focus on delivering more value-add services >> Discover what IT Professionals Know. Rescue delivers >> http://p.sf.net/sfu/logmein_12329d2d >> _______________________________________________ >> Pyblosxom-devel mailing list >> Pyb...@li... >> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Pyblosxom-devel mailing list > Pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel |
Thanks for helping keep SourceForge clean.
X