Re: Incubator release task force

2012-08-08 Thread Jukka Zitting
Hi,

For people interested in working on this, the ongoing Bloodhound
release vote has triggered some good discussion that would be great to
capture somehow.

BR,

Jukka Zitting

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



Re: Incubator release task force

2012-08-08 Thread Bertrand Delacretaz
On Thu, Jul 26, 2012 at 4:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:

 ...I'd like to start fixing this by forming a release task force of a
 handful of volunteers who are ready to invest an hour or two per week
 to work onb) migrating
 /dist/incubator to svnpubsub by the end of this year...

I'm interested in helping with that but I'd suggest starting from
scratch on new docs in svnpubsub, in order to create a minimal set of
docs that's understandable and maintainable. We'd keep the current
docs around as the old docs and refer to them less and less and the
new, smaller ones take shape. I'll discuss that in a separate thread.

-Bertrand

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



Re: Incubator release task force

2012-08-08 Thread Benson Margulies
On Wed, Aug 8, 2012 at 5:18 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Thu, Jul 26, 2012 at 4:10 PM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:

 ...I'd like to start fixing this by forming a release task force of a
 handful of volunteers who are ready to invest an hour or two per week
 to work onb) migrating
 /dist/incubator to svnpubsub by the end of this year...

 I'm interested in helping with that but I'd suggest starting from
 scratch on new docs in svnpubsub, in order to create a minimal set of
 docs that's understandable and maintainable. We'd keep the current
 docs around as the old docs and refer to them less and less and the
 new, smaller ones take shape. I'll discuss that in a separate thread.

I'm in on this.


 -Bertrand

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


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



Re: Incubator release task force

2012-07-28 Thread Daniel Shahaf
Jukka Zitting wrote on Fri, Jul 27, 2012 at 10:38:56 +0300:
 The existing Incubator release guide [1] is a noble effort, but I
 think it went wrong in trying to explain everything (even the table of
 contents is TL;DR, and parts of the page are already outdated) instead
 of just pointing to more authoritative information under
 http:://www.apache.org/dev/ and fixing/clarifying that documentation
 in-place where needed.
 

Actually www.apache.org/dev/ has FOUR releas*.html pages... and I assume
3.5 of them are out of date.  That's less than ideal.

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



Re: Incubator release task force

2012-07-27 Thread Jukka Zitting
Hi,

On Fri, Jul 27, 2012 at 1:44 AM, Joe Schaefer joe_schae...@yahoo.com wrote:
 I'm sure I speak for Marvin when I say I would love to participate on a task
 force dedicated to producing such documentation, but I am also weary about
 writing about a whole bunch of hypotheticals that nobody (other than Roy)
 has a really good handle on anyway.

That's a key reasons for why I think it would be a good idea for the
task force to spend time looking at actual release candidates and
helping podlings with the release process. If there's an issue that
isn't clearly documented, then fix that, otherwise just point to
existing docs on the matter.

The existing Incubator release guide [1] is a noble effort, but I
think it went wrong in trying to explain everything (even the table of
contents is TL;DR, and parts of the page are already outdated) instead
of just pointing to more authoritative information under
http:://www.apache.org/dev/ and fixing/clarifying that documentation
in-place where needed.

I'm of course happy for volunteers to contribute in any ways they
prefer, but as general guidance I'd be vary about the idea that simply
writing more documentation, especially without a firm rooting in
concrete problems, will help solve the issue.

[1] http://incubator.apache.org/guides/releasemanagement.html

BR,

Jukka Zitting

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



Re: Incubator release task force

2012-07-27 Thread Ross Gardler
From a mobile device - forgive errors and terseness
On Jul 26, 2012 11:07 PM, Joe Schaefer joe_schae...@yahoo.com wrote:

 
  From: Upayavira u...@odoko.co.uk
 To: general@incubator.apache.org
 Sent: Thursday, July 26, 2012 5:37 PM
 Subject: Re: Incubator release task force
 
 Marvin,
 
 While I (think I) can understand your concern (that it should be the
 mentors who are reviewing releases, not yet another group), I'd suggest
 that Jukka's approach might be a way to get there.


 Not for me- it is the podling's PPMC that needs to vet them properly,
 and we need to ensure that people who do a good job at that are suitably
 empowered to cast binding votes on release candidates.  I can see why
 podlings will be challenged for IPMC votes the first time thru, but
 by the third release they should have enough IPMC participation in their
 podling that the thought of coming to general@ and begging for votes
 won't ever occur to them.

+1 I can think of at least one case where we pushed a PPMC forward so he
could help other podlings. I've seen at least four releases benefit from
this move. We need to do it more, and I hope this task-force will start to
role that social structure into the docs (e.g. encourage successful release
managers to ask for IPMC membership).



 The reasons why we don't do this have nothing to do with the release
process
 or its documentation- it's just social norms colliding from different
 areas of the ASF.


 
 The incubator release process is, at the moment, pretty fraught, and I
 suspect there are only a handful of people who really get it. I would


 It sucks for the same old tired rationale behind excluding competent
 peer reviewers from the halls of power here.  Some of us think this
 is a core failing of the IPMC, others disagree.  If Jukka can satisfy
 the anti-progressives and bring in more people willing to do a competent
 job of reviewing candidates simply because these people are trying to
 review other-podling candidates, more power to him.  Again I will say
 that this is slightly missing the point about *competent* review versus
 a casual glance at licensing issues that someone unskilled in a codebase
 might AT-BEST provide.


 posit that one outcome of Jukka's suggestion is a simplified release
 process, which is likely to be understandable to a larger number of
 mentors, meaning you address your core issue.


 The release process *is* simple but laborious- it's supposed to be that
way.
 But if you've done one successful release iterating on those learnings
 is considerably easier than trying to do it from scratch with just our
 bloated process docs.

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



Incubator release task force

2012-07-26 Thread Jukka Zitting
Hi,

The Incubator ships about half a dozen releases each month on average,
but our release process is notoriously lengthy, fraught with problems,
and badly documented. If this was any other project, we'd have had a
well-oiled release process in place already years ago.

Much of our extra release overhead can of course be attributed to the
high release manager turnaround (ideally nobody would make more than
one or at most a few incubating releases) and the different
requirements (source layout, build process, packaging style,
distribution channels, etc.) of different podlings. However, there's
much that we could do that so far hasn't been done or has been
sidetracked. For example, our current release guide [1] is the result
of quite a bit of work, but without a clear vision accompanied with a
process of incremental improvements it's become a mess that few people
read, let alone understand.

I'd like to start fixing this by forming a release task force of a
handful of volunteers who are ready to invest an hour or two per week
to work on a) helping podlings get their releases out, b) migrating
/dist/incubator to svnpubsub by the end of this year as requested by
infra, c) improving related documentation, and d) proposing updates to
the Incubator release policy if needed to streamline the process. In
concrete terms I'd like the task force to 1) be the first port of call
for podlings who're failing to get enough +1s from their mentors and
2) to contribute a short updates (one sentence to one paragraph) on
their progress for inclusion in the monthly Incubator board reports.

Anyone interested?

[1] http://incubator.apache.org/guides/releasemanagement.html

BR,

Jukka Zitting

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



Re: Incubator release task force

2012-07-26 Thread Mohammad Nour El-Din
I like the idea, but I suggest to do it in a different way:

Why not to have volunteers who are already mentoring different podlings
with different sizes of both number of people and the size of code base,
these mentors then volunteer:

1- Update the release process docs
2- Report their their experience

Which is exactly what you said but the only change IMO is about who should
volunteer

