Re: Clarifying the process for PMCs adopting codebases from the Attic

[Mark Murphy]

Thanks Henk, this covers all of my concerns very well.

On Fri, Jul 20, 2018 at 2:40 AM Henk P. Penning  wrote:

> On Thu, 19 Jul 2018, Bertrand Delacretaz wrote:
>
> > Date: Thu, 19 Jul 2018 14:43:05 +0200
> > From: Bertrand Delacretaz 
> > To: general@attic.apache.org
> > Subject: Clarifying the process for PMCs adopting codebases from the
> Attic
>
> Hi Bertrand,
>
>thanks for your help ; appreciated.
>
> > I just subscribed here - we had a discussion about this at yesterday's
> > Board meeting (thanks Henk for joining that), I think it's good to
> > clarify this and here looks like the best place.
> >
> > IIUC the first occurence that just happened is
> > https://issues.apache.org/jira/browse/ATTIC-169
> >
> > I didn't have a good phone link for that meeting yesterday so might
> > have missed some details but I felt like there was some confusion
> > between "project" and "codebase".
> >
> > IMO, focusing on the adoption of the codebase, while keeping the
> > project's state as "in the Attic" with as few changes as possible
> > helps simplify and clarify what's happening.
> >
> > So here we go, here's a tentative set of principles for PMCs adopting
> > codebases which are currently in the Attic.
> >
> > 1. When a project goes to the Attic, its PMC is terminated, which
> > means that the Apache Project ceases to exist.
> >
> > 2. The project's codebase, on the other hand, continues to exist in
> > the Attic. It's just frozen, so the ASF is not expected for example to
> > provide security fixes for code that's in the Attic.
> >
> > 3. If there's renewed interest in the project, it might be revived by
> > recreating a PMC, either via the Incubator or directly, as happens for
> > top-level projects. I don't think this has happened so far but it
> > feels easy to handle using existing processes.
> >
> > 4. Another option for the *codebase* (or part of it) to become active
> > again is for an existing PMC to adopt it, which is what happened in
> > https://issues.apache.org/jira/browse/ATTIC-169
> >
> > If the above makes sense, I suggest the following (also tentative)
> > rules, assuming the codebase that's in the Attic belonged to project
> > FROM and it's the TO PMC which adopts it.
> >
> > a) TO can adopt the FROM codebase that's in the attic, provided it's
> > not been adopted by a different PMC so far
> >
> > b) Various modules of FROM might be adopted by different PMCs
>
>Re a) and b) ; splitting the codebase complicates matters a lot ;
>it is not "on the [attic] menu" ; it is not the current 'problem'.
>For now, let's not go there.
>Below I assume (regarding codebase) it is "all or nothing".
>
>[ Note that many other PMCs have split the codebase ;
>  for example Hadoop is a split-of of Lucune ;
>]
>
>[ Note that Attic is very reluctant to change the FROM website
>; we've worked hard at not having to touch it
>; The "this project is in the attic" notices on every html pages
>  are generated /outside/ the FROM website (by a lua filter)
>]
>
> > c) For this to happen, a positive vote of the Attic PMC is sufficient,
> > on this list, backed by a JIRA ticket to describe the details and
> > actions
>
>I don't think a possitive Attic vote is sufficient or even required.
>
>As Jim pointed out, the board resolution that terminated FROM,
>also tasked Attic with "oversight over the software [of FROM]" ;
>that is, to freeze it.
>Only another board resolution can relieve Attic of that task,
>and responsibility.
>So, Attic does nothing until Board formally decides.
>If/when Board passes a resolution that moves oversight of the
>codebase from Attic to TO, Attic unatticks FROM.
>
> > d) When that happens, the FROM website is updated to indicate that TO
> > adopted the code, saying something like "The TO PMC has now adopted
> > the FROM codebase", indicating exactly which part(s) of the codebase
> > have been adopted. No other change is made to that website, it remains
> > frozen apart from that note. TO can copy the website content under
> > their own to evolve it, but the original FROM.apache.org domain
> > content must stay as it was when FROM moved to the Attic.
>
>Not applicable if TO "takes all".
>
> > e) The Attic website is updated with that same information
> >
> > f) TO can release the FROM modules that it adopted, using names like
> > TOO-FROM-module-V1.2.3 to differentiate those artifacts from the older
> > ones that FROM released - adding the TOO prefix to their names, both
> > for release archives and things like Java jars, etc.
>
>This is a key-point :
>
>This name change is exactly what POI wanted to avoid ;
>XMLbeans users want (maven-name-space) continuity ; not change.
>The fact that XMLbeans is "under new management" should not be
>visible to users ; project management stuff is an ASF-internal
>thing.
>
>This is the 'Project' vs 'Product' discusion. The ASF presents
>its 

