Possible git reset needed to fix history
by Stanislav Ochotnicky
Heya all,
as has happened before...it's happened again :-/ fedora-review repo (devel
branch) has become a mess due to recent cross-merging.
We can either let it be or fix it by resetting devel branch to commit b80cd0
(NEWS: update from Alec) and then rebasing issue-212 on top of that + add latest
commit from Alec. Amount of work is quite minimal, but this would of course
break all clones out there + Jenkins would have to be reset (this is a minor
issue though).
I *really* hate to reset things and break peoples' clones, but current history
is confusing as hell. If you feel strongly one way or the other, reply. I'll
wait a few days before reset.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
10 years, 8 months
[fedora-review] Bug 989946: what plugins are we running?
by Alec Leamas
Seems that this bug [1], together with yesterday's libvoikko issue has
opened a can of worms. Since the discussion seems to be rather general,
it might make sense to continue here on the list.
Trying to summarize some aspects, the first is how we make the decision
what plugin(s) to run:
- If we base decisions on the sources, we should use buildsrc IMHO. We
should not care about things removed in %prep.
- Shouldn't the basic strategy be to check in what's in the rpms?
- How much should we handle pitfalls such as java packages putting
.class files into a .zip container?
- Could we assume that the GL are followed? Then we could just look
into %javadir and %jnidir to check if this is a java package...
Next aspect is user feedback on what plugins are run:
- Stan's approach is a short note why a certain plugin is activated (see
bug)
- Another way might be to focus on what plugins are run or not rather
then why.. Something like
Active plugins: generic, java
Disabled plugins: ruby, C/C++, R, perl, python, php
- In any case, we need better logs describing why plugins are activated
or not.
Finally, if we provide feedback like above it should be possible to
tweak the list of running plugins. Something like
--plugins/-P e. g., -P java:off,C/C++.
If a plugin is listed here the on/off value basically overrides the
automatic is_applicable() decision.
Just my 5 öre
--alec
[1] https://bugzilla.redhat.com/show_bug.cgi?id=989946
10 years, 8 months