On Thu, Jul 26, 2012 at 4:10 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 The Incubator ships about half a dozen releases each month on average,
 but our release process is notoriously lengthy, fraught with problems,
 and badly documented. If this was any other project, we'd have had a
 well-oiled release process in place already years ago.

 Much of our extra release overhead can of course be attributed to the
 high release manager turnaround (ideally nobody would make more than
 one or at most a few incubating releases) and the different
 requirements (source layout, build process, packaging style,
 distribution channels, etc.) of different podlings. However, there's
 much that we could do that so far hasn't been done or has been
 sidetracked. For example, our current release guide [1] is the result
 of quite a bit of work, but without a clear vision accompanied with a
 process of incremental improvements it's become a mess that few people
 read, let alone understand.

 I'd like to start fixing this by forming a release task force of a
 handful of volunteers who are ready to invest an hour or two per week
 to work on a) helping podlings get their releases out, b) migrating
 /dist/incubator to svnpubsub by the end of this year as requested by
 infra, c) improving related documentation, and d) proposing updates to
 the Incubator release policy if needed to streamline the process. In
 concrete terms I'd like the task force to 1) be the first port of call
 for podlings who're failing to get enough +1s from their mentors and
 2) to contribute a short updates (one sentence to one paragraph) on
 their progress for inclusion in the monthly Incubator board reports.

 Anyone interested?

 [1] http://incubator.apache.org/guides/releasemanagement.html

 BR,

 Jukka Zitting

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




-- 
Thanks
- Mohammad Nour

Life is like riding a bicycle. To keep your balance you must keep moving
- Albert Einstein


Re: Incubator release task force

2012-07-26 Thread Marvin Humphrey
On Thu, Jul 26, 2012 at 7:10 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:

 For example, our current release guide [1] is the result
 of quite a bit of work, but without a clear vision accompanied with a
 process of incremental improvements it's become a mess that few people
 read, let alone understand.

I am interested in this task.

 In concrete terms I'd like the task force to 1) be the first port of call
 for podlings who're failing to get enough +1s from their mentors

Please exclude me from this group[1].

Marvin Humphrey

[1] I believe the approach is misguided, but don't wish to rehash the arguments,
thereby delaying potential incremental progress on other fronts.

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



Re: Incubator release task force

2012-07-26 Thread Joe Schaefer
Ditto.





 From: Marvin Humphrey mar...@rectangular.com
To: general@incubator.apache.org 
Sent: Thursday, July 26, 2012 11:48 AM
Subject: Re: Incubator release task force
 
On Thu, Jul 26, 2012 at 7:10 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:

 For example, our current release guide [1] is the result
 of quite a bit of work, but without a clear vision accompanied with a
 process of incremental improvements it's become a mess that few people
 read, let alone understand.

I am interested in this task.

 In concrete terms I'd like the task force to 1) be the first port of call
 for podlings who're failing to get enough +1s from their mentors

Please exclude me from this group[1].

Marvin Humphrey

[1] I believe the approach is misguided, but don't wish to rehash the 
arguments,
    thereby delaying potential incremental progress on other fronts.

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





Re: Incubator release task force

2012-07-26 Thread Gary Martin
As someone who is currently attempting to go through their first 
release, I am not really in the category of someone who could be in such 
a taskforce. However, I am very interested in seeing an improvement in 
the release documentation. I would certainly consider looking back over 
my recent experience to potentially offer suggestions for updating the 
documentation.


It might not be a task that other first time release managers would want 
to add to their workload but, if this kind of contribution is seen as 
valuable, I would hope that it would not hurt to ask.


Cheers,
Gary


On 07/26/2012 03:10 PM, Jukka Zitting wrote:

Hi,

The Incubator ships about half a dozen releases each month on average,
but our release process is notoriously lengthy, fraught with problems,
and badly documented. If this was any other project, we'd have had a
well-oiled release process in place already years ago.

Much of our extra release overhead can of course be attributed to the
high release manager turnaround (ideally nobody would make more than
one or at most a few incubating releases) and the different
requirements (source layout, build process, packaging style,
distribution channels, etc.) of different podlings. However, there's
much that we could do that so far hasn't been done or has been
sidetracked. For example, our current release guide [1] is the result
of quite a bit of work, but without a clear vision accompanied with a
process of incremental improvements it's become a mess that few people
read, let alone understand.

I'd like to start fixing this by forming a release task force of a
handful of volunteers who are ready to invest an hour or two per week
to work on a) helping podlings get their releases out, b) migrating
/dist/incubator to svnpubsub by the end of this year as requested by
infra, c) improving related documentation, and d) proposing updates to
the Incubator release policy if needed to streamline the process. In
concrete terms I'd like the task force to 1) be the first port of call
for podlings who're failing to get enough +1s from their mentors and
2) to contribute a short updates (one sentence to one paragraph) on
their progress for inclusion in the monthly Incubator board reports.

