Re: [DISCUSS] Attic Contribution process to newbie
Git mirror ready: https://github.com/apache/attic-site let the PRs flow... On 2022/07/05 07:14:38 Brahma Reddy Battula wrote: > On Tue, 5 Jul 2022 at 12:11 PM, Herve Boutemy wrote: > > > I improved the Attic main page to clarify the 2 main options to leave the > > Attic > > = fork outside ASF or recreate at ASF > > Clearly, the previous flat 4 options were not helping at they should > > > > on helping with Attic site, svn does not help much providing patches: I'll > > ask infra to create a svn2git mirror so we'll be able to get PRs > > We'll see later if/how we switch to Git first: this will at least imply to > > change CI and site publication, perhaps other automation, so we need to go > > step by step > > > Thanks Herve, this will be helpful… > > > > > > > On documenting the mechanical steps to bringing back a project, I feel > > that it won't be used much, then will not be ready when necessary (in 5 > > years?). > > Sebb created ATTIC-206 for the only real problem we had: removing files in > > the site has currently to be manual, it would be nice if it could be > > automatic. > > Everything else is really just undoing what was done during the move to > > Attic, and is so exceptional that I don't see much value in writing. > > But once we have a Git mirror, this will provide PRs and review process, > > perhaps there will be good PRs proposed, finding the right balance > > > > Regards, > > > > Hervé > > > > On 2022/07/04 07:14:12 Roman Shaposhnik wrote: > > > On Mon, Jul 4, 2022 at 9:57 AM Brahma Reddy Battula > > wrote: > > > > > > > > Hi All, > > > > > > > > I recently came across one scenario where a project (ambari) is > > revived and > > > > became the TLP. > > > > > > > > As this was not covered in the attic site[1], I would like to update > > in the > > > > following[2] doc with the something like following for future > > > > reference.(Might not very critical but i feel it's better to have as > > doc > > > > persist longer) > > > > > > > > " TLP project can be revived as TLP again if three ASF members are > > > > involved to bring it back". > > > > > > > > > > > > Currently the contribution process is unknown to me as the attic is > > based > > > > on SVN, any pointers here..? > > > > and any chance to move to git..? > > > > > > > > > > > > 1.https://attic.apache.org/ > > > > > > > > 2. > > https://svn.apache.org/viewvc/attic/site/xdocs/index.xml?view=markup > > > > > > To pile on top of what Brahma is saying, I'd like to suggest we > > > document all the mechanical steps of bringing a project back to > > > mirror: > > > https://attic.apache.org/process.html > > > but in reverse. > > > > > > WDYAT? > > > > > > Thanks, > > > Roman. > > > > > > -- > > > > --Brahma Reddy Battula >
Re: [DISCUSS] Attic Contribution process to newbie
On Tue, 5 Jul 2022 at 12:11 PM, Herve Boutemy wrote: > I improved the Attic main page to clarify the 2 main options to leave the > Attic > = fork outside ASF or recreate at ASF > Clearly, the previous flat 4 options were not helping at they should > > on helping with Attic site, svn does not help much providing patches: I'll > ask infra to create a svn2git mirror so we'll be able to get PRs > We'll see later if/how we switch to Git first: this will at least imply to > change CI and site publication, perhaps other automation, so we need to go > step by step Thanks Herve, this will be helpful… > > On documenting the mechanical steps to bringing back a project, I feel > that it won't be used much, then will not be ready when necessary (in 5 > years?). > Sebb created ATTIC-206 for the only real problem we had: removing files in > the site has currently to be manual, it would be nice if it could be > automatic. > Everything else is really just undoing what was done during the move to > Attic, and is so exceptional that I don't see much value in writing. > But once we have a Git mirror, this will provide PRs and review process, > perhaps there will be good PRs proposed, finding the right balance > > Regards, > > Hervé > > On 2022/07/04 07:14:12 Roman Shaposhnik wrote: > > On Mon, Jul 4, 2022 at 9:57 AM Brahma Reddy Battula > wrote: > > > > > > Hi All, > > > > > > I recently came across one scenario where a project (ambari) is > revived and > > > became the TLP. > > > > > > As this was not covered in the attic site[1], I would like to update > in the > > > following[2] doc with the something like following for future > > > reference.(Might not very critical but i feel it's better to have as > doc > > > persist longer) > > > > > > " TLP project can be revived as TLP again if three ASF members are > > > involved to bring it back". > > > > > > > > > Currently the contribution process is unknown to me as the attic is > based > > > on SVN, any pointers here..? > > > and any chance to move to git..? > > > > > > > > > 1.https://attic.apache.org/ > > > > > > 2. > https://svn.apache.org/viewvc/attic/site/xdocs/index.xml?view=markup > > > > To pile on top of what Brahma is saying, I'd like to suggest we > > document all the mechanical steps of bringing a project back to > > mirror: > > https://attic.apache.org/process.html > > but in reverse. > > > > WDYAT? > > > > Thanks, > > Roman. > > > -- --Brahma Reddy Battula
Re: [DISCUSS] Attic Contribution process to newbie
I improved the Attic main page to clarify the 2 main options to leave the Attic = fork outside ASF or recreate at ASF Clearly, the previous flat 4 options were not helping at they should on helping with Attic site, svn does not help much providing patches: I'll ask infra to create a svn2git mirror so we'll be able to get PRs We'll see later if/how we switch to Git first: this will at least imply to change CI and site publication, perhaps other automation, so we need to go step by step On documenting the mechanical steps to bringing back a project, I feel that it won't be used much, then will not be ready when necessary (in 5 years?). Sebb created ATTIC-206 for the only real problem we had: removing files in the site has currently to be manual, it would be nice if it could be automatic. Everything else is really just undoing what was done during the move to Attic, and is so exceptional that I don't see much value in writing. But once we have a Git mirror, this will provide PRs and review process, perhaps there will be good PRs proposed, finding the right balance Regards, Hervé On 2022/07/04 07:14:12 Roman Shaposhnik wrote: > On Mon, Jul 4, 2022 at 9:57 AM Brahma Reddy Battula wrote: > > > > Hi All, > > > > I recently came across one scenario where a project (ambari) is revived and > > became the TLP. > > > > As this was not covered in the attic site[1], I would like to update in the > > following[2] doc with the something like following for future > > reference.(Might not very critical but i feel it's better to have as doc > > persist longer) > > > > " TLP project can be revived as TLP again if three ASF members are > > involved to bring it back". > > > > > > Currently the contribution process is unknown to me as the attic is based > > on SVN, any pointers here..? > > and any chance to move to git..? > > > > > > 1.https://attic.apache.org/ > > > > 2. https://svn.apache.org/viewvc/attic/site/xdocs/index.xml?view=markup > > To pile on top of what Brahma is saying, I'd like to suggest we > document all the mechanical steps of bringing a project back to > mirror: > https://attic.apache.org/process.html > but in reverse. > > WDYAT? > > Thanks, > Roman. >
Re: [DISCUSS] Attic Contribution process to newbie
On Mon, Jul 4, 2022 at 9:57 AM Brahma Reddy Battula wrote: > > Hi All, > > I recently came across one scenario where a project (ambari) is revived and > became the TLP. > > As this was not covered in the attic site[1], I would like to update in the > following[2] doc with the something like following for future > reference.(Might not very critical but i feel it's better to have as doc > persist longer) > > " TLP project can be revived as TLP again if three ASF members are > involved to bring it back". > > > Currently the contribution process is unknown to me as the attic is based > on SVN, any pointers here..? > and any chance to move to git..? > > > 1.https://attic.apache.org/ > > 2. https://svn.apache.org/viewvc/attic/site/xdocs/index.xml?view=markup To pile on top of what Brahma is saying, I'd like to suggest we document all the mechanical steps of bringing a project back to mirror: https://attic.apache.org/process.html but in reverse. WDYAT? Thanks, Roman.
[DISCUSS] Attic Contribution process to newbie
Hi All, I recently came across one scenario where a project (ambari) is revived and became the TLP. As this was not covered in the attic site[1], I would like to update in the following[2] doc with the something like following for future reference.(Might not very critical but i feel it's better to have as doc persist longer) " TLP project can be revived as TLP again if three ASF members are involved to bring it back". Currently the contribution process is unknown to me as the attic is based on SVN, any pointers here..? and any chance to move to git..? 1.https://attic.apache.org/ 2. https://svn.apache.org/viewvc/attic/site/xdocs/index.xml?view=markup --Brahma Reddy Battula -- --Brahma Reddy Battula
Re: reviewing our detailed process instructions
Le vendredi 14 mai 2021, 13:59:22 CEST sebb a écrit : > On Fri, 14 May 2021 at 06:34, Hervé BOUTEMY wrote: > > Hi all, > > > > I just finished Trafodion's move to Attic: it was a lot easier than 1 year > > ago, being helped by 2 nice scripts. But the process documentation did > > not mention these scripts, then showed previous complexity. > > > > I updated the documentation to take these scripts into account. Please > > review http://attic.apache.org/process.html > > To me, there is only the DOAP file line that we need to choose if it's for > > Attic PMC or for ComDev > > Do you mean: whose responsibility is updating the DOAP file? > Whilst Attic could offload that to ComDev, Attic would still have to > ensure it was done. > It's much easier for Attic to do it; only committer karma is needed. the karma part was the info I was missing: I wanted to be sure anybody in the Attic could do the job then no problem, you're right, much easier as part of Attic move > > > On next project retirement, it would be great to have someone new trying > > to > > follow the instructions to make sure everything is clear: any volunteer? > > Good idea. > > > Regards, > > > > Hervé
Re: reviewing our detailed process instructions
On Fri, 14 May 2021 at 06:34, Hervé BOUTEMY wrote: > > Hi all, > > I just finished Trafodion's move to Attic: it was a lot easier than 1 year > ago, > being helped by 2 nice scripts. But the process documentation did not mention > these scripts, then showed previous complexity. > > I updated the documentation to take these scripts into account. Please review > http://attic.apache.org/process.html > To me, there is only the DOAP file line that we need to choose if it's for > Attic PMC or for ComDev Do you mean: whose responsibility is updating the DOAP file? Whilst Attic could offload that to ComDev, Attic would still have to ensure it was done. It's much easier for Attic to do it; only committer karma is needed. > On next project retirement, it would be great to have someone new trying to > follow the instructions to make sure everything is clear: any volunteer? Good idea. > Regards, > > Hervé > >
reviewing our detailed process instructions
Hi all, I just finished Trafodion's move to Attic: it was a lot easier than 1 year ago, being helped by 2 nice scripts. But the process documentation did not mention these scripts, then showed previous complexity. I updated the documentation to take these scripts into account. Please review http://attic.apache.org/process.html To me, there is only the DOAP file line that we need to choose if it's for Attic PMC or for ComDev On next project retirement, it would be great to have someone new trying to follow the instructions to make sure everything is clear: any volunteer? Regards, Hervé
Re: Clarifying the process for PMCs adopting codebases from the Attic
On Mon, 23 Jul 2018, Ralph Goers wrote: Date: Mon, 23 Jul 2018 15:24:58 +0200 From: Ralph Goers To: general@attic.apache.org Subject: Re: Clarifying the process for PMCs adopting codebases from the Attic On Jul 23, 2018, at 1:47 AM, Bertrand Delacretaz wrote: As for having a Board decision when reviving a project, that probably makes sense for symmetry with the Board resolution that moved the project to the Attic. But I don't think the Board necessarily needs to be involved in the discussions that lead to that resolution, I think the Attic PMC can simply add a resolution to the Board agenda as needed, and the Board just ratifies it. There is no symmetry. The board terminated the PMC and gave its assets to the attic to manage. The board passed a resolution saying : RESOLVED, that the Attic PMC be and hereby is tasked with oversight over the software developed by the Apache X Project; and My question is : can Attic 'un-task' itself, or is a board resolution required ? If a resolution is required, board might as well (symmetry) task the new PMC with "oversight over ...". Since you (rightly, in my view) broaden "the software" to "all assets", the resolution would effectively move the PROJECT (== all assets) to another PMC. The board is NOT reinstating a PMC or creating a new one. True. Once the attic owns the assets it should be free to assign those assets to any PMC willing to manage them. Ralph 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 Utrecht, NL F +31 30 253 4553 \_/ \_/ http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
Re: Clarifying the process for PMCs adopting codebases from the Attic
> On Jul 23, 2018, at 1:47 AM, Bertrand Delacretaz > wrote: > > As for having a Board decision when reviving a project, that probably > makes sense for symmetry with the Board resolution that moved the > project to the Attic. But I don't think the Board necessarily needs to > be involved in the discussions that lead to that resolution, I think > the Attic PMC can simply add a resolution to the Board agenda as > needed, and the Board just ratifies it. There is no symmetry. The board terminated the PMC and gave its assets to the attic to manage. The board is NOT reinstating a PMC or creating a new one. Once the attic owns the assets it should be free to assign those assets to any PMC willing to manage them. Ralph
Re: Clarifying the process for PMCs adopting codebases from the Attic
On Mon, 23 Jul 2018, Bertrand Delacretaz wrote: Date: Mon, 23 Jul 2018 10:47:59 +0200 From: Bertrand Delacretaz To: general@attic.apache.org Subject: Re: Clarifying the process for PMCs adopting codebases from the Attic Hi Bertrand, thanks for the notes. On Fri, Jul 20, 2018 at 6:40 AM Henk P. Penning wrote: ... 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... Ok, I think this is where we see things from a different angle. I agree with you from the user's perspective, a seamless change is useful. From the Foundation's governance point of view however, by default a project found at foo.apache.org is governed by the foo PMC. If that's not the case, like here, I think there should be a clear note like "XMLBeans is managed by the Apache POI PMC" on all pages of http://xmlbeans.apache.org/ . A small thing in the site's footer is good enough IMO. Fine ; maintaining xmlbeans.apache.org is the receiving PMC's (POI)'s business, but we can add it to the list, of course. It looks like "the codebase" and the (Maven-name-space) 'GroupId' are very closely related. Whoever 'owns' "the codebase", has the right to publish releases using the GroupId. Is this something that is always true ? The Board has to manage about 180 PMC and 300 projects if i remember correctly, so it's important to have clarity there. It's a small thing that can be added to the Attic's documentation on how to revive codebases. Clarity is vitally important ; and it is lacking in spades. As for having a Board decision when reviving a project, that probably makes sense for symmetry with the Board resolution that moved the project to the Attic. But I don't think the Board necessarily needs to be involved in the discussions that lead to that resolution, I think the Attic PMC can simply add a resolution to the Board agenda as needed, and the Board just ratifies it. Attic implements board resolutions ; I think it is as simple as that. Before the move, Attic is not involved. In Attic, there is nothing to discuss, or vote upon. It is upto the board to decide if the move is ok ; that's not Attic's business. -Bertrand Groeten, HPP _ 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 \_/
Re: Clarifying the process for PMCs adopting codebases from the Attic
Hi, On Fri, Jul 20, 2018 at 6:40 AM Henk P. Penning wrote: > ... 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... Ok, I think this is where we see things from a different angle. I agree with you from the user's perspective, a seamless change is useful. >From the Foundation's governance point of view however, by default a project found at foo.apache.org is governed by the foo PMC. If that's not the case, like here, I think there should be a clear note like "XMLBeans is managed by the Apache POI PMC" on all pages of http://xmlbeans.apache.org/ . A small thing in the site's footer is good enough IMO. The Board has to manage about 180 PMC and 300 projects if i remember correctly, so it's important to have clarity there. It's a small thing that can be added to the Attic's documentation on how to revive codebases. As for having a Board decision when reviving a project, that probably makes sense for symmetry with the Board resolution that moved the project to the Attic. But I don't think the Board necessarily needs to be involved in the discussions that lead to that resolution, I think the Attic PMC can simply add a resolution to the Board agenda as needed, and the Board just ratifies it. HTH, -Bertrand
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
Re: Clarifying the process for PMCs adopting codebases from the Attic
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
Re: Clarifying the process for PMCs adopting codebases from the Attic
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 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"
Re: Clarifying the process for PMCs adopting codebases from the Attic
On Thu, 19 Jul 2018, Mark Murphy wrote: Date: Thu, 19 Jul 2018 17:55:51 +0200 From: Mark Murphy To: general@attic.apache.org Subject: Re: Clarifying the process for PMCs adopting codebases from the Attic 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. I agree ; what has actually happened is that project XMLbeans moved from : pmc XMLbeans ; state : active via : pmc Attic; state : retired to : pmc Poi ; state : active The fact that project XMLbeans was, for a while, "retired" is just an not-too-important, historic fact. For the future : if/when a PMC wants to take over an atticked codebase, a board resolution is required (in my view ; this is still being discussed), simply because a board resolution tasked Attic with management of the codebase, and only another board resolution can undo that. The point is that in the XMLbeans case, Poi wanted more than just the codebase ; it wanted everything ; fine. Since the board has to pass a resolution for the codebase-ownership, it might as well approve the revival of the /project/ (and all resources associated with it), and task the TO-PMC with managing the revived project. Apart from the (hopefully coming soon) board resolution, this was effectively done ; and everybody is happy, I think. I think that a PMC can't just take over just the codebase (without the responsibilities that come with running a project). They can fork, but the official codebase remains frozen ; this is just my opinion ; it is unexplored teritory. Regards, Henk Penning 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
Re: Clarifying the process for PMCs adopting codebases from the Attic
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 >
Clarifying the process for PMCs adopting codebases from the Attic
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: process
On Fri, 13 Apr 2018, Jan Iversen wrote:
Date: Fri, 13 Apr 2018 08:35:23 +0200
From: Jan Iversen <jancasacon...@gmail.com>
To: Henk P. Penning <penn...@uu.nl>
Cc: general@attic.apache.org
Subject: Re: process
Hi Jan,
Done.
Nice work !
Thanks.
typo : touch docsflagged => docs/flagged
Perhaps change :
Create directory to signal project is moved to Attic
into
Signal that retired banners must be added to ${project}.a.o.
[ because, older retirees already have banners
and shouldn't be 'flagged'.
]
Jan I
Thanks ; regards,
HPP
_
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 \_/
On 13 Apr 2018, at 07:46, Henk P. Penning <penn...@uu.nl> wrote:
Hi Jan,
can you please update the 'process page' ?
-- after 2.5 "Create project page ..." add (as one bullit) :
mkdir flagged/${project}.apache.org ;
touch flagged/${project}.apache.org/${project}.apache.org
-- remove 2.6.i "Update website with Attic notice: ..."
FYI,
-- The layout of the 'flagged' directory is not yet fixed.
-- perhaps we'll use it to augment it with (per project)
meta info, quickly accessible by httpd/lua.
Thanks ; groeten,
HPP
_
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 \_/
Documented: Process for moving into the Attic
See http://attic.apache.org/process.html for a document on how to move a project into the Attic. Feel free to beat it up :) Hen
Re: Process for moving a project to the Attic
On Jan 6, 2009, at 7:04 AM, Ralph Goers wrote: On Jan 6, 2009, at 1:54 AM, Henri Yandell wrote: I think the path lies in between the two views. We're not out to kill user lists outright imo. A project becomes viable for the Attic when it has no developer community. It may still have user community and part of the point of having the Attic is to be more transparent to that user community that they're on their own. Keeping some level of resource open to them is valuable I think - in themselves a user list provides a community that can support itself and knowing the dev community is dead may kick them into doing something. That may be at SourceForge, it may be in the Incubator, but it's better than the slow heat-death that projects usually go through. However - we're not here to maintain that user community. We're fully expecting the list to quieten down if it's not already quiet. We need use cases to really figure this stuff out. The only cost to keeping the user list alive is that it will still need moderators. I have no problem volunteering to moderate a low traffic list. Sign me up. I think it would be much easier if users could be redirected to an attic users list that we could moderate. This would be similar to commons where the subject in a post is supposed to reflect the subproject. +1 It would send a good message if we were to rename lists similar to what we use for incubating projects: project-...@attic.apache.org. Traffic sent to dev@ or user@ project.apache.org would be redirected to the attic mailing lists. What would be even better is if when they post to the dead project's mailing list if that project name could automatically be tacked on to the subject. +1 Craig Ralph Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp!
