Re: no projects in the Attic
On 23 July 2018 at 15:12, Henk P. Penning wrote: > On Sat, 21 Jul 2018, Hervé BOUTEMY wrote: > >> Date: Sat, 21 Jul 2018 19:17:03 +0200 >> From: Hervé BOUTEMY >> To: general@attic.apache.org >> Subject: 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 > > > ... now separate PMC and PROJECT PMC == Project Management Committee. i.e. the committee that manages one or more projects. A project is "an individual or collaborative enterprise that is planned to achieve a particular aim." i.e. it is a group of people (committers) working on a particular product (code-base). A PMC exists to coordinate the projects under its control. There may be several projects which may overlap in terms of personnel. e.g. Creadur has RAT, Tentacles, Whisker There are 3 projects working to produce separate products; some people may work on all 3, some on only one Similarly in Commons there are a lot of products. Many of them are no longer active and the product is marked 'Dormant', i.e. there is no longer a project team which is producing that product. > -- it is the PMC that has a 'community' >(members, committers, developers, users) > -- a PROJECT (as an entity on it's own) has no community ; > if/when a PROJECT moves from one PMC to another, > it happily lives on, cared for by another community I disagree - it is the product (code-base) that lives on as part of another project. The new project may have different aims from the original project. e.g. I imagine the project team developing XMLBeans as part of POI will (mainly) focus on the parts that relate to POI. > evolution : > > -- when a project enters the Attic, >we 'evolve' it to a 'retired' project There is no project at this point. > -- then we wait for it to be revived ; >if/when that happens, we 'evolve' the project some more : >we 'revive' it in some other PMC. > > I maintain that this is a consistent world-view. > > 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 \_/ > >> 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. >>> >>> --
Re: no projects in the Attic
On Sat, 21 Jul 2018, Hervé BOUTEMY wrote: Date: Sat, 21 Jul 2018 19:17:03 +0200 From: Hervé BOUTEMY To: general@attic.apache.org Subject: 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 ... now separate PMC and PROJECT -- it is the PMC that has a 'community' (members, committers, developers, users) -- a PROJECT (as an entity on it's own) has no community ; if/when a PROJECT moves from one PMC to another, it happily lives on, cared for by another community evolution : -- when a project enters the Attic, we 'evolve' it to a 'retired' project -- then we wait for it to be revived ; if/when that happens, we 'evolve' the project some more : we 'revive' it in some other PMC. I maintain that this is a consistent world-view. 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 \_/ 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 : * -
Re: no projects in the Attic
Hi,
Le dimanche 22 juillet 2018, 08:21:38 CEST Henk P. Penning a écrit :
> On Sat, 21 Jul 2018, Hervé BOUTEMY wrote:
> > Date: Sat, 21 Jul 2018 19:17:03 +0200
> > From: Hervé BOUTEMY
> > To: general@attic.apache.org
> > Subject: Re: no projects in the Attic
>
> Hi,
>
> > 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)
>
>I like 'project x is in the attic' (but I won't be stubborn :-).
>
>I like the idea of 'project' as a (separate) object that
>-- is created by Incubator ; may die in Incubator
>-- can move from PMC to PMC ;
> graduation : project -> move ( Incubator, Parent )
> retirement : project -> move ( Parent, Attic )
> reviving : project -> move ( Attic, Parent )
>-- board ok's the moves
>
>A Project has more attributes than (pointer to) 'codebase' ;
>like name, description, website, logo, trademark, MavenId (?) etc.
>Even "in the attic", a project has more 'presence' than
>just 'codebase'.
yes, a project has many assets: codebase is only one
(notice: we talk about Maven coordinates, and yes, Maven coordinates are a
great asset since people often consume the software through these coordinates)
>In fact, an Attic project is just a project without a 'community'.
>
>[ Why do you say "project means evolution" ?
>; That is what everybody seems to think :-),
> but I don't get it ; hence, I won't stubborn
>; Can you please explain that for me ?
>]
yes, this is important:
to be more precise, project means intent of evolution
in plain english (without software in mind), when you have projects, you want
to do something in the future. And when you don't expect anything, you don't
have any project.
In software, from IDE's inception, everything is "project": IDE's "project"
term is the most less adapted, even if you use your IDE because you want to
have an evolution in your software
Then back to Attic: when a former project goes to Attic, it's because it has
lost his community and its intent of evolution (even just bugfix), then what
board really vote on is to drop the PMC which is what used to manage the
evolution = the project that the community had with the codebase.
And the intent of Attic is really to not make any evolution: what goes to
Attic is frozen assets from former project, but no project to make any
evolution, just keep every asset perfectly frozen and whatever is necessary to
keep them available without any real evolution (just technical moves if
necessary, like platform migration)
>
> > 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
>-- I think 'project X' is always the same thing ;
> some of it's attributes my change from time to time.
>
>-- PMCs Incubator and Attic are like other PMCs,
> except that they have special rules for managing projects.
>
>-- Remember the 'Project' versus 'Product' discussion ?
> A 'Product' is just the public facing side of a 'Project' ;
> same object, different presentation.
>
>-- When the board kills a product, it is taken of the shelves,
> but it is/was still a 'product' ('not available, at the moment').
>
>I think the above is a clean, clear design ; easy to explain,
>easy to document, and easy to implement (put in a database).
>
>For a fresh look, please read the above again ;
>read 'product' where it says 'project' :-).
the only point in time when this dos not really work is when some assets are
un-Attic'ed to an existing community + PMC, to be added to the intent of their
project: or we're back to TLP vs sub-project terms, which starts a long
discussion...
I could understand that the ASF does not want to give Attic the power to give
assets to an existing PMC, then want the board to decide before letting Attic
PMC do the give-away. But there is no PMC creation ("known as XXX project"),
just an exising project that gets more code, more "sub-projects": the fact
that the origin of the new code is internal to the ASF should make it even
more simple than when new code comes from outside
Regards,
Hervé
>
> > Hervé
>
>Groeten,
>
>HPP
>
> --
Re: no projects in the Attic
On Sat, 21 Jul 2018, Hervé BOUTEMY wrote:
Date: Sat, 21 Jul 2018 19:17:03 +0200
From: Hervé BOUTEMY
To: general@attic.apache.org
Subject: Re: no projects in the Attic
Hi,
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)
I like 'project x is in the attic' (but I won't be stubborn :-).
I like the idea of 'project' as a (separate) object that
-- is created by Incubator ; may die in Incubator
-- can move from PMC to PMC ;
graduation : project -> move ( Incubator, Parent )
retirement : project -> move ( Parent, Attic )
reviving : project -> move ( Attic, Parent )
-- board ok's the moves
A Project has more attributes than (pointer to) 'codebase' ;
like name, description, website, logo, trademark, MavenId (?) etc.
Even "in the attic", a project has more 'presence' than
just 'codebase'.
In fact, an Attic project is just a project without a 'community'.
[ Why do you say "project means evolution" ?
; That is what everybody seems to think :-),
but I don't get it ; hence, I won't stubborn
; Can you please explain that for me ?
]
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
-- I think 'project X' is always the same thing ;
some of it's attributes my change from time to time.
-- PMCs Incubator and Attic are like other PMCs,
except that they have special rules for managing projects.
-- Remember the 'Project' versus 'Product' discussion ?
A 'Product' is just the public facing side of a 'Project' ;
same object, different presentation.
-- When the board kills a product, it is taken of the shelves,
but it is/was still a 'product' ('not available, at the moment').
I think the above is a clean, clear design ; easy to explain,
easy to document, and easy to implement (put in a database).
For a fresh look, please read the above again ;
read 'product' where it says 'project' :-).
Hervé
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 \_/
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
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 san
no projects in the Attic
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 Utrecht, NL F +31 30 253 4553 \_/ \_/ http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/ As for the POI stuff, well, IMHO POI lacks the ability and power and authority to "unretire" XMLBeans: XMLBeans was not "retired". It was terminated (https://www.apache.org/foundation/records/minutes/2013/board_minutes_2013_07_17.txt). That was an action by the board. A PMC can not reverse nor overturn that on its own. Also, the binding of a project and a PMC is also something that the bylaws clearly state (Section 6.3)[1] is something that must be done by the board and via a resolution. 1: "Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors"
Re: Moving projects to the Attic
On Thu, 16 Jan 2014, sebb wrote:
Date: Thu, 16 Jan 2014 00:39:23 +0100
From: sebb seb...@gmail.com
To: Henk P. Penning penn...@uu.nl
Cc: general@attic.apache.org,
Apache Infrastructure infrastruct...@apache.org
Subject: Re: Moving projects to the Attic
On 15 January 2014 09:01, Henk P. Penning penn...@uu.nl wrote:
On Wed, 15 Jan 2014, Henri Yandell wrote:
Date: Wed, 15 Jan 2014 04:30:02 +0100
From: Henri Yandell he...@yandell.org
To: general@attic.apache.org
Cc: Apache Infrastructure infrastruct...@apache.org
Subject: Re: Moving projects to the Attic
Sender: hyand...@gmail.com
So updating with Sebb's response:
Hi,
Can be done by Attic:
- Create page on Attic site
- Inform users
- Delete from committee-info.txt (members)
- Remove from www.apache.org navigation
- Announce on announce at apache.org
Needs permissions from Infra for Attic:
Shouldn't the (svn) permissions for 'site' and 'dist' be
transfered from project committers to attic committers ?
to freeze the web-site and dist-area, and let 'attic' do
its thing?
If Infra are happy with the idea, then updating the authn files can be
done by the following groups:
[/infrastructure/trunk/subversion/authorization]
@member = rw
@pmc-chairs = rw
@svnadmins = rw
@board = rw
@exec-officers = rw
Which should be enough for Attic to assign themselves the necessary
karma for the site, as has already been done here:
[/websites/production/esme]
@attic-pmc = rw
@esme = rw
Not sure where the dist/release permissions are defined, so I don't
know if this can be done by Attic personnel
That file is generated by 'infra' with :
https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/generate-dist-authorization
As you can see, at the moment, 'esme' is a special case :
@attic-pmc = rw is added to [/dev/esme], [/release/esme].
Also, for the record, infra wants to remove the dist/dev/esme
and dist/release/esme areas (six months after 'attic' day).
IHMO, it would be a lot simpler if 'project' esme could simply
move from (defunct) pmc-esme to pmc-attic ; A PMC can run more
than one project.
Regards,
HPP
for dist : [eg esme] https://dist.apache.org/repos/dist/release/esme
eg : svn ls -v https://dist.apache.org/repos/dist/release/esme
[ there may also be a https://dist.apache.org/repos/dist/dev/esme ]
for site : don't know how this would work for a CMS site.
- Update website with Attic notice
- Update HEADER.html in downloads
- Update the project DOAP file
- 6 months+: strip dist/project and add a .htaccess redirect
Needs to be done by Infra:
- Point SVN mails to general at attic
- Make SVN + JIRA/Bugzilla read-only
- Turn off automated builds
- Close down infrastructure resources
- 6 months+: Consider deleting the user list
With sites on the CMS, updating the website with an Attic notice is likely
to be a challenge. Typically I did a search and replace on every .html
page
and inserted a div at the top of the page. Any thoughts from anyone
CMS-knowledgable about whether it's best to try and do that in the CMS
somehow, or perhaps to have a more programmatic notion that marks a site
as
retired and inserts a header?
... or add to the site's style-sheet
body:before
{ content:This project retired ...;
background-color:yellow;
float : top ;
color:red;
font-weight:bold;
}
Hen
_
Henk P. Penning, ICT-beta R Uithof BBL-761 _/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Princetonplein 5, 3584CC Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
_
Henk P. Penning, ICT-beta R Uithof BBL-761 _/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Princetonplein 5, 3584CC Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
Re: Moving projects to the Attic
On 16 January 2014 14:56, Henk P. Penning penn...@uu.nl wrote:
On Thu, 16 Jan 2014, sebb wrote:
Date: Thu, 16 Jan 2014 12:51:57 +0100
From: sebb seb...@gmail.com
To: Henk P. Penning penn...@uu.nl
Cc: general@attic.apache.org,
Apache Infrastructure infrastruct...@apache.org
Subject: Re: Moving projects to the Attic
On 16 January 2014 10:45, Henk P. Penning penn...@uu.nl wrote:
On Thu, 16 Jan 2014, sebb wrote:
https://svn.apache.org/repos/infra/infrastructure/trunk/subversion/authorization/generate-dist-authorization
Also, for the record, infra wants to remove the dist/dev/esme
and dist/release/esme areas (six months after 'attic' day).
The dev/esme tree could be deleted immediately.
I assume svnpubsub will have to be switched off for the release tree
first.
And that can only happen after the .htaccess redirects have been set up.
Once release/esme is deleted, the esme/.htaccess file will no longer
be anywhere in current SVN - the only copy will in backups.
Ah yes ; I forgot that after six months the dist/TLP/ should be
stripped down to a .htaccess (not removed, as I said).
Perhaps the .htaccess redirects should be added to the parent (dist)
directory, in which case the esme directory could be removed entirely
from dist?
It seems a bit unnecessary for all attic projects to have directories
which only contain .htaccess files, but perhaps there is a reason why
this is better than updating the parent .htaccess file.
I dont' think putting the redirects in dist/.htaccess can be made
to work properly. In the 'Redirect' the first argument must be an
absolute path, and that won't work on the mirrors ;
.htaccess doesn't take Directory directives ;
hence the 'RedirectMatch' in (fi) dist/beehive/.htaccess.
OK, that's a pity.
I /would/ like to remove (in /dist/) anything pointing to an attic'ed
TLP after some time ; say 2 years.
-- Would anybody veto that :-?
So for example beehive and harmony and jakarta would now be candidates
for deletion?
I assume the original websites would remain.
If the redirects were removed, the mirror download pages would break completely.
At present they redirect to the Attic holding page; I think they would
404 instead.
It would be a lot of effort to update all the site download pages to
document or fix this, and deleting the pages would lose useful
information.
Keeping the redirects would avoid this.
My vote would be -1 (but is not binding).
I note that the parent directory (dist) does not seem to be in SVN.
Maybe it should be, in which case attic dirs could be moved to that
for ongoing maintenance.
... dist/.htaccess doesn't get synced from mino to the rsync servers ...
... I think the attic'ed TLP's shouldn't be moved ; setting proper
(@attic) rw-rights is enough.
IHMO, it would be a lot simpler if 'project' esme could simply
move from (defunct) pmc-esme to pmc-attic ; A PMC can run more
than one project.
Not sure I follow how that would work technically with the existing
auth files.
The /dist/ svn auth file is generated (url above) ; the script could/
should be made smarter (it should know about attic'ed projects).
I don't know if there is a reliable database saying project esme
now belongs to pmc-attic.
If the only place that needs to know about them is the script, then it
could be listed there.
As is done for projects that allow non-PMC RMs.
Regards,
HPP
_
Henk P. Penning, ICT-beta R Uithof BBL-761 _/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Princetonplein 5, 3584CC Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
Re: Moving projects to the Attic
On 15 January 2014 09:01, Henk P. Penning penn...@uu.nl wrote:
On Wed, 15 Jan 2014, Henri Yandell wrote:
Date: Wed, 15 Jan 2014 04:30:02 +0100
From: Henri Yandell he...@yandell.org
To: general@attic.apache.org
Cc: Apache Infrastructure infrastruct...@apache.org
Subject: Re: Moving projects to the Attic
Sender: hyand...@gmail.com
So updating with Sebb's response:
Hi,
Can be done by Attic:
- Create page on Attic site
- Inform users
- Delete from committee-info.txt (members)
- Remove from www.apache.org navigation
- Announce on announce at apache.org
Needs permissions from Infra for Attic:
Shouldn't the (svn) permissions for 'site' and 'dist' be
transfered from project committers to attic committers ?
to freeze the web-site and dist-area, and let 'attic' do
its thing?
If Infra are happy with the idea, then updating the authn files can be
done by the following groups:
[/infrastructure/trunk/subversion/authorization]
@member = rw
@pmc-chairs = rw
@svnadmins = rw
@board = rw
@exec-officers = rw
Which should be enough for Attic to assign themselves the necessary
karma for the site, as has already been done here:
[/websites/production/esme]
@attic-pmc = rw
@esme = rw
Not sure where the dist/release permissions are defined, so I don't
know if this can be done by Attic personnel
for dist : [eg esme] https://dist.apache.org/repos/dist/release/esme
eg : svn ls -v https://dist.apache.org/repos/dist/release/esme
[ there may also be a https://dist.apache.org/repos/dist/dev/esme ]
for site : don't know how this would work for a CMS site.
- Update website with Attic notice
- Update HEADER.html in downloads
- Update the project DOAP file
- 6 months+: strip dist/project and add a .htaccess redirect
Needs to be done by Infra:
- Point SVN mails to general at attic
- Make SVN + JIRA/Bugzilla read-only
- Turn off automated builds
- Close down infrastructure resources
- 6 months+: Consider deleting the user list
With sites on the CMS, updating the website with an Attic notice is likely
to be a challenge. Typically I did a search and replace on every .html
page
and inserted a div at the top of the page. Any thoughts from anyone
CMS-knowledgable about whether it's best to try and do that in the CMS
somehow, or perhaps to have a more programmatic notion that marks a site
as
retired and inserts a header?
... or add to the site's style-sheet
body:before
{ content:This project retired ...;
background-color:yellow;
float : top ;
color:red;
font-weight:bold;
}
Hen
_
Henk P. Penning, ICT-beta R Uithof BBL-761 _/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Princetonplein 5, 3584CC Utrecht, NL F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
Re: Moving projects to the Attic
So updating with Sebb's response: Can be done by Attic: - Create page on Attic site - Inform users - Delete from committee-info.txt (members) - Remove from www.apache.org navigation - Announce on announce at apache.org Needs permissions from Infra for Attic: - Update website with Attic notice - Update HEADER.html in downloads - Update the project DOAP file - 6 months+: strip dist/project and add a .htaccess redirect Needs to be done by Infra: - Point SVN mails to general at attic - Make SVN + JIRA/Bugzilla read-only - Turn off automated builds - Close down infrastructure resources - 6 months+: Consider deleting the user list With sites on the CMS, updating the website with an Attic notice is likely to be a challenge. Typically I did a search and replace on every .html page and inserted a div at the top of the page. Any thoughts from anyone CMS-knowledgable about whether it's best to try and do that in the CMS somehow, or perhaps to have a more programmatic notion that marks a site as retired and inserts a header? Hen
Re: Additional projects to the Attic
I've been afk with vacation and illness, but I can look into this slowly. Hen On Thu, Jul 18, 2013 at 7:06 AM, Brett Porter br...@apache.org wrote: Hi, In the July board meeting, the board resolved to move Apache C++ Standard Library (stdcxx) and Apache XMLBeans to the attic. Are there any volunteers here who are able to help take the process forward with one or both of those projects? Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Fwd: Handling /dist for projects in the attic
Attic folks, The below is what infra is doing to remove projects that are now in the attic from the download mirrors. If you would prefer something else (such as complete removal) just let infra know. Cheers, Mark Original Message Subject: Handling /dist for projects in the attic Date: Sat, 04 Jun 2011 21:10:37 +0100 From: Mark Thomas ma...@apache.org Reply-To: infrastructure-priv...@apache.org To: infrastructure-priv...@apache.org I will be addressing these, starting (and hopefully finishing but you never know) this evening. Any project that has been in the attic less than 6 months will be left as is. Projects in the attic for more than 6 months will be dealt with as follows: - add an .htaccess file that permanently redirects /dist/$tlp(.*) to http://attic.apache.org/tlp.html - remove all other content from /dist/tlp Mark
Projects.a.o - how to handle projects in the Attic?
I originally asked this on the site-dev list (and got no reply), but having read the Attic web-site, it looks like the DOAPs are supposed to be updated when moved to the Attic. I think I can grant myself permission to fix the incorrect DOAPs - is it OK if I start on this? = At present, there is just one project which is shown as being in the Attic, which is Beehive. The parent PMC is identified by a line in the project DOAP file, e.g. for Beehive: Project rdf:about=http://beehive.apache.org; ... nameApache Beehive/name homepage rdf:resource=http://beehive.apache.org; / asfext:pmc rdf:resource=http://attic.apache.org; / Now the DOAPs are normally in the project SVN which is marked read-only when in the Attic. If it is OK to update the DOAP in each Attic project, then I can start making the changes. WDYT?
Re: Projects.a.o - how to handle projects in the Attic?
How about we copy the doap files over to a writable attic location, and change the references to point to those files? That way, we can continue to update our doaps as needs require. Upayavia On Wed, 03 Nov 2010 09:45 +, sebb seb...@gmail.com wrote: I originally asked this on the site-dev list (and got no reply), but having read the Attic web-site, it looks like the DOAPs are supposed to be updated when moved to the Attic. I think I can grant myself permission to fix the incorrect DOAPs - is it OK if I start on this? = At present, there is just one project which is shown as being in the Attic, which is Beehive. The parent PMC is identified by a line in the project DOAP file, e.g. for Beehive: Project rdf:about=http://beehive.apache.org; ... nameApache Beehive/name homepage rdf:resource=http://beehive.apache.org; / asfext:pmc rdf:resource=http://attic.apache.org; / Now the DOAPs are normally in the project SVN which is marked read-only when in the Attic. If it is OK to update the DOAP in each Attic project, then I can start making the changes. WDYT?
Re: Projects.a.o - how to handle projects in the Attic?
On Wed, Nov 03, 2010 at 10:22:35AM +, Upayavira wrote: How about we copy the doap files over to a writable attic location, and change the references to point to those files? That way, we can continue to update our doaps as needs require. +1. Seems like the right way to go about it leaving the project untouched. vh Mads Toftum -- http://soulfood.dk
Re: Projects.a.o - how to handle projects in the Attic?
On 3 November 2010 10:28, Mads Toftum m...@toftum.dk wrote: On Wed, Nov 03, 2010 at 10:22:35AM +, Upayavira wrote: How about we copy the doap files over to a writable attic location, and change the references to point to those files? That way, we can continue to update our doaps as needs require. +1. Seems like the right way to go about it leaving the project untouched. In that case, the Attic docs need to be updated, as they currently state that the DOAPs are changed. Why would there be any need to update the DOAPs further? Also, having a different copy of the DOAP is likely to be confusing if the project emerges from the Attic. vh Mads Toftum -- http://soulfood.dk
