Submitters complain more and more about the spam they're getting from
staging projects - and we rather leave that weapon for actual feedback.
One especially annoying case is if a package is added to one staging project
and then later moved to another, the submitter will receive notifications
of all kind of bots and actions for both staging projects.
Distinct copyrights were left as I do not wish to track down commit
history to ensure it properly documents the copyright holders. Also left
non-GPLv2 licenses and left bs_copy untouched as a mirror from OBS.
Already have a mix of with and without headers and even OBS does not place
on majority of files. If SUSE lawyers have an issue it will come up in
legal review for Factory.
These methods provide for a generic place to store meta data related to
a project. For the time being, keep the original :Staging/dashboard
location for openSUSE products.
OBS likes to not follow its API documentation and tends to ignore the
specific attribute option and returns everything. This results in
returning the first element that lxml decide to match to the pattern.
Not sure if OBS broke this recently, or if #1573 was poorly tested.
Human eyes can vertically. One does not write math homework like:
1. y = mx + b
b = y - mx
or
1. y = mx + b
b = y - mx
one write it
1. y = mx + b
b = y - mx
Right now we require a Staging subproject to use staging plugin, which
is suboptimal especially for maintenance requests. The OBS attributes allow
to store the things right attached to the project - and the permissions
can be controlled in parallel to the maintainers right, which gives us
enough freedom
Implementation virtually accept the delete request, the delete request will be
added another delreq-review review and also wipes the binary in the main
project, the backend will sync 'nothing' to ToTest and Snapshot after all. Once
all repository has no binary then remove the package in real.
The variable project might got changed through
map_ring_package_to_subject(), according to release process, we have to
given the origin project path to set_review() always.
* Create sub-package in case an adi request is multiple specfile package
* Use the consistent workflow in rm_from_prj(). The main package must to
through map_ring_package_to_subject() like what it did in
submit_to_prj()
The new logic is introduced, the description is below:
* If adi package: return sub-package list according to the specfiles
of main package.
* If ring package: return sub-package list by showlinked call and the
sub-package must be in another ring.
* The others: return empty list, no reason to return anything or even
checking it in the devel project. Otherwise selecting a non-ring
package to a letter staging probably would created unneededsub-package.
