2016-10-18 12:21 GMT+02:00 Andreas Färber <afaer...@suse.de>:
> There is nothing to try out in a Staging project here, this is all about
> creating JeOS-raspberrypi2 and JeOS-raspberrypi3 in Factory!
That is completely unrelated. The point is that you're changing a
project that is supposed to be stable without agreeing on a consensus
*before* doing so and then expect the maintainer to clean that stuff
up. This is the part htat is upsetting me.
> conflicts by name with any Contrib projects it is deprecating, whomever
> may have maintained them previously. As you may have read, Guillaume and
> me tested out images from my home project before I flipped the switch
> for :Factory:ARM.
again, I'm not talking about Factory:ARM.
>> I think this violates the rule that "JeOS-flavor link diff should be
>> empty" rule.
> Well, I did not create JeOS-raspberrypi2 that way. ;) And my point was
> about "one", not literal "JeOS".
I explained why it was created that way by me.
>> What I would have liked to see here instead is the
> Good idea, if we disable the JeOS package like I did in :Contrib:HEAD.
That is unrelated, it doesn't have to be disabled. when it is enabled
you can look at the build result as well.
Why did you choose to use two different solutions for two contrib
projects? if the point was to cleaning it up, then make it more
similar than before. now its just awkward imho.
> No, in order to have an official JeOS-raspberrypi2 in :Factory:ARM this
> is _not_ temporary.
3rd time. I do not talk about Factory:ARM at all.
> I believe the :Factory:ARM JeOS package should not contain unnecessary
> cruft for Contribs *whenever* there are upstream images. In that case
> IMO the Contribs should be abandoned as soon as the upstream images are
> usable - which for rpi2 will be the case with vc4 and USB.
Which is fine by me. my point is that we don't make contribs more
complicated than they are now or change non-staging projects without
testing things in Staging first. I personally spent already way too
many nights on fixing the random regression because someone thought
some change somewhere would not affect anything else, but it did.
> to keep maintaining a Contrib package, but don't complain about the
> burden the duplication poses then.
Why is it so complicated to discuss things before they are done?
> Alex however suggested that we might rename the downstream images after
> an upstream image exists, so that they can be maintained in parallel in
> :Factory:ARM with no link diffs in the other projects.
I think we should just always have a -Contrib- in the image name when
it is a contrib image. this way the occassional mail chatter about
"well, which image exactly did you use from where?" is solved.
> fighting against the awkward list of IS_FLAVOR_raspberrypi3 ||
> IS_FLAVOR_raspberrypi3_tralala, so the only sane way around it would be
> to reuse my $flavor vs. $flavor_type trick as for _aarch64, together
> with some other #define where really needed to distinguish; the kernel
> name can be already checked today to distinguish upstream and downstream
> for anything but raspberrypi3_aarch64. It just doesn't allow to
> distinguish Staging from non-Staging downstream, and wouldn't the whole
> point of Staging be to test the same, not just similar code paths?
I don't think you need to do anything in that area, this can be done
automatically by the build service rather those crude hacks.
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org