[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
|
> First, I need to find location of proper dependency versions
> to build for luna, kepler and juno (we have N-1 compatibility policy).
> Second, I need a way to know if these dependency repositories go
> stale and need to be updated.
It's actually not that difficult once you get setup doing this. For
Sapphire, we are currently building against 12 different targets (Indigo
through Luna, including all SR levels and separately for 3.8 and 4.2
variants of Juno). Once a target definition references released binaries,
you don't have to ever touch it again, so for instance, now I am only
updating Kepler SR1 and Luna targets.
> This still does not solve the problem of reproducible builds, but
> I don't it's possible to have reproducible builds and build against
> latest versions of dependencies at the same time, i.e. these two
> requirements are mutually exclusive.
Not mutually exclusive at all, but you do have to take explicit steps to
move up to newer builds of your dependencies. For Sapphire, the first step
in producing the milestone contribution is to update the target to milestone
contributions of the dependencies. That triggers a build and we test that
build.
Thanks,
- Konstantin
-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Igor
Fedorenko
Sent: Wednesday, August 21, 2013 10:46 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
Again, I am not arguing against building with individual dependency
repositories. All I am saying there is currently no convenient way to do
this and I don't have the time&resources to maintain such fine-grained
dependency configuration. I am particularly concerned about two problems.
First, I need to find location of proper dependency versions to build for
luna, kepler and juno (we have N-1 compatibility policy). Second, I need a
way to know if these dependency repositories go stale and need to be
updated.
One way to address these is to require each participating project provide
separate repository URL they recommend for use as build target for each
yearly release and make list of these URLs documented somewhere.
This still does not solve the problem of reproducible builds, but I don't
it's possible to have reproducible builds and build against latest versions
of dependencies at the same time, i.e. these two requirements are mutually
exclusive.
--
Regards,
Igor
On 2013-08-21 12:51 PM, Konstantin Komissarchik wrote:
> Note that due to Equinox changes in Luna M1, this is a particularly
> dangerous time to not be building with Luna components when
> contributing to Luna.
>
> One of the primary reasons that it is bad to build against Luna simrel
> repo as opposed to particular builds of all dependencies is that an
> in-progress simrel repo is a moving target. This breaks a fundamental
> releng tenet by making builds not reproducible and requires the
> project team to remember to manually trigger a build just before
> contributing or risk contributing something built with stale
> dependencies. Note that these issue can be fixed quite easily by producing
versioned simrel repos that are never modified...
> Doing this will not address all issues with using simrel repo as a
> build target, but it will make such strategy less fraught with problems.
>
> - Konstantin
>
>
> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Igor Fedorenko
> Sent: Wednesday, August 21, 2013 8:36 AM
> To: cross-project-issues-dev@xxxxxxxxxxx
> Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
>
> Theoretically, yes, it does open possibility for bad things to happen.
> In practice, however, this worked for us for last three releases. If
> there was an easy way to consume current simrel dependencies from the
> build, I'd certainly do it, but I am not willing to spend any time on
> this when building against previous simrel repo works good enough.
>
> --
> Regards,
> Igor
>
> On 2013-08-21 10:08 AM, Doug Schaefer wrote:
>> I'm with David on this one. The simrel repo is supposed to be the
>> aggregation of all the project builds. If you are building against an
>> old simrel repo, chances are you aren't building against the bits
>> that will appear with your bits in this round's simrel repo. Doesn't
>> that open up the potential for bad things?
>>
>> Doug.
>>
>> On 13-08-21 7:29 AM, "Igor Fedorenko" <ifedorenko@xxxxxxxxxxxx> wrote:
>>
>>> I did the same, too. I simply don't have the time needed to maintain
>>> list of project-level repositories and will build against kepler
>>> until I can switch to luna simrel repo.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On 2013-08-21 4:05 AM, Marcel Bruch wrote:
>>>> Maybe it would help if project could publish a (stable) URL of
>>>> their latest Luna artifacts on a common wiki page? I had trouble to
>>>> find all dependencies and features to set up our target platform
>>>> accordingly two weeks ago. So decided to build the software against
> Kepler instead.
>>>>
>>>> Best,
>>>> Marcel
>>>>
>>>> On Aug 21, 2013, at 9:57 AM, David M Williams
>>>> <david_williams@xxxxxxxxxx <mailto:david_williams@xxxxxxxxxx>> wrote:
>>>>
>>>>> Yes, has been discussed before, and I said "bad idea", because
>>>>> anyone building for the Luna repository, should not be building
>>>>> against the Luna repository.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: Eike Stepper <stepper@xxxxxxxxxx
>>>>> <mailto:stepper@xxxxxxxxxx>>
>>>>> To: cross-project-issues-dev@xxxxxxxxxxx
>>>>> <mailto:cross-project-issues-dev@xxxxxxxxxxx>,
>>>>> Date: 08/21/2013 03:49 AM
>>>>> Subject: [cross-project-issues-dev] Pre-M1 Aggregation Repository
>>>>> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
>>>>> <mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -----
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I noticed that an empty Luna repository had been created some time
>>>>> after the release of Kepler. An empty repository is not really
>>>>> useful as a source for build dependencies and I wondered if it
>>>>> would make sense in the future to seed the new repository with the
>>>>> old content. Would it? Has it been discussed already?
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://www.esc-net.de <http://www.esc-net.de/>
>>>>> http://thegordian.blogspot.com <http://thegordian.blogspot.com/>
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cross-project-issues-dev mailing list
>>>>> cross-project-issues-dev@xxxxxxxxxxx
>>>>> <mailto: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
>>>>> <mailto: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
>
> _______________________________________________
> 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
