incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <antel...@apache.org>
Subject Re: Making up policy on the fly
Date Fri, 21 Aug 2009 06:32:39 GMT
On Thu, Aug 20, 2009 at 12:01 PM, Niall
Pemberton<niall.pemberton@gmail.com> wrote:
> 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.

There are two differences between here and elsewhere releases that are
making that not work so well here:

1) The group of people reviewing Incubator releases is much more
variable compared to a TLP PMC
2) The people voting on Incubator releases are usually not on the
poddling dev/commit lists so don't give input during the release
preparation

> 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.
>

Several improvements have been suggested on this thread so far, the
two mains ones are:

- hold the release votes on the poddling mailing lists not general@
- make complying with "best practices" a graduation requirement not a
release requirement

I'll go start a separate thread on the first of those to see what people think.

   ...ant

> Niall
>

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


Mime
View raw message