Re: [VOTE] retire zeta components from incubation

[Thomas Nunninger]

Hi,

Am Freitag, 20. April 2012, 11:25:20 schrieb Tobias Schlitt:
> Hi,

[snip]
> sadly, I did not find time to look into all this stuff. This also seems
> the reason that Zeta is dying: Time lack.
> 
> I'm a bit sad, that Zeta is being closed down, but I think that it's the
> logical way to go.
> 
> Since I won't find any time to take care for it in the near future, I
> cannot go any other way than vote

Nice to see some reactions of the core developers. Especially thanks to Toby 
because of the very clear words.

It's really sad to see that the Zeta Components did not reached it's goals 
here at Apache. It's sad to see that the core committers are not able to 
maintain the project. It's sad to see no more development. (It's sad that I 
wasn't able to support the Components more.) Probably github is a better 
place. But I do not expect more life there.

What I'm missing:

- What's the future of the Components? Is it just maintenance mode?

- What's the legal/license situation regarding the history/eZ Systems?

- What's eZ's position? (I guess they are most interested in a clear situation
  of the project.)

Would it be helpful to have an IRC meeting to discuss the future? (Or is it to 
political to speak clear words where everything is perhaps somehow logged?)

Thomas

Re: [zeta-dev] Missing report (was: Fwd: Incubator Board Report November 2011)

[Thomas Nunninger]

Hi,

> While not being an active contributor to the project, i am in a similar
> situation :
> i use & like the Zeta Components a lot.

Same situation for me. I use them a lot and base some software on it.

Thomas

Re: [zeta-dev] Proposal: Commit guidelines

[Thomas Nunninger]

Hi,

Am Freitag, 8. April 2011 07:50:20 schrieb Jerome Renard:
> Hi Patrick,
>
> On Thu, Apr 7, 2011 at 4:09 PM, Patrick ALLAERT
>
>  wrote:
> > 2011/4/1 Tobias Schlitt :
> >> Hi,
> >>
> >> I wrote down our commit guidelines. Please review them shortly, before I
> >> commit:
> >>
> >>        http://files.schlitt.info/tmp/commit_guidelines.patch
> >
> > Good work Toby!
> >
> > I have however a remark regarding:
> >
> > +However, larger features or bug fixes, should be split them into smaller
> > +commits. In this case, the issue number should only occur in the final
> > commit, +which closes the issue.
> >
> > I think having the issue number on the latest commit only might be a
> > problem for different reasons:
> > 1. While looking at a commit mentioning an issue ID, you have no clue
> > whether other commits are required or not to fix that specific issue.
> > 2. In the case a commit fixing a bug has to be reverted for whatever
> > the reason, the one which will definitely resolve the problem will
> > also mention that issue which is not consistent to the guidelines.
> > 3. In the case a bug issue is reopened, we might have the same problem as
> > in 2.
>
> I already thought about this problem but to be honnest I never found
> an acceptable
> solution. The only "solution" I came up with is to write commit log
> message like this:
>
> - Fixed #1234321 part 1 : bla bla bla bla

Perhaps it's possible to come up with some other (fixed) term instead of "part 
X" after the issue number. A term that means something like: "not 
finished", "to be continued" or whatever. It shouldn't be to long. Perhaps an 
abbreviation.

Regards,
Thomas

>
> That way you actually now which commits are related to which issue but
> I really do not
> like this solution at all. The ideal solution would be to create a new
> branch named "issue-XXX"
> which contain as many commits as required and then push/merge the
> branch when the
> issue/feature is fixed/implemented. But that requires Git (or
> Mercurial) and ASF only provides
> SVN (Git is only a read only mirror).
>
> :)



-- 
Dipl.-Inf. Thomas Nunninger
Steinhalde 108
79117 Freiburg

Tel.:  +49 761 1201850
Mobil: +49 163 7115153
http://nunninger.info

USt-IdNr: DE259832548