| Re: [dsdp-mtj-dev] MTJ SR1 work |
I'm in agreement. But I also must say that this is where the hard work comes in... maintenance and backwards compatibility...
On 6/26/09 1:47 PM, Eric Hildum wrote:I really do not believe that we should wait a year to expose new functionality provide that we maintain very, very good backwards compatibility. There is a lot of functionality that is currently private that we intend to make public, but could not in the Galileo timeframe due to time pressure. I think this is all candidate for release prior to next year.
Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Developer Platforms and Services
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
809 11th Avenue
Sunnyvale, CA 94089
USA
On Fri, Jun 26, 2009 at 11:41 AM, Craig Setera <craigjunk@xxxxxxxxxx> wrote:
I think our best bet is to build the new functionality out on trunk. From there, we can argue risk/reward of moving functionality over to SR1.
While I understand that it is not traditional to do lots of new work for a service release, I think we need to be realistic in the needs of some of the consumers of the MTJ platform. If there is something that a consumer absolutely must have in order to consume MTJ (and therefore get more involved in MTJ), then we have to think seriously about whether we make them wait another year. On the flip side, I think we need to get a good feel for how much benefit there is to the project in terms of additional involvement from consumers before we do add new features to a service release.
Craig
On 6/26/09 1:37 PM, Eric Hildum wrote:If we are moving existing private APIs public, I think we should be able to do that without a separate release branch. Entirely new APIs may be a different matter.
Eric Hildum
Senior Product Manager, Mobile Developer Tools & SDK
Developer Platforms and Services
Ecosystem and Market Development
Motorola
Direct: +1-408-541-6809
809 11th Avenue
Sunnyvale, CA 94089
USA
On Fri, Jun 26, 2009 at 6:28 AM, Gorkem Ercan <gercan@xxxxxxx> wrote:
We should have a limit on the new functionality and APIs we bring in on a maintainance release. It does not matter much what is the release number, I think we still need a 1_0_maintainance branch. Some lighter new functionality and bug fixes can happen in there. And HEAD can be used for the next major release. This is basically the practice on most Eclipse projects and I do not think we have strong enough needs for doing it differently.
--
Gorkem
On Thu, Jun 25, 2009 at 4:57 PM, Paula Gustavo-WGP010 <wgp010@xxxxxxxxxxxx> wrote:
I mean that we could do a MTJ 1.1 on Galileo SR1. As far as I understand there is no problem to add APIs on this service release and, if we add new APIs, it should be a 1.1 release instead of a 1.0.1 isn’t it?
J
Gep
De: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em nome de Gorkem Ercan
Enviada em: quinta-feira, 25 de junho de 2009 10:53
Para: Mobile Tools for The Java Platform mailing list
Assunto: Re: [dsdp-mtj-dev] MTJ SR1 work
Do you suggest that we must chose either 1.0.1 or 1.1. I think both should happen. I guess 1.1 release will happen together with the Eclipse Helios simultaneous release.
By the way, is not having the 1.0.1 release even an option since MTJ is part of Galileo? http://wiki.eclipse.org/Galileo#SR1
--
GorkemOn Thu, Jun 25, 2009 at 4:40 PM, Paula Gustavo-WGP010 <wgp010@xxxxxxxxxxxx> wrote:
Hi guys,
Sorry for joining the discussion late. I was deeply involved in the past weeks on closing the final release (both on pulsar and MTJ) and didn’t have a lot of time to look at the next steps.
I think that it is a good time that we can have another call to talk about the next steps. A clear decision is what is the next MTJ version? 1.0.1 or 1.1?. If we plan to add the new API / extension to register the SDKs, then it should be 1.1
I will check with Eric / Christian a good time for them and we can send a proposed date / agenda.
One additional thing to have in mind on those “next steps” is the proposal that was sent to DSDP PMC list a couple of days ago (http://dev.eclipse.org/mhonarc/lists/dsdp-pmc/msg01766.html ). This proposal talks about moving the “pulsar” code that now is on MTJ to a possible new project. This is still a proposal, but is important that we also consider it.
Internally we are also thinking about some possible features that we can do on SR1 timeframe.
J
gep
De: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] Em nome de Gorkem Ercan
Enviada em: quinta-feira, 25 de junho de 2009 10:27
Para: Mobile Tools for The Java Platform mailing list
Assunto: Re: [dsdp-mtj-dev] MTJ SR1 work
I think the tag is in place I see a 1.0GA tag on SVN. So we need a 1.0.1 branch. I guess we can branch the plugins as needed if the plugin receives a new development (or a breaking fix). If everybody agrees
--
GorkemOn Thu, Jun 25, 2009 at 4:17 PM, Craig Setera <craigjunk@xxxxxxxxxx> wrote:
I would agree. I would:
* Expect that we would tag 3.5 and create a branch for 3.5.1.
* The tag doesn't move.
* Pure bug fixes go on the 3.5.1 branch.
* New development goes on trunk.
* If we decide to ship something in 3.5.1 that isn't a pure bug fix, we agree amongst the team (via this email list) and then merge it to the 3.5.1 branch from trunk.
This is the way I've tended to do this type of work in the past and believe it is the correct approach. The question is whether we have tagged and branched yet? This is something any committer could do, although I won't have time until this weekend (at least).
Craig
On 6/25/09 8:01 AM, Gorkem Ercan wrote:Now that Galileo is out. Is the HEAD open for new development now?
Craig, I think your suggestion is to use the HEAD for both bug fixes and new features. Am I correct? IMHO It is better to branch for service release because it would allow us to be more liberal with the new features. I guess we can always backport some of them to SR branch
--
Gorkem
On Thu, Jun 18, 2009 at 10:33 PM, Jon Dearden <jdearden@xxxxxxx> wrote:
Craig, is there a general mechanism available in the API for validating user data entered into vendor-specific JAD properties?
Cheers,
Jon
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: Friday, June 12, 2009 9:31 AM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] MTJ SR1 work
What are we thinking in terms of additional features/functions for this point release? I know that that isn't all that standard for most Eclipse projects, but given that we are still trying to get all of the basics in place it seems we might want to consider it. I'm thinking, in particular, that I might like to try to find the time to go back and finish out the SDK provider extension point work I started.
If we are starting point release work, do we have appropriate source control branches in place?
Craig
On 6/11/09 1:07 PM, Eric Hildum wrote:Everyone, we have had a very successful development and release of MTJ1.0. Thank you all for your hard work and contributions.Even though Galileo has not been officially released yet, I think itis time we start looking at the work for SR1. Looking at the currentbug list for MTJ, I see 42 open bugs at this time. Some of these wedefinitely need to resolve for SR1, others it is not clear to me thatthey are still valid or at the right severity/priority. Could we alltake a look at the open bugs and:1. See if they are still valid. If not, would the reporters please close them2. Check to see if they have the correct severity/priority.3. Make sure that we have correctly identified and recorded inBugzilla the correct blocking/depends on relationships4. Update the reports with any additional information that may have come in.Also, I noticed that at least one bug has a valid patch but seems tobe moving into new problems. Could we close the initial problem reportas that has been fixed, and open a separate bug report so we can keepthe bugs on a single topic?---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________dsdp-mtj-dev mailing listdsdp-mtj-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________ dsdp-mtj-dev mailing list dsdp-mtj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________ dsdp-mtj-dev mailing list dsdp-mtj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev