PMC Release Meeting 20100224
Date: 2010-02-24
Time: 7AM GMT
Venue: irc #adempiere-team
Support Spreadsheet: Adempiere PMC Release
Chat times in GMT-5
(01:00:04) CarlosRuiz: Hi
(01:02:30) phib: hi
(01:02:44) nwessel [~nwessel@194.95.62.19] entered the channel.
(01:02:51) nwessel: hi everybody
(01:03:00) nwessel: sorry for being late
(01:03:56) CarlosRuiz: Hi Norbert - Paul - glad to see you here
(01:04:35) nwessel: yes, nice to see Paul again :-)
(01:05:09) phib: sorry I missed the last one -- just catching up on the transcript
(01:06:21) CarlosRuiz: Satyakaam doesn't seem to be available
(01:06:27) CarlosRuiz: ok, let's start then
(01:06:58) nwessel: ok
(01:07:20) CarlosRuiz: Paul, we're working on a google spreadsheet called "Adempiere PMC Release" - did you receive the link for that?
(01:07:29) phib: yep
(01:08:55) nwessel: I guess approach for this meeting is to start fixing tasks from top
(01:09:43) CarlosRuiz: tasks are still not prioritized, so maybe they're not in the exact order we would like to work them
(01:09:46) CarlosRuiz: I started a discussion in mail list touching maybe the points 1 and 8 of the spreadsheet
(01:10:10) nwessel: I like 1 and 2 pretty much
(01:10:58) nwessel: because that is where the pain is at the moment
(01:11:15) CarlosRuiz: ok - we can review those two points on this meeting - if you agree, that can be the agenda for today
(01:11:58) nwessel: Paul, do you share that view?
(01:12:16) phib: ok
(01:13:39) CarlosRuiz: good, Norbert, which one to start? what do you think?
(01:13:47) nwessel: first question is, if we are applying time based release to first stable release
(01:14:03) phib: what are the requirements for a "stable" release --
(01:14:12) nwessel: better question
(01:14:18) phib: and is it possible for us to meet them?
(01:14:20) nwessel: lets define that
(01:15:04) nwessel: stable means that the business processes within the application must work
(01:15:15) nwessel: work means, you get right numbers and get from a to b
(01:15:28) nwessel: its an erp software
(01:15:53) nwessel: no one has a problem when you have a gui problem and its fixed later
(01:16:31) nwessel: the quality under "stable" shoud be, do not expect no bugs but that the numbers and logic are correct
(01:16:49) phib: we have failed so far to eliminate all prio 9 bugs, some are just things no one is interested in fixing
(01:17:00) nwessel: lots of companies use adempiere and modify and develop it further locally anyway
(01:17:16) nwessel: the reason for that is to think over p9 definition
(01:17:37) nwessel: we are having regular bug days
(01:17:55) nwessel: and mark is organizing them for our time zone
(01:18:02) CarlosRuiz: which are the possible status for a release?
(01:18:06) nwessel: and they kill 2-3 bugs each time
(01:18:19) CarlosRuiz: in terms of quality? in terms of maintenance?
(01:19:40) CarlosRuiz: in terms of quality I would say we can think on:
(01:19:40) CarlosRuiz: * beta
(01:19:40) CarlosRuiz: * release candidate
(01:19:40) CarlosRuiz: * stable
(01:19:40) CarlosRuiz: and we can try to define how can we get the tag for a release
(01:20:09) CarlosRuiz: we could think also avoiding the work "stable" - is very tricky - we have some functionalities in beta, and others in stable at the same release
(01:21:10) CarlosRuiz: in terms of maintenance, we can have a "maintained" version, this is: we expect to release some patches with bug fixes but not much new functionality
(01:21:10) CarlosRuiz: and "unmaintained version" - this is, if you install this version, you're on your own fixing bugs, don't expect patches from community
(01:21:27) nwessel: thats a good idea
(01:21:31) phib: I agree
(01:21:45) nwessel: and the maintained version does only include features that work
(01:22:00) nwessel: that means also we should think about stripping functionality of or at least hiding
(01:22:10) nwessel: carlos do you remember the feature list?
(01:22:18) phib: the problem is people use the beta stuff
(01:22:31) nwessel: we could clearly declare what feature in what feature has which maturity
(01:22:41) nwessel: if people use the beta they need to maintain it
(01:22:52) nwessel: carlos, would you provide an upgrade path for beta?
(01:23:04) nwessel: I mean for "unmaintained version"
(01:23:31) CarlosRuiz: yes - that's why we could try to avoid the "stable" name, and instead use a name to state that basic business processes were tested - but you can find beta functionality there on more complex businesses processes or in new things, or in extensions
(01:24:01) CarlosRuiz: sorry, that was not answering your question Norbert, but reaffirming a previous statement :-)
(01:24:17) nwessel: np :)
(01:24:50) CarlosRuiz: I guess at this moment we don't have the required modularity to decouple partially working things
(01:24:54) nwessel: I think that we can kill most of the P9 for the maintained version just by declaring the scope of the application
(01:25:13) nwessel: carlos, but to declare the unsupported and hide them from the tree
(01:25:17) nwessel: -the
(01:25:20) nwessel: +them
(01:25:27) CarlosRuiz: I have a pending work to create the inventory of features (working on that on Adempiere Functional spreadsheet)
(01:25:27) nwessel: e.g.
(01:25:48) CarlosRuiz: we could accompany the release with that inventory list
(01:26:03) CarlosRuiz: so people can know what they're installing :-) and what they can expect from such release
(01:26:12) nwessel: exactly
(01:26:24) nwessel: and we would also have a documentation for the maintained release
(01:26:34) nwessel: but not for the unmaintained
(01:27:05) phib: is the unmaintained = trunk, or will there actually be another branch?
(01:27:15) CarlosRuiz: so, a maintained release (independent of its quality status) is expected to have documentation and patches
(01:27:29) nwessel: yes
(01:27:33) CarlosRuiz: Paul - the idea is all releases come from /release
(01:28:15) CarlosRuiz: maintained versions will have a branch for bug fixing and patches
(01:28:40) CarlosRuiz: unmaintained versions won't / they'll be just tagged
(01:28:58) nwessel: carlos, will they have migration path?
(01:29:24) nwessel: I mean migration scripts
(01:29:27) CarlosRuiz: sure - they must be incremental
(01:29:40) nwessel: yes, that is what I'd expect
(01:30:42) nwessel: can make a task list for that?
(01:30:51) CarlosRuiz: we could think on changing the strategy: instead of trying to get the next stable, we can move to the time based release, and define how to tag a version
(01:31:06) phib: presumably unmaintained releases comes out more often than maintained release
(01:31:27) nwessel: yes
(01:31:34) CarlosRuiz: which task Norbert? (please feel free to change the spreadsheet, you're the owner) :-)
(01:32:11) phib: so unmaintained releases give latest functionality
(01:32:31) phib: but how will the new features get rolled into maintained?
(01:33:05) hengsin: phib: what 2 u mean by that ?
(01:33:10) phib: i.e. will unmaintained=maintained every six months, say
(01:33:13) CarlosRuiz: at this moment I think better think on not adding new features to maintained
(01:33:35) phib: or will maintained always lag behind
(01:34:51) CarlosRuiz: but we can think with architecture how to improve that - because adding functionalities to maintained version via migration scripts is a hassle, if we improve the upgrade mechanism we could think about adding, but sounds hard with the current upgrade mechanism
(01:35:01) phib: CarlosRuiz: so a new feature must be in (say) 2 unmaintained releases before it can be merged into the maintained release?
(01:35:33) nwessel: I do not know if that is a criteria
(01:35:56) nwessel: if a feature should go to maintained should rather be dependent
(01:36:17) nwessel: on if it has bugs, functionals, documentation, test cases,...
(01:36:35) CarlosRuiz: I proposed (but we need to review if feasible) to release every four months, and every year (meaning every three releases) we declare a version as maintained
(01:36:35) CarlosRuiz: so the criteria for maintained would be based just on time
(01:37:02) phib: nwessel, surely that applies to unmaintained releases too
(01:37:25) nwessel: I thought trunk is experimental? did I miss something here?
(01:37:44) nwessel: and release branch is controlled
(01:37:54) hengsin: phib: it doesn't have to be that way, whether a release should be tagged as maintain/stable should be based on the current known status and user feedbacl
(01:38:52) CarlosRuiz: nwessel: yes, trunk is experimental, release is controlled, versions must come from release, all of them, maintained and unmaintained, beta, rc, "stable", etc
(01:38:56) phib: nwessel, quoting Carlos "Paul - the idea is all releases come from /release"
(01:39:00) hengsin: backport is always lot of hassle, we shouldn't do that unless it is a sponsor job
(01:40:06) CarlosRuiz: indeed the task 4 is to define what to do with trunk / at this moment there are several commits on trunk that needs to be reverted, but I suppose nobody likes to revert :-) so, we need to define how to cope with that (task 4, for another meeting)
(01:41:21) nwessel: phib: thanks for the hint
(01:42:03) nwessel: would be nice if you explained how we release unmaintained version
(01:42:39) nwessel: I thought it is tagging the trunk
(01:42:48) nwessel: which is experimental
(01:43:15) phib: I think Carlos is suggesting tagging release for all versions
(01:43:31) phib: maintained versions would then become a separate branch for patches
(01:43:54) nwessel: ok, I got it
(01:43:58) phib: unmaintained versions would never be patched
(01:43:59) nwessel: thanks for clarification
(01:44:06) CarlosRuiz: yes, my proposal is to release every X months / whatever is on /release
(01:44:47) CarlosRuiz: and with every release we define the inventory of working/non-working/partially-working functionality and define some tag for the release based on that
(01:44:59) CarlosRuiz: and maintained or unmaintained is based just on time
(01:45:23) CarlosRuiz: every Y releases a version is maintained
(01:45:37) nwessel: not each?
(01:45:40) CarlosRuiz: in such case we just need to define X and Y
(01:46:08) nwessel: ok, so we could say that we always provide working upgrade path to next m-version
(01:46:13) nwessel: (m=maintained)
(01:46:18) CarlosRuiz: in my draft proposal I said / X=4, Y=3
(01:46:18) CarlosRuiz: we release every 4 months, every 3 releases is maintained (meaning every year we release a maintained version)
(01:47:30) CarlosRuiz: but it's just draft / if you like the approach, we can try to define a better X and Y
(01:47:30) CarlosRuiz: some people didn't like the 4 months and called me crazy ;-)
(01:47:30) CarlosRuiz: others prefer monthly
(01:47:33) nwessel: is there any background to that definition??
(01:47:47) hengsin: I prefer 6 month
(01:47:54) nwessel: I mean are the numbers chosen at will=
(01:47:55) nwessel: ?
(01:48:00) CarlosRuiz: X=2 Y=2 ?
(01:48:14) CarlosRuiz: yes, nwessel, no study behind those numbers
(01:49:04) CarlosRuiz: I trust with QA on /release every version will become more and more quality
(01:49:04) hengsin: I guess each person need is different, I prefer a 6 month cycle and don't really care whether a release is called a maintained or not maintained release
(01:49:54) CarlosRuiz: yes, some implementors tend to auto-maintain the release they choose, but I think there are like 100 users out there following community patches
(01:50:02) phib: 1 maintained release a year is enough for us
(01:50:22) CarlosRuiz: 10 minutes to go ...
(01:50:24) phib: our customers don't tend to rush into upgrading
(01:50:52) phib: OK, can we do away with the alpha/beta/stable tags
(01:50:57) phib: they scare people off
(01:51:29) CarlosRuiz: I think if you share the concept, we can make a poll on community to ask for X and Y
(01:51:29) CarlosRuiz: to release it's not a hard thing - to maintain is a little hard
(01:52:06) phib: CarlosRuiz, I agree
(01:52:15) nwessel: Carlos, I do not think that it is up to community to decide that but up to the people who need to deliver the releases
(01:52:37) nwessel: each release is work and needs to be good
(01:52:52) nwessel: when we ask community we are back again in the field of wishes
(01:52:56) CarlosRuiz: you're right Norbert
(01:52:56) CarlosRuiz: releasing is easy - but if we add the inventory feature, then it becomes hard
(01:53:08) nwessel: exactly
(01:53:11) phib: ok poll the developers
(01:53:16) nwessel: thats better
(01:53:18) nwessel: :-)
(01:53:36) nwessel: or set up a list of maintainers and ask them
(01:53:52) nwessel: we once said that features must be backed up by maintainers
(01:53:55) CarlosRuiz: :-) or poll the release group :-) even easier, if we're the most interested and probably who are going to be in charge
(01:54:51) nwessel: I suggest to start with long cycle. we can increase later
(01:55:01) viola [~viola@p57A1DBDF.dip.t-dialin.net] entered the channel.
(01:55:05) nwessel: 1 maintained per year and 2 unmaintained
(01:55:15) nwessel: is that the smallest we can agree upon?
(01:55:16) phib: +1
(01:55:26) nwessel: hengsin?
(01:55:28) hengsin: +1
(01:55:31) CarlosRuiz: ok, let's try that
(01:55:39) CarlosRuiz: that means every 4 months - right?
(01:55:39) viola: hi all
(01:55:46) CarlosRuiz: Hi Jörg
(01:55:47) nwessel: hi Jörg
(01:56:01) hengsin: hi Jorg
(01:56:14) CarlosRuiz: ok - let's try if we can define this on the remaining 5 minutes
(01:56:29) nwessel: Carlos, that means every 12 months a maintained and every 6 months an unmaintained
(01:56:49) nwessel: am I wrong?
(01:57:09) phib: nwessel, no
(01:57:39) nwessel: if releasing is easy we can change that anyway
(01:58:12) CarlosRuiz: 1 maintained and 2 unmaintained per year, means 3 releases per year, meaning every 4 months.
(01:58:12) CarlosRuiz: the other proposal: can we get rid off about the "quality status" (alpha, beta, stable) - and instead accompany every release with the list of features and its status?
(01:58:31) nwessel: yes, good point
(01:58:58) CarlosRuiz: that would mean that for the next release the most important task becomes the inventory of features
(01:59:00) nwessel: I thought that we release m- and u-versions same time
(01:59:10) nwessel: right
(01:59:19) nwessel: that is what everybody is waiting for
(01:59:39) nwessel: so we have a consense
(01:59:52) CarlosRuiz: yep, we just need to put a date for the next release :-)
(02:00:13) nwessel: shall we do our next meeting next wednesday?
(02:00:13) CarlosRuiz: and close the meeting :-)
(02:00:20) nwessel: to keep up the pace?
(02:00:29) hengsin: carlos: can we touch on the coordination with official extension ?
(02:00:45) hengsin: I think that's critical for making a release
(02:01:34) CarlosRuiz: Heng Sin, now, or in architectural meeting?
(02:01:34) CarlosRuiz: Norbert, sure, we can meet next wednesday to keep the pace
(02:01:42) nwessel: ok
(02:01:54) hengsin: the coordination should be a release task, right ?
(02:01:59) nwessel: do you update the calendar or can I do it?
(02:02:18) CarlosRuiz: doing it now ...
(02:03:29) CarlosRuiz: sent
(02:03:40) trifon has left the channel (quit: Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100214235958]).
(02:03:52) phib: hengsin, wouldn't extensions just mirror the main release?
(02:04:21) phib: release schedule, i mean
(02:04:51) CarlosRuiz: ok, if you agree we can close the release meeting and start the architectural one
(02:04:51) CarlosRuiz: next wednesday we review the date and coordination with extensions
(02:04:59) CarlosRuiz: agree?
(02:05:12) phib: yes
(02:05:32) viola: only to put a little pressure;-) 8GMT is quite a fixed ending time for me, so can we start arch meeting?
(02:06:26) nwessel: thanks, bye
(02:06:40) phib: bye
(02:06:50) CarlosRuiz: thanks Norbert, you can stay if you want - all meetings are open
(02:07:17) viola: :-| hope I didn't disappoint them