Anyone interested?

[1] http://incubator.apache.org/guides/releasemanagement.html

BR,

Jukka Zitting

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





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



Re: Incubator release task force

2012-07-26 Thread Ross Gardler
Great idea.

For those interested in helping the documentation side of this you
might find the task oriented documenation that the Rave project
developed during incubation useful. This has already been successfully
adopted by at least two other podlings.

Of course it is project and build tool specific but as a template for
other projects to adopt and adapt it may be useful.

http://rave.apache.org/release-management.html

On 26 July 2012 15:10, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 The Incubator ships about half a dozen releases each month on average,
 but our release process is notoriously lengthy, fraught with problems,
 and badly documented. If this was any other project, we'd have had a
 well-oiled release process in place already years ago.

 Much of our extra release overhead can of course be attributed to the
 high release manager turnaround (ideally nobody would make more than
 one or at most a few incubating releases) and the different
 requirements (source layout, build process, packaging style,
 distribution channels, etc.) of different podlings. However, there's
 much that we could do that so far hasn't been done or has been
 sidetracked. For example, our current release guide [1] is the result
 of quite a bit of work, but without a clear vision accompanied with a
 process of incremental improvements it's become a mess that few people
 read, let alone understand.

 I'd like to start fixing this by forming a release task force of a
 handful of volunteers who are ready to invest an hour or two per week
 to work on a) helping podlings get their releases out, b) migrating
 /dist/incubator to svnpubsub by the end of this year as requested by
 infra, c) improving related documentation, and d) proposing updates to
 the Incubator release policy if needed to streamline the process. In
 concrete terms I'd like the task force to 1) be the first port of call
 for podlings who're failing to get enough +1s from their mentors and
 2) to contribute a short updates (one sentence to one paragraph) on
 their progress for inclusion in the monthly Incubator board reports.

 Anyone interested?

 [1] http://incubator.apache.org/guides/releasemanagement.html

 BR,

 Jukka Zitting

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




-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

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



Re: Incubator release task force

2012-07-26 Thread Mohammad Nour El-Din
Hi Gary...

On Thu, Jul 26, 2012 at 6:20 PM, Gary Martin gary.mar...@wandisco.comwrote:

 As someone who is currently attempting to go through their first release,
 I am not really in the category of someone who could be in such a
 taskforce. However, I am very interested in seeing an improvement in the
 release documentation. I would certainly consider looking back over my
 recent experience to potentially offer suggestions for updating the
 documentation.

 It might not be a task that other first time release managers would want
 to add to their workload but, if this kind of contribution is seen as
 valuable, I would hope that it would not hurt to ask.


Actually I believe you added another aspect that might not be covered by
what Jukka suggested, which is people consuming information from such
documentation and their feedback how much it is comprehensible and
readable, so for sure such feedback would be great.

Thanks for your suggestions :)



 Cheers,
 Gary



 On 07/26/2012 03:10 PM, Jukka Zitting wrote:

 Hi,

 The Incubator ships about half a dozen releases each month on average,
 but our release process is notoriously lengthy, fraught with problems,
 and badly documented. If this was any other project, we'd have had a
 well-oiled release process in place already years ago.

 Much of our extra release overhead can of course be attributed to the
 high release manager turnaround (ideally nobody would make more than
 one or at most a few incubating releases) and the different
 requirements (source layout, build process, packaging style,
 distribution channels, etc.) of different podlings. However, there's
 much that we could do that so far hasn't been done or has been
 sidetracked. For example, our current release guide [1] is the result
 of quite a bit of work, but without a clear vision accompanied with a
 process of incremental improvements it's become a mess that few people
 read, let alone understand.

 I'd like to start fixing this by forming a release task force of a
 handful of volunteers who are ready to invest an hour or two per week
 to work on a) helping podlings get their releases out, b) migrating
 /dist/incubator to svnpubsub by the end of this year as requested by
 infra, c) improving related documentation, and d) proposing updates to
 the Incubator release policy if needed to streamline the process. In
 concrete terms I'd like the task force to 1) be the first port of call
 for podlings who're failing to get enough +1s from their mentors and
 2) to contribute a short updates (one sentence to one paragraph) on
 their progress for inclusion in the monthly Incubator board reports.

 Anyone interested?

 [1] 
 http://incubator.apache.org/**guides/releasemanagement.htmlhttp://incubator.apache.org/guides/releasemanagement.html

 BR,

 Jukka Zitting

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




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




-- 
Thanks
- Mohammad Nour

Life is like riding a bicycle. To keep your balance you must keep moving
- Albert Einstein


Re: Incubator release task force

2012-07-26 Thread Upayavira
Marvin,

While I (think I) can understand your concern (that it should be the
mentors who are reviewing releases, not yet another group), I'd suggest
that Jukka's approach might be a way to get there.

The incubator release process is, at the moment, pretty fraught, and I
suspect there are only a handful of people who really get it. I would
posit that one outcome of Jukka's suggestion is a simplified release
process, which is likely to be understandable to a larger number of
mentors, meaning you address your core issue.

Just a thought.

Upayavira

On Thu, Jul 26, 2012, at 04:48 PM, Marvin Humphrey wrote:
 On Thu, Jul 26, 2012 at 7:10 AM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
 
  For example, our current release guide [1] is the result
  of quite a bit of work, but without a clear vision accompanied with a
  process of incremental improvements it's become a mess that few people
  read, let alone understand.
 
 I am interested in this task.
 
  In concrete terms I'd like the task force to 1) be the first port of call
  for podlings who're failing to get enough +1s from their mentors
 
 Please exclude me from this group[1].
 
 Marvin Humphrey
 
 [1] I believe the approach is misguided, but don't wish to rehash the
 arguments,
 thereby delaying potential incremental progress on other fronts.
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

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



Re: Incubator release task force

2012-07-26 Thread Benson Margulies
On Thu, Jul 26, 2012 at 5:37 PM, Upayavira u...@odoko.co.uk wrote:
 Marvin,

 While I (think I) can understand your concern (that it should be the
 mentors who are reviewing releases, not yet another group), I'd suggest
 that Jukka's approach might be a way to get there.

 The incubator release process is, at the moment, pretty fraught, and I
 suspect there are only a handful of people who really get it. I would
 posit that one outcome of Jukka's suggestion is a simplified release
 process, which is likely to be understandable to a larger number of
 mentors, meaning you address your core issue.

It seems to me that the goal of this effort is to make it easier for
podlings to produce appropriate releases, regardless of who reviews
them.


 Just a thought.

 Upayavira

 On Thu, Jul 26, 2012, at 04:48 PM, Marvin Humphrey wrote:
 On Thu, Jul 26, 2012 at 7:10 AM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:

  For example, our current release guide [1] is the result
  of quite a bit of work, but without a clear vision accompanied with a
  process of incremental improvements it's become a mess that few people
  read, let alone understand.

 I am interested in this task.

  In concrete terms I'd like the task force to 1) be the first port of call
  for podlings who're failing to get enough +1s from their mentors

 Please exclude me from this group[1].

 Marvin Humphrey

 [1] I believe the approach is misguided, but don't wish to rehash the
 arguments,
 thereby delaying potential incremental progress on other fronts.

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


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


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



Re: Incubator release task force

2012-07-26 Thread Joe Schaefer

 From: Upayavira u...@odoko.co.uk
To: general@incubator.apache.org 
Sent: Thursday, July 26, 2012 5:37 PM
Subject: Re: Incubator release task force
 
Marvin,

While I (think I) can understand your concern (that it should be the
mentors who are reviewing releases, not yet another group), I'd suggest
that Jukka's approach might be a way to get there.


Not for me- it is the podling's PPMC that needs to vet them properly,
and we need to ensure that people who do a good job at that are suitably
empowered to cast binding votes on release candidates.  I can see why
podlings will be challenged for IPMC votes the first time thru, but
by the third release they should have enough IPMC participation in their
podling that the thought of coming to general@ and begging for votes
won't ever occur to them.


The reasons why we don't do this have nothing to do with the release process
or its documentation- it's just social norms colliding from different
areas of the ASF.



The incubator release process is, at the moment, pretty fraught, and I
suspect there are only a handful of people who really get it. I would


It sucks for the same old tired rationale behind excluding competent
peer reviewers from the halls of power here.  Some of us think this
is a core failing of the IPMC, others disagree.  If Jukka can satisfy
the anti-progressives and bring in more people willing to do a competent
job of reviewing candidates simply because these people are trying to
review other-podling candidates, more power to him.  Again I will say
that this is slightly missing the point about *competent* review versus
a casual glance at licensing issues that someone unskilled in a codebase
might AT-BEST provide.


posit that one outcome of Jukka's suggestion is a simplified release
process, which is likely to be understandable to a larger number of
mentors, meaning you address your core issue.


The release process *is* simple but laborious- it's supposed to be that way.
But if you've done one successful release iterating on those learnings
is considerably easier than trying to do it from scratch with just our
bloated process docs.

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



Re: Incubator release task force

2012-07-26 Thread Dave Fisher

On Jul 26, 2012, at 3:07 PM, Joe Schaefer wrote:

 
 From: Upayavira u...@odoko.co.uk
 To: general@incubator.apache.org 
 Sent: Thursday, July 26, 2012 5:37 PM
 Subject: Re: Incubator release task force
 
 Marvin,
 
 While I (think I) can understand your concern (that it should be the
 mentors who are reviewing releases, not yet another group), I'd suggest
 that Jukka's approach might be a way to get there.
 
 
 Not for me- it is the podling's PPMC that needs to vet them properly,
 and we need to ensure that people who do a good job at that are suitably
 empowered to cast binding votes on release candidates.  I can see why
 podlings will be challenged for IPMC votes the first time thru, but
 by the third release they should have enough IPMC participation in their
 podling that the thought of coming to general@ and begging for votes
 won't ever occur to them.
 
 
 The reasons why we don't do this have nothing to do with the release process
 or its documentation- it's just social norms colliding from different
 areas of the ASF.
 
 
 
 The incubator release process is, at the moment, pretty fraught, and I
 suspect there are only a handful of people who really get it. I would
 
 
 It sucks for the same old tired rationale behind excluding competent
 peer reviewers from the halls of power here.  Some of us think this
 is a core failing of the IPMC, others disagree.  If Jukka can satisfy
 the anti-progressives and bring in more people willing to do a competent
 job of reviewing candidates simply because these people are trying to
 review other-podling candidates, more power to him.  Again I will say
 that this is slightly missing the point about *competent* review versus
 a casual glance at licensing issues that someone unskilled in a codebase
 might AT-BEST provide.
 
 
 posit that one outcome of Jukka's suggestion is a simplified release
 process, which is likely to be understandable to a larger number of
 mentors, meaning you address your core issue.
 
 
 The release process *is* simple but laborious- it's supposed to be that way.
 But if you've done one successful release iterating on those learnings
 is considerably easier than trying to do it from scratch with just our
 bloated process docs.

I think that the problem is navigating the documentation. Most IP and packaging 
questions have specific circumstances. It should be possible to look for 
answers using this data.

As a mentor I would really like to be able to point to either a decision tree 
or matrix for how to include, produce and consume binary artifacts, build 
dependencies, and source license categories in svn, source releases, and 
unofficial binary artifacts.

Podlings can then lookup the answer according to the circumstance. The answer 
can reference the bloated docs for the reasoning.

To avoid creating meta-bloat these trees and matrices would need to be kept to 
an absolute minimum with broad categories.

Regards,
Dave

 



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


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



Re: Incubator release task force

2012-07-26 Thread Joe Schaefer
- Original Message -

 From: Dave Fisher dave2w...@comcast.net
 To: general@incubator.apache.org
 Cc: 
 Sent: Thursday, July 26, 2012 6:33 PM
 Subject: Re: Incubator release task force
 
 
 On Jul 26, 2012, at 3:07 PM, Joe Schaefer wrote:
 
  
  From: Upayavira u...@odoko.co.uk
  To: general@incubator.apache.org 
  Sent: Thursday, July 26, 2012 5:37 PM
  Subject: Re: Incubator release task force
 
  Marvin,
 
  While I (think I) can understand your concern (that it should be the
  mentors who are reviewing releases, not yet another group), I'd 
 suggest
  that Jukka's approach might be a way to get there.
 
 
  Not for me- it is the podling's PPMC that needs to vet them properly,
  and we need to ensure that people who do a good job at that are suitably
  empowered to cast binding votes on release candidates.  I can see why
  podlings will be challenged for IPMC votes the first time thru, but
  by the third release they should have enough IPMC participation in their
  podling that the thought of coming to general@ and begging for votes
  won't ever occur to them.
 
 
  The reasons why we don't do this have nothing to do with the release 
 process
  or its documentation- it's just social norms colliding from different
  areas of the ASF.
 
 
 
  The incubator release process is, at the moment, pretty fraught, and I
  suspect there are only a handful of people who really get it. I would
 
 
  It sucks for the same old tired rationale behind excluding competent
  peer reviewers from the halls of power here.  Some of us think this
  is a core failing of the IPMC, others disagree.  If Jukka can satisfy
  the anti-progressives and bring in more people willing to do a competent
  job of reviewing candidates simply because these people are trying to
  review other-podling candidates, more power to him.  Again I will say
  that this is slightly missing the point about *competent* review versus
  a casual glance at licensing issues that someone unskilled in a codebase
  might AT-BEST provide.
 
 
  posit that one outcome of Jukka's suggestion is a simplified 
 release
  process, which is likely to be understandable to a larger number of
  mentors, meaning you address your core issue.
 
 
  The release process *is* simple but laborious- it's supposed to be that 
 way.
  But if you've done one successful release iterating on those learnings
  is considerably easier than trying to do it from scratch with just our
  bloated process docs.
 
 I think that the problem is navigating the documentation. Most IP and 
 packaging 
 questions have specific circumstances. It should be possible to look for 
 answers 
 using this data.
 
 As a mentor I would really like to be able to point to either a decision tree 
 or 
 matrix for how to include, produce and consume binary artifacts, build 
 dependencies, and source license categories in svn, source releases, and 
 unofficial binary artifacts.

I'm sure I speak for Marvin when I say I would love to participate on a task
force dedicated to producing such documentation, but I am also weary about
writing about a whole bunch of hypotheticals that nobody (other than Roy)
has a really good handle on anyway.  Yes, it's far easier for podlings to repeat
what some existing project has done than to recognize their situation as 
belonging
to an abstract category we have addressed somehow here.  I worry about arming
the people who fuss about such stuff as if it were critical to address 
everything
in *this* release instead of simply accepting a promise to fix certain things in
the next.

 
 Podlings can then lookup the answer according to the circumstance. The answer 
 can reference the bloated docs for the reasoning.
 
 To avoid creating meta-bloat these trees and matrices would need to be kept 
 to 
 an absolute minimum with broad categories.
 
 Regards,
 Dave
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


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



Re: Incubator release task force

2012-07-26 Thread Marvin Humphrey
On Thu, Jul 26, 2012 at 9:49 AM, Ross Gardler
rgard...@opendirective.com wrote:
 For those interested in helping the documentation side of this you
 might find the task oriented documenation that the Rave project
 developed during incubation useful. This has already been successfully
 adopted by at least two other podlings.

 Of course it is project and build tool specific but as a template for
 other projects to adopt and adapt it may be useful.

 http://rave.apache.org/release-management.html

Thanks, Ross.

Nearly every TLP documents and automates their release process eventually, and
I think it makes sense for us to encourage podlings to tackle that task early
on.  The smoother the release process, the easier it is for other podling
contributors to take a turn as release manager, which is a good way to
integrate people.

I would be up for distilling out the portions of that document which are
universally applicable.

Alternatively, we can simply link to the page where it is now, along with some
other examples.

Marvin Humphrey

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