Re: Clarifying the process for PMCs adopting codebases from the Attic

[Mark Murphy]

I don't know why you are trying so hard to keep XMLBeans dead. XMLBeans has
been revived by the POI PMC, not just for benefit of POI, but for whomever
needs updates. The updates benefit everyone, but keeping it in the attic
makes it look dead. This will be confusing to everyone who wants to use it.
There should be no website that says XMLBeans is retired. That will cause
confusion, and makes it look like ASF's left hand doesn't know what he
right hand is doing. I see no difference functionally between XMLBeans
being revived and the codebase being adopted. And there should be no
difference to the Jira or the website. This is being made far too difficult
with no benefit to Apache, but with serious negative repercussions to the
community.

In my mind step d) above is just wrong. Here is why. If I am trying to use
FROM, and looking for information on it, I will likely find FROM.apache.org.
Which will tell me it is dead, but maybe I will find another site under
TO.apache.org that looks almost entirely the same except it claims to be
alive. Now we have competing websites, with no benefit, only confusion. I
don see why that would be put forth as a good idea. F) is a bad idea
because there is no continuity in the Maven repository, and requires
massive refactoring for anyone who uses FROM. I still don't understand the
need to differentiate modules from the original. We don't rename modules
for anything else when the PMC changes. Just pretend the PMC changed for
XMLBeans, and it is revived.

On Thu, Jul 19, 2018 at 8:43 AM Bertrand Delacretaz 
wrote:

> Hi Attic team,
>
> I just subscribed here - we had a discussion about this at yesterday's
> Board meeting (thanks Henk for joining that), I think it's good to
> clarify this and here looks like the best place.
>
> IIUC the first occurence that just happened is
> https://issues.apache.org/jira/browse/ATTIC-169
>
> I didn't have a good phone link for that meeting yesterday so might
> have missed some details but I felt like there was some confusion
> between "project" and "codebase".
>
> IMO, focusing on the adoption of the codebase, while keeping the
> project's state as "in the Attic" with as few changes as possible
> helps simplify and clarify what's happening.
>
> So here we go, here's a tentative set of principles for PMCs adopting
> codebases which are currently in the Attic.
>
> 1. When a project goes to the Attic, its PMC is terminated, which
> means that the Apache Project ceases to exist.
>
> 2. The project's codebase, on the other hand, continues to exist in
> the Attic. It's just frozen, so the ASF is not expected for example to
> provide security fixes for code that's in the Attic.
>
> 3. If there's renewed interest in the project, it might be revived by
> recreating a PMC, either via the Incubator or directly, as happens for
> top-level projects. I don't think this has happened so far but it
> feels easy to handle using existing processes.
>
> 4. Another option for the *codebase* (or part of it) to become active
> again is for an existing PMC to adopt it, which is what happened in
> https://issues.apache.org/jira/browse/ATTIC-169
>
> If the above makes sense, I suggest the following (also tentative)
> rules, assuming the codebase that's in the Attic belonged to project
> FROM and it's the TO PMC which adopts it.
>
> a) TO can adopt the FROM codebase that's in the attic, provided it's
> not been adopted by a different PMC so far
>
> b) Various modules of FROM might be adopted by different PMCs
>
> c) For this to happen, a positive vote of the Attic PMC is sufficient,
> on this list, backed by a JIRA ticket to describe the details and
> actions
>
> d) When that happens, the FROM website is updated to indicate that TO
> adopted the code, saying something like "The TO PMC has now adopted
> the FROM codebase", indicating exactly which part(s) of the codebase
> have been adopted. No other change is made to that website, it remains
> frozen apart from that note. TO can copy the website content under
> their own to evolve it, but the original FROM.apache.org domain
> content must stay as it was when FROM moved to the Attic.
>
> e) The Attic website is updated with that same information
>
> f) TO can release the FROM modules that it adopted, using names like
> TOO-FROM-module-V1.2.3 to differentiate those artifacts from the older
> ones that FROM released - adding the TOO prefix to their names, both
> for release archives and things like Java jars, etc.
>
> g) Java package names etc. can remain as they were, for convenience
>
> How does this sound?
>
> Maybe this is how ATTIC-169 has been handled, though the note at
> http://attic.apache.org/ saying that XMLBeans was "revived" can be
> understood as the project getting back to life which is not the case
> IMO - it's only the codebase that's been adopted.
>
> Also, I don't see an Attic mention at http://xmlbeans.apache.org/ and
> I think that's not good as per d) above.
>
> -Bertrand
>

Re: new PMC for xmlbeans

[Mark Murphy]

According to Maven Central, there are 495 artifacts with dependencies on
XMLBeans. Many of the projects have last update dates in the last year.
This is compared with Apache POI which is used by 795 artifacts. It seems
usage of XMLBeans is still significant.

On Fri, Mar 2, 2018 at 3:25 PM, Craig Russell  wrote:

> A project is not just code. In addition to the community (duh), there are
> web pages, mail lists, reporting requirements, issue management,
> build/release tooling, and various infra bits that need to be maintained.
>
> I agree with Jan that if POI is the only project that (currently) uses
> Xmlbeans, it will be far easier to "simply" import whatever is relevant
> from the project directly into POI. And if it makes life easier, you can
> even repackage (rename) the build artifacts.
>
> Craig
>
> > On Mar 2, 2018, at 6:17 AM, Jan Iversen  wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On 2 Mar 2018, at 14:59, PJ Fanning 
> wrote:
> >>
> >> Apache POI is used by Apache Tika and Apache SOLR.
> >> The XmlBeans build is pretty complicated and outdated and changing its
> package names is going to be fairly hard (in short, XmlBeans is used to
> autogenerate some of the code shipped in XmlBeans).
> > The question was not who uses POI, but who would also (if any) use
> XmlBeans.
> >
> > The beauty of my proposal is that you do not need to change naming or
> other stuff. You simply put it in your codebase in a separate directory.
> The reason is that you do not release XmlBeans, you release POI containing
> (not using, as you have been doing) XmlBeans.
> >
> > In case you want to restart the project, you need to change name as well
> as go through the process of asking to be a TLP.
> >
> > rgds
> > jan i
> >
> >>
> >>   On Monday 26 February 2018, 20:07:49 GMT, PJ Fanning <
> fannin...@yahoo.com> wrote:
> >>
> >> Hi,
> >> There is general interest in the Apache POI PMC and general Contributor
> community in forming a new PMC for Apache XMLBeans. POI has a dependency on
> XMLBeans and there are some fixes that we would like to apply to
> XMLBeans.Some of the discussion appears in these threads.
> >> http://apache-poi.1045710.n5.nabble.com/publishing-poi-
> xmlbeans-jars-td5730234.html
> >> http://apache-poi.1045710.n5.nabble.com/DISCUSS-Getting-a-
> fixed-version-of-XMLBeans-td5729378.htmlhttp://apache-
> poi.1045710.n5.nabble.com/XMLBeans-in-4-0-0-release-td5729862.html
> >>
> >>
> >> If we can get 3 or more people to form a new XMLBeans PMC, would it be
> feasible to reopen the XMLBeans svn for new commits?
> >> Regards,PJ
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>