Support.Mozilla.com (SUMO) :: Excellent news!! :: Proposal for an early release of Tiki5

[Marc Laporte-3]

Hi!

We have excellent news:
https://wiki.mozilla.org/index.php?title=Support/TikiWikiUpgrade&diff=0&oldid=172946

As you read the whole page
https://wiki.mozilla.org/Support/TikiWikiUpgrade, you will realize
there was a very real possibility that Support.Mozilla.com was no
longer going to use Tiki.

The main reason is that by lack of keeping up with the main Tiki, they
ended up with a fork. A fork is painful and time-consuming to manage.
This was not a planned, intentional fork. This was a
we-have-this-big-deadline-coming-up-let's-just-get-this-in-and-we'll-upstream-latter
fork. Of course, the longer you wait, the more difficult it is. They
were on an old, never released 1.10 code base. Not being based on a
stable branch made things even more tricky.

So this should be a reminder/warning to everyone: "Commit early,
commit often". Tiki is too big an application to maintain on your own.
There are 400-700 commits per month
(http://cia.vc/stats/project/tikiwiki). If you don't stay in sync with
the main code base, within 1 year, you are completely out of the game.
And it's more time-consuming in the long run.

Nelson did upstream some things and he did the best he could. Staging
& Approval is born from this project! However, unless there is an
institutional policy to upstream, short term deadlines tend to win the
struggle for resources. Also, back in the 1.10 days, we didn't have a
planned release schedule. Thus, it was not possible to "plan" periods
to resync with Tiki trunk. And the longer you wait, the more difficult
it is to upstream. In Tiki, we don't even pretend that discussion
forums from Tiki3 can work with Tiki4 core (for example). Even for
applications which intend/promote to be good at this, I question how
actually reliable it is.

And one day, when the code has diverged too much, you have:
1- Tiki community members wondering: Why isn't SUMO contributing code?
2- SUMO community members wondering: Why isn't the Tiki community
collaborating with us?

If you do a Tiki project, and you don't have any commits to Tiki:
that's certainly a warning. It's highly unlikey that there is not a
single enhancement, bug fix, visual or profile improvement.

What that means to me: you are most probably doing something wrong.
You are lacking discipline to upstream/contribute your fixes. And
you'll end up having to do them again. And worse, perhaps someone else
will have implemented differently in the main code base, and you'll
end up with dead-end code and even maybe a dead-end data structure.
This is not good for Tiki. This is not good for you and your project.
This happened for polls in SUMO. Poor Sylvie had to try to merge the
two afterwards.

So after this period, SUMO made the difficult but right decision to
bite the bullet, put the urgent stuff aside and allocate time &
resources to get back on track. This is not unrelated to the fact that
many community members have stepped up this time and in the past to
help merge the code. And to the fact that I personally visited the
SUMO project manager, David Tenser, in Sweden
http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/

Here is an outline of SUMO contributions that will be made generic and
upstreamed:
https://wiki.mozilla.org/Support/TikiUpstreamTriage

Louis-Philippe will be helping upstream the features. Gary & luci for
themes and I am involved in coordination. Nelson is helping as well,
as he has most of the "institutional knowledge". Louis-Philippe was
too fast for us, and some things were supposed to be in Tiki5, but
will be in Tiki4 as experimental. (ex.: screencast) because we were
too slow to branch :-)

Now, I want SUMO to focus as much as possible on trunk. They normally
work with "patches" instead of "commit to trunk":
http://dev.tikiwiki.org/SUMO+Tiki+differences+and+similarities#Specific_advice_for_SUMO_developers

But to avoid too much worry of Tiki5 being way too far away, and to
reduce backport SUMO fixes to 4.x

1- It would be huge workload on our quality team.
2- And many things are much too big to have in 4.1, 4.2
3- I want to avoid that SUMO maintains its own 4.x version "plus
fixes"  (This is how we got into trouble!)

I am exploring the following:
http://dev.tikiwiki.org/Tiki5

