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 <[email protected]>
> > To: [email protected]
> > 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
> 
> ------------------------------------------------------------   _
> Henk P. Penning, ICT-beta                 R Uithof MG-403    _/ \_
> Faculty of Science, Utrecht University    T +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL          F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M [email protected]     \_/
> 
> > 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 University    T +31 30 253 4106 / \_/ \
> >> Leuvenlaan 4, 3584CE Utrecht, NL          F +31 30 253 4553 \_/ \_/
> >> http://www.staff.science.uu.nl/~penni101/ M [email protected]     \_/
> >> 
> >> ---------- Forwarded message ----------
> >> Date: Thu, 19 Jul 2018 21:11:03 +0200
> >> From: Henk P. Penning <[email protected]>
> >> To: Apache Board <[email protected]>
> >> 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 <[email protected]>
> >>>  To: Apache Board <[email protected]>
> >>>  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 University    T +31 30 253 4106 / \_/ \
> >> Leuvenlaan 4, 3584CE Utrecht, NL          F +31 30 253 4553 \_/ \_/
> >> http://www.staff.science.uu.nl/~penni101/ M [email protected]     \_/
> >> 
> >>>  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_2
> >>>  01
> >>>  3_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"




Reply via email to