Thanks Henk, this covers all of my concerns very well. On Fri, Jul 20, 2018 at 2:40 AM Henk P. Penning <penn...@uu.nl> wrote:
> On Thu, 19 Jul 2018, Bertrand Delacretaz wrote: > > > Date: Thu, 19 Jul 2018 14:43:05 +0200 > > From: Bertrand Delacretaz <bdelacre...@apache.org> > > 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 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 penn...@uu.nl \_/ >
