http://habariproject.org/dist/plugins/ lists plugins. Very nice. Could someone possibly maintain either a README file, or perhaps a .htaccess file containing AddDescription lines, stating as briefly as possible what these things do, so that I don't have to download and unzip every one of them to find out? Who's got access to that directory? At least, a README file in there that links to a wiki page that lists the filenames and what's in them.
Thanks.
-- A poet more than thirty years old is simply an overgrown child. H. L. Mencken
Attached is a compiled text file of the currently existing plugins and their descriptions. I tried to make descriptions as short as possible for some and I used the short description for others.
I dont have access to upload this but I figured that someone with access would find it easier to just appends the content of the file to the current .htaccess file.
Feel free to review this for lingual and/or technical mistakes :)
On Wed, Apr 2, 2008 at 2:31 PM, Rich Bowen <rbo...@rcbowen.com> wrote: > ... or perhaps a .htaccess file containing AddDescription lines, stating > as briefly as possible what these things do, so that I don't have to > download and unzip every one of them to find out?
On that note, I think it's time that plugins in extras start getting
tags for "stable" releases, and those go to the /dist/ directory. I
realize there's a lot of discussion still to be had about the repo in
general, but I think we need to start being sympathetic to non-dev
type users we are trying to attract. As I understand it, those zips
are snapshots of a latest commit, and can be b0rked. I'm not sure
what all would be entailed to the process, and who would determine
what is "stable", but I'd say at least a revision that works with .4.1
would be nice to have.
Anyone else brave enough to be working with trunk should be capable of
getting the <head> of extras also.
Just my $0.02
~miklb
On Apr 2, 8:31 am, Rich Bowen <rbo...@rcbowen.com> wrote:
> http://habariproject.org/dist/plugins/lists plugins. Very nice.
> Could someone possibly maintain either a README file, or perhaps
> a .htaccess file containing AddDescription lines, stating as briefly
> as possible what these things do, so that I don't have to download
> and unzip every one of them to find out? Who's got access to that
> directory? At least, a README file in there that links to a wiki page
> that lists the filenames and what's in them.
> Thanks.
> --
> A poet more than thirty years old is simply an overgrown child.
> H. L. Mencken
On Thu, Apr 03, 2008 at 06:32:40PM -0700, Michael Bishop wrote:
> On that note, I think it's time that plugins in extras start getting > tags for "stable" releases, and those go to the /dist/ directory. I > realize there's a lot of discussion still to be had about the repo in > general, but I think we need to start being sympathetic to non-dev > type users we are trying to attract. As I understand it, those zips > are snapshots of a latest commit, and can be b0rked. I'm not sure > what all would be entailed to the process, and who would determine > what is "stable", but I'd say at least a revision that works with .4.1 > would be nice to have.
> Anyone else brave enough to be working with trunk should be capable of > getting the <head> of extras also.
I agree we need to split the -extras. How about trunk and tags (with standardised naming of tags), with the latest tag being put automatically onto /dist as all -extras commits are now?
I also think Sean's earlier suggestion of owners or maintainers for everything in -extras is something we should do.
/extras/feedburner/trunk - To install with Habari's HEAD
/extras/feedburner/stable - To install with Habari's latest stable
release
Splitting /extras at the root would be a PITA to maintain.
What I'm wondering is who's going to be the maintainer of each
plugin's stable.
As much as I'm for liberty, there should be strict guidelines (like
Habari's trunk) and appointed people to build the zips.
miklb was talking about having zips built on the fly, don't know SVN
enough to figure that out.
On Apr 7, 8:42 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> On Thu, Apr 03, 2008 at 06:32:40PM -0700, Michael Bishop wrote:
> > On that note, I think it's time that plugins in extras start getting
> > tags for "stable" releases, and those go to the /dist/ directory. I
> > realize there's a lot of discussion still to be had about the repo in
> > general, but I think we need to start being sympathetic to non-dev
> > type users we are trying to attract. As I understand it, those zips
> > are snapshots of a latest commit, and can be b0rked. I'm not sure
> > what all would be entailed to the process, and who would determine
> > what is "stable", but I'd say at least a revision that works with .4.1
> > would be nice to have.
> > Anyone else brave enough to be working with trunk should be capable of
> > getting the <head> of extras also.
> I agree we need to split the -extras. How about trunk and tags (with
> standardised naming of tags), with the latest tag being put
> automatically onto /dist as all -extras commits are now?
> I also think Sean's earlier suggestion of owners or maintainers for
> everything in -extras is something we should do.
On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
> Suggestion:
> /extras/feedburner/trunk - To install with Habari's HEAD > /extras/feedburner/stable - To install with Habari's latest stable > release
The reason I suggested tags was that at some point we will support more than one release.
> Splitting /extras at the root would be a PITA to maintain.
I wasn't suggesting that, sorry if I wasn't clear.
> What I'm wondering is who's going to be the maintainer of each > plugin's stable.
I'm not sure what you mean. I'm happy to be the maintainer of all the plugins I've committed. If other people put their hand up and say they're happy to maintain theirs, that's fine. If there are some that don't have a maintainer, we can discuss what happens to them then.
> As much as I'm for liberty, there should be strict guidelines (like > Habari's trunk) and appointed people to build the zips.
What sort of guidelines were you thinking of?
> miklb was talking about having zips built on the fly, don't know SVN > enough to figure that out.
On Apr 8, 1:48 am, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
> > Suggestion:
> > /extras/feedburner/trunk - To install with Habari's HEAD
> > /extras/feedburner/stable - To install with Habari's latest stable
> > release
> The reason I suggested tags was that at some point we will support
> more than one release.
Ok, good point.
> > What I'm wondering is who's going to be the maintainer of each
> > plugin's stable.
> I'm not sure what you mean. I'm happy to be the maintainer of all the
> plugins I've committed. If other people put their hand up and say
> they're happy to maintain theirs, that's fine. If there are some that
> don't have a maintainer, we can discuss what happens to them then.
Indeed, it's for those who get left behind, or for example, if the
maintainer goes away for some time.
Who should take over, and I wasn't talking about the code itself, but
the releases (stable) of the plugin.
Some sort of release manager for each plugin, or all plugins.
> > As much as I'm for liberty, there should be strict guidelines (like
> > Habari's trunk) and appointed people to build the zips.
> What sort of guidelines were you thinking of?
Compression, no DSTORE (or whatever is the Mac OS X hidden file)
no .ThumbsDB :P
Do we put the files in a folder, or not, etc..
> > miklb was talking about having zips built on the fly, don't know SVN
> > enough to figure that out.
On Apr 8, 9:10 am, Andrew da Silva <andrewdasi...@mac.com> wrote:
> On Apr 8, 1:48 am, "Michael C. Harris" <michael.twof...@gmail.com>
> wrote:
> > On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
> > > Suggestion:
> > > /extras/feedburner/trunk - To install with Habari's HEAD
> > > /extras/feedburner/stable - To install with Habari's latest stable
> > > release
> > The reason I suggested tags was that at some point we will support
> > more than one release.
Here's a crazy idea I'll float:
Let's split the extras repo at the root. The reason we'd split the
repo at the root is so that we can allow a group of "contributor"
users access to commit to the repo just like we do, but via the single
trunk branch, while restricting commit access to the release tags to
specific logins. An alternative would be to assign contributor
permissions into each plugin and theme trunk subdirectory, which could
get messy.
Everyone will have access to commit to trunk, but only the *server*
will have commit access to the stable branches. A project maintainer
would have access via the web site to publish a new version of any
plugin in trunk. The interface for this would allow him to enter an
update description and status for the beacon. The server would update
the beacon, create the version tag in svn, and produce the
distribution zip file.
Potential additional features could be to add new repo directories
from the server, and to provide a non-svn interface for interacting
with svn. For example, we could allow theme builders to upload a zip
file of their theme, which would be extracted into a working copy of
their theme from svn, then committed from the server itself. This
might help get around some themers' reluctance to using the repo.
> > > As much as I'm for liberty, there should be strict guidelines (like
> > > Habari's trunk) and appointed people to build the zips.
> > What sort of guidelines were you thinking of?
> Compression, no DSTORE (or whatever is the Mac OS X hidden file)
> no .ThumbsDB :P
> Do we put the files in a folder, or not, etc..
If using the system above, the server would manage all of that, since
it's building the zip files itself. Actually, this is already the
case. Under no circumstances should a zip file be released on hp.o
that is not built from svn.
> > > miklb was talking about having zips built on the fly, don't know SVN
> > > enough to figure that out.
> > We do that now, afaik. That's what's in /dist.
> How do does get created?
When a doe and a buck really love each other...
There's a post-commit script that executes which builds the files for /
dist.
On Tue, Apr 08, 2008 at 06:10:19AM -0700, Andrew da Silva wrote: > On Apr 8, 1:48 am, "Michael C. Harris" wrote: > > On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
> > > What I'm wondering is who's going to be the maintainer of each > > > plugin's stable.
> > I'm not sure what you mean. I'm happy to be the maintainer of all the > > plugins I've committed. If other people put their hand up and say > > they're happy to maintain theirs, that's fine. If there are some that > > don't have a maintainer, we can discuss what happens to them then.
> Indeed, it's for those who get left behind, or for example, if the > maintainer goes away for some time. > Who should take over, and I wasn't talking about the code itself, but > the releases (stable) of the plugin. > Some sort of release manager for each plugin, or all plugins.
What I was suggesting is let's set up a system if there are any plugins that don't have a maintainer we can deal with it then. One step at a time.
> > > As much as I'm for liberty, there should be strict guidelines (like > > > Habari's trunk) and appointed people to build the zips.
> > What sort of guidelines were you thinking of?
> Compression, no DSTORE (or whatever is the Mac OS X hidden file) > no .ThumbsDB :P > Do we put the files in a folder, or not, etc..
All dealt with in be subversion hook script.
> > > miklb was talking about having zips built on the fly, don't know SVN > > > enough to figure that out.
> > We do that now, afaik. That's what's in /dist.
> How do does get created?
I haven't read his email yet, but I think Owen answers the question.
On Tue, Apr 08, 2008 at 08:08:20AM -0700, ringmaster wrote:
> On Apr 8, 9:10 am, Andrew da Silva <andrewdasi...@mac.com> wrote: > > On Apr 8, 1:48 am, "Michael C. Harris" <michael.twof...@gmail.com> > > wrote:
> > > On Mon, Apr 07, 2008 at 10:03:54PM -0700, Andrew da Silva wrote:
> > > > Suggestion:
> > > > /extras/feedburner/trunk - To install with Habari's HEAD > > > > /extras/feedburner/stable - To install with Habari's latest stable > > > > release
> > > The reason I suggested tags was that at some point we will support > > > more than one release.
> Here's a crazy idea I'll float:
> Let's split the extras repo at the root. The reason we'd split the > repo at the root is so that we can allow a group of "contributor" > users access to commit to the repo just like we do, but via the single > trunk branch, while restricting commit access to the release tags to > specific logins. An alternative would be to assign contributor > permissions into each plugin and theme trunk subdirectory, which could > get messy.
> Everyone will have access to commit to trunk, but only the *server* > will have commit access to the stable branches. A project maintainer > would have access via the web site to publish a new version of any > plugin in trunk. The interface for this would allow him to enter an > update description and status for the beacon. The server would update > the beacon, create the version tag in svn, and produce the > distribution zip file.
Splitting the whole -extras repo sounds like the way to go. The second part of your idea sounds like plugin content types, which I've been mulling over for a while as a way to show off plugins. An additional feature of the plugin content type might be to allow users to "Add this plugin to my download bundle" so that users can browse the plugin posts on hp.o and download a bunch of them at once to be unzipped in user/plugins.
> Potential additional features could be to add new repo directories > from the server, and to provide a non-svn interface for interacting > with svn. For example, we could allow theme builders to upload a zip > file of their theme, which would be extracted into a working copy of > their theme from svn, then committed from the server itself. This > might help get around some themers' reluctance to using the repo.
... and a theme content type for showing off themes, which could have a theme switcher built in. Theme authors could use it on their own sites for themes they don't want to submit to -extras and it could be used on hp.o for the themes in -extras.
On Apr 24, 8:53 pm, Vicki Frei <vka...@bytehaven.com> wrote:
> Abstain - I know nothing about code, and none of the post on either of
> these subjects make any sense to me.
> V
The basic premise is that we are maintaining a repo of plugins and
themes that numerous people have access to, which is great for
development and community building, however, for users who download
these zips (which are currently being built anytime a new commit is
made), they can be grabbing "in-development" code, or not-ready-for-
prime-time. The proposal is for a system in which we can still offer
this community collaboration on development, yet still maintain some
stability in the actual downloadable package. There's probably still
some discussion as to what the download should be compatible with,
etc, however, as this element of the community grows, we need to tame
it now, for the aforementioned reasons (IMO). I also see this as a
extension of fostering potential PMC members.
Just to clarify.
> Michael C. Harris wrote:
> > Those in favour of splitting the -extras repo into stable and
> > unstable (exact format can be argued about) say +1:
> > +1
> > Those in favour of naming a maintainer for everything in the -extras
> > repo (details can be argued about) say +1:
> > +1
+1 to both -assuming I follow the discussion about the maintainer
portion meaning a single "maintainer" per project
> On Apr 24, 8:53 pm, Vicki Frei <vka...@bytehaven.com> wrote: >> Abstain - I know nothing about code, and none of the post on either of >> these subjects make any sense to me.
>> V
> The basic premise is that we are maintaining a repo of plugins and > themes that numerous people have access to, which is great for > development and community building, however, for users who download > these zips (which are currently being built anytime a new commit is > made), they can be grabbing "in-development" code, or not-ready-for- > prime-time. The proposal is for a system in which we can still offer > this community collaboration on development, yet still maintain some > stability in the actual downloadable package. There's probably still > some discussion as to what the download should be compatible with, > etc, however, as this element of the community grows, we need to tame > it now, for the aforementioned reasons (IMO). I also see this as a > extension of fostering potential PMC members.
> Just to clarify.
>> Michael C. Harris wrote: >>> Those in favour of splitting the -extras repo into stable and >>> unstable (exact format can be argued about) say +1: >>> +1 >>> Those in favour of naming a maintainer for everything in the -extras >>> repo (details can be argued about) say +1: >>> +1
> +1 to both -assuming I follow the discussion about the maintainer > portion meaning a single "maintainer" per project
On Thu, Apr 24, 2008 at 07:56:52PM -0700, Michael Bishop wrote: > > Michael C. Harris wrote: > > > Those in favour of splitting the -extras repo into stable and > > > unstable (exact format can be argued about) say +1:
> > > +1
> > > Those in favour of naming a maintainer for everything in the -extras > > > repo (details can be argued about) say +1:
> > > +1
> +1 to both -assuming I follow the discussion about the maintainer > portion meaning a single "maintainer" per project
Yes, that's the vote I was proposing, that one person be "responsible" for each project. That doesn't necessarily mean that they'd do all the coding necessary or anything like that, but they'd be the person to contact and keep an eye on any issues.
> On Thu, Apr 24, 2008 at 07:56:52PM -0700, Michael Bishop wrote: >>> Michael C. Harris wrote: >>>> Those in favour of splitting the -extras repo into stable and >>>> unstable (exact format can be argued about) say +1:
>>>> +1
>>>> Those in favour of naming a maintainer for everything in the - >>>> extras >>>> repo (details can be argued about) say +1:
>>>> +1
>> +1 to both -assuming I follow the discussion about the maintainer >> portion meaning a single "maintainer" per project
> Yes, that's the vote I was proposing, that one person be "responsible" > for each project. That doesn't necessarily mean that they'd do all the > coding necessary or anything like that, but they'd be the person to > contact and keep an eye on any issues.
> On Apr 25, 2008, at 4:55 AM, Michael C. Harris wrote:
> > On Thu, Apr 24, 2008 at 07:56:52PM -0700, Michael Bishop wrote: > >>> Michael C. Harris wrote: > >>>> Those in favour of splitting the -extras repo into stable and > >>>> unstable (exact format can be argued about) say +1:
> >>>> +1
> >>>> Those in favour of naming a maintainer for everything in the - > >>>> extras > >>>> repo (details can be argued about) say +1:
> >>>> +1
> >> +1 to both -assuming I follow the discussion about the maintainer > >> portion meaning a single "maintainer" per project
> > Yes, that's the vote I was proposing, that one person be "responsible" > > for each project. That doesn't necessarily mean that they'd do all the > > coding necessary or anything like that, but they'd be the person to > > contact and keep an eye on any issues.
> -----Original Message----- > From: habari-dev@googlegroups.com [mailto:habari-dev@googlegroups.com] > On Behalf Of Michael C. Harris > Sent: 25. april 2008 10:55 > To: habari-dev@googlegroups.com > Subject: [habari-dev] Re: Plugins directory
> On Thu, Apr 24, 2008 at 07:56:52PM -0700, Michael Bishop wrote: > > > Michael C. Harris wrote: > > > > Those in favour of splitting the -extras repo into stable and > > > > unstable (exact format can be argued about) say +1:
> > > > +1
> > > > Those in favour of naming a maintainer for everything in the - > extras > > > > repo (details can be argued about) say +1:
> > > > +1
> > +1 to both -assuming I follow the discussion about the maintainer > > portion meaning a single "maintainer" per project
> Yes, that's the vote I was proposing, that one person be "responsible" > for each project. That doesn't necessarily mean that they'd do all the > coding necessary or anything like that, but they'd be the person to > contact and keep an eye on any issues.
On Apr 24, 2008, at 20:11, Michael C. Harris wrote:
> Those in favour of splitting the -extras repo into stable and > unstable (exact format can be argued about) say +1:
> +1
+0 , no opinion
> Those in favour of naming a maintainer for everything in the -extras > repo (details can be argued about) say +1:
> +1
-1
Explicitly naming a maintainer for a piece of code has a number of negative social impacts, all of which are variations on the same thing - this code belongs to Bob, and so I'm reluctant to touch it. Either the code belongs to the community, or it doesn't. If it doesn't, it doesn't belong in our repo.
-- What the world needs is more geniuses with humility, there are so few of us left. Oscar Levant
> On Apr 24, 2008, at 20:11, Michael C. Harris wrote:
> > Those in favour of splitting the -extras repo into stable and
> > unstable (exact format can be argued about) say +1:
> > +1
> +0 , no opinion
> > Those in favour of naming a maintainer for everything in the -extras
> > repo (details can be argued about) say +1:
> > +1
> -1
> Explicitly naming a maintainer for a piece of code has a number of
> negative social impacts, all of which are variations on the same thing
> - this code belongs to Bob, and so I'm reluctant to touch it. Either
> the code belongs to the community, or it doesn't. If it doesn't, it
> doesn't belong in our repo.
I originally felt the same way, but after I thought about the term
"maintainer", and not owner, or author, or some other term that
implied "ownership", I felt more comfortable that it simply indicated
someone taking responsibility for making sure stable releases were
maintained. What if we called them something else? Guardian ;-)
If we weren't to go this route (not having a maintainer), what would
you suggest as a solution for making sure that we were providing users
with a stable, functional plugin that was compatible with the latest
stable release? Or does your +0 vote indicate that you don't feel
that is important at this juncture of the project?
While I'm thrilled at the influx of community development on plugins
and themes, and community attribution for that matter, I have joined
in bringing this up simply because I am afraid of the effect it might
have on a new user. Currently, they can download one of these plugins
at a particular moment that it's buggy (like the other morning when I
made several poor commits), try out the plugin/theme, be turned off,
and move on. Even though we are still "alpha"/ "developer release"
officially,, I think we are really moving towards portraying the
project as as semi-stable for people to check out, which means many
people downloading zipped files, and not doing SVN, IRC, etc. I don't
want to scare them away completely.
I'd also hate to see plugins "die on the vine" because there is no one
tending to it. These people do not have to be "coders", simply
community members who want to volunteer in some fashion.
Finally, there's already a bit of confusion/fear about who's plugin is
who's, regardless of the attribution, and stepping one's toes.
Perhaps this is a good time for someone (is that the sound of me
volunteering?) blogging about what the extras repo is, how it's
intended, and where we see it going.
> On Apr 26, 8:29 pm, Rich Bowen <rbo...@rcbowen.com> wrote:
> > On Apr 24, 2008, at 20:11, Michael C. Harris wrote:
> > > Those in favour of splitting the -extras repo into stable and
> > > unstable (exact format can be argued about) say +1:
> > > +1
> > +0 , no opinion
> > > Those in favour of naming a maintainer for everything in the -extras
> > > repo (details can be argued about) say +1:
> > > +1
> > -1
> > Explicitly naming a maintainer for a piece of code has a number of
> > negative social impacts, all of which are variations on the same thing
> > - this code belongs to Bob, and so I'm reluctant to touch it. Either
> > the code belongs to the community, or it doesn't. If it doesn't, it
> > doesn't belong in our repo.
> I originally felt the same way, but after I thought about the term
> "maintainer", and not owner, or author, or some other term that
> implied "ownership", I felt more comfortable that it simply indicated
> someone taking responsibility for making sure stable releases were
> maintained. What if we called them something else? Guardian ;-)
> If we weren't to go this route (not having a maintainer), what would
> you suggest as a solution for making sure that we were providing users
> with a stable, functional plugin that was compatible with the latest
> stable release? Or does your +0 vote indicate that you don't feel
> that is important at this juncture of the project?
> While I'm thrilled at the influx of community development on plugins
> and themes, and community attribution for that matter, I have joined
> in bringing this up simply because I am afraid of the effect it might
> have on a new user. Currently, they can download one of these plugins
> at a particular moment that it's buggy (like the other morning when I
> made several poor commits), try out the plugin/theme, be turned off,
> and move on. Even though we are still "alpha"/ "developer release"
> officially,, I think we are really moving towards portraying the
> project as as semi-stable for people to check out, which means many
> people downloading zipped files, and not doing SVN, IRC, etc. I don't
> want to scare them away completely.
> I'd also hate to see plugins "die on the vine" because there is no one
> tending to it. These people do not have to be "coders", simply
> community members who want to volunteer in some fashion.
> Finally, there's already a bit of confusion/fear about who's plugin is
> who's, regardless of the attribution, and stepping one's toes.
> Perhaps this is a good time for someone (is that the sound of me
> volunteering?) blogging about what the extras repo is, how it's
> intended, and where we see it going.
> ~miklb
> > --
> > What the world needs is more geniuses with humility, there are so few
> > of us left.
> > Oscar Levant
