On Thu, 19 Jul 2018, Bertrand Delacretaz wrote:
Date: Thu, 19 Jul 2018 14:43:05 +0200
From: Bertrand Delacretaz <[email protected]>
To: [email protected]
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 products divided by organisation-lines (PMCs) ; in general,
that is bad idea. It is hard to fix, because of the way the ASF
is managed (strongly independent PMC's).
g) Java package names etc. can remain as they were, for convenience
Not applicable if TO "takes all".
How does this sound?
I think the "TO takes all" (as was done in the POI/XMLbeans case)
works well ; I see no problems in the future, should it happen again.
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
Thanks ; regards,
Henk Penning
------------------------------------------------------------ _
Henk P. Penning, ICT-beta R Uithof MG-403 _/ \_
Faculty of Science, Utrecht University T +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M [email protected] \_/
