polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Apache Zest by-laws
Date Thu, 09 Jul 2015 10:36:30 GMT
The pages you reference;

Participate & Codebase -> Doesn't follow what ASF expects, where everyone
are peers.

Playing Field - talks about "reverts", where in ASF there is a concept of
"Veto a change", which would lead to discussion and resolution. Whether
that is a revert, amendment or something else is not really defined.


We used to have a release notes, which was generated from Jira issues
solved in the release. Are you talking about something else?

// Niclas

On Thu, Jul 9, 2015 at 1:19 PM, Paul Merlin <paul@nosphere.org> wrote:

> Gang,
>
> FIY, we already have some "by-laws" content divided in:
>
> https://zest.apache.org/community/participate.html
> https://zest.apache.org/community/playing_field.html
> https://zest.apache.org/community/codebase.html
>
>
> What we don't actually do, and maybe should, is maintain a CHANGES files.
>
> I like the idea and would like to start building one for 2.0 -> 2.1
> changes.
> Something that should be easy to read, much easier than SCM history.
>
> WDYAT?
>
>
> /Paul
>
> Niclas Hedhman a écrit :
> > A discussion erupted recently on ComDev (Community Development mailing
> > list, open to all I think) about project specific by-laws.
> >
> > It was highlighted that the Board resolution for creating projects
> > instructs the PMC to create the by-laws for the project.
> >
> > The conclusion of that thread was roughly;
> >   1. Projects are allowed to craft their own by-laws.
> >
> >    2. When this text was created, it was not known how easy it is to get
> > things wrong.
> >
> >     3. Over time, many/most projects operated without explicit by-laws.
> >
> >     4. Board would assume, if intervening, that the HTTPd project's
> by-laws
> > would apply by default.
> >
> >      5. It would be better for the project to spell it out on its own
> > website.
> >
> > So, I suggest that we all take a look at the HTTPd's by-laws and bring up
> > anything we have questions about, disagrees with or perhaps don't
> > understand.
> >
> > However I can't find those right now, unless what people mean are the
> > "guidelines"... http://httpd.apache.org/dev/guidelines.html
> >
> > The immediate thing is Commit-Then-Review vs Review-Then-Commit. Almost
> no
> > projects do RTC for 'develop', only for changes in stable branches.
> > In general RTC slows down progress a bit, and I don't think we need it,
> > although in reality we are doing it with feature branches....
> >
> > Cheers
> >
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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