Re: [Tikiwiki-devel] Quality Team [QT] suggestions for 4.0/4.1

[Jonny B. <tw...@no...>]

Way woo! Welcome Sept_7!

I'd like to see one more join us, someone with CSS knowledge maybe?

As far at dir names for the new proposed, +1 for renaming/moving the  
current one, and good plan to put them all in branches/proposed. I  
know Sylvie didn't like the "x" in 4.x, but I hope you don't mind some  
more - it should be consistant, right?

Personally, I'm more optistic about 4.0, and I hope 4.1 will be ready  
for release quite soon, with some added upgrade assistance, better  
perms checking, and just the one (maybe two) img plugins! :)

jonny


On 15 Nov 2009, at 05:52, Nyloth <ny...@ti...> wrote:

> Hi Jonny, (and others)
>
> Thanks for restarting this topic.
>
>
> * About commiting directly to branches/4.x until 4.1 is released
>
> In one hand, Marc's suggestion seems good to me, especially to  
> reduce the amount of work needed by us (QT).
>
> But, on the other hand, svn merge does not work well, sometimes. For  
> each svnbranchupdate you make, you may loose some fixes or, worse,  
> you may end in an inconsistancy state. I experienced this  
> "incomplete merge" result when backporting stuff from the proposed  
> branch to the stable one. I had to manually backport every files  
> missed by svn... svn is apparently not a robust enough tool.
>
> So... since we are already working that way, I would say that I'm ok  
> to try Marc's suggestion.
>
> Another point : Nothing really dramatic, but IMO 4.0 will be  
> released too early.
> This suggestion from Marc clearely shows that we expect a lot of  
> fixes on a very short period of time between 4.0 and 4.1. For me,  
> this means that 4.0 will probably not be "stable". 4.1 or even 4.2  
> will be the "stable" ones. So... I would have prefered to release  
> another beta2, then the RC1, then an RC2, etc. and give people  
> enough time to really test and fix those RC...
>
>
> * About 3.x
>
> I think another point here have to be added...
>
> The QT agreed (off-list discussions) to continue our QT work for 3.x  
> until - at least - 5.0 is released. You mentionned "branches/ 
> 4_proposed", which means that we will not using branches/proposed  
> for 4.x and have its own proposed branch. This will allow us to  
> support multiple stable / legacy branches in parallel.
>
> So, we can consider that 3.x will survive a bit more, like an LTS  
> (Long Term Support) - which is good if we suppose that 4.x will not  
> be really stable before 4.1 or 4.2 or more ;)
>
> About branches/proposed, currently used for 3.x, I think we should  
> rename it to avoid mistakes.
> I'm not against branches/4_proposed and branches/3_proposed, but I  
> would prefer something like branches/proposed/4.x and branches/ 
> proposed/3.x , etc. Any objection ?
>
>
> * About QT members
>
> Currently the QT members are Jonny, Sylvie and myself.
> As defined when the QT was created, a new major release is the  
> appropriate time to change QT members.
>
> So... Jonny, Sylvie and myself will continue (as discussed off-list)  
> to be part of the QT.
> We also discussed about new members and I'm happy to announce that  
> Sept_7 will join us !
>
> And since Sept_7 is now part of the QT, his opinion is obviously  
> also very welcome on this topic.
>
>
> So, that's all for the moment,
> Cheers,
> Nyloth
>
>
> 2009/11/14 Jonny Bradley <tw...@no...>
>
> Hi Sylvie and Nyloth - via the devels list. This is coming to you from
> TikiFest Montreal 4
>
> I'm sending this to everyone to let you know we're starting
> discussions again about how to proceed with the QT for 4.x, now that
> RC1 is out (maybe a bit late for this, but we've been busy! ;)
>
> We may well take this chat privately between the three of us for a
> time, while we work out what's the best way forward - Sylvie and
> Nyloth; reply selectively as you prefer. But i thought i better to
> start off openly here.
>
> As 4.0 RC1 is now out (w00t!), and only trivial fixes have been
> reported (so far... i know it'll take time and there will be more) i
> think we should proceed from this point forward as if this is now
> released, so only __genuine__ fixes directly into 4.x from now on.
>
> We are planning/hoping to do a final release tomorrow (Sunday)
> afternoon - so get your last minute emergency fixes in now! :)
>
> On the subject of how to proceed with the Quality Team monitoring
> changes to 4.x for 4.1, Marc came up with a suggestion of a
> modification of the current 3.x procedure (he's worried about us
> burning ourselves out, spending all our time assessing proposals and
> back-porting etc).
>
> For the next week or two we could try not having a 4_proposed branch,
> as originally envisaged by the QT (off-list). While the
> svnbranchupdate script still works merging changes from 4.x to trunk,
> we should let people commit __FIXES__ to 4.x directly.
>
> The QT will continue to monitor all commits and will have a duty to
> rollback regressions when at 2 or more members agree, but in this
> transition stage we would proceed assuming most fixes will be ok,
> rather than the other way round.
>
> Enhancements and new stuff should be committed to trunk and tested
> there first, and then back-ported to 4.x with a [bp/r...] reference as
> with proposed for 3.x.
>
> There should be no more database schema changes in 4.x (so no DB
> alterations until 5.0)
> --- 
> --- 
> --- 
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
>
> When the branch update script becomes too painful to run (in a week or
> two) we should then (hopefully) release 4.1 and set up branches/
> 4_proposed (or whatever name) and run that in the same way as proposed
> has been working for 3.x
>
> How does that sound? This is all up for discussion of course, but we
> need to get a system in place pretty quickly, while doing everything
> we can to get 4.1 out and pushed as the default choice for new
> installs and upgrades (whereas the advice with 4.0 for now, i believe,
> is "upgrade with care", especially if you used 3.x category
> permissions!)
>
> Greetings and salutations from the 'fest - more soon
>
> jonny
>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> 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
> Tik...@li...
> 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
> Tik...@li...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel