Re: no projects in the Attic
I like that there is no project in the Attic: there is only static codebases (and other types of assets like mailing lists or sites), with nobody to make them evolve, then no project (project means evolution) IMHO, recreating frozen projects is not a good idea it's a question of wording to better represent the semantic behind Attic: project = codebase + community to make it evolve and a PMC to manage the evolution we should perhaps rephrase: a project is not Attic'ed, but a former project's codebase (+ site + mailing lists) is Attic'ed because community disappeared Regards, Hervé Le vendredi 20 juillet 2018, 09:45:47 CEST Henk P. Penning a écrit : > Hi Attic, > >FYI ; for the record. > >Last wednesday I attended the Board meeting ; >this is recommended for new chairs ; also, >the board would discuss Attic's last report. > >To my surprise I've learned that formally >there are no "projects in the Attic". > >The reason is that the board resolution that terminates >a PMC, also terminates the Project. Because the project >does not (formally) exist, it can't be in the Attic ; >so, there are no projects in the Attic. > >This (formal) worldview is at variance with our charter, >and it is not how we work, or what we present to the world. > >So, I took the liberty to ask the board to >-- pass a resolution (see below, lines marked with '*') > which (formally) re-establishes 'our' projects again, >-- in the future, move projects into the Attic, > instead of terminating them >so we can keep on working as we have upto now. > >I hope the board will accept this ; it would erase >the difference between the 'formal' worldview, >and what we do and present to the world. > >Regards, > >Henk Penning > >PS : I hope I didn't violate accepted procedure ; >If not, I hope this post will correct that. > > _ > Henk P. Penning, ICT-beta R Uithof MG-403_/ \_ > Faculty of Science, Utrecht UniversityT +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 \_/ > > -- Forwarded message -- > Date: Thu, 19 Jul 2018 21:11:03 +0200 > From: Henk P. Penning > To: Apache Board > Subject: Re: XMLBeans => POI and decision making > > On Thu, 19 Jul 2018, Jim Jagielski wrote: > > Date: Thu, 19 Jul 2018 13:05:54 +0200 > > From: Jim Jagielski > > To: Apache Board > > Subject: Re: XMLBeans => POI and decision making > > > > As the canonical sources of truth, board resolutions are pretty high > > on the list. If a board resolution, which was voted on and passed by > > the board, says that a project was terminated, well, it was terminated. > >Great ; that's clear. > > The (formal) 'truth' is that, at the moment, PMC Attic > is tasked with "oversight over the software developed > by the Apache XMLBeans Project" [Board minutes 17 Jul 2013] > https://whimsy.apache.org/board/minutes/XMLBeans.html > > I think I must ask the board to pass a resolution effectively > relieving PMC Attic of this task, because the XMLbeans > codebase is now managed by PCM Poi. > > > For convenience referring to Apache Foo as being moved to > > the Attic or lumping (ex) projects under Apache Attic is simply > > that... convenience. It is much easier to say "Apache Foo is > > now in the Attic" (colloquial) than "The Apache Foo project no > > longer exists but the codebase which comprised the project > > is now under the official oversight of the Apache Attic and the > > software can be found there". > > * The discrepancy 'truth' vs 'colloquial' is ... inconvenient, > * and confusing for many people. It can me remedied easily. > > * I propose that the board passes a resolution which > * -- establishes (retired) projects : > * -- "Apache Abdera Project" > * -- "Apache ACE Project" > * -- "Apache Avalon Project" > * -- ... > * -- "Apache XML Project" > * -- tasks PMC "Apache Attic Project" with the oversight the projects > * -- pursuant to bylaws of the Foundation > > * In the future, the board 'termination' resolution should > *-- terminate the PMC XXX [as is usual] > *-- terminate the office of "VP, Apache XXX" [as is usual] > *-- task PMC Attic with the oversight of Project XXX > > * Note that this : > *... merely sanctions current, established, accepted practice > *... cleans up the process, a little > *... hopefully avoids some endless, confused discussions in the future > >Thanks ; regards, > >Henk Penning > > _ > Henk P. Penning, ICT-beta R Uithof MG-403_/ \_ > Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \ > Leuvenlaan 4, 3584CE
Re: Clarifying the process for PMCs adopting codebases from the Attic
+1 to most parts the only part that I'd prefer to keep simple is the Board vote vs Attic vote: this is exactly the type of vote we tried to get from Board when digging into XMLBeans details and got as answer "just do it" Which is sufficient to me: we don't create any new project (= a new community and a new PMC), but merge a disappeared community into a live community IMHO, project = codebase + community + PMC a board vote is useful for a new project because it represents a new community then a new PMC When a community and its PMC create a new "internal" project, also called sub- project, the PMC does not ask any vote from board. notice: I won't fight against a Board vote: the next time, since Board will better know what it votes about, the vote will just be a formal approval "from the top of ASF" I like Bertrands's summary start: once consensus on the end is ok and process (board vote or not), this is exactly what we could keep in Attic site to document this scenario Regards, Hervé Le vendredi 20 juillet 2018, 13:50:38 CEST Mark Murphy a écrit : > 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 > >