For the record, I think getting everything done for a Tiki5 release in
January is very ambitious. But if we all focus on it, we can do
ambitious things! I think February-March instead of April is more
likely. But I want to show flexibility to get SUMO enhancements as
soon as possible in trunk.

To those that think we wouldn't have enough new features to justify
calling it Tiki5 with such short dev time. Keep in mind that we'll be
upstreaming 2 years of work for SUMO.

SUMO has quality control standards like nothing we historically have
in Tiki so far (with 12 millions page views per week, bugs or
performance issues really hit hard!). They have professional QA staff
with all the tools. So if we can get full SUMO support behind Tiki5,
5.0, it could be as or even more stable than 4.1, for all features
used by SUMO (which is all the important ones, except trackers).

And this will not just be for Firefox. It would also be for Fennec,
Thunderbird, and surely others. Mozilla calls this productization. So
we are talking about very broad testing. This is very exciting!

The discussion is ongoing. Will keep you posted.

Thanks!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[Marc Laporte-3]

An early TIki5 could coincide with:
http://tikiwiki.org/TikiFestConfoo2010

M ;-)


On Sun, Nov 8, 2009 at 8:36 PM, Marc Laporte <marc@...> wrote:

> Hi!
>
> We have excellent news:
> https://wiki.mozilla.org/index.php?title=Support/TikiWikiUpgrade&diff=0&oldid=172946
>
> As you read the whole page
> https://wiki.mozilla.org/Support/TikiWikiUpgrade, you will realize
> there was a very real possibility that Support.Mozilla.com was no
> longer going to use Tiki.
>
> The main reason is that by lack of keeping up with the main Tiki, they
> ended up with a fork. A fork is painful and time-consuming to manage.
> This was not a planned, intentional fork. This was a
> we-have-this-big-deadline-coming-up-let's-just-get-this-in-and-we'll-upstream-latter
> fork. Of course, the longer you wait, the more difficult it is. They
> were on an old, never released 1.10 code base. Not being based on a
> stable branch made things even more tricky.
>
> So this should be a reminder/warning to everyone: "Commit early,
> commit often". Tiki is too big an application to maintain on your own.
> There are 400-700 commits per month
> (http://cia.vc/stats/project/tikiwiki). If you don't stay in sync with
> the main code base, within 1 year, you are completely out of the game.
> And it's more time-consuming in the long run.
>
> Nelson did upstream some things and he did the best he could. Staging
> & Approval is born from this project! However, unless there is an
> institutional policy to upstream, short term deadlines tend to win the
> struggle for resources. Also, back in the 1.10 days, we didn't have a
> planned release schedule. Thus, it was not possible to "plan" periods
> to resync with Tiki trunk. And the longer you wait, the more difficult
> it is to upstream. In Tiki, we don't even pretend that discussion
> forums from Tiki3 can work with Tiki4 core (for example). Even for
> applications which intend/promote to be good at this, I question how
> actually reliable it is.
>
> And one day, when the code has diverged too much, you have:
> 1- Tiki community members wondering: Why isn't SUMO contributing code?
> 2- SUMO community members wondering: Why isn't the Tiki community
> collaborating with us?
>
> If you do a Tiki project, and you don't have any commits to Tiki:
> that's certainly a warning. It's highly unlikey that there is not a
> single enhancement, bug fix, visual or profile improvement.
>
> What that means to me: you are most probably doing something wrong.
> You are lacking discipline to upstream/contribute your fixes. And
> you'll end up having to do them again. And worse, perhaps someone else
> will have implemented differently in the main code base, and you'll
> end up with dead-end code and even maybe a dead-end data structure.
> This is not good for Tiki. This is not good for you and your project.
> This happened for polls in SUMO. Poor Sylvie had to try to merge the
> two afterwards.
>
> So after this period, SUMO made the difficult but right decision to
> bite the bullet, put the urgent stuff aside and allocate time &
> resources to get back on track. This is not unrelated to the fact that
> many community members have stepped up this time and in the past to
> help merge the code. And to the fact that I personally visited the
> SUMO project manager, David Tenser, in Sweden
> http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/
>
> Here is an outline of SUMO contributions that will be made generic and
> upstreamed:
> https://wiki.mozilla.org/Support/TikiUpstreamTriage
>
> Louis-Philippe will be helping upstream the features. Gary & luci for
> themes and I am involved in coordination. Nelson is helping as well,
> as he has most of the "institutional knowledge". Louis-Philippe was
> too fast for us, and some things were supposed to be in Tiki5, but
> will be in Tiki4 as experimental. (ex.: screencast) because we were
> too slow to branch :-)
>
> Now, I want SUMO to focus as much as possible on trunk. They normally
> work with "patches" instead of "commit to trunk":
> http://dev.tikiwiki.org/SUMO+Tiki+differences+and+similarities#Specific_advice_for_SUMO_developers
>
> But to avoid too much worry of Tiki5 being way too far away, and to
> reduce backport SUMO fixes to 4.x
>
> 1- It would be huge workload on our quality team.
> 2- And many things are much too big to have in 4.1, 4.2
> 3- I want to avoid that SUMO maintains its own 4.x version "plus
> fixes"  (This is how we got into trouble!)
>
> I am exploring the following:
> http://dev.tikiwiki.org/Tiki5
>
> For the record, I think getting everything done for a Tiki5 release in
> January is very ambitious. But if we all focus on it, we can do
> ambitious things! I think February-March instead of April is more
> likely. But I want to show flexibility to get SUMO enhancements as
> soon as possible in trunk.
>
> To those that think we wouldn't have enough new features to justify
> calling it Tiki5 with such short dev time. Keep in mind that we'll be
> upstreaming 2 years of work for SUMO.
>
> SUMO has quality control standards like nothing we historically have
> in Tiki so far (with 12 millions page views per week, bugs or
> performance issues really hit hard!). They have professional QA staff
> with all the tools. So if we can get full SUMO support behind Tiki5,
> 5.0, it could be as or even more stable than 4.1, for all features
> used by SUMO (which is all the important ones, except trackers).
>
> And this will not just be for Firefox. It would also be for Fennec,
> Thunderbird, and surely others. Mozilla calls this productization. So
> we are talking about very broad testing. This is very exciting!
>
> The discussion is ongoing. Will keep you posted.
>
> Thanks!
>

