Oberhuber, Martin schrieb:
Hi Eike,
If your Bucky Builds are cool,
can you produce an update site (p2 repository) for anybody to consume
(i.e. manually through p2 > Install Additional Software...)?
If you can do that, then
manually contributing a *.build file for M4 should not be the problem?
This file is quickly written.
Seems like manually contributing
for M4 is easier than making the case for an exception just to get
builds perfect and fully
automated?
Or am I missing something?
No, you seem perfectly right. I'll do so ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Martin
David M Williams schrieb:
Eike,
This list is the "human readable"
way to do that and I appreciate the "advance" notice.
There is also a field in your
projects meta-data that should (still) be marked before the deadline,
as that's the formal record keeping mechanism for the EMO.
I updated these fields (version and simultaneousrelease)
already.
So, now for the hard part.
First, we (the Planning Council)
agreed this year we'd have a exception process to go through (as
opposed to me just deciding from my benevolent throne on high :)
The process is basically for you
to convince your Project Leads and then your PMC that it is a good
thing to do, and if they agree, your PMC rep to Planning Council would
bring forward the exception, make the case, and the PC would vote. It
does not have to be unanimous ... we said 3 pluses and no negatives.
(For this case, this could happen
on the PC mailing list, or at our next PC meeting on 1/6).
Oh my goodness! People hate me for loving fat processes, but I'd really
wish a proper workflow tool to support this djungle :P
I cc'ed Ed (my PMC)...
Second, how to make the case for
an exception. You definitely don't want to blame the build system ...
that's never a good excuse to miss a milestone!.
Why not?
Instead you want to focus
on what value you bring to the release,
A better build system.
and how it'd be worth
deviating from the rules for your case and that it would cause no or
little harm (you don't have any downstream dependents, I assume?
Not yet.
If you did, that'd be
much worse, as you'd "drag them down" too). Also, you should spend some
time detailing the factors that caused the lateness, and how you are
correcting those factors in the future.
I don't expect to change the build system that frequently in the future
;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
In other words, can you
make us trust this is a one time thing, or an ongoing pattern of
unpredictability. At least, those are all some of the things I'd look
for if I were evaluating a request for an exception.
Let me know if I've misunderstood.
Thanks again. Keep us posted.
Hi Dave,
Can I declare my intent to participate (again) with the EMF CDO and EMF
Net4j projects through this mailing list? Our new Buckminster builds
are cool but we're still working on the headless tests and it's already
clear that we won't manage to contribute something for M4.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
David M Williams schrieb:
1. its next Friday, 12/18!
2. That's the deadline for expressing intent to participate in Helios,
which is formally done by marking the simultaneousrelease flag in
Eclipse Portal (there's a Helios field to edit to "1"). The list is
currently (understandably) short, so I'll keep my eye on it, and send
more nag notes if expected teams don't mark soon.
modeling.amalgam
modeling.emf.compare
modeling.emf.eef
modeling.m2t.acceleo
rt.jetty
rt.swordfish
stp.sca
technology.egit
technology.subversive
tools.ptp
webtools
3. I suggest we not "announce" our individual Project milestones until
the Helios M4 date, 12/18. Of course, we need to announce on mailing
lists, etc., for our committers and adopters ... I just mean the
general news items, forums, and similar, targeted to general end-users
asking for early testing. That is what we have to do for the final
release, and I suggest we get in the habit of working "simultaneously"
now, even during milestones. Not a huge problem, but I do recall some
issue in the past where there were complaints or questions, because
someone tried to update part of their environment, but couldn't, since
some other part had not release an M4 version yet. Ends up being
frustrating and making us appear unorganized. (And we all know that's
not true :)
Thanks,
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
