Am Fri, 18 Nov 2011 15:54:32 -0300
schrieb Luis Falcon <lfal...@thymbra.com>:
> On Fri, Nov 18, 2011 at 3:09 PM, Udo Spallek
> <udo.spal...@googlemail.com> wrote:
> > Thu, 17 Nov 2011 15:23:16 -0300
> > Luis Falcon <lfal...@gnusolidario.org>:
> >> On Thu, Nov 17, 2011 at 2:02 PM, Nicolas Évrard
> >> <nicolas.evr...@b2ck.com> wrote:
> >> > * Luis Falcon [2011-11-17 15:48 +0100]:
> >> >>>> > I started the wiki page for goals of 2.4
> >> >>>> > https://code.google.com/p/tryton/wiki/Release_2_4_0
> >> >>>> Thanks Cedric. Very happy to see the Production module on the
> >> >>>> list !
> >> >>> We will see if it will be achieved.
> >> >> What do you mean ? We will achieve it. If it's included we
> >> >> should, otherwise don't publish it. People expectations are
> >> >> high on this and this is not a game.
> >> > According to me goals are goals that we want to achieve. It may
> >> > happen, the focus is on those points but I may not happen.
> >> > We are in a free software world, it will happen if anybody is
> >> > ready to work on it and if anybody has time for it. If one of
> >> > those condition is not met, it will not happen ; if a more
> >> > important stuff arise in the community (I don't know what but
> >> > who knows), it will not happen ; etc … Moreover, this point is
> >> > IMHO not more important than some others. To change that either
> >> > you do it yourself or you pay someone to do it : this is free
> >> > software.
> >> I don't agree. I believe we need to have commitment in what we
> >> talk, suggest and write. A project must meet and deliver its
> >> goals. Then, of course, in rare circumstances, something might not
> >> be delivered on time, but that would be just an exception.
> > I know this: First case, a project can deliver all goals in all the
> > time needed to catch them all. Or second case, a project can
> > deliver some of the goals in a predictable time. And sometimes
> > there is a mixture between both cases.
> > For me and afaik most distribution packager the second way to go is
> > the best.
> > I don't like to slow down release cycle only for catching goals
> > which are collected by a number of changing individuals. I don't
> > like unpredictable release dates only because of missing features.
> >> What we can't do is getting do meeting in Belgium, move people
> >> around from many countries around the world, agreed on the
> >> production module and now say "we'll see if it happens...." or
> >> "this is free software world and things might not happen". Is just
> >> not serious.
> > I participated the discussion group about 'production'. After one
> > cycle where everyone tells his needs and requirements, one thing
> > was clear for me: we need a generic production module which is able
> > to be the base for all this totally different cases of production.
> > IIRC we talked about individual, serial, finishing production,
> > production for maintaining gardening and forests. [Hopefully I
> > found the correct English translations]
> > For me the first goal is to find a general base for all this very
> > different requirements in production. And I can wait as long as we
> > have a very good base for the implementation. I don't like to have
> > some module which is the result of a quick shot but only usable for
> > some cases but useless in general.
> > Why are you so impatient?
> I'm not being impatient... I didn't put it for the 2.4 release.
I think this is a misunderstanding of our release cycle. Our release
cycle is based on the release process of Open BSD[1][2][3]. The over all
rule is to release Tryton on a strict regular basis. This is for the
reason to make release-preparations, release, delivery and developing of
Tryton as easy and predictable as possible for all together.
So Tryton has regular date based stable releases twice a year[4],
minimum one maintenance and bug fix release, back ports of bug fixes for
two years old Tryton versions. This all is very comfortable for users,
implementers, projects like gnu health[5], and at least you and me and
our users.
I my partners, my customers, all user of Tryton can decide within two
years to upgrade their Tryton installation or not. I even can plan my
holidays under the question if I like to participate to a particular
Tryton release[4] or not.
This is a no vendor-login guarantee for all end users of the Tryton
project. No implementer can change this for his customers. This is
quite a solid marketing argument. There is really no need to upgrade, and
if you like, it is always possible.
All this sweet comfort works only because Trytons release criteria is
a stupid date in a calendar. Predicting release goals as you
mentioned is another approach. There, catching all release goals is the
criteria for a release. But please tell me how to catch all goals of
everyone in a variable community project without slavery?
Not to forget:
1. as a community project we are not able to predict the human
power which will help to catch the goals.
2. We can not predict if a goal is solvable or not.
3. Everyone can add goals to the wiki page and disappear forever.
The Tryton project has shown that it is able to provide regular basis
releases and to maintain several back ports. Who needs more for free?
[1] https://code.google.com/p/tryton/wiki/ReleaseGeneral
[2]
http://openbsd.org/papers/asiabsdcon2009-release_engineering/mgp00016.html
[3] http://openbsd.org/papers/asiabsdcon2009-release_engineering/
[4] http://www.tryton.org/de/community/calendar.html
[5] http://health.gnu.org/
> >> Same with the homepage.... quite a few people worked on design,
> >> made proposals, etc... and nothing happened yet, even though most
> >> of us wanted to update it. Things get washed away but discussions
> >> about templates / vim / Sphinx and other curiosities....
> > I did not participated about the homepage changes for now, but I
> > really like this two aspects of the projects:
> >
> > * http://hg.tryton.org/www.tryton.org/
> > * http://hg.tryton.org/doc.tryton.org/
> >
> > It is easy to change layout/content/whatever for *everyone* in the
> > target audience of Tryton. Simply because everything needed is
> > provided. I don't like any CMS for a project like Tryton. And
> > bringing the technologies for presenting website and documentation
> > together is for me a perfect way to go. Yes, I really like sphinx.
> The community, especially those that dedicated their time and talent
> working on the template will appreciate if you can turn into the
> sphinx template.
> We need to be pragmatic.
Yes, but not this way. I really not like new ideas, because they are
just new ideas. To tell you the hard way:
For me the homepage discussion is boring uninteresting and misleading.
I am not interested in investing time in this topic. Come on, Tryton is
a framework, not a cool music player or browser targeting the masses.
Other more popular frameworks doesn't look so different[6]. Some
learned nothing ;-) and have code snippets on their title page[7]...
I become a little sad, when I see so many people investing time in this
topic. Because they should better invest time in topics which are
more interesting for me: quality, features, bugfixes.
BUT, for me pragmatic means:
* I would really like if there is someone who takes the css of Tryton
make some style proposals and a nice cold color but nothing more, I
will vote for this, because I like to see some nice changes after the
years.
* New and better content, specially module wise documentation will get
my vote, too.
* If there is someone who is able to put the Tryton Homepage into
a sphinx document, I promote this, too. My interest is, to provide my
customer with nice PDF project documentation, just for the case they
ask. When I can get two (PDF and HTML) for the price of one (Sphinx
using RST) this would be really good.
BTW next time when you write 'the community', make sure you are not
trying to cheat. At least I am not part of the community you
describe, but I am part of the Tryton community. You tell the
untruth when you write this stuff; now everyone knows.
[6] https://www.djangoproject.com/
[7] http://twistedmatrix.com/trac/
> >> Don't get me wrong. This is a great project and that's why a lot
> >> of us are here, contributing and supporting it, but we need to
> >> deliver the goals, otherwise it will become chaotic and
> >> unpredictable.
> > As already mentioned, for my experience, your suggestions to
> > strictly deliver all the goals, will result in an unpredictable and
> > chaotic project.
> On the contrary. If you set goals, you make projects, teams,
> deadlines, etc...
And you have stress, stress youself, stress others, stress customers,
overdue deadlines, never ending releases, rc1, rc2, rc3, rcX, always
beta. Sadness all around. I don't need this. You?
> >> PS: Time to have the Tryton foundation.
> > How is the Tryton foundation related to this discussion? What do you
> > expect of a foundation to clear the above aspects?
> We need the foundation to protect and promote Tryton.
My opinion:
* Protect: Yes,
* Promote: We will see what this mean exactly. Hopefully: agree
> Decision making
> __as a community__,
Who will bring the decision to reality?
I do not work without motivation, you?
> being represented by the foundation
We will see, what the foundation has to tell in 'my name'... but
hopefully: agree
> voting
> members,
Agree.
> is key for the points mentioned above.
No, sorry I can not see the relation. Please help.
> It's quite important
> that the community will is respected.
Agree.
> Similar concept applies to
> fundings.
What exactly do you mean?
Cheers Udo
--
tryton-dev@googlegroups.com mailing list
