You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Leo Simons <ma...@leosimons.com> on 2007/05/05 17:10:40 UTC
[suggestion] making documentation management more lightweight
Jo!
The whole jira-patch-commit workflow for the documentation seems
annoying. At least it annoys me -- in particular the patches don't
show up in my email so I have to visit jira which I try and avoid as
much as possible :-).
Suggestions:
1) create
http://svn.apache.org/repos/asf/incubator/public/staging
writeable by *all* committers
svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \
http://svn.apache.org/repos/asf/incubator/public/staging
vi infrastructure/trunk/subversion/authorization/asf-authorization
svn commit infrastructure/trunk/subversion/authorization/asf-
authorization
2) create an svn:externals on
http://svn.apache.org/repos/asf/incubator/public/trunk/site-
publish
like this
website-staging http://svn.apache.org/repos/asf/incubator/
public/staging/site-publish
so that you can see the work-in-progress at
http://incubator.apache.org/website-staging/
3) instead of sending documentation patches, people who are helping
with the documentation work on the staging branch
4) set up svnmerge.py for staging/ and trunk/
* see http://www.orcaware.com/svn/wiki/Svnmerge.py
* make sure to block the revision from step #2!
5) propose documentation changes on the mailing list
* get diffs
cd incubator/trunk
svnmerge.py --bidirectional diff > ~/staging-diffs.txt
# or use -r to get only a few revisions
* send diff to mailing list for discussion and lazy
consensus approval
6) merge
cd incubator/trunk
svnmerge.py --bidirectional avail
svnmerge.py --bidirectional # or use -r12345,...
svn commit -F svnmerge-commit-message.txt
cd ../staging
svnmerge.py
svn commit -F svnmerge-commit-message.txt
7) rejoice at the lightweight workflow, which also survives Robert's
laptop sinking to the bottom of the sea!
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [suggestion] making documentation management more lightweight
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/5/07, Leo Simons <ma...@leosimons.com> wrote:
> Jo!
>
> The whole jira-patch-commit workflow for the documentation seems
> annoying. At least it annoys me -- in particular the patches don't
> show up in my email so I have to visit jira which I try and avoid as
> much as possible :-).
>
> Suggestions:
>
> 1) create
>
> http://svn.apache.org/repos/asf/incubator/public/staging
>
> writeable by *all* committers
>
> svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \
> http://svn.apache.org/repos/asf/incubator/public/staging
> vi infrastructure/trunk/subversion/authorization/asf-authorization
> svn commit infrastructure/trunk/subversion/authorization/asf-
> authorization
ok
> 2) create an svn:externals on
>
> http://svn.apache.org/repos/asf/incubator/public/trunk/site-
> publish
>
> like this
>
> website-staging http://svn.apache.org/repos/asf/incubator/
> public/staging/site-publish
>
> so that you can see the work-in-progress at
>
> http://incubator.apache.org/website-staging/
perhaps http://incubator.apache.org/~website-draft-staging/ would be better
> 3) instead of sending documentation patches, people who are helping
> with the documentation work on the staging branch
ok
> 4) set up svnmerge.py for staging/ and trunk/
> * see http://www.orcaware.com/svn/wiki/Svnmerge.py
> * make sure to block the revision from step #2!
looks good
> 5) propose documentation changes on the mailing list
> * get diffs
>
> cd incubator/trunk
> svnmerge.py --bidirectional diff > ~/staging-diffs.txt
> # or use -r to get only a few revisions
>
> * send diff to mailing list for discussion and lazy
> consensus approval
ok
> 6) merge
>
> cd incubator/trunk
> svnmerge.py --bidirectional avail
> svnmerge.py --bidirectional # or use -r12345,...
> svn commit -F svnmerge-commit-message.txt
> cd ../staging
> svnmerge.py
> svn commit -F svnmerge-commit-message.txt
bit uncertain whether a single set of drafts will work but willing to
give it a go
so, ok by me
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [suggestion] making documentation management more lightweight
Posted by Michael Wechner <mi...@wyona.com>.
Leo Simons wrote:
> On May 5, 2007, at 7:55 PM, Michael Wechner wrote:
>
>> what about a CMS with a workflow, which would sit on top SVN
>> accessing both branches (staging resp. draft and live) and hence
>> would allow devs still accessing it through other SVN clients and
>> also allow updating the live site as static SVN update?
>
>
> Ah, that's an old subject! Several people have done prototypes along
> these lines (I've done about one and a half in python, but in python
> the most promising codebase is probably (still) SubWiki), and I'll
> argue something like this ("edit this page" links backed by
> subversion) is what we "really really want". Mozilla has (or had) it
> for their site.
>
> site-dev@apache.org was set up with this in mind, ages ago, and
> there's still some requirements/designs lying around for how it would
> work. David Crossley is a good person to ask about it.
>
> I think one of the problems why this effort has stalled has been that
> apache has so many CMS or CMS-ish tools that it is really hard to
> come up with a common way to do things that satisfies enough people
> to make setting it up worthwhile, so you get into loads of arguing.
well, it seems to me that SVN is the common denominator at the ASF and
only a tool
which is able to connect to SVN will satisfy enough people within the
ASF. That's one of the reasons I have spent time how a CMS can use SVN
as a data repo.
>
>> We have implemented versioning and workflow into Yulup (http://
>> www.yulup.org), which is available within the recent trunk version
>> or next week's release. Yulup does decouple this functionality from
>> the actual server implementation.
>>
>> I would be happy to help to set something up in case this would make
>> sense for the incubator folks.
>
>
> I'd rather not see a tool like this for a project-specific setup --
> anything that writes to SVN needs to be very carefully evaluated for
> security and stability reasons and be maintained and supported by
> infrastructure@.
I understand, but I would assume writing to draft/staging SVN on a
dedicated zone would be less an issue and then allow dedicated people to
merge from there into the "live SVN" as you describe it above.
> If you're interested in signing up for the "bigger job", please work
> with site-dev@ (and infrastructure@).
>
> I can tell you right now that something "off of trunk" of a non-
> Apache project that's in a 0.x release series, doesn't document how
> it uses SVN, and is licensed under the GPL is not that likely to
> receive a warm welcome immediately. "I could set something up" will
> also probably receive a healthy amount of scepticism; I wrote a blog
> post about why that is ages ago:
>
> http://www.jroller.com/page/lsd/20050717#why_we_say_no_to
>
> all that said, don't let me discourage you (too much)! We could
> definitely use this, but you'll have to volunteer for (quite) a bit
> more work and get some others to help out ;-)
I very well understand what you are saying ;-) and I don't want to
impose anything, but I believe that I finally have the tools at hand to
do this and I am currently working on this for my own needs. Hence I
wanted to ask and see how big the skepticism is and I don't mean this
cynical, but just would like to be constructive.
Anyway I will start with http://incubator.apache.org/guides/website.html
and will see how far I will get and will hopefully come back within
reasonable time :-)
Cheers
Michael
>
>
> cheers,
>
>
> Leo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [suggestion] making documentation management more lightweight
Posted by Leo Simons <ma...@leosimons.com>.
On May 5, 2007, at 7:55 PM, Michael Wechner wrote:
> what about a CMS with a workflow, which would sit on top SVN
> accessing both branches (staging resp. draft and live) and hence
> would allow devs still accessing it through other SVN clients and
> also allow updating the live site as static SVN update?
Ah, that's an old subject! Several people have done prototypes along
these lines (I've done about one and a half in python, but in python
the most promising codebase is probably (still) SubWiki), and I'll
argue something like this ("edit this page" links backed by
subversion) is what we "really really want". Mozilla has (or had) it
for their site.
site-dev@apache.org was set up with this in mind, ages ago, and
there's still some requirements/designs lying around for how it would
work. David Crossley is a good person to ask about it.
I think one of the problems why this effort has stalled has been that
apache has so many CMS or CMS-ish tools that it is really hard to
come up with a common way to do things that satisfies enough people
to make setting it up worthwhile, so you get into loads of arguing.
> We have implemented versioning and workflow into Yulup (http://
> www.yulup.org), which is available within the recent trunk version
> or next week's release. Yulup does decouple this functionality from
> the actual server implementation.
>
> I would be happy to help to set something up in case this would
> make sense for the incubator folks.
I'd rather not see a tool like this for a project-specific setup --
anything that writes to SVN needs to be very carefully evaluated for
security and stability reasons and be maintained and supported by
infrastructure@. If you're interested in signing up for the "bigger
job", please work with site-dev@ (and infrastructure@).
I can tell you right now that something "off of trunk" of a non-
Apache project that's in a 0.x release series, doesn't document how
it uses SVN, and is licensed under the GPL is not that likely to
receive a warm welcome immediately. "I could set something up" will
also probably receive a healthy amount of scepticism; I wrote a blog
post about why that is ages ago:
http://www.jroller.com/page/lsd/20050717#why_we_say_no_to
all that said, don't let me discourage you (too much)! We could
definitely use this, but you'll have to volunteer for (quite) a bit
more work and get some others to help out ;-)
cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [suggestion] making documentation management more lightweight
Posted by Michael Wechner <mi...@wyona.com>.
Leo Simons wrote:
> Jo!
>
> The whole jira-patch-commit workflow for the documentation seems
> annoying. At least it annoys me -- in particular the patches don't
> show up in my email so I have to visit jira which I try and avoid as
> much as possible :-).
>
> Suggestions:
>
> 1) create
>
> http://svn.apache.org/repos/asf/incubator/public/staging
>
> writeable by *all* committers
>
> svn cp http://svn.apache.org/repos/asf/incubator/public/trunk \
> http://svn.apache.org/repos/asf/incubator/public/staging
> vi infrastructure/trunk/subversion/authorization/asf-authorization
> svn commit infrastructure/trunk/subversion/authorization/asf-
> authorization
>
> 2) create an svn:externals on
>
> http://svn.apache.org/repos/asf/incubator/public/trunk/site-
> publish
>
> like this
>
> website-staging http://svn.apache.org/repos/asf/incubator/
> public/staging/site-publish
>
> so that you can see the work-in-progress at
>
> http://incubator.apache.org/website-staging/
>
> 3) instead of sending documentation patches, people who are helping
> with the documentation work on the staging branch
>
> 4) set up svnmerge.py for staging/ and trunk/
> * see http://www.orcaware.com/svn/wiki/Svnmerge.py
> * make sure to block the revision from step #2!
>
> 5) propose documentation changes on the mailing list
> * get diffs
>
> cd incubator/trunk
> svnmerge.py --bidirectional diff > ~/staging-diffs.txt
> # or use -r to get only a few revisions
>
> * send diff to mailing list for discussion and lazy
> consensus approval
>
> 6) merge
>
> cd incubator/trunk
> svnmerge.py --bidirectional avail
> svnmerge.py --bidirectional # or use -r12345,...
> svn commit -F svnmerge-commit-message.txt
> cd ../staging
> svnmerge.py
> svn commit -F svnmerge-commit-message.txt
>
> 7) rejoice at the lightweight workflow, which also survives Robert's
> laptop sinking to the bottom of the sea!
what about a CMS with a workflow, which would sit on top SVN accessing
both branches (staging resp. draft and live) and hence would
allow devs still accessing it through other SVN clients and also allow
updating
the live site as static SVN update?
We have implemented versioning and workflow into Yulup
(http://www.yulup.org), which is available within the recent trunk
version or next week's release. Yulup does decouple this functionality
from the actual server implementation.
I would be happy to help to set something up in case this would make
sense for the incubator folks.
Cheers
Michael
>
>
> cheers,
>
>
> Leo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org