forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Proposal for Forrest-Cocoon-Lenya commit access
Date Sun, 04 Sep 2005 02:08:10 GMT
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

Mime
View raw message