Am Montag, 31. August 2020, 13:14:04 CEST schrieb Simon Lees:
On 8/18/20 6:19 AM, Christian Boltz wrote:
> Am Montag, 10. August 2020, 12:22:50 CEST schrieb Lubos Kocman:
[Community access to Jira]
We'll initially have rather a smaller pool of
users (initially 10)
and will grow it over time based on the popularity. Just FYI: The
standard size of the pool for partners is 2, so openSUSE is being
taken seriously as a partner here.
Let me play devil's advocate, and also warn you that the following
paragraph might contain traces of sarcasm ;-)
Let me maybe play devil's advocate back.
That's fine, I already wondered if/why nobody dares to answer ;-)
In the good
 old times ;-) of FATE (aka features.o.o),
was able to submit a feature request and to see feature requests by
community members. And now you are telling us that we should be
thankful that 10 selected people will get access, and maybe that
number will increase? Of course, 10 is better than nobody, but IMHO
the perfect number of people allowed to access Jira would be ∞ ;-)
I think the problem here was more while everyone could create a
feature request, no one was reading them let alone thinking about
I know this was a problem, but - playing devil's advocate again - why
should this be different/better just because we switch to another tool?
And I still think only allowing 10 community members to access Jira
would be a serious problem.
atleast now they are going into a tool where
someone will probably look at them, let the maintainer know about
them and maybe provide some feedback.
I guess that still needs someone who assigns the request to the
maintainer, so where's the difference to FATE/openFATE?
everybody to access JIRA could have benefits for both SUSE
and the community. For example, with more people having access,
maybe someone would accidently stumble over a feature request, and
help to implement it? Or someone comes up with an idea for _the_
feature that would generate lots of money for SUSE, but doesn't
want to do the paperwork to get access to JIRA?
It would have benefits, but I'm not sure they outweigh the excessive
costs that would be required to purchase a license that would allow
every member of the community simultaneous access.
I guess when the product management team were considering the tool
they wanted to use they didn't consider needing that number of
licenses and considered a bunch of features jira provides over the
competition as really important.
I can't imagine (well, at least I hope) that the product management team
didn't have openSUSE in mind when choosing Jira over $alternatives.
But if the costs are the only problem you see - AFAIK Atlassian also
provides a community license . I don't know the exact conditions and
requirements, but in general, we could ask for a community license for
openSUSE, which should help to solve the costs argument.
And even if openSUSE doesn't qualify for a community license for
whatever strange reason, I still think that giving access to all
communiy members would be worth the price.
[ Personally I wonder why we (both SUSE and openSUSE) need a separate
tool for tracking feature requests at all. I'd simply do everything in
bugzilla, maybe with a separate "feature requests" product. And yes, I'm
aware that bugzilla doesn't let managers do their paperwork (or
"workflow") games they like so much in FATE and now Jira and ECO ;-) ]
I also have a
question: which feature requests will the selected
openSUSE contributors be able to see? Those reported by other
openSUSE contributors (would be similar to FATE/features.o.o), or
also feature requests reported by other partners?
(You can probably guess my prefered answer, but I also understand
that other partners might want to have their requests kept
My guess is GDPR will mean that only the later, and its reasonable to
expect that some others are under NDA so certainly not all.
Please don't abuse GDPR as an argument ;-)
GDPR always has the option of permitting something, so if some partners
are willing to make their requests public, GDPR won't stop them.
NDAs are of course a different beast.
Backports and openSUSE Leap code submissions will have
the same experience as now. With the exception that you'll be able
to use just one submit request target for more convenience and
reusability as there will be one build used for both Package Hub
So technically Leap will be (with very few exceptions, like
equal to SLE + Package Hub?
Package hub could end up linked to the version in tumbleweed,
I don't like this idea - it would make Leap a half-rolling release
(unless the maintainers take explicit action, as in your fish/fish3
example), and that's not what people expect from Leap.
maintainer could choose to keep an older version, ie not upgrade to
the next major version until the next major Leap release, for example
fish shell version 3 breaks alot of config so I decided its not
suitable for inclusion in a minor leap version (but I created a fish3
package for people who want it) in this case I informed the package
hub team and package hub has both, but that might not always be the
This would be more or less a regular way to update an
0) The contributor reports a bug or logs in to jira.suse.com
files a partner feature request for new features.
JIRA request can still be created by TAM (Lubos) if there would be
any problem (e.g. missing access etc). User (and other openSUSE
contributors who requested JIRA access) see updates in JIRA.
That sounds like additional paperwork. Is this really needed for
each and every SR that goes towards SLE?
Disclaimer: I've seen a "nice" example of that paperwork with a
somewhat late AppArmor submission for 15.2 and might therefore be
overly sensitive. I have no idea if this was "typical" paperwork or
if I just had bad luck ;-) OTOH, earlier submissions didn't need
such paperwork - or the SLE maintainer did all the paperwork
without telling me.
As you mention here if the SLE package maintainers are aware
request and can easily justify it for SLE and would like to see it
included i'm sure we will try and find the way of including it with
the least amount of paperwork (atleast I don't like doing unnecessary
My latest experience was slightly ;-) different (the details are
probably worth a story to tell with a beer^Wglass of wine in reach) and
I'm not completely happy about the result - but maybe it was just bad
luck and/or bad timing (too close to the freeze).
And to make it clear: this is not meant as a complaint about that
maintainer - several earlier submissions were accepted without problems.
Submissions to SUSE Linux Enterprise* are a bit more
tricky due to
the project inheritance, as packages are coming from older SLE
Service Packs, respective its ":Update" projects.
That means that it won't be uncommon that the user will be
code against for an example openSUSE Leap 15.3 during the Early
phase, however, in the end, it's going to be a submission for
SUSE:SLE- 15-SP1:Update. Such submission may require additional
approval or will result in a fork in the latest Service Pack of
So I recommend all users to use "osc origin" to check where does
package come from, to avoid any surprises later on.
- in your example, what would be the correct target of the SR?
- can't that be automagically handled via OBS redirects?
To make this easier, here's a practical real life example, as far as I
can see dbus-1 has updated versions for SLE-12-SP3, SLE-12-SP5 and
SLE-15-SP1 but not SLE-12-SP4 or SLE-15-SP2. I don't create a new
version of the package for each release because then there would be
more places where i'd have to backport security features, this costs
time and money. Right now if I need to fix a security issue for
dbus-1 by just updating the SLE-15-SP1 package I can fix it in
SLE-15-SP1, 15-SP2 and 15-SP3, While because 15-GA-LTSS is a separate
package id have to fix that manually.
Now if you have a new dbus-1 "feature" for leap 15.3, I have two
slightly different choices A. if it seems like it fixes an issue I can
probably convince the maintenance team just to accept a fix for
SLE-15-SP1 which will also fix everything later, If its not a "fix"
but I still think its useful for older versions I can do lots of
paperwork and fill out the ECO* Lubos was talking about in that case
someone who gets paid much more then me gets to make the call on
whether it is acceptable.
If its not then we get option B. Where I need to create a new version
of the package for SLE-15-SP3 which could increase maintenance cost
especially for some packages so again that additional cost needs to
be taken into account, we might decide it is worth it for that
feature or we might need to do a new version of that package for
other reasons (if this is the case I can probably slip in minor
features with almost no paperwork). On the other hand there might be
some cases where we decide the feature (especially a minor one) isn't
worth the cost of having another version of the package and we might
choose to defer the feature until next time we actually need to
branch the package for another reason and atleast make sure its in
tumbleweed so it automagically finds its way into SLE-16.
Thanks for the explanation, it makes things more clear, and highlights
the "fun" of handling multiple releases, especially if they share the
same version of a package.
However, I still wonder if this could be somehow automagically handled
so that someone who submits for example an update for 15.2 can just do
that without doing any lookups before.
Just as an idea - maybe osc could ask something like
The package you just submitted is equal in 15.1 and 15.2. Do you
want to submit to a) 15.2 b) 15.1 c) both?
 Ask your favorite search engine for "powered by a free Atlassian
Jira open source license", and you'll get a long list, for example
Apache, Linux Foundation, MariaDB, Moodle, and it seems even Fedora
Natürlich kann ich Traktor fahren. Ich bin der geborene Traktorfahrer.
Es dürfte dir schwer fallen, jemanden zu finden, der annähernd so
perfekt Traktor fährt wie ich. Ja, ich _bin_ geradezu ein Traktor.
Wieviele Räder hat so ein Traktor eigentlich? [Ratti]
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org