incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: Making up policy on the fly
Date Thu, 20 Aug 2009 11:01:33 GMT
On Thu, Aug 20, 2009 at 9:12 AM, ant elder<ant.elder@gmail.com> wrote:
> On Thu, Aug 20, 2009 at 8:15 AM, Bertrand
> Delacretaz<bdelacretaz@apache.org> wrote:
>> On Wed, Aug 19, 2009 at 7:15 PM, Ted Leung<twleung@sauria.com> wrote:
>>>
>>> On Aug 19, 2009, at 10:01 AM, William A. Rowe, Jr. wrote:
>>>
>>>> Exactly.  The incubator enforces Best Practices even when these are poorly
>>>> documented or incomplete, and discusses why they should be normalized.
>>>
>>> And how is this PMC supposed to enforce something which might be incomplete
>>> or contradictory?  I have no problem with enforcement, but I have a lot of
>>> problems with saying
>>>
>>>> In the meantime, we have dozens of projects who are here to learn the
>>>> *right* way to build code and communities
>>>
>>> when we can't even agree / document what that *right* way is....
>>
>> I agree with Bill that it's a good thing for the Incubator to clarify
>> best practices, and teach podlings to follow them even if older
>> projects sometimes don't. We tend to do the same for our kids, don't
>> we ? ;-)
>>
>> And I agree with Ted that it's often very hard for podlings (or even
>> mentors) to find out what those best practices are, without reading
>> tons of sometimes stale discussions here.
>>
>> Something like legal's "previously asked questions"
>> (http://apache.org/legal/resolved.html) would help a lot. We could
>> discuss things like this LICENSE and NOTICE matter here, vote on the
>> outcome and document the question and answer there, with a permanent
>> URL that points to the question.
>>
>> I'm willing to help maintain such a page if people think that's a good idea.
>>
>> -Bertrand
>>
>
> Having trouble finding where to reply on this thread so I'll just go
> here at the bottom...
>
> I don't have any issue with trying to teach poddlings best practices
> being a good idea, but i don't think the way we're handling poddling
> releases is doing that. The debate about separate vs single LICENSE
> files has become a bit of a distraction, even in the recent Cassandra
> release that was just one of a whole list of issues brought up.
>
> I think a big cause of frustration for poddlings and mentors is the
> unpredictable nature of release reviews with each vote for a release
> or RC respin getting a different set of best practice requirements
> depending on who is around to review. Could we make following "best
> practices" what ever we decide those are a graduation requirement
> instead of a release requirement? So releases which don't clearly
> violate some ASF policy are voted out quickly and its the poddling
> graduation that is delayed until they've done a release we're all
> happy with.

I understand theres frustration, but usually its short_term - once a
podling has resolved the issues that people raise then the next
release should be easier / have less comments. All these issues about
whether something is or is not policy or just someones view of best
practice is, in my experience, what happens elsewhere in projects when
it comes to releases. At the end of the day if you want someone to
vote +1 on a release then release managers need to address peoples
feedback. If they ignore feedback that is nice-to-have but not
absolute requirements then they risk that person not voting or
bothering to review a release next time. Being a release manager takes
patience and judgement/negotiation about whether something needs to be
fixed for a release or can be left till next time and this is
something that will happen once a project graduates and not just here.
If there are improvements that can be made to policy/docs then great,
but complaining about feedback rather than appreciating that someone
took the trouble to review a release is a mistake IMO.

Niall

>  ...ant

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message