You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2010/07/26 03:05:59 UTC
Wiki non-migration
Greets,
The Lucy Incubator proposal contained the following text:
Lucy already has a MoinMoin wiki at wiki.apache.org/lucy. It would be
convenient to keep it, especially since its current location is also where
it would end up upon TLP graduation, but we will defer to the wishes of
the Incubator PMC if standard Incubator wiki placement is recommended.
Turns out I was confused -- there is no such "standard Incubator wiki
placement". The Incubator has lots to say about branding and about podling
websites -- including website placement -- but existing podlings seem to have
their wikis at what would be the final location:
https://cwiki.apache.org/BeanValidation/
https://cwiki.apache.org/ETCH/
Nevertheless, I think there are two items we should consider for the existing
Lucy wiki.
First, I think we should add the incubation disclaimer to the main wiki page.
http://incubator.apache.org/guides/branding.html#disclaimers
Podling web sites MUST include a clear disclaimer on their website and in
all documentation (including releases) stating that they are in
incubation. Podlings SHOULD use the following text for all disclaimers:
Apache "Podling-Name" is an effort undergoing incubation at The Apache
Software Foundation (ASF), sponsored by the name of sponsor.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does
indicate that the project has yet to be fully endorsed by the ASF.
Second, I think the following directive is germane and we should consider
locking down some of the existing wiki pages:
http://incubator.apache.org/guides/sites.html#create-website-using-wiki
Podlings may use a wiki to create documentation (including the website)
providing that follow the guidelines. In particular, care must be taken to
ensure that access to the wiki used to create documentation is restricted
to only those with filed CLAs. The PPMC MUST review all changes and ensure
that trust is not abused.
I'm thinking of these pages in particular, as it might make sense to bundle
them with the distro some day and we need to make sure that they don't contain
any contributions of unknown origin:
http://wiki.apache.org/lucy/HowToContribute
http://wiki.apache.org/lucy/LucyStyleGuide
I don't know how to handle permissions with MoinMoin, though. I could go
research the issue, but since I should avoid becoming a SPOF[1] in yet another
area, anybody else out there willing to take these two tasks on?
Once there's consensus that those issues are resolved, I think we can check
this item off of our list:
http://incubator.apache.org/projects/lucy.html
Ask infrastructure to set up wiki (Confluence, Moin).
Marvin Humphrey
[1] SPOF: Single Point Of Failure
Re: Wiki non-migration
Posted by Upayavira <uv...@odoko.co.uk>.
On Fri, 2010-07-30 at 14:51 -0700, Marvin Humphrey wrote:
> On Fri, Jul 30, 2010 at 09:10:25PM +0100, Upayavira wrote:
>
> > Have you created an AdminGroup page and locked that down with an ACL?
>
> I just tried to create an AdminGroup page with the following directive:
>
> #acl MarvinHumphrey:read,write All:read
>
> The effort failed with this message:
>
> You can't change ACLs on this page since you have no admin rights on it!
Fair enough. So it needs a little bit of editing in the config.py file.
> > > >From what I can tell, granting a user admin rights to the whole wiki needs to
> > > be done in wikiconfig.py:
> > >
> > > http://wiki.apache.org/lucy/HelpOnConfiguration#Overview_of_configuration_options
> >
> > You're probably right. If we want to make that change, I can do it.
> >
> > > It seems to me that like JIRA admin karma, MoinMoin wiki-wide admin karma
> > > ought to be restricted to PMC members. However, I suspect we have to ask
> > > Infra to edit that file for us. Maybe it's possible for them to add
> > > a "PMCMembers" or "AdminGroup" group and then for us to edit that group?
> >
> > Most folks don't need admin rights in that way. If you do, then maybe
> > you'd be better off having a parallel wiki for that content.
>
> The goal here is for PMC members to be able to lock down certain individual
> pages so that only contributors with CLAs on file can edit their content, per
> the recommendation at
> <http://incubator.apache.org/guides/sites.html#create-website-using-wiki>.
> That way, if we want to distribute that content in the future under ASL2, we
> can.
Sure. Technically, that is possible (and potentially better than
confluence for it), but I don't believe that anyone else at Apache is
doing it, so it would require a little thought.
> We don't need to lock down the whole wiki -- just individual pages.
While that is true, it is simpler to just have two wikis, one protected
and one not.
> In theory, we could go back to Infra every time that a new PMC member wants
> such karma. But what I was thinking was that infra could grant admin
> privileges to AdminGroup once; then we could manage membership in AdminGroup
> ourselves by editing the content of <http://wiki.apache.org/lucy/AdminGroup>.
That is what would happen. I would set up ACLs, and grant admin privs to
the AdminGroup, and put a few folks in it. The group could then be
self-maintaining from then on.
> However, I'm speculating about this having only perused the documentation.
> I'm not sure I've got the mechanism exactly right.
That's pretty much it.
> > > Oo, I think this is a good idea:
> > >
> > > https://issues.apache.org/jira/browse/INFRA-1029
> > >
> > > We'd prefer change emails to go to ivy-commits@incubator
> >
> > Assuming no-one will object, I have changed lucy wiki diffs to go to
> > lucy-commits instead. Let me know if I should undo it.
>
> Sweet, thanks!
You're welcome.
Upayavira
Re: Wiki non-migration
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Jul 30, 2010 at 09:10:25PM +0100, Upayavira wrote:
> Have you created an AdminGroup page and locked that down with an ACL?
I just tried to create an AdminGroup page with the following directive:
#acl MarvinHumphrey:read,write All:read
The effort failed with this message:
You can't change ACLs on this page since you have no admin rights on it!
> > >From what I can tell, granting a user admin rights to the whole wiki needs to
> > be done in wikiconfig.py:
> >
> > http://wiki.apache.org/lucy/HelpOnConfiguration#Overview_of_configuration_options
>
> You're probably right. If we want to make that change, I can do it.
>
> > It seems to me that like JIRA admin karma, MoinMoin wiki-wide admin karma
> > ought to be restricted to PMC members. However, I suspect we have to ask
> > Infra to edit that file for us. Maybe it's possible for them to add
> > a "PMCMembers" or "AdminGroup" group and then for us to edit that group?
>
> Most folks don't need admin rights in that way. If you do, then maybe
> you'd be better off having a parallel wiki for that content.
The goal here is for PMC members to be able to lock down certain individual
pages so that only contributors with CLAs on file can edit their content, per
the recommendation at
<http://incubator.apache.org/guides/sites.html#create-website-using-wiki>.
That way, if we want to distribute that content in the future under ASL2, we
can.
We don't need to lock down the whole wiki -- just individual pages.
In theory, we could go back to Infra every time that a new PMC member wants
such karma. But what I was thinking was that infra could grant admin
privileges to AdminGroup once; then we could manage membership in AdminGroup
ourselves by editing the content of <http://wiki.apache.org/lucy/AdminGroup>.
However, I'm speculating about this having only perused the documentation.
I'm not sure I've got the mechanism exactly right.
> > Oo, I think this is a good idea:
> >
> > https://issues.apache.org/jira/browse/INFRA-1029
> >
> > We'd prefer change emails to go to ivy-commits@incubator
>
> Assuming no-one will object, I have changed lucy wiki diffs to go to
> lucy-commits instead. Let me know if I should undo it.
Sweet, thanks!
Marvin Humphrey
Re: Wiki non-migration
Posted by Upayavira <uv...@odoko.co.uk>.
On Fri, 2010-07-30 at 12:16 -0700, Marvin Humphrey wrote:
> On Fri, Jul 30, 2010 at 10:08:28AM +0100, Upayavira wrote:
> > Moin can do access rights.
>
> Well, what do you know!
>
> http://wiki.apache.org/lucy/HelpOnAccessControlLists
> http://wiki.apache.org/lucy/HelpIndex
>
> Apparently they are off by default.
>
> > You can either do it on a page-by-page basis, or apply access rights across
> > the whole site.
>
> It looks like what you're supposed to do is insert a line like this one:
>
> #acl SomeUser:read,write All:read
>
> However, you need to have admin rights to either add or edit acl's. I wasn't
> able to add such a line to an existing page, nor create a new page that
> included such a line, because apparently my user (MarvinHumphrey) doesn't have
> admin rights.
Have you created an AdminGroup page and locked that down with an ACL?
> >From what I can tell, granting a user admin rights to the whole wiki needs to
> be done in wikiconfig.py:
>
> http://wiki.apache.org/lucy/HelpOnConfiguration#Overview_of_configuration_options
You're probably right. If we want to make that change, I can do it.
> It seems to me that like JIRA admin karma, MoinMoin wiki-wide admin karma
> ought to be restricted to PMC members. However, I suspect we have to ask
> Infra to edit that file for us. Maybe it's possible for them to add
> a "PMCMembers" or "AdminGroup" group and then for us to edit that group?
Most folks don't need admin rights in that way. If you do, then maybe
you'd be better off having a parallel wiki for that content.
> http://wiki.apache.org/lucy/HelpOnAccessControlLists#Groups
>
> Oo, I think this is a good idea:
>
> https://issues.apache.org/jira/browse/INFRA-1029
>
> We'd prefer change emails to go to ivy-commits@incubator
Assuming no-one will object, I have changed lucy wiki diffs to go to
lucy-commits instead. Let me know if I should undo it.
Upayavira
Re: Wiki non-migration
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Jul 30, 2010 at 10:08:28AM +0100, Upayavira wrote:
> Moin can do access rights.
Well, what do you know!
http://wiki.apache.org/lucy/HelpOnAccessControlLists
http://wiki.apache.org/lucy/HelpIndex
Apparently they are off by default.
> You can either do it on a page-by-page basis, or apply access rights across
> the whole site.
It looks like what you're supposed to do is insert a line like this one:
#acl SomeUser:read,write All:read
However, you need to have admin rights to either add or edit acl's. I wasn't
able to add such a line to an existing page, nor create a new page that
included such a line, because apparently my user (MarvinHumphrey) doesn't have
admin rights.
>From what I can tell, granting a user admin rights to the whole wiki needs to
be done in wikiconfig.py:
http://wiki.apache.org/lucy/HelpOnConfiguration#Overview_of_configuration_options
It seems to me that like JIRA admin karma, MoinMoin wiki-wide admin karma
ought to be restricted to PMC members. However, I suspect we have to ask
Infra to edit that file for us. Maybe it's possible for them to add
a "PMCMembers" or "AdminGroup" group and then for us to edit that group?
http://wiki.apache.org/lucy/HelpOnAccessControlLists#Groups
Oo, I think this is a good idea:
https://issues.apache.org/jira/browse/INFRA-1029
We'd prefer change emails to go to ivy-commits@incubator
Send change emails to the commits list rather than the dev list.
Marvin Humphrey
Re: Wiki non-migration
Posted by Upayavira <uv...@odoko.co.uk>.
On Thu, 2010-07-29 at 12:42 -0700, Marvin Humphrey wrote:
> On Sun, Jul 25, 2010 at 06:16:42PM -0700, Chris Hostetter wrote:
> > : First, I think we should add the incubation disclaimer to the main wiki page.
> >
> > +1
>
> Done.
>
> > : I'm thinking of these pages in particular, as it might make sense to bundle
> > : them with the distro some day and we need to make sure that they don't contain
> > : any contributions of unknown origin:
> >
> > if those are the only pages you are worried about, i would suggest
> > promoting them out of the wiki and into svn.
>
> OK, that's what we should do, then.
>
> > : I don't know how to handle permissions with MoinMoin, though. I could go
> >
> > MoinMOin doesn't have any perms -- it's all or nothing. which is why no
> > MoinMoin content can ever be included in a release.
>
> OK. IMO, that's a nice-to-have. I don't think it's essential.
>
> > 1) do you want to use Confluence for managing the Lucy site?
> > (instead of forrest, or something else in svn)
>
> I'm reluctant to use Confluence for the website a couple reasons.
>
> First, it seems like overkill. The main site only needs to be a few static
> pages. It's trivial to generate such a site using a few component templates
> (header footer nav), a few content source files, and a 200-line Perl script
> with no dependencies.
>
> Second, I've gotten the impression that Confluence is a bit of a pain for
> Infra to support. Enough projects depend on Confluence that it's not going to
> go away, but if we don't need it, I don't think we should use it.
>
> Regardless of what tool we use to generate the main site, we're going to need
> to generate documentation for each release using the tools favored by our
> various host languages in order to present idiomatic display. This will be a
> bit of a pain, but IMO, it will be well worth it -- and so that's where I
> think we should focus our energies.
>
> > 2) do you want to use Confluence for managing a user ediable wiki?
> > (instead of MoinMoin)
>
> IMO MoinMoin's fine, and we already have it set up.
>
> > You can do both (by having two Confluence spaces created) or you can do
> > one, or you can do the other ... or you can decided to do #1 now, and then
> > punt on deciding #2 for later -- but #1 should probably be decided before
> > much work is put into building the "new" Lucy website and adding any
> > content to it.
>
> In order to get something in place right away that looks half-decent, I think
> we should just adapt the existing Forrest site. It would be nice if nobody new
> had to learn how to use Forrest, though.
>
> That means I stay a bottleneck on the website in the short term, but IMO it's
> better to proceed at leisure rather than worry about the site all-at-once
> up-front. By going with what we have, we'll immediately look spiffier than a
> lot of other incubating projects. :\
I am in general agreement with your conclusions. Although I do recognise
that the ASF does not yet have any perfect web site production system.
One day maybe.
Moin can do access rights. You can either do it on a page-by-page basis,
or apply access rights across the whole site. Generally, if you're going
to use a wiki to develop your site, it is recommended to have two, one
public access, and one for editing your site. That way you can manage
access more clearly. Even though moin is capable of building sites,
no-one at the ASF has used it that way at the moment.
But as you say, if you only want something simple, then you don't need
any complex web building system for it.
Regards, Upayavira
Re: Wiki non-migration
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Jul 25, 2010 at 06:16:42PM -0700, Chris Hostetter wrote:
> : First, I think we should add the incubation disclaimer to the main wiki page.
>
> +1
Done.
> : I'm thinking of these pages in particular, as it might make sense to bundle
> : them with the distro some day and we need to make sure that they don't contain
> : any contributions of unknown origin:
>
> if those are the only pages you are worried about, i would suggest
> promoting them out of the wiki and into svn.
OK, that's what we should do, then.
> : I don't know how to handle permissions with MoinMoin, though. I could go
>
> MoinMOin doesn't have any perms -- it's all or nothing. which is why no
> MoinMoin content can ever be included in a release.
OK. IMO, that's a nice-to-have. I don't think it's essential.
> 1) do you want to use Confluence for managing the Lucy site?
> (instead of forrest, or something else in svn)
I'm reluctant to use Confluence for the website a couple reasons.
First, it seems like overkill. The main site only needs to be a few static
pages. It's trivial to generate such a site using a few component templates
(header footer nav), a few content source files, and a 200-line Perl script
with no dependencies.
Second, I've gotten the impression that Confluence is a bit of a pain for
Infra to support. Enough projects depend on Confluence that it's not going to
go away, but if we don't need it, I don't think we should use it.
Regardless of what tool we use to generate the main site, we're going to need
to generate documentation for each release using the tools favored by our
various host languages in order to present idiomatic display. This will be a
bit of a pain, but IMO, it will be well worth it -- and so that's where I
think we should focus our energies.
> 2) do you want to use Confluence for managing a user ediable wiki?
> (instead of MoinMoin)
IMO MoinMoin's fine, and we already have it set up.
> You can do both (by having two Confluence spaces created) or you can do
> one, or you can do the other ... or you can decided to do #1 now, and then
> punt on deciding #2 for later -- but #1 should probably be decided before
> much work is put into building the "new" Lucy website and adding any
> content to it.
In order to get something in place right away that looks half-decent, I think
we should just adapt the existing Forrest site. It would be nice if nobody new
had to learn how to use Forrest, though.
That means I stay a bottleneck on the website in the short term, but IMO it's
better to proceed at leisure rather than worry about the site all-at-once
up-front. By going with what we have, we'll immediately look spiffier than a
lot of other incubating projects. :\
Marvin Humphrey
Re: Wiki non-migration
Posted by Chris Hostetter <ho...@fucit.org>.
: First, I think we should add the incubation disclaimer to the main wiki page.
+1
: I'm thinking of these pages in particular, as it might make sense to bundle
: them with the distro some day and we need to make sure that they don't contain
: any contributions of unknown origin:
if those are the only pages you are worried about, i would suggest
promoting them out of the wiki and into svn.
: I don't know how to handle permissions with MoinMoin, though. I could go
MoinMOin doesn't have any perms -- it's all or nothing. which is why no
MoinMoin content can ever be included in a release.
the comment you were looking at was specificly in refrence to Confluence,
where it *is* possible to lock down pages so that only certain people have
perms to edit pages, while all users can have perms to "comment" on pages
(and you can export pages w/o the comments)
Now is probably a good time to decide:
1) do you want to use Confluence for managing the Lucy site?
(instead of forrest, or something else in svn)
2) do you want to use Confluence for managing a user ediable wiki?
(instead of MoinMoin)
You can do both (by having two Confluence spaces created) or you can do
one, or you can do the other ... or you can decided to do #1 now, and then
punt on deciding #2 for later -- but #1 should probably be decided before
much work is put into building the "new" Lucy website and adding any
content to it.
-Hoss