It's not a matter of liking it or not, it's what is practical. It's not feasible to have a deadline that does not give projects caught in the middle time to do their builds and tests. There must either be more time built in to the process or the final build must give way.
Please point me at the documentation describing exactly what you say below.
The later you are in this chain (+0 ... +3 ... EPP) the more you like it if upstream deadlines are met. And I know what I am talking about. EPP takes the +3 output as input for the packages, and the +3 output is the final p2 repository in /releases/staging. This was scheduled for Wednesday and we are already a day behind this deadline.
Maybe it wasn't communicated clear enough but +3 is the last opportunity for projects to deliver their content to the Simultaneous Release Train, not the EPP-needs-to-have-the-packages-ready date. Friday is not only release date for RC1, it is also RC2+0 day!
Regards, Markus On 20 May 2010 15:48, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
Well, I don't think this is reasonable. I requested status on DSDP TM yesterday and received no reply, nor any estimate on when it would be ready. I don't see how you can expect a "simultaneous" release to work if downstream components are not give time to complete their builds when their dependent components are two days late.
If you plan to have an arbitrary 10am cutoff then you should document it. The release plan says Helios EPP is today, which implies COB to me.
The PTP build that is in RC1 at this stage is the same as the M7 build. So RC1 is useless for us.
Regards, Greg On May 20, 2010, at 9:28 AM, David M Williams wrote:
> Given that some projects are this late I think it's
reasonable to allow dependent projects some extra time to do their build.
Sorry, we're done. With RC1. Guess you could claim an
early start on RC2? :)
For any exceptions at this point, you'll need to ask your
PMC and planning council representative to champion an exception for your
case.
This might be unreasonable, but ... maybe not. Here's
why.
First we've heard about it (already past the deadline,
other wheels in motion).
My assumption is you and dsdp tm delivered _something_
to RC1, even if not the latest you wanted to do.
Its a common technique (at Eclipse) to always meet deadlines,
at the expense of slipping function. (This is what allows the complicated
train of dependencies to stay on track, for the next increment).
There are exceptions, of course, that's why we have an
exception process.
But, I think its important to stick to the fundamental
principles.
But, I appreciate you keeping us (and adopters, and early
testers) informed, even at this point, that your content for RC1 is not
as you'd hoped.
Thanks very much,
We have not been able to build against all RC1 components
because DSDP TM only completed their RC1+1 build this morning. Given that
some projects are this late I think it's reasonable to allow dependent
projects some extra time to do their build.
Regards,
Greg
On May 20, 2010, at 3:50 AM, Markus Knauer wrote:
10 AM (Eastern) for the staging repository
- if there is a small problem/error it will cause a delay, but I am confident
that it can be done...
10am - 11.30am -> time frame for building the EPP repo
11.30am +++ -> build the final packages, package maintainer can test
and sign off immediately when their package drops out of the build
Friday 1am -> copy the packages to the mirrors
Friday XX pm -> enable package download for all packages that received
a "+1" until then
The consequence of this is (but that is no difference to the last milestones)
that a "-1" vote of a package results in disabling it on Friday's
release. If possible I would try to fix such a "-1" package,
rebuild it and add it some time next week to the download packages, but
that needs to be decided as the case arises.
Thanks and regards, Markus
On 20 May 2010 07:42, David M Williams <david_williams@xxxxxxxxxx>
wrote:
Late again? A little.
There is a fairly final /releases/staging repository, but has a few problems:
1) I had to remove teneo, since it was failing in a way that would fail
whole build .... and Martin Taal contacted me right before I went to bed
:) saying he thinks he has it fixed and has started a rebuild.
2) Riena has a bad pack.gz file, so its set of bundles are incomplete.
Christian Campo is actively looking into it .. but he just got up :)
3) And ... I just noticed from hudson log ... a new (late) contribution
from MPC!?: bug 308687: [releng] include MPC contribution
So, I'm willing to check in morning, and promote one more ... if everything
is perfectly successful. Otherwise, we'll have an RC1 with what we have
right now and ... well, we'll see how it looks Thursday morning.
I'll set 10 AM (Eastern) as a hard cut-off ... we will be done by then,
one way or the other. Oh ... and no one else please use this as an excuse
to add some new build/fixes. If your building now, leave it alone and
don't risk breaking anything.
If anyone (Markus?) has any concerns with this slightly extended deadline,
please just say so. I personally am fine with what we have.
And, team, let's please put the "simultaneous" back in simultaneous
release, and everyone be on time next week. Or, at least, _you_ write the
long note like this one to cross-project explaining why you are late.
Thanks all,
_______________________________________________
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|