HansBKK
2008-11-21 04:41:33 UTC
Sorry to come back so quick but I just got the digest
Big -1 from me on keeping both - I'd rather keep things as they are
than do that.
Fewer places to check is critical, having different cliques in
different media sucks. It's hard enough to build consensus!
AFAIK **drop** them both; all conversations could take place in the
issues queue, IMO the bumping feature there is very helpful (ref's
Joshua's point on old conversations), and it's mail notifications are
I think? just as good as GDO.
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
Big -1 from me on keeping both - I'd rather keep things as they are
than do that.
Fewer places to check is critical, having different cliques in
different media sucks. It's hard enough to build consensus!
AFAIK **drop** them both; all conversations could take place in the
issues queue, IMO the bumping feature there is very helpful (ref's
Joshua's point on old conversations), and it's mail notifications are
I think? just as good as GDO.
Send documentation mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.drupal.org/listinfo/documentation
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of documentation digest..."
1. Re: Proposal to deprecate the docs mailing list (Ryan Cross)
2. Re: Proposal to deprecate the docs mailing list (Angela Byron)
3. Re: Proposal to deprecate the docs mailing list (Addison Berry)
4. Re: Proposal to deprecate the docs mailing list (Shai Gluskin)
5. Re: Proposal to deprecate the docs mailing list (Hans
Henderson) (HansBKK)
6. Re: Problem With One of the Main CVS Pages (Shari)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Nov 2008 12:58:40 +1100
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset="utf-8"
as a supplement. You have to be a member to use a wiki page and if we
open up membership then folks can create any kind of group content
which will end up spawning some discussions on g.d.o and some on the
mail list.
I think it would be worth while to open up the group membership and see if
there is a natural migration towards them. In the same experimental mindset
as opening up the editing rights to everyone, lets try it out and see how it
goes. Yes, there may be problems with cross posting and etc, but lets see
what people gravitate towards and the evolutionary tendency.
I completely agree with Josh's assesment (especially about wiki competency)
and I am not a fan of deprecating the mailing list, but I'm willing to let
the masses speak and change my thinking. I would also point out that often
the reason for people's reluctance to joining a mailing list is the
perceived high traffic of them (which it usually isn't) and it would be
quite easy to setup the mailing lists to have a better archive interface by
joining services like mail-archive.org or nabble, so I don't think those are
solid reasons for deprecating the list.
One possibility would be to initially setup the group to only allow new
members to collaborate on wikis, so we can use it as a supplement (instead
of a full discussion forum).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/36817dc2/attachment-0001.htm
------------------------------
Message: 2
Date: Thu, 20 Nov 2008 21:28:30 -0500
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
that most people find web interfaces more friendly than e-mail, I
actually found myself nodding along with basically all of Josh's points.
If the main idea is to have central rallying points for organizing
stuff, then... why not do so right on Drupal.org?
For example, http://drupal.org/please-review-my-patch is a sort of "ad-
hoc" page that members of the Drupal 7 core development team use to
escalate issues up to me that are either "quickies" that could be
committed while I'm on one of my many daily phone calls, or that
really need core maintainer intervention because they are dead-locked
in discussion or need architectural advice. And, unlike
groups.drupal.org, drupal.org has no problem displaying the revision
log: http://drupal.org/node/309321/revisions. And finally, it's really
nice because you can do short-hand [#xxxxx] to automatically link to
relevant issues.
Not sure if this will address the current needs of the docs team, but
it's worth a thought?
But the bottom line is that g.d.o's current subscription and
collaboration options are pretty lackluster compared to the power e-
mail affords; until the situation improves, we are probably jumping
ship too soon. The Documentation issue queue can be used for web-based
conversations and comes complete with a very clear signal of whether
an issue is dealt with or not, and handbook pages work better than
g.d.o anyway for wiki-style collaboration.
-Angie
------------------------------
Message: 3
Date: Thu, 20 Nov 2008 22:02:31 -0500
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
for wiki pages is for temporary stuff, like drafting up a forum post
announcement to go to the front page or working out a new outline for
a section of the handbook. How would we handle not cluttering up with
lots and lots of these kind of pages that will never be used as real
handbook pages? I guess we could just have a doc team book. That isn't
as "stumble-upon-able" by casual contributors (which is one of my
goals). Hm. The only other disadvantage would be that there is no
email notification from handbook pages, but at least people could see
them in their d.o tracker, which would be nice.
I still feel like that is harder for casual contributors to notice and
get involved, but yeah, we could give that go in terms of at least
being able to work together. Something to consider.
------------------------------
Message: 4
Date: Thu, 20 Nov 2008 22:29:58 -0500
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset="iso-8859-1"
This whole conversation is just screaming out to mobilize advocating for a
few basic improvements on g.d.o. I agree with Nat's suggestions for pushing
through full messages in notifications and installing mailhandler.
I agree that Wiki functionality on g.d.o without history and diff is
useless. I'd like to hear more details about what is holding this up? Is it
a problem specific to OG? It's pretty basic functionality.
*I think we should use whatever clout we have as an important group within
the Drupal community to get the needed changes to g.d.o. As Nat also said,
every other group is probably screaming for this also. Let's band together.*
What kind of example are we setting when tasks that clearly fall into the
realm of "Community Plumbing" are not being handled by Drupal?
Yes, e-mail has been the killer ap for a whole generation. It can be hard to
move away from it. But the future is server and not client. It's the
"Semantic Web" and not the junk heap on your (my) hard drive. We aren't
there yet, but I feel like it helps move everything forward when we are
willing to be guinea pigs in attempting to actually use the technology we
are developing.
It was interesting hearing Angie's story of how the D7 core folks use
drupal.org pages for a similar need. Clever! But I would call that a
"community plumbing hack." I don't want to start replicating hacks. I'd
rather try to get g.d.o fixed!
My 3 cents,
Shai
for wiki pages is for temporary stuff, like drafting up a forum post
announcement to go to the front page or working out a new outline for
a section of the handbook. How would we handle not cluttering up with
lots and lots of these kind of pages that will never be used as real
handbook pages? I guess we could just have a doc team book. That isn't
as "stumble-upon-able" by casual contributors (which is one of my
goals). Hm. The only other disadvantage would be that there is no
email notification from handbook pages, but at least people could see
them in their d.o tracker, which would be nice.
I still feel like that is harder for casual contributors to notice and
get involved, but yeah, we could give that go in terms of at least
being able to work together. Something to consider.
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081120/696b6c0b/attachment-0001.htm
------------------------------
Message: 5
Date: Fri, 21 Nov 2008 11:34:25 +0700
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list (Hans Henderson)
Content-Type: text/plain; charset=ISO-8859-1
Big +1 from me
Joshua makes some great technical points, but it comes down to
preference and work style, and mine is to visit a web location to
participate in a discussion rather than having it come to me.
I do think it shouldn't be that hard to get the best of both worlds
with some enhancements that would benefit all OG sites and Drupal in
general, but also recognize that Moshe's got limited bandwidth to
implement any code changes. But would be nice. . .
------------------------------
Message: 6
Date: Thu, 20 Nov 2008 22:27:37 -0600
Subject: Re: [documentation] Problem With One of the Main CVS Pages
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I thought I would add what someone who doesn't know anything about HEAD
or CVS thought when going to the page...
Reading what is there, I would have assumed it was talking about the
latest unstable release of version 6. Because I didn't know for sure
what HEAD referred to I moved backward, along the breadcrumb, to "Drupal
and CVS", I still wasn't sure if HEAD was referring to 6 or 7. So I
clicked on CVS FAQ it isn't answered there but there is a note: "-
What's "HEAD"? What should I use it for?" as something that needs to be
answered. So then I went back, and clicked on "Drupal CVS branches and
tags" to see if it was explained there. I found "The HEAD branch is
special and is used to refer to the latest development version.," still
doesn't answer if it's 6.7 or 7.x. There was a link for a more detailed
"In /Drupal core/, HEAD is the name given to the version of Drupal core
being worked on by developers right now. Of course, now that core is
only using two digits for the version number (starting with the 5.0
release), there's no longer any ambiguity about what the next version of
core will be called, so the use of "HEAD" to identify a release is no
longer necessary. For example, now that the official 6.0 release of
Drupal core is out, everyone knows that the next version of core under
development will eventually become the 7.x release series, so the
nightly snapshot releases are more properly called "7.x-dev", not "HEAD"."
The 1st part seems to be saying that it would be the next 2 digit core
version which would mean it would be 6.7, but then it says it's 7.x-dev,
so I'm still not sure what HEAD refers to. Is it 6.7 or 7.x?
Also the title, actually doesn't mean anything to me either. Checking
out from the main repository, wouldn't be something I would have any
idea of meaning, and would most likely ignore it. I would suggest
Getting files from the main repository, Downloading from..., Access the ...
I thought I would share my entire process, so you can see why some of
this does indeed need to be made clearer if the intention is for anyone
visiting and wanting to learn, to be able to understand. I know, I don't
know or understand some of the lingo, and am willing to move back, or
attempt to find the information, however as in this case even trying to
find the information left me still not understanding, and if I have to
work harder then this, it's likely to be something I just let go.
Now that I just typed all that, I reread the original post, and noticed
that Shai had placed stable release in italics, this leads me to believe
that 7 is what you get when you dl HEAD. If HEAD is indeed 7, I would
suggest something like this to explain it: Once a version has been
released e.g. 6.0, all further version release under the number 6, are
considered "Stable" releases and not "Development" releases. The HEAD or
development release would be the next /full /number e.g. 7.x
Shari
_______________________________________________
documentation mailing list
http://lists.drupal.org/listinfo/documentation
End of documentation Digest, Vol 48, Issue 7
********************************************
--To subscribe or unsubscribe via the World Wide Web, visit
http://lists.drupal.org/listinfo/documentation
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of documentation digest..."
1. Re: Proposal to deprecate the docs mailing list (Ryan Cross)
2. Re: Proposal to deprecate the docs mailing list (Angela Byron)
3. Re: Proposal to deprecate the docs mailing list (Addison Berry)
4. Re: Proposal to deprecate the docs mailing list (Shai Gluskin)
5. Re: Proposal to deprecate the docs mailing list (Hans
Henderson) (HansBKK)
6. Re: Problem With One of the Main CVS Pages (Shari)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Nov 2008 12:58:40 +1100
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset="utf-8"
In sort my vote would be that the email list should remain the
primary workspace and wiki pages, when appropriate, can serve a
valuable purpose as a supplement.
Well the main problem is that we can't "occasionally" use wiki pagesprimary workspace and wiki pages, when appropriate, can serve a
valuable purpose as a supplement.
as a supplement. You have to be a member to use a wiki page and if we
open up membership then folks can create any kind of group content
which will end up spawning some discussions on g.d.o and some on the
mail list.
there is a natural migration towards them. In the same experimental mindset
as opening up the editing rights to everyone, lets try it out and see how it
goes. Yes, there may be problems with cross posting and etc, but lets see
what people gravitate towards and the evolutionary tendency.
I completely agree with Josh's assesment (especially about wiki competency)
and I am not a fan of deprecating the mailing list, but I'm willing to let
the masses speak and change my thinking. I would also point out that often
the reason for people's reluctance to joining a mailing list is the
perceived high traffic of them (which it usually isn't) and it would be
quite easy to setup the mailing lists to have a better archive interface by
joining services like mail-archive.org or nabble, so I don't think those are
solid reasons for deprecating the list.
One possibility would be to initially setup the group to only allow new
members to collaborate on wikis, so we can use it as a supplement (instead
of a full discussion forum).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/36817dc2/attachment-0001.htm
------------------------------
Message: 2
Date: Thu, 20 Nov 2008 21:28:30 -0500
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Comments below. I'm NOT a fan of the idea of deprecating the mailing
list for the reasons below.
While I was originally in favour of the move to g.d.o on the groundslist for the reasons below.
that most people find web interfaces more friendly than e-mail, I
actually found myself nodding along with basically all of Josh's points.
If the main idea is to have central rallying points for organizing
stuff, then... why not do so right on Drupal.org?
For example, http://drupal.org/please-review-my-patch is a sort of "ad-
hoc" page that members of the Drupal 7 core development team use to
escalate issues up to me that are either "quickies" that could be
committed while I'm on one of my many daily phone calls, or that
really need core maintainer intervention because they are dead-locked
in discussion or need architectural advice. And, unlike
groups.drupal.org, drupal.org has no problem displaying the revision
log: http://drupal.org/node/309321/revisions. And finally, it's really
nice because you can do short-hand [#xxxxx] to automatically link to
relevant issues.
Not sure if this will address the current needs of the docs team, but
it's worth a thought?
But the bottom line is that g.d.o's current subscription and
collaboration options are pretty lackluster compared to the power e-
mail affords; until the situation improves, we are probably jumping
ship too soon. The Documentation issue queue can be used for web-based
conversations and comes complete with a very clear signal of whether
an issue is dealt with or not, and handbook pages work better than
g.d.o anyway for wiki-style collaboration.
-Angie
------------------------------
Message: 3
Date: Thu, 20 Nov 2008 22:02:31 -0500
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
If the main idea is to have central rallying points for organizing
stuff, then... why not do so right on Drupal.org?
For example, http://drupal.org/please-review-my-patch is a sort of
"ad-
hoc" page that members of the Drupal 7 core development team use to
escalate issues up to me that are either "quickies" that could be
committed while I'm on one of my many daily phone calls, or that
really need core maintainer intervention because they are dead-locked
in discussion or need architectural advice. And, unlike
groups.drupal.org, drupal.org has no problem displaying the revision
log: http://drupal.org/node/309321/revisions. And finally, it's really
nice because you can do short-hand [#xxxxx] to automatically link to
relevant issues.
Not sure if this will address the current needs of the docs team, but
it's worth a thought?
Hm. Hm. Well, yeah it works in certain ways, but the main uses we havestuff, then... why not do so right on Drupal.org?
For example, http://drupal.org/please-review-my-patch is a sort of
"ad-
hoc" page that members of the Drupal 7 core development team use to
escalate issues up to me that are either "quickies" that could be
committed while I'm on one of my many daily phone calls, or that
really need core maintainer intervention because they are dead-locked
in discussion or need architectural advice. And, unlike
groups.drupal.org, drupal.org has no problem displaying the revision
log: http://drupal.org/node/309321/revisions. And finally, it's really
nice because you can do short-hand [#xxxxx] to automatically link to
relevant issues.
Not sure if this will address the current needs of the docs team, but
it's worth a thought?
for wiki pages is for temporary stuff, like drafting up a forum post
announcement to go to the front page or working out a new outline for
a section of the handbook. How would we handle not cluttering up with
lots and lots of these kind of pages that will never be used as real
handbook pages? I guess we could just have a doc team book. That isn't
as "stumble-upon-able" by casual contributors (which is one of my
goals). Hm. The only other disadvantage would be that there is no
email notification from handbook pages, but at least people could see
them in their d.o tracker, which would be nice.
I still feel like that is harder for casual contributors to notice and
get involved, but yeah, we could give that go in terms of at least
being able to work together. Something to consider.
------------------------------
Message: 4
Date: Thu, 20 Nov 2008 22:29:58 -0500
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list
Content-Type: text/plain; charset="iso-8859-1"
This whole conversation is just screaming out to mobilize advocating for a
few basic improvements on g.d.o. I agree with Nat's suggestions for pushing
through full messages in notifications and installing mailhandler.
I agree that Wiki functionality on g.d.o without history and diff is
useless. I'd like to hear more details about what is holding this up? Is it
a problem specific to OG? It's pretty basic functionality.
*I think we should use whatever clout we have as an important group within
the Drupal community to get the needed changes to g.d.o. As Nat also said,
every other group is probably screaming for this also. Let's band together.*
What kind of example are we setting when tasks that clearly fall into the
realm of "Community Plumbing" are not being handled by Drupal?
Yes, e-mail has been the killer ap for a whole generation. It can be hard to
move away from it. But the future is server and not client. It's the
"Semantic Web" and not the junk heap on your (my) hard drive. We aren't
there yet, but I feel like it helps move everything forward when we are
willing to be guinea pigs in attempting to actually use the technology we
are developing.
It was interesting hearing Angie's story of how the D7 core folks use
drupal.org pages for a similar need. Clever! But I would call that a
"community plumbing hack." I don't want to start replicating hacks. I'd
rather try to get g.d.o fixed!
My 3 cents,
Shai
If the main idea is to have central rallying points for organizing
stuff, then... why not do so right on Drupal.org?
For example, http://drupal.org/please-review-my-patch is a sort of
"ad-
hoc" page that members of the Drupal 7 core development team use to
escalate issues up to me that are either "quickies" that could be
committed while I'm on one of my many daily phone calls, or that
really need core maintainer intervention because they are dead-locked
in discussion or need architectural advice. And, unlike
groups.drupal.org, drupal.org has no problem displaying the revision
log: http://drupal.org/node/309321/revisions. And finally, it's really
nice because you can do short-hand [#xxxxx] to automatically link to
relevant issues.
Not sure if this will address the current needs of the docs team, but
it's worth a thought?
Hm. Hm. Well, yeah it works in certain ways, but the main uses we havestuff, then... why not do so right on Drupal.org?
For example, http://drupal.org/please-review-my-patch is a sort of
"ad-
hoc" page that members of the Drupal 7 core development team use to
escalate issues up to me that are either "quickies" that could be
committed while I'm on one of my many daily phone calls, or that
really need core maintainer intervention because they are dead-locked
in discussion or need architectural advice. And, unlike
groups.drupal.org, drupal.org has no problem displaying the revision
log: http://drupal.org/node/309321/revisions. And finally, it's really
nice because you can do short-hand [#xxxxx] to automatically link to
relevant issues.
Not sure if this will address the current needs of the docs team, but
it's worth a thought?
for wiki pages is for temporary stuff, like drafting up a forum post
announcement to go to the front page or working out a new outline for
a section of the handbook. How would we handle not cluttering up with
lots and lots of these kind of pages that will never be used as real
handbook pages? I guess we could just have a doc team book. That isn't
as "stumble-upon-able" by casual contributors (which is one of my
goals). Hm. The only other disadvantage would be that there is no
email notification from handbook pages, but at least people could see
them in their d.o tracker, which would be nice.
I still feel like that is harder for casual contributors to notice and
get involved, but yeah, we could give that go in terms of at least
being able to work together. Something to consider.
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081120/696b6c0b/attachment-0001.htm
------------------------------
Message: 5
Date: Fri, 21 Nov 2008 11:34:25 +0700
Subject: Re: [documentation] Proposal to deprecate the docs mailing
list (Hans Henderson)
Content-Type: text/plain; charset=ISO-8859-1
Big +1 from me
Joshua makes some great technical points, but it comes down to
preference and work style, and mine is to visit a web location to
participate in a discussion rather than having it come to me.
I do think it shouldn't be that hard to get the best of both worlds
with some enhancements that would benefit all OG sites and Drupal in
general, but also recognize that Moshe's got limited bandwidth to
implement any code changes. But would be nice. . .
------------------------------
Message: 6
Date: Thu, 20 Nov 2008 22:27:37 -0600
Subject: Re: [documentation] Problem With One of the Main CVS Pages
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I thought I would add what someone who doesn't know anything about HEAD
or CVS thought when going to the page...
Reading what is there, I would have assumed it was talking about the
latest unstable release of version 6. Because I didn't know for sure
what HEAD referred to I moved backward, along the breadcrumb, to "Drupal
and CVS", I still wasn't sure if HEAD was referring to 6 or 7. So I
clicked on CVS FAQ it isn't answered there but there is a note: "-
What's "HEAD"? What should I use it for?" as something that needs to be
answered. So then I went back, and clicked on "Drupal CVS branches and
tags" to see if it was explained there. I found "The HEAD branch is
special and is used to refer to the latest development version.," still
doesn't answer if it's 6.7 or 7.x. There was a link for a more detailed
"In /Drupal core/, HEAD is the name given to the version of Drupal core
being worked on by developers right now. Of course, now that core is
only using two digits for the version number (starting with the 5.0
release), there's no longer any ambiguity about what the next version of
core will be called, so the use of "HEAD" to identify a release is no
longer necessary. For example, now that the official 6.0 release of
Drupal core is out, everyone knows that the next version of core under
development will eventually become the 7.x release series, so the
nightly snapshot releases are more properly called "7.x-dev", not "HEAD"."
The 1st part seems to be saying that it would be the next 2 digit core
version which would mean it would be 6.7, but then it says it's 7.x-dev,
so I'm still not sure what HEAD refers to. Is it 6.7 or 7.x?
Also the title, actually doesn't mean anything to me either. Checking
out from the main repository, wouldn't be something I would have any
idea of meaning, and would most likely ignore it. I would suggest
Getting files from the main repository, Downloading from..., Access the ...
I thought I would share my entire process, so you can see why some of
this does indeed need to be made clearer if the intention is for anyone
visiting and wanting to learn, to be able to understand. I know, I don't
know or understand some of the lingo, and am willing to move back, or
attempt to find the information, however as in this case even trying to
find the information left me still not understanding, and if I have to
work harder then this, it's likely to be something I just let go.
Now that I just typed all that, I reread the original post, and noticed
that Shai had placed stable release in italics, this leads me to believe
that 7 is what you get when you dl HEAD. If HEAD is indeed 7, I would
suggest something like this to explain it: Once a version has been
released e.g. 6.0, all further version release under the number 6, are
considered "Stable" releases and not "Development" releases. The HEAD or
development release would be the next /full /number e.g. 7.x
Shari
Hi gang,
This is about http://drupal.org/node/320
The title of the page is: /Checking out from the main repository
/The assumption on that page is that you want to check out HEAD. There
is one small section which says, "If you want to check out a specific
version of Drupal..."
I believe the assumption of the page should be opposite, that you want
to check out a specific version of Drupal. That is how you can check
out the latest stable release.
The use-case for checking out HEAD is for core committers or folks
testing patches to core. That is very important. However, I think the
vast majority of people wanting to get their feet wet in CVS (and
therefore coming to this handbook page) want to check out the latest
/stable release/ in order to make it easier to upgrade the next time
an updated stable release is deployed.
I'd like to edit the page so that the primary instructions are for
checking out a specific version and the secondary instructions are for
folks wanting to checkout HEAD.
I thought this was a big enough change that I wanted to run it by others.
Thanks,
Shai
------------------------------------------------------------------------
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
------------------------------This is about http://drupal.org/node/320
The title of the page is: /Checking out from the main repository
/The assumption on that page is that you want to check out HEAD. There
is one small section which says, "If you want to check out a specific
version of Drupal..."
I believe the assumption of the page should be opposite, that you want
to check out a specific version of Drupal. That is how you can check
out the latest stable release.
The use-case for checking out HEAD is for core committers or folks
testing patches to core. That is very important. However, I think the
vast majority of people wanting to get their feet wet in CVS (and
therefore coming to this handbook page) want to check out the latest
/stable release/ in order to make it easier to upgrade the next time
an updated stable release is deployed.
I'd like to edit the page so that the primary instructions are for
checking out a specific version and the secondary instructions are for
folks wanting to checkout HEAD.
I thought this was a big enough change that I wanted to run it by others.
Thanks,
Shai
------------------------------------------------------------------------
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
_______________________________________________
documentation mailing list
http://lists.drupal.org/listinfo/documentation
End of documentation Digest, Vol 48, Issue 7
********************************************
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/