corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: [PROPOSAL] make release 0.1
Date Sat, 01 Aug 2015 15:18:33 GMT
On 1 August 2015 at 17:15, Peter Kelly <pmkelly@apache.org> wrote:

> Sounds like a good plan to me.
>
> I volunteer to write the README - I think what we have on the website/wiki
> is a little unclear at the moment, and have some ideas on how to better
> express what the project’s about.
>
super, then we can later update the website/wiki or you do it the other way
round, whatever you prefer.

>
> I suggest we do this (along with LICENSES and NOTICE) as files in the root
> of the Git repository, so we can each make changes via the usual means as
> for code.
>
+1

>
> Another thing I would like to suggest is we have a CONTRIBUTORS file (or
> similar name) which lists all those who have contributed to the project.
> I’m aware this isn’t strictly required, but I think it's a good way to give
> credit/recognition to everyone involved for their work.
>
+1, I assume you mean the file contains the names of people who have
actively done commits on what is being released ?

rgds
jan i.

>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
> > On 30 Jul 2015, at 9:21 pm, jan i <jani@apache.org> wrote:
> >
> > Traditionally cutting the first apache release for a podling is one big
> > PITA, therefore
> > I propose we get started.
> >
> > I propose we make release 0.1 consisting of
> >    - docFormats (the library only with the OOXML filter)
> >    - dfTest (the main test utility)
> >    - dfUtil (the conversion utility)
> >
> > We have a lot to learn here, about the files LICENSES and NOTICE and
> about
> > how to
> > handle release candidates and the final release, therefore I propose to
> > include the
> > "stable" parts. It can be argued that version 0.1 is not very useful for
> a
> > end-user, which
> > might be right, but it helps us get the release framework up and running.
> >
> > Once we have 0.1 through the needle of IPMC, version 0.2 can focus a lot
> > more on the
> > technical content.
> >
> > The steps we have to pass (I have surely forgotten a number) are:
> > - Make a branch (stable_0.1) that only contains what we intent to release
> > - Make it work (adapt CMake files etc)
> > - Correct LICENSES and NOTICE
> > - Prepare a release candidate (upload source with SHA5 to somewhere on
> dist)
> > - Vote on the release (min. 3 +1 NO -1)
> > - Ask IPMC to check the release and have them vote on it
> >  this is the needle, they tend to find things we have not thought about,
> >  but Justin (he is one of the best release checkers in incubators)
> earlier
> > promised
> >  me to do a pre-check so we avoid the normal errors.
> > - When the vote finally passes, move the source to the release part of
> dist.
> > - Congratulate each other with work well done.
> >
> > If we agree on the content and the idea of cutting a release, I volunteer
> > to do the work and
> > of course write about every step in here (and on the wiki), so we all
> learn
> > from the experience.
> > I do however need help from e.g. Dave, with some of the specialties.
> >
> > Following the suggestion from Dave, Let us discuss this until August 7th,
> > and then see
> > if we have reached consensus.
> >
> > Comments ?
> >
> > rgds
> > jan i.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message