David Crossley wrote:
Antonio Gallardo wrote:
...
Is there a hope for Doco?
===================
IMO, yes:
1-The 3 communities are bigger now than 2 years ago.
2-We need to surf the increasing wave of Doco interest inside the
communities.
3-THE BEST: the communities already digested the overall Doco idea and
are ready to help each other in order to make Doco a reality!
I agree, but we have to really get to the point where we are talking the
same language. We have a long way to go, but the amount of common ground
is increasing.
Why Lenya need access to our SVN?
===========================
The lastest discusions about Doco showed that we can try to create a
"Lenya Publication"[2] in forrest. That means that is going to be
renderd by forrest. To make the things easiers, some of use believe we
need to give SVN access to Lenya that way all the people can work
together in the same repository.
Well that thread talks about it being in Lenya SVN.
But whatever, as long as we can keep some common stuff
in one or other SVN and get on with it. Maintaining
it should be the least of our worries, either by direct
commit or by patch.
Like I said in the Lenya lists thread as long as I have commit access to
it I don't care where it goes, lets just get on with it.
Why do I want commit access? Because I know I will be working on this,
but in my own time. I don't want to hang around waiting for patches to
be applied, if I supply a patch on Monday and find I have a little time
on Tuesday I want the patch to have been reviewed so that I can proceed.
If I *commit* the patch I know it's been reviewed, if it is sitting in a
patch queue it has not been reviewed. Sure I can do more work and then
submit a new patch, but what if there is a fundamental flaw in the first
patch that is taking me in the wrong direction?
So apply the patches faster. OK fine, if they get applied quickly (i.e.
within 24 hours) that can work, but why increase everyones workload? I'd
rather spend my time reading more commit mails than applying more
patches, it takes less time, and in a busy schedule every few minutes
saved are valuable - multiply that up by all the PMC members responsible
for oversight of the project.
---
OK, I have commit access to Forrest, commit it there, but there are
Lenya folk in the same position as I am. They don't want to wait for the
patch cycle. So we need a joint SVN.
---
Will they commit because they have access? Probably not, at least not in
this first phase. But the time will come, hopefully soon, that they will
commit. Doco is important to both communities and to the ASF as a whole.
It's now months since I showed how easy it was to render Lenya pages
with Forrest. I only did a quick example, with Gregors assistance on the
Lenya side. I never created a plugin, we now have one (thanks to
Joachim), this first tiny step requires changes to the Lenya
publication) - that's why I never created the plugin, I didn't have the
knowledge about Lenya, nor the time to understand their language on the
Lenya lists. Wouldn't it be great if I could have created the framework
of the plugin and said on the Lenya list "OK, please modify the Lenya
publication here to do XYZ".
[I'll address the joint list thing later]
---
Will opening write access undermine the meritocracy process? I'm not
sure, I've heard good arguments for yes and no, both pretty convincing.
As far as I am concerned this is the only important issue.
I'm not sure if it will harm things, but I want to find out. I stated I
was against simple committership for the project generally, however, I
think this new use case is worth the "risk" since folk have already gone
trough the meritocracy process. It will be simple enough for us to
revoke it (on an individual basis) if things go wrong.
For these reasons I will leave my existing +1 in the vote thread:
http://marc.theaimsgroup.com/?t=112551931500004&r=1&w=2
Thanks to everyone for their views on this contentious issue, especially
those who felt the need to say something like "I'm new/not a committer
but here's what I think...", I've not changed my vote, but I think I now
have a better understanding of what we need to look for to ensure things
are not going wrong as a result of this - everyones input is *extremely*
valuable in this thread.
Remember PMC members can -1 this, if you really believe this is wrong
then use your veto. I've stated my case, if it doesn't convince you then
I will argue no further since I am not 100% certain this is the right
decision. I'll work with patches if I have to.
Why not a new incubator project or a new list?
==============================================
Because it moves the important development work away from the core
communities that will be creating it. If the project gets too large and
creates too much noise, then we can think about splitting it off. But if
we do it too early we will only serve to split the communities.
What we actually need is not shared SVN (that is just
a minor convenience).
I think I've given a case for it being more than a minor convenience,
but maybe not...
What we need is shared communication.
This common mailing list idea is excellent.
Yes, but only if it is a "virtual" list as suggested by Nicola. I would
not want to see these discussions going on away from the two core
communities.
I see from another thread Thorsten is on the case (thanks).
Ross
