Hi, David
Some clarification:
1. As Anas said, most of the projects in https://gitorious.org/meego-boss are
staging
ones, which will be moved back to the official place, say,
http://meego.gitorious.org/meego-infrastructure-tools
2. For boss.git, notify participant, and ruote-amqp-pyclient, Li Yi and I
created clones from the "upstream" ones,
based on the commit point which we are using in current production
environment.
Why?
Because these projects had many dramatically changes in the last several
months with incompatibility. Our
production instances can be be updated or upgraded frequently. We need
keep the compatibility in a safer places.
I think it is also the typical work model of open source projects.
3. I feel there are not too many overlap parts of the deployment of MeeGo
production cycles and the Nokia environment.
Most the "official" part of changes and document are focused on Nokia env
only, and we can not learn the details
until now. So the running components in MeeGo env were developed and
deployed based on our own understanding and
feature requirement.
For these incoherent parts, I think we need not to merge together.
4. We DO try to and like to merge back the changes to the "upstream" git
tree, if the changes are compatible and
valuable. Of course it is just in a start stage, but it will be more
frequently and fluently, I hope.
5. For SF MeeGo conference, I DID like to go there to meet you guys to talk
about the BOSS. But the committee didn't
think my BOSS related presentation was important enough:)
Thanks
- jf.ding
On Sat, Jun 11, 2011 at 05:00:44AM +0800, David Greaves wrote:
> Hi all
>
> It's good to see continued interest in BOSS and the associated participants.
>
> I see that several of the projects have been cloned (well, not cloned, just
> copied for some reason) at:
> https://gitorious.org/meego-boss
> and there is some active development there.
>
> I do hope the plan is to co-operate with the upstream team - we're really not
> that far away ... #meego and #meego-arm usually :)
>
> There are commits going back to January ... and as far as I'm aware we've
> never
> really been approached to discuss how these tools are evolving in MeeGo RE.
> We've had a couple of merge requests (incidentally - gitorious doesn't seen
> to
> notify very well so if you talk to us we'd look at them a *lot* faster). I
> know
> Islam has made several enquiries about changes to your tools but we didn't
> get
> any reply.
>
> There must be some mistake because I'm sure the RE team would *never* ignore
> the
> "work with upstream" policy they ask others to follow.
>
> In fact I was only vaguely aware BOSS was being used in MeeGo RE - and that
> is
> decidedly odd considering I'm the architect for them and have presented on
> the
> tools at both the MeeGo conferences. You can even see how some people would
> get
> a little paranoid about here :)
>
> I know Intel pulled the entire RE team from the SF conference - maybe we'd
> have
> had a chance to discuss it there ... sadly we'll never know.
>
> Anyhow, as you may know we're hoping to provide a more productised
> installation:
> http://wiki.meego.com/Release_Infrastructure/BOSS/Installation
>
> Would it make sense to simply join our team and talk directly about your
> requirements?
>
> For example it would be nice if the work in could be aligned with :
> http://wiki.meego.com/Release_Infrastructure/BOSS/Roadmap
>
> So... what do you think? Can I expect some more communication and some
> proposed
> patches?
>
> David
>
> --
> "Don't worry, you'll be fine; I saw it work in a cartoon once..."
> _______________________________________________
> MeeGo-packaging mailing list
> [email protected]
> http://lists.meego.com/listinfo/meego-packaging
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
