You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Justin Mclean <ju...@classsoftware.com> on 2019/02/19 22:38:41 UTC
Starting at the incubator and releases
Hi,
Looking at some of the situations we currently have I think we may need some more general guidance for incubating projects and making releases after just joining the incubator. In this context “non approved” means releases or distributions not approved by the PPPM and IPMC (usually by voting) and available and promoted to the general public. This doesn’t cover snapshots, RCs or nightly which are not advertised to the general public. Feedback / changes / thoughts from the rest of the IPMC members welcome.
1. Can the PPMC can distrubite artefacts in other places that are based on approved releases.
Yes.
2. Can the PPMC make unapproved releases in other places after joining the incubator?
No but 3rd parties can and someone from the PPMC can act as a 3rd party, it must be clear that:
a) These are produced by a 3rd party and not the PPMC and follow Apache's branding and trademark policy.
b) This is not being used as a mechanism to avoid making Apache releases.
3. Can the PPMC make unapproved releases in their Apache repo after the code has been moved to the incubator repo?
No.
4. Can the PPMC make unapproved release in other places after the code has been moved to the incubator repo?
No but 3rd parties can. See 2.
5. Can the PPMC keep two repos and continue to make releases in the non Apache one after the code has been moved to the incubator repo?
No but 3rd parties can. See 2. It’s likely that the old repo name may need to change to avoid confusion with the Apache project.
6. Can the PPMC link to unapproved releases or distributions from their website or download pages.
No, unless these are clearly marked as 3rd party releases and not endorsed by the PPMC.
7. When should the first ASF release be made.
Ideally within six months of joining the incubator. Remember this first release doesn’t have to be perfect.
There may be the occasional exception to these guidelines, this would need to be discussed and approved by your mentors and the IPMC informed.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Marvin Humphrey <ma...@apache.org>.
Hi Mick,
The ASF's official Release Policy lives here:
https://www.apache.org/legal/release-policy
The policy text itself is up-to-date and authoritative. (The associated FAQ,
also on that page, does not live up to the same standard.)
On 2019/02/25 09:05:30, "Mick Semb Wever" <mc...@apache.org> wrote:
> ii) "There is documentation _all over the place_ and it's not possible to
> know which of it is outdated and which is still current especially in
> the face of conflicting information." – Lars Francke.
The Incubator cannot solve the problem of excessive and inconsistent policy
documentation, because the Incubator doesn't make Foundation-level policy.
What the Incubator should do is request in its monthly report that the Board
endorse and maintain an authoritative, bounded list of all ASF policy
documents -- to say "only these and no more".
It should back up this request with illustrations of how the current unbounded
morass of documentation burdens our contributors -- both podlings trying to
absorb and IPMC trying to explain -- and how the ensuing confusion foments
conflict.
> b) legal but not fully ASF compliant,
The Incubator has the flexibility to make releases which deviate from ASF
policy (though not law). It just has to exercise sound judgment and to keep
the Board informed of what it's doing.
Deviations are actually expected (within reason) and accounted for in the text
of Release Policy:
https://www.apache.org/legal/release-policy.html#administration
Projects MUST notify the Board of Directors of any deviations from
recommended or required policy directives.
This applies to other top-level projects, not just the Incubator. The Board
exercises a certain flexibility when enforcing policy -- if you can articulate
why what you want to do is consistent with the ASF's values, the Board will
work with you.
This assumes you have grokked the ASF's values well enough to make your case.
And that goes to show why policy per se cannot be the primary focus of
incubation -- well-developed soft skills (such as biasing towards action) and
an understanding of the rationales behind why the ASF is the way it is are
fundamental to project success.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Christofer Dutz <ch...@c-ware.de>.
Or/and the existing mentors could concentrate more on helping the podling they handle to become a TLP and not stay in the incubator for too long.
Even if that sometimes requires becoming more a PITA to the podlings that are sort of living in the incubator forever ...
And in the end we should also think about releasing (in the sense of kicking them out) podlings that are obviously not actively adopting the Apache way. (Of course after a quite large grace-period)
After all we mentors are investing our time and therefore we could also expect them to work on their end.
If they don't, we could then invest the time we are wasting on them on other projects that might be more in need of active mentoring.
Chris
Am 28.02.19, 13:55 schrieb "Mark Thomas" <ma...@apache.org>:
On 25/02/2019 19:22, Dave Fisher wrote:
<snip/>
> To me the main Incubator problem is most podlings do not have three fully engaged mentors.
+1
> 52 or 53 Incubating podlings may be too many.
+1
> The Incubator may be too lenient in (a) allowing podlings in with minimal mentors
+1
The tricky part in all of this is that it isn't the podlings fault if
the mentors don't engage.
We need more engaged mentors per podling. The obvious solutions to that
are recruit more mentors (where from?) or accept fewer podlings (seems
unfair to prospective podlings).
I think the IMPC has some tough decisions ahead.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Mark Thomas <ma...@apache.org>.
On 25/02/2019 19:22, Dave Fisher wrote:
<snip/>
> To me the main Incubator problem is most podlings do not have three fully engaged mentors.
+1
> 52 or 53 Incubating podlings may be too many.
+1
> The Incubator may be too lenient in (a) allowing podlings in with minimal mentors
+1
The tricky part in all of this is that it isn't the podlings fault if
the mentors don't engage.
We need more engaged mentors per podling. The obvious solutions to that
are recruit more mentors (where from?) or accept fewer podlings (seems
unfair to prospective podlings).
I think the IMPC has some tough decisions ahead.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Dave Fisher <da...@comcast.net>.
Hi -
I agree with what Myrle wrote I wanted to focus on this paragraph which I think describes one of the major issues with the IPMC.
> On Feb 25, 2019, at 3:03 AM, Myrle Krantz <my...@apache.org> wrote:
>
> Also, our mentors were not always the most active, so it would have been
> impossible for us to get a release out at all if we had depended on only
> them to vote on our releases. We have a shortage of mentors in the
> incubator. If projects are not willing to accept fly-by help, there may
> actually not be enough help at all in certain areas. The incubator could
> be forced to accept less projects. Weex (the podling I'm currently
> mentoring) currently only has two mentors. If Justin were to stop voting
> on their releases, they wouldn't be able to make official Apache releases
> anymore.
>
To me the main Incubator problem is most podlings do not have three fully engaged mentors. Even if they do they are also volunteers and may not be able to vote quickly. A minimum from a Mentor should be to VOTE on releases. Some podlings get The Apache Way and a good mentor may only need appear to VOTE. Others do not and the amount of engagement needed is large which causes some mentors to resign and others to fade away.
Put another way is that even if a new podling comes in with four or five mentors some of these never, ever engage with the podling. In my experience there is always one or two that may engage at the start and never engage after.
Release VOTES on the general@incubator list are better as a final check than they are as the primary official vote. If a podling likes a particular IPMC member's VOTEs on general@ maybe they can ask them to mentor and/or vote on their dev list.
Recently Justin added a question on podling reports to indicate if the Mentors are being helpful. Maybe the question needs to be refined to ask if all Mentors are helping with Release Votes.
52 or 53 Incubating podlings may be too many. The Incubator may be too lenient in (a) allowing podlings in with minimal mentors and (b) not recognizing when as unfair as it may seem incubation has failed. Maybe when a podling is failing due to IPMC issues the mentors should go to members@ to see if there is a volunteer for that podling.
Regards,
Dave
Re: Starting at the incubator and releases
Posted by Myrle Krantz <my...@apache.org>.
Hey Mick,
I see some promise in the approach you outline. I'd like to explain the
advantages my project drew from the current system, so that we don't lose
anything important in the process of change. Then I would like to suggest
a refinement of your approach. I'm top posting here, because I'm
organizing my thoughts a little differently than yours and Justin's
The problem I believe you are expressing
-------------------------------------------------------------
Correct me if I've got it wrong.
The release process is working as a barrier rather than a path through the
incubator. This is especially problematic if a business involved in the
project has a commercial requirement for continuous releases. The problem
is bigger still if code import is unexpectedly slowed down by any sort of
legal or technical issues. This issue could prevent otherwise promising
projects from coming to Apache.
What I value in the current system
-------------------------------------------------------------
When my project (Fineract for the record) moved to the incubator, I read
the release voting mails for my own and other's projects. This helped me
develop an understanding of what was expected of an Apache release.
Justin's emails were by far the most informative. Whether he gave a +1 or
a -1, he evaluated the release as far as was possible. For all issues he
identified, Justin explained how they contributed to his vote, what would
need to change, and whether it blocked a release or blocked graduation.
I learned both from the votes on Fineract releases *and* the votes on the
other projects in the incubator.
Documentation is good, but seeing a process lived is so much more helpful.
I say this both as a former podling member and as a mentor who is still
learning. And I've heard similar sentiments from many others, including
ASF board members.
Also, our mentors were not always the most active, so it would have been
impossible for us to get a release out at all if we had depended on only
them to vote on our releases. We have a shortage of mentors in the
incubator. If projects are not willing to accept fly-by help, there may
actually not be enough help at all in certain areas. The incubator could
be forced to accept less projects. Weex (the podling I'm currently
mentoring) currently only has two mentors. If Justin were to stop voting
on their releases, they wouldn't be able to make official Apache releases
anymore.
When Fineract releases were voted on we took the feedback and captured it
in Jira tickets. Because our users do not always communicate with us in
Jira tickets, we were accustomed to capturing our work items ourselves. We
do use Jira, but not all Apache projects do. Weex uses github issues.
Expecting someone who is helping many projects to find your issue tracker
also seems unreasonable to me. I'd rather have the input in the form of an
e-mail than no input at all.
When it came time to for Fineract to graduate, no one had to figure out
what our last x releases were and check if they conformed. If we had made
a release it was at least pretty good, and the evidence of how good was
right there on the list. Not only that, but others could observe how we
respond to feedback. They had a sense of how we might respond if the board
asked us for some change.
It was also always clear what Fineract releases the Apache legal shield
applied to: all of them.
How I'd compose the current suggestions
-------------------------------------------------------------
I think Mick's approach of sorting releases into types is promising, and
potentially helpful, and I do think that moving away from a binary vote for
all releases (+1/-1) can create a path for podlings where what we have now
feels like a wall that needs to be jumped over.
I'd suggest we stick with emails. If the expectation is that voting
produces tickets, the podling is perfectly capable of capturing them. And
there are other ways to make a release evaluation less binary.
Currently Justin (and many who have started following his example including
me), gives a vote, lists what he checked and what he found. It would be
possible to list what was checked and what was found without the vote.
Instead of a vote, each problem found could be put in the categories you've
identified: (not fully ASF compliant, illegal). Informally we already do
this.
I agree with you, Mick, that we should allow releases outside of the ASF.
I think we're all in agreement that that must be resolved before
graduation. This means that the ASF legal shield won't apply to these
releases. But many projects were already making releases before they
started incubating. Removing that legal shield may not be fair to any new
committers you gain during incubation. They may believe they are protected
when they are not. This is a drawback that we may simply have to accept
here.
I also believe projects should be able to make nightlies/snapshots/QA
builds available for testing without voting both before and after
graduation. As a mentor, I _shudder_ at the thought of being asked to vote
on a new release every day. Removing the possibility for QA builds only
forces project activity behind corporate firewalls. It doesn't enable
transparency or community.
As to the documentation
-------------------------------------------------------------
This is both a typical software project problem and a typical volunteer
organization problem: "'somebody' should fix this mess". Whoever takes it
on certainly will not be paid for it, and is very likely to get yelled at
for it. Given those two conditions, it's actually surprising that it's as
good as it is. And that's not even considering the ways in which incubator
information is duplicated in other places in the foundation, or
contradicted, or linked.
Best Regards,
Myrle
On Mon, Feb 25, 2019 at 10:05 AM Mick Semb Wever <mc...@apache.org> wrote:
>
> I'll chime in, but on the technical front my experience is rather new in
> the incubator, i'm still learning.
>
>
> > Looking at some of the situations we currently have I think we may need
> > some more general guidance for incubating projects and making releases
> > after just joining the incubator.
>
>
> By far, the two biggest issues I see are:
> i) "too many cooks in the kitchen" and IPMC strangers _policing_ the
> rules on podlings,
> ii) "There is documentation _all over the place_ and it's not possible to
> know which of it is outdated and which is still current especially in the
> face of conflicting information." – Lars Francke.
>
> Addressing and improving the rules and process can help. But better
> documentation, automation of checks, and better communication style and
> channels, will go a lot further, imho.
>
> Another way to think of this is: it is not the podling that failed the
> release process, but the IPMC that failed the podling. Why were the tooling
> and documentation not put in place by the IPMC so that it then had to rely
> upon instead late policing and being the gatekeepers.
>
>
> > In this context “non approved” means
> > releases or distributions not approved by the PPPM and IPMC (usually by
> > voting) and available and promoted to the general public.
>
>
> Something that has been brought up is allowing a podling to incrementally
> improve their releases. What this actually means has not been stated
> clearly.
>
> The different types of resulting podling releases I'm aware of are…
> a) fully ASF compliant,
> b) legal but not fully ASF compliant,
> c) illegally ASF,
> d) staged/nightly/snapshot,
> e) external.
>
>
> With these types, my understanding is that a podling needs to demonstrate
> a number of releases of type (a) before raising its vote for graduation.
> What's not clear is what releases are (b), and where should (c) releases
> get hosted? (For example can they simply stay as staged releases.)
>
> If the goal is to encourage momentum, and for some podling cultures this
> means permitting incrementally improving ASF releases, then the more
> minimal the requirements to (a) are the better, and any shortcomings in
> releases of type (b) should be listed in a jira ticket rather than as a
> "-1" vote on the release.
>
> So far there's been the effort to minimise the requirements to (a), and
> this is very appreciated.
>
> https://lists.apache.org/thread.html/7690a00c6a8aba9f51a6dfaa9dc9273626715006eab4c43e6893a839@%3Cprivate.incubator.apache.org%3E
>
> It's still unclear to me what are all the soft requirements that when
> violated lead to type (b)?
> For example this document alludes to the distinction, but not the
> separation: https://wiki.apache.org/incubator/IncubatorReleaseChecklist
>
> Is this documented correctly anywhere? If this was better documented, and
> violations dealt with as jira tickets, it might well have been enough to
> have prevented the situation with Zipkin. I'm sure the same is true for the
> other podlings that have experienced such feedback as abrasive.
>
> Another thing is legal violations that lead to (a) but that are not
> specific to one podling, should not suddenly become a burden on a podling
> doing its first release. If other releases have the problem, for example
> it's not been properly identified before, it's brand new or the dust on how
> to deal with it is still settling, then for the love of god don't decide to
> pick on it with a podling's *first* release attempt. Get it in order
> (settled and documented) elsewhere before policing the podling. Taking
> release violations up with mentors first would also be another way around
> this problem.
>
> I'm also in favour of aiming for deprecating the need for the IPMC votes.
> With the correct documentation and tooling in place the PPMC vote with 3
> mentors approval should be enough to get a release to at least type (b).
>
>
> > This doesn’t
> > cover snapshots, RCs or nightly which are not advertised to the general
> > public. Feedback / changes / thoughts from the rest of the IPMC members
> > welcome.
>
>
> Docker images need to be staged somewhere. Just like the actual
> convenience binaries need to be signed, checksummed, and tested as-is. So
> should docker images before they are released to
> https://hub.docker.com/u/apache
> Having to build docker images, to verify them as a release candidate, is
> not cool.
>
> Is this something we are to request of Infra?
>
>
> > 2. Can the PPMC make unapproved releases in other places after joining
> > the incubator?
> >
> > No but 3rd parties can and someone from the PPMC can act as a 3rd
> > party, it must be clear that:
> > a) These are produced by a 3rd party and not the PPMC and follow
> > Apache's branding and trademark policy.
> > b) This is not being used as a mechanism to avoid making Apache
> > releases.
>
>
> Please make it clear, and do what you can, to support a podling's existing
> release cadence.
>
> The Zipkin community with 15 repositories makes regular (fortnightly)
> releases. Just because one repository has been migrated to ASF does not
> mean the other 14 repositories will be (or expect to be) avoiding this
> release cadence. Neither do they expect trademark/branding issues over the
> Zipkin name. It is understood that those releases outside of the ASF have
> to avoid the Apache trademark and anything that implies ASF-endorsed.
>
> The distinction between the PPMC and the existing community needs to be
> written up clearly. As these often will be the same group of people, and
> people of other cultures/languages may have trouble initially appreciating
> the important nuance here.
>
>
> > 5. Can the PPMC keep two repos and continue to make releases in the non
> > Apache one after the code has been moved to the incubator repo?
> >
> > No but 3rd parties can. See 2. It’s likely that the old repo name may
> > need to change to avoid confusion with the Apache project.
>
>
> Please make it clear that during the transition period this applies only
> to each individual repository, not the original name of the podling. In the
> situation like Zipkin's, no one is going to be temporarily renaming the 14
> external repositories to a different name because only one repository has
> so far been migrated.
>
> regards,
> Mick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Starting at the incubator and releases
Posted by Mick Semb Wever <mc...@apache.org>.
I'll chime in, but on the technical front my experience is rather new in the incubator, i'm still learning.
> Looking at some of the situations we currently have I think we may need
> some more general guidance for incubating projects and making releases
> after just joining the incubator.
By far, the two biggest issues I see are:
i) "too many cooks in the kitchen" and IPMC strangers _policing_ the rules on podlings,
ii) "There is documentation _all over the place_ and it's not possible to know which of it is outdated and which is still current especially in the face of conflicting information." – Lars Francke.
Addressing and improving the rules and process can help. But better documentation, automation of checks, and better communication style and channels, will go a lot further, imho.
Another way to think of this is: it is not the podling that failed the release process, but the IPMC that failed the podling. Why were the tooling and documentation not put in place by the IPMC so that it then had to rely upon instead late policing and being the gatekeepers.
> In this context “non approved” means
> releases or distributions not approved by the PPPM and IPMC (usually by
> voting) and available and promoted to the general public.
Something that has been brought up is allowing a podling to incrementally improve their releases. What this actually means has not been stated clearly.
The different types of resulting podling releases I'm aware of are…
a) fully ASF compliant,
b) legal but not fully ASF compliant,
c) illegally ASF,
d) staged/nightly/snapshot,
e) external.
With these types, my understanding is that a podling needs to demonstrate a number of releases of type (a) before raising its vote for graduation. What's not clear is what releases are (b), and where should (c) releases get hosted? (For example can they simply stay as staged releases.)
If the goal is to encourage momentum, and for some podling cultures this means permitting incrementally improving ASF releases, then the more minimal the requirements to (a) are the better, and any shortcomings in releases of type (b) should be listed in a jira ticket rather than as a "-1" vote on the release.
So far there's been the effort to minimise the requirements to (a), and this is very appreciated.
https://lists.apache.org/thread.html/7690a00c6a8aba9f51a6dfaa9dc9273626715006eab4c43e6893a839@%3Cprivate.incubator.apache.org%3E
It's still unclear to me what are all the soft requirements that when violated lead to type (b)?
For example this document alludes to the distinction, but not the separation: https://wiki.apache.org/incubator/IncubatorReleaseChecklist
Is this documented correctly anywhere? If this was better documented, and violations dealt with as jira tickets, it might well have been enough to have prevented the situation with Zipkin. I'm sure the same is true for the other podlings that have experienced such feedback as abrasive.
Another thing is legal violations that lead to (a) but that are not specific to one podling, should not suddenly become a burden on a podling doing its first release. If other releases have the problem, for example it's not been properly identified before, it's brand new or the dust on how to deal with it is still settling, then for the love of god don't decide to pick on it with a podling's *first* release attempt. Get it in order (settled and documented) elsewhere before policing the podling. Taking release violations up with mentors first would also be another way around this problem.
I'm also in favour of aiming for deprecating the need for the IPMC votes. With the correct documentation and tooling in place the PPMC vote with 3 mentors approval should be enough to get a release to at least type (b).
> This doesn’t
> cover snapshots, RCs or nightly which are not advertised to the general
> public. Feedback / changes / thoughts from the rest of the IPMC members
> welcome.
Docker images need to be staged somewhere. Just like the actual convenience binaries need to be signed, checksummed, and tested as-is. So should docker images before they are released to https://hub.docker.com/u/apache
Having to build docker images, to verify them as a release candidate, is not cool.
Is this something we are to request of Infra?
> 2. Can the PPMC make unapproved releases in other places after joining
> the incubator?
>
> No but 3rd parties can and someone from the PPMC can act as a 3rd
> party, it must be clear that:
> a) These are produced by a 3rd party and not the PPMC and follow
> Apache's branding and trademark policy.
> b) This is not being used as a mechanism to avoid making Apache
> releases.
Please make it clear, and do what you can, to support a podling's existing release cadence.
The Zipkin community with 15 repositories makes regular (fortnightly) releases. Just because one repository has been migrated to ASF does not mean the other 14 repositories will be (or expect to be) avoiding this release cadence. Neither do they expect trademark/branding issues over the Zipkin name. It is understood that those releases outside of the ASF have to avoid the Apache trademark and anything that implies ASF-endorsed.
The distinction between the PPMC and the existing community needs to be written up clearly. As these often will be the same group of people, and people of other cultures/languages may have trouble initially appreciating the important nuance here.
> 5. Can the PPMC keep two repos and continue to make releases in the non
> Apache one after the code has been moved to the incubator repo?
>
> No but 3rd parties can. See 2. It’s likely that the old repo name may
> need to change to avoid confusion with the Apache project.
Please make it clear that during the transition period this applies only to each individual repository, not the original name of the podling. In the situation like Zipkin's, no one is going to be temporarily renaming the 14 external repositories to a different name because only one repository has so far been migrated.
regards,
Mick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 19, 2019, at 3:10 PM, Kevin A. McGrail <km...@apache.org> wrote:
>
> On 2/19/2019 6:07 PM, Dave Fisher wrote:
>> (5) Go and develop in The Apache Way!
>>
>> Only once these four things happen can we start any timer on the first Apache Release.
>
> Four, no FIVE things! Don't forget the Spanish Inquisition.
>
> Agreed. We need to setup the reason hurdles with a carrot so that
> podlings understand these steps are necessary for releases to resume.
Please let’s bring on the comfy chair!
Apologies to all who have not had the joy of Monty Python’s Flying Circus in your life ;-)
I always prefer to avoid “The Argument Room” - You can google all these references!
Regards,
Dave
>
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 2/19/2019 6:07 PM, Dave Fisher wrote:
> (5) Go and develop in The Apache Way!
>
> Only once these four things happen can we start any timer on the first Apache Release.
Four, no FIVE things! Don't forget the Spanish Inquisition.
Agreed. We need to setup the reason hurdles with a carrot so that
podlings understand these steps are necessary for releases to resume.
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> (1) Mentor or champion bootstraps the podling files and mailing lists then starts:
> (2) Onboard the individuals to join the mailing lists, file ICLAs and get their apache ids.
> (3) SGA must be filed. (Or it is determined that ICLA covers everything) (Domain transfer?)
> (4) Repository of code is moved to Apache.
> (5) Go and develop in The Apache Way!
I've often wondered if all this is strictly required given the DISCLAIMER file?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Dave Fisher <da...@comcast.net>.
We have to make sure that the steps that occur before work can proceed are addressed.
(1) Mentor or champion bootstraps the podling files and mailing lists then starts:
(2) Onboard the individuals to join the mailing lists, file ICLAs and get their apache ids.
(3) SGA must be filed. (Or it is determined that ICLA covers everything) (Domain transfer?)
(4) Repository of code is moved to Apache.
(5) Go and develop in The Apache Way!
Only once these four things happen can we start any timer on the first Apache Release.
It has happened in the past that (3) takes over a year for occasional Podlings. There were reasons for this and while that was happening there were many releases and non-Apache Way behavior. I volunteered as a prod because I saw it.
Regards,
Dave
> On Feb 19, 2019, at 2:56 PM, Kevin A. McGrail <km...@apache.org> wrote:
>
> I think this might be a really important faq on the top of the list of
> OK, now we are voted in, what's next? and a FAQ about releases.
>
> On 2/19/2019 5:38 PM, Justin Mclean wrote:
>> Hi,
>>
>> Looking at some of the situations we currently have I think we may need some more general guidance for incubating projects and making releases after just joining the incubator. In this context “non approved” means releases or distributions not approved by the PPPM and IPMC (usually by voting) and available and promoted to the general public. This doesn’t cover snapshots, RCs or nightly which are not advertised to the general public. Feedback / changes / thoughts from the rest of the IPMC members welcome.
>>
>> 1. Can the PPMC can distrubite artefacts in other places that are based on approved releases.
>>
>> Yes.
>>
>> 2. Can the PPMC make unapproved releases in other places after joining the incubator?
>>
>> No but 3rd parties can and someone from the PPMC can act as a 3rd party, it must be clear that:
>> a) These are produced by a 3rd party and not the PPMC and follow Apache's branding and trademark policy.
>> b) This is not being used as a mechanism to avoid making Apache releases.
>>
>> 3. Can the PPMC make unapproved releases in their Apache repo after the code has been moved to the incubator repo?
>>
>> No.
>>
>> 4. Can the PPMC make unapproved release in other places after the code has been moved to the incubator repo?
>>
>> No but 3rd parties can. See 2.
>>
>> 5. Can the PPMC keep two repos and continue to make releases in the non Apache one after the code has been moved to the incubator repo?
>>
>> No but 3rd parties can. See 2. It’s likely that the old repo name may need to change to avoid confusion with the Apache project.
>>
>> 6. Can the PPMC link to unapproved releases or distributions from their website or download pages.
>>
>> No, unless these are clearly marked as 3rd party releases and not endorsed by the PPMC.
>>
>> 7. When should the first ASF release be made.
>>
>> Ideally within six months of joining the incubator. Remember this first release doesn’t have to be perfect.
>>
>> There may be the occasional exception to these guidelines, this would need to be discussed and approved by your mentors and the IPMC informed.
>>
>> Thanks,
>> Justin
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> --
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by "Kevin A. McGrail" <km...@apache.org>.
I think this might be a really important faq on the top of the list of
OK, now we are voted in, what's next? and a FAQ about releases.
On 2/19/2019 5:38 PM, Justin Mclean wrote:
> Hi,
>
> Looking at some of the situations we currently have I think we may need some more general guidance for incubating projects and making releases after just joining the incubator. In this context “non approved” means releases or distributions not approved by the PPPM and IPMC (usually by voting) and available and promoted to the general public. This doesn’t cover snapshots, RCs or nightly which are not advertised to the general public. Feedback / changes / thoughts from the rest of the IPMC members welcome.
>
> 1. Can the PPMC can distrubite artefacts in other places that are based on approved releases.
>
> Yes.
>
> 2. Can the PPMC make unapproved releases in other places after joining the incubator?
>
> No but 3rd parties can and someone from the PPMC can act as a 3rd party, it must be clear that:
> a) These are produced by a 3rd party and not the PPMC and follow Apache's branding and trademark policy.
> b) This is not being used as a mechanism to avoid making Apache releases.
>
> 3. Can the PPMC make unapproved releases in their Apache repo after the code has been moved to the incubator repo?
>
> No.
>
> 4. Can the PPMC make unapproved release in other places after the code has been moved to the incubator repo?
>
> No but 3rd parties can. See 2.
>
> 5. Can the PPMC keep two repos and continue to make releases in the non Apache one after the code has been moved to the incubator repo?
>
> No but 3rd parties can. See 2. It’s likely that the old repo name may need to change to avoid confusion with the Apache project.
>
> 6. Can the PPMC link to unapproved releases or distributions from their website or download pages.
>
> No, unless these are clearly marked as 3rd party releases and not endorsed by the PPMC.
>
> 7. When should the first ASF release be made.
>
> Ideally within six months of joining the incubator. Remember this first release doesn’t have to be perfect.
>
> There may be the occasional exception to these guidelines, this would need to be discussed and approved by your mentors and the IPMC informed.
>
> Thanks,
> Justin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Starting at the incubator and releases
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Thanks for tech feedback John.
> This is a loaded statement, since PPMC's can never make releases. The IPMC
> approves the release always within the scope of Apache.
I did say above that it does need to be approved by the PPMC and IPMC I’ll see if I can reword.
>> Ideally within six months of joining the incubator. Remember this first
>> release doesn’t have to be perfect.
>>
>
> Personally, I disagree with this statement. I would prefer to see "as soon
> as the podling feels ready to do a release”
I added it because the podlings we seem to be having issues with are the one who take the longest to make a release and continue make unapproved releases elsewhere. I know in some cases it take longer and there’s no issues. No issue in dropping it however.
Thanks,
Justin
Re: Starting at the incubator and releases
Posted by "John D. Ament" <jo...@apache.org>.
Hi Justin
On Tue, Feb 19, 2019 at 5:38 PM Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> Looking at some of the situations we currently have I think we may need
> some more general guidance for incubating projects and making releases
> after just joining the incubator. In this context “non approved” means
> releases or distributions not approved by the PPPM and IPMC (usually by
> voting) and available and promoted to the general public. This doesn’t
> cover snapshots, RCs or nightly which are not advertised to the general
> public. Feedback / changes / thoughts from the rest of the IPMC members
> welcome.
>
> 1. Can the PPMC can distrubite artefacts in other places that are based on
> approved releases.
>
> Yes.
>
> 2. Can the PPMC make unapproved releases in other places after joining the
> incubator?
>
> No but 3rd parties can and someone from the PPMC can act as a 3rd party,
> it must be clear that:
> a) These are produced by a 3rd party and not the PPMC and follow Apache's
> branding and trademark policy.
> b) This is not being used as a mechanism to avoid making Apache releases.
>
I would rephrase to make it clear that 3rd party is anyone who is doing
something in a capacity not as a PPMC member.
>
> 3. Can the PPMC make unapproved releases in their Apache repo after the
> code has been moved to the incubator repo?
>
> No.
>
This is a loaded statement, since PPMC's can never make releases. The IPMC
approves the release always within the scope of Apache.
>
> 4. Can the PPMC make unapproved release in other places after the code has
> been moved to the incubator repo?
>
> No but 3rd parties can. See 2.
>
> 5. Can the PPMC keep two repos and continue to make releases in the non
> Apache one after the code has been moved to the incubator repo?
>
> No but 3rd parties can. See 2. It’s likely that the old repo name may need
> to change to avoid confusion with the Apache project.
>
> 6. Can the PPMC link to unapproved releases or distributions from their
> website or download pages.
>
> No, unless these are clearly marked as 3rd party releases and not endorsed
> by the PPMC.
>
"Yes, as long as they are clearly marked as 3rd party releases and not
endorsed by the PPMC"
>
> 7. When should the first ASF release be made.
>
> Ideally within six months of joining the incubator. Remember this first
> release doesn’t have to be perfect.
>
Personally, I disagree with this statement. I would prefer to see "as soon
as the podling feels ready to do a release"
>
> There may be the occasional exception to these guidelines, this would need
> to be discussed and approved by your mentors and the IPMC informed.
>
> Thanks,
> Justin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>