--
Marc Laporte

http://MarcLaporte.com
http://TikiWiki.org/MarcLaporte
http://AvanTech.net
http://OurWiki.net

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[Xavier de Pedro Puente-2]

Congratulations, Marc, and others involved, for making this chance a
reality!
I know many people like you had put lots of energy and wisdom into
facilitate that this could happen.
Cheers
Xavi

En/na Marc Laporte ha escrit:

> Hi!
>
> We have excellent news:
> https://wiki.mozilla.org/index.php?title=Support/TikiWikiUpgrade&diff=0&oldid=172946
>
> As you read the whole page
> https://wiki.mozilla.org/Support/TikiWikiUpgrade, you will realize
> there was a very real possibility that Support.Mozilla.com was no
> longer going to use Tiki.
>
> The main reason is that by lack of keeping up with the main Tiki, they
> ended up with a fork. A fork is painful and time-consuming to manage.
> This was not a planned, intentional fork. This was a
> we-have-this-big-deadline-coming-up-let's-just-get-this-in-and-we'll-upstream-latter
> fork. Of course, the longer you wait, the more difficult it is. They
> were on an old, never released 1.10 code base. Not being based on a
> stable branch made things even more tricky.
>
> So this should be a reminder/warning to everyone: "Commit early,
> commit often". Tiki is too big an application to maintain on your own.
> There are 400-700 commits per month
> (http://cia.vc/stats/project/tikiwiki). If you don't stay in sync with
> the main code base, within 1 year, you are completely out of the game.
> And it's more time-consuming in the long run.
>
> Nelson did upstream some things and he did the best he could. Staging
> & Approval is born from this project! However, unless there is an
> institutional policy to upstream, short term deadlines tend to win the
> struggle for resources. Also, back in the 1.10 days, we didn't have a
> planned release schedule. Thus, it was not possible to "plan" periods
> to resync with Tiki trunk. And the longer you wait, the more difficult
> it is to upstream. In Tiki, we don't even pretend that discussion
> forums from Tiki3 can work with Tiki4 core (for example). Even for
> applications which intend/promote to be good at this, I question how
> actually reliable it is.
>
> And one day, when the code has diverged too much, you have:
> 1- Tiki community members wondering: Why isn't SUMO contributing code?
> 2- SUMO community members wondering: Why isn't the Tiki community
> collaborating with us?
>
> If you do a Tiki project, and you don't have any commits to Tiki:
> that's certainly a warning. It's highly unlikey that there is not a
> single enhancement, bug fix, visual or profile improvement.
>
> What that means to me: you are most probably doing something wrong.
> You are lacking discipline to upstream/contribute your fixes. And
> you'll end up having to do them again. And worse, perhaps someone else
> will have implemented differently in the main code base, and you'll
> end up with dead-end code and even maybe a dead-end data structure.
> This is not good for Tiki. This is not good for you and your project.
> This happened for polls in SUMO. Poor Sylvie had to try to merge the
> two afterwards.
>
> So after this period, SUMO made the difficult but right decision to
> bite the bullet, put the urgent stuff aside and allocate time &
> resources to get back on track. This is not unrelated to the fact that
> many community members have stepped up this time and in the past to
> help merge the code. And to the fact that I personally visited the
> SUMO project manager, David Tenser, in Sweden
> http://djst.org/blog/2009/08/24/marc-laporte-coming-to-town/
>
> Here is an outline of SUMO contributions that will be made generic and
> upstreamed:
> https://wiki.mozilla.org/Support/TikiUpstreamTriage
>
> Louis-Philippe will be helping upstream the features. Gary & luci for
> themes and I am involved in coordination. Nelson is helping as well,
> as he has most of the "institutional knowledge". Louis-Philippe was
> too fast for us, and some things were supposed to be in Tiki5, but
> will be in Tiki4 as experimental. (ex.: screencast) because we were
> too slow to branch :-)
>
> Now, I want SUMO to focus as much as possible on trunk. They normally
> work with "patches" instead of "commit to trunk":
> http://dev.tikiwiki.org/SUMO+Tiki+differences+and+similarities#Specific_advice_for_SUMO_developers
>
> But to avoid too much worry of Tiki5 being way too far away, and to
> reduce backport SUMO fixes to 4.x
>
> 1- It would be huge workload on our quality team.
> 2- And many things are much too big to have in 4.1, 4.2
> 3- I want to avoid that SUMO maintains its own 4.x version "plus
> fixes"  (This is how we got into trouble!)
>
> I am exploring the following:
> http://dev.tikiwiki.org/Tiki5
>
> For the record, I think getting everything done for a Tiki5 release in
> January is very ambitious. But if we all focus on it, we can do
> ambitious things! I think February-March instead of April is more
> likely. But I want to show flexibility to get SUMO enhancements as
> soon as possible in trunk.
>
> To those that think we wouldn't have enough new features to justify
> calling it Tiki5 with such short dev time. Keep in mind that we'll be
> upstreaming 2 years of work for SUMO.
>
> SUMO has quality control standards like nothing we historically have
> in Tiki so far (with 12 millions page views per week, bugs or
> performance issues really hit hard!). They have professional QA staff
> with all the tools. So if we can get full SUMO support behind Tiki5,
> 5.0, it could be as or even more stable than 4.1, for all features
> used by SUMO (which is all the important ones, except trackers).
>
> And this will not just be for Firefox. It would also be for Fennec,
> Thunderbird, and surely others. Mozilla calls this productization. So
> we are talking about very broad testing. This is very exciting!
>
> The discussion is ongoing. Will keep you posted.
>
> Thanks!
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel