On 6/25/20 1:18 PM, Ben Cotton wrote:
Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.
I would like to counter propose that we make ed the default editor :P
___
devel mailing list -- dev
On 6/25/20 1:54 PM, Randy Barlow wrote:
I would like to counter propose that we make ed the default editor :P
Just in case it wasn't clear, I was joking here. I support nano as a
default. Let's make Fedora easier for new users, especially those who
are new to the command line an
On 7/3/20 12:41 PM, Chris Murphy wrote:
# rm -rf/var/lib/mysql/
# mv/var/lib/mysql2/ /var/lib/mysql/
## resume operation
BTW this should be proofread/sanity checked, especially because
there's an rm command (that will fail in the original).
You also might need a restorecon after this, since
Hello!
I would like to become a Fedora package maintainer. I've long been a
proponent of Free Software, and have been a Fedora user for about three
years now (Gentoo before that, and Red Hat before that). I work at Red
Hat as a contributor to the Pulp project:
http://pulp.readthedocs.org/
I've b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/07/2015 01:37 PM, Randy Barlow wrote:
> I've filed a request to add a new package called ari-backup:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1269609
My package reviewer and I had some questions about whether the
perm
st a
configuration file. Do you think that would be a good way to go?
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/ma
7;ve missed the answer to
this question in an obvious place.
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproj
w
VPN connection so that it knows to use the VPN-provided DNS server for
hosts on that particular domain, rather than the usual external records
for that same domain?
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital sign
write
depends on as part of a normal dnf upgrade. Backwards incompatible
changes should be reserved for Rawhide.
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
deve
here or on the ticket.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1287148
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.
ng the same hours so far. I'll keep looking out for him, good
to know that he is signing in occasionally!
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedora
to get in touch with you. I'm rbarlow in
FAS, and I look forward to working together on mongoengine. Thanks so much!
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fed
tag is at
least greater than 0.0.2016 ☺
What is the collective wisdom with problems like this? Is this situation
what the epoch is for (i.e., version schemes changing)?
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital
Thanks to everyone who replied!
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Hello Adam!
I have noticed that the Koji build of the "cloud vagrant libvirt" box[0] found
at [1] doesn't boot. The console just says that it's waiting for the disk.
I scanned through the page at [1] but I didn't see a section that was
specifically dedicated to documenting problems that are spe
we have quite a few that are
waiting for review.
Once those packages are all available in Rawhide, we will start working
on getting ejabberd >= 16.1 packaged, which should silence the error
e-mails we get every day ☺
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bow
Ben Cotton wrote:
> When speaking to technical people, there is no "close enough" except
> for "entirely and unassailably accurate". :-)
Hermes Conrad, you are technically correct, the best kind of correct.
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
ir
friendly reminder of this policy because I'm
concerned about the stability of Fedora and EPEL. Thank you for reading!
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
deve
Randy Barlow wrote:
> I just
> wanted to send out a friendly reminder of this policy because I'm
> concerned about the stability of Fedora and EPEL. Thank you for reading!
I was corrected by fale in #fedora-devel (Thanks!) that there is a
formal policy for releasing backwards-incomp
Hello my fellow Fedora friends!
It's 01:00 in my local time and perhaps I should be resting instead of
trying to figure out chicken-and-egg problems at such a time, but my
tired mind is on the fence about the solution to one of my tickets and
I would love the input of others:
https://bugzilla.red
Hello again Fedora friends!
I just built bodhi-2.1.8-1.fc26 for Rawhide, and wanted to give you a
heads up as it is a backwards incompatible change. Rawhide previously
had bodhi-0.9.12.2-5.fc25.noarch so this is a pretty major update.
The bodhi client is probably what most of you are used to inte
I forgot to mention, I'm also maintaining a Copr for Bodhi 2 for Fedora
23 and 24:
https://copr.fedorainfracloud.org/coprs/bowlofeggs/bodhi/
Copr doesn't seem to have Fedora 25 buildroots yet, but I'll try to
remember to add Fedora 25 as well once it does.
signature.asc
Description: This is a di
On Thu, 2016-09-01 at 20:45 +0200, Fabio Alessandro Locati wrote:
> The F24 copr seems to be broken. I've enabled it, updated all
> packages
> and running 'bodhi', it seems to be broken:
>
> pkg_resources.DistributionNotFound: The 'bodhi==2.1.8' distribution
> was
> not found and is required by t
I've filed an issue to track this problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1372461
Thanks again!
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraprojec
Thanks to a lot of help from fale and puiterwijk, I've now built bodhi-
2.2.0-1.fc26 in Rawhide and it should be pushed out soon. This update
is not backwards compatible, so it will only go out to Fedora Rawhide
and EPEL 7 (with special permission). If you would like to use the
bodhi 2 client on Fe
On Sun, 2017-02-12 at 18:27 +0530, Parag Nemade wrote:
> I've got one nodejs module package in need of review. I will be happy
> to review your package requests in return.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1408105
I've taken it. I've got quite a few open review requests, so take you
Hello!
In working on packaging Ampache, I found a dependency that has a
bundled version of this file:
https://github.com/kazuhikoarase/qrcode-generator/blob/master/js/qrcode.js
I started working on doing the right thing and packaging that file
separately, but it seems that the repository also ha
Thanks for all the input! I went with the popular option of calling it
qrcode-generator and inviting comaintainers to add subpackages in the
future if they desire:
https://bugzilla.redhat.com/show_bug.cgi?id=1422344
signature.asc
Description: This is a digitally signed message part
__
On Thu, 2017-02-16 at 09:36 -0500, Steve Grubb wrote:
> Yesterday I built a security update for the suricata package, 3.2.1-
> 1:
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=10021
>
> Any time I try to create the bodhi new release, it finds an older
> build, 3.2-1.
> Typing the
On Fri, 2017-02-17 at 05:08 +, Zbigniew Jędrzejewski-Szmek wrote:
> Filing bugs for transitive FTBFS during a mass rebuild isn't
> particularly helpful as it is done now.
I think it is helpful, because even if it is not the fault of the
package that failed to build, the package does still need
Hello Fedora devs!
Today I deployed Bodhi 2.4.0 to production. It's got a few new features
and some bug fixes. You can read the release notes here:
https://github.com/fedora-infra/bodhi/blob/2.4.0/docs/release_notes.rst#240
If you find issues with Bodhi, please let us know!
https://github.com/f
On Tue, 2017-02-28 at 23:39 +, Richard W.M. Jones wrote:
> I get this doing 'fedpkg update':
>
> fedora.client.bodhi.BodhiClientException: Unable to create update.
> Authentication required
>
> It's unclear what authentication is required, but I have a valid ssh
> key and live Kerberos ke
Hello!
During a package review[0], I suggested that a CLI application's header
files need to go into a -devel subpackage (they are currently not being
packaged, except for the -debuginfo subpackage.) The reviewer
disagrees, but fedora-review uses the word must. I went to the
packaging guidelines[1
On Tue, 2017-03-14 at 22:55 +0100, Michael Schwendt wrote:
> The review is highly misleading, and the latest spec file does not
> include any headers in the package:
>
> %files
> %license COPYING
> %doc EXTENDING.html FAQ NEWS README
> %{_bindir}/arduino-ctags
> %{_mandir}/man1/arduino-c
Hello!
I would like to unretire nodejs-grunt-contrib-copy[0], and have filed a
package re-review:
https://bugzilla.redhat.com/show_bug.cgi?id=1432995
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1432995
signature.asc
Description: This is a digitally signed message part
_
On Fri, 2017-03-24 at 13:38 +, Petr Pisar wrote:
> third-party == from different host (bodhi.fedoraproject.org. !=
> taskotron.fedoraproject.org.).
The JavaScript that loads the taskotron results from resultsdb is in
Bodhi, not taskotron:
https://github.com/fedora-infra/bodhi/blob/2.4.0/bodhi
On Fri, 2017-03-24 at 15:37 -0400, Matthew Miller wrote:
> Oh good — this was going to be my comment… having different main
> contacts and package admins might be.
Oh good — this was going to be my comment ☺
I do like and use the ability to have bug reports for different
branches go to different
On Mon, 2017-03-27 at 12:26 +, Petr Pisar wrote:
> Or are these test failures expected to be delivered through FMN only?
This is currently how they are handled. I have my FMN settings
configured to send these to me over IRC and that works well for me.
However, I don't believe that is the defau
On Wed, 2017-05-03 at 19:51 -0500, Richard Shaw wrote:
> I have two packages which I got notifications that they were
> "ejected" from the push…
> Bodhi is giving me the option to push it to testing again but the
> koji tag is already showing f26-updates-testing...
This was due to a Bodhi mash ru
vagrant-hostmanager has changed its license from MIT to MPLv2.0 with
version 1.8.6:
https://github.com/devopsgroup-io/vagrant-hostmanager/compare/v1.8.5...v1.8.6
Due to this, I only plan to release 1.8.6 on Rawhide[0].
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1447820
signature.asc
Descr
On Fri, 2017-05-05 at 09:46 +0200, Vít Ondruch wrote:
> I love this well explained license changes: "Ah, removing file
> extension, that is good opportunity to change the license as well" :)
> https://github.com/devopsgroup-io/vagrant-hostmanager/commit/e97bc6fd
> 169bed754755d8f3f68786610ef48281
On Fri, 2017-05-05 at 19:41 +0100, Michael Young wrote:
> See https://bugzilla.redhat.com/show_bug.cgi?id=1445294 and in
> particular
> the patches linked to in Comments 6 and 7.
Indeed, I'm working right now at getting a bodhi-2.6.2 update released.
Also, Patrick has made a python-fedora-0.9 rel
The following updates address the bodhi client issue:
Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=887188
F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-26b2a7f9ba
F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d069d3faf9
F24: https://bodhi.fedorap
On Fri, 2017-05-05 at 17:35 -0500, po...@pouar.net wrote:
> Though according to the Fedora Wiki, they say to "inform upstream".
> Should I do this first before creating a review request for the
> package or wait until the package is approved?
You can do it in either order - it's more about introdu
There is a common issue that people have been hitting with the Bodhi
CLI. If you've been seeing lots of HTML printed to your terminal and a
traceback that mentions HTTP 403 codes, the following updates will
help:
Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=887188
F26: https:
Hello!
I had an idea for a summer internship project, but I wanted to ask my
fellow Fedora devs if something like this already exists so it doesn't
get created as a duplicate project.
The idea is to create a dnf plugin that would allow you to do this:
$ sudo dnf upgrade FEDORA-2017-30604deb62
T
On Fri, 2017-05-19 at 15:34 +0100, Sérgio Basto wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1234930#c18
>
> claims that dnf equivalent of “yum update --security” is available in
> dnf 2.something
>
> also
> https://unix.stackexchange.com/questions/221983/dnf-equivalent-of-yum
> -update
On Fri, 2017-05-19 at 11:48 -0400, Matthew Miller wrote:
> Yeah, I just tested and this works:
>
> $ sudo dnf upgrade --advisory FEDORA-2017-f590422f5b
Fantastic! I'm bummed that I now need a new idea, but I'm glad this
exists because I will use it ☺
The Koji thing could be cool, but it is getti
On Fri, 2017-05-26 at 08:33 +0200, Zdenek Dohnal wrote:
> I asked about this message on IRC #fedora-admin channel and they told
> me
> this message should disappear after future updates (no specific
> version
> wasn't told).
I wrote a bit about this here:
https://bugzilla.redhat.com/show_bug.cgi?
On Fri, 2017-05-26 at 13:04 -0400, Charalampos Stratakis wrote:
> Seeing this also on my F25 machine.
Hmmm, I'm not sure why, but I don't see this on my F24 machine with the
bodhi client (which has the same version of bodhi and python-fedora
though obviously a different release since it's F24):
$
On Fri, 2017-06-02 at 21:42 +0200, Pierre-Yves Chibon wrote:
> What do you think?
Bodhi also currently cares about users being in the packager group to
decide whether they can create buildroot overrides (I think, not
actually 100% sure). It uses pkgdb to decide whether a user has access
to create
On Sat, 2017-06-03 at 09:32 +0200, Pierre-Yves Chibon wrote:
> Bodhi I believe also check this, maybe Randy could confirm this.
I think I just answered this in another e-mail. Let me know if you need
more info.
signature.asc
Description: This is a digitally signed message part
___
On Sun, 2017-06-04 at 08:50 +0200, Pierre-Yves Chibon wrote:
> Do you think we could change this to check:
> - has the user rights on that particular package?
> - is the user a member of the packager group?
I believe it does both of these currently.
signature.asc
Description: This is a digitally
On Thu, 2017-06-08 at 22:17 +0200, Adam Samalik wrote:
> You add the package and other people start to use it. That's great
> until you need to change the version, but can't, because other people
> started to use it as a dependency and it would break their stuff.
I recently heard that it will be i
On Fri, 2017-07-07 at 11:55 -0500, Adam Miller wrote:
> My question to the Fedora Contributor Community is, how should we
> handle this?
I am guilty of doing this a few times in a couple of my packages. My
reasons when I did it were that I didn't know the version, and didn't
know an easy way to de
The upstream for erlang-p1_pam has changed their license from GPLv2 to
ASL 2.0 in version 1.0.1[0]. I almost missed it since that's a .z
release! I plan to make that update only on Rawhide[1] (to version
1.0.3).
[0] https://github.com/processone/epam/blob/master/CHANGELOG.md
[1] https://bugzilla.
On Mon, 2017-07-10 at 11:40 -0500, Adam Miller wrote:
> The main motivation for bundling as of late is golang[0], it's
> extremely common out in the community for software to pull in
> "Vendored" libraries even if they are exact copies of remote
> upstreams
> (this is common with tools like godep[1
On Thu, 2017-07-13 at 00:36 +0200, Kevin Kofler wrote:
> Koji will take care of the signing for Flatpaks
> built in Koji as it does for RPMs built in Koji.
Sigul[0] is actually the system that signs the packages. They are
placed into a Koji tag when they need to be signed, and when Sigul is
done
I forwarded this to vjancik at his personal address.
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel
should be
considering? Am I a special snowflake?
[0]
https://fedoraproject.org/wiki/Packaging:Conflicts#Potential_Conflicting_Files
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
Description: OpenPGP digital signature
--
devel mailing lis
point too. I think I will invest a little time in seeing
if I can figure out how to do this today.
Thanks so much for your input. I'm a new Fedora packager and I'm also
new at Erlang, so I appreciate your perspective!
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: b
s/ejabberd rbarlow DENIED
by fallthru
remote: error: hook declined to update refs/heads/rbarlow-16.01
Is there a way for me to remove this branch, or is it going to be there
permanently?
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
signature.asc
D
erlang-p1_zlib-1.0.1 has changed the license from GPLv2 to ASL 2.0. I'm
making the change in the spec file as needed, but thought I'd mention
here just in case there's something more I should do.
--
Randy Barlow
xmpp: bowlofe...@electronsweatshop.com
irc: bowlofeggs on Freenode
There are some good thoughts in this thread. A few people have
suggested that getting the update process to go faster would really
help with these problems, and I agree.
Patrick Uiterwijk has recently made quite a few contributions to Bodhi
that a) make it more reliable, and b) allow it to gate on
On Fri, 2016-10-28 at 10:15 -0400, Mike Miller wrote:
> My GitHub username
> is milleruntime.
Welcome Mike! Your username made me chuckle…
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedorapro
Hello fellow Fedora developers!
I wanted to inform you all that our change proposal for adding non-RPM
artifacts to Bodhi[0] is not going to be done in time for Fedora 26 as
was previously planned. There are simply too many things on my plate
for Fedora 26, and so it's been decided that we'll have
Hello Friends!
Igor and I were having a discussion on a package review ticket[0] about
how to handle a bundled library that seems to have no upstream that
either of us can find, and for which we don't know its version!
According to the packaging guidelines, it is OK to bundle the library
in certa
On Sat, 2016-11-26 at 06:26 +0100, Ralf Corsepius wrote:
> I have been trying to push a package chain consisting of 2 new
> packages,
> which are required to update a 3 package, to Fedora:
>
> The first package hit "the freeze". It took ~3 weeks to make it to
> fc25
> stable. The second package
On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> Additionally, via GSSAPI many browsers allow you to seamlessly login
> to any of our ipsilon using applications simply by clicking on the
> login
> button ( bodhi, fedorahosted trac, elections, fedocal, mailman3, etc)
This is fantastic,
On Mon, 2016-12-12 at 14:33 -0700, Kevin Fenzi wrote:
> First, I'll note you don't need to get a new ticket every day, you
> can
> just renew with 'kinit -R'. I am not sure what env kinit needs, but
> you
> may even be able to do this from a cron job. That will work for 1
> week.
You can even use
Hello!
I maintain ejabberd and I've got an issue filed about ejabberd's
policykit policy being desktop-centric[0]. I've done some reading about
how I could alter the policy to make it so that it doesn't expect the
user to be at a seat, but I can't help but think that sudo is a great
way to handle
On Wed, 2016-12-21 at 09:42 +0100, Ralf Corsepius wrote:
> > The fontconfig cache files are placed onto /var/cache/fontconfig
> > now.
> > this seems incompatible with the ostree model. so this is a
> > proposal
> > to move it to /usr/lib/fontconfig/cache.
>
> This proposal likely is incompatible
On Wed, 2016-12-21 at 12:08 -0500, Matthew Miller wrote:
> I see that the fc-cache data is arch-specific, but is it really
> host-specific? What if we just pre-generated it at *build* time and
> put
> it into /usr/share or /usr/lib? I guess that'd end up making font
> files
> archful, but that's no
On Wed, 2016-12-21 at 20:16 +0100, Mattia Verga wrote:
> Second question: I've uploaded new sources by using the new kinit
> method, but I see that the sources are actually double uploaded
> (upload
> reaches 100% and then restart again a second time). Is that normal?
I also noticed this change,
Hello fellow devs!
I recently unorphaned python-ipdb and in working to get it updated to
it's latest release I noted that upstream's license has shifted from
GPLv2+ to BSD with their 0.9 release (Rawhide currently has 0.8.3). I'm
working on updating Rawhide to 0.10.1, but I will leave F24/25 on
0.
On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote:
> Which definitely changes how software is built.
Containers also change the way software must be written in some cases,
since they expect there to be one main process and don't expect that
main process to interact with other "main" process
Hello Fedora devs!
I recently started working on getting Ampache packaged for Fedora, and
it turns out it is no small feat. There are two problems:
0) 5 of the packages have been abandoned upstream, and have been
replaced with different packages that are now recommended. Ampache is
aware of this
On Mon, 2017-01-16 at 10:30 -0500, Matthew Miller wrote:
> > BTW, perhaps another way is to use bundled versions for these, to
> not
> > expose them as something "stable and maintained".
>
> Yeah, I was going to make this suggestion too. Seems like a
> reasonable
> use of bundling — having them se
On 4/1/20 11:25 AM, Felix Schwarz wrote:
I don't want to presume too much but I just hope you researched why packagedb
was decommissioned and why people thought integrating the functionality into
pagure was a good idea?
pkgdb was decommissioned because modularity needed a lot of changes
across
On 4/1/20 1:16 PM, Adam Williamson wrote:
Has it been demonstrated that either Pagure or Gitlab CE are
"not viable" for the purposes Fedora needs?
Hey Adam!
I agree with you that Pagure and Gitlab CE are both viable for Fedora's
needs in terms of feature matrices and requirements. We have shi
On 4/2/20 3:03 AM, Adam Williamson wrote:
At the outset of this whole mess, quite a lot of people said "well this
is obviously just all a pretext for dropping Pagure and going to hosted
Gitlab". Much offence seemed to be taken at this, and much was made of
this absolutely not being the case at al
On 4/3/20 1:53 PM, Neal Gompa wrote:
Honestly, the main app I have trouble seeing a broader community for
is Bodhi. It*could* be done, but I'd have to sit down and do a fair
bit of work to figure out what parts are "Fedora-only" verses
"Fedora-favored". It speaks volumes that even*Red Hat* does
On 4/3/20 3:08 PM, Leigh Griffin wrote:
It may have caught that for sure but it would have opened a lot more
problems as stakeholders try to counter each others requirements with
new more specific requirements to influence the decision.
This is how software development is *supposed* to work. I
On 4/3/20 4:41 PM, Leigh Griffin wrote:
This is how a specific flavour of software development works centered on
a singular product, with a shared vision. The CPE relationship with
stakeholders is unique, it's clear the visions are not aligned across
all bodies (and we do not expect it to be) a
On 4/4/20 3:02 PM, Aoife Moloney wrote:
However we do
recognize that it was still nonetheless a decision that was not made
in public, and for that we can only now offer our apologies for this
mistake and learn a hard lesson from it.
It's simply not true that this is the only thing that can be d
On 4/6/20 6:13 AM, Leigh Griffin wrote:
CPE is entirely unique in this industry and is not perfectly aligned to
the idealistic software engineering process, we are getting there.
No software team is perfectly aligned to the idealistic software
engineering process. CPE is not unique in that eithe
On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how
the team historically worked.
It's a classic no-no to start an apology with "I'm sorry *if you*". It's
not an apology at all, it's a defense disguised as an apology. It is
thus dishon
On 4/6/20 6:41 AM, Leigh Griffin wrote:
We are engaged with the Fedora Council on the next steps here for the
adoption of Gitlab / the retirement of Pagure from the CPE remit. That
much of the decision has been made, the actual specifics are what we are
engaging on to make sure that the Fedora
On 4/6/20 8:28 AM, Miro Hrončok wrote:
I think it's hard to see who's vocal against GitLab and who just wants a
truly open decision process for this.
I've heard people who would love to get GitLab, but who are genuinely
sad about how CPE management handled this.
This. I personally actually l
On 4/6/20 10:36 AM, Leigh Griffin wrote:
Answering 100+ replies individually is engaging with the community.
Happy to stop that if people aren't seeing the benefit of it though.
Writing 100 e-mails isn't automatically "engagement".
I could reply to what you wrote above with "If I had a world o
On 4/6/20 11:02 AM, Leigh Griffin wrote:
Ok let's scenario this out so as several people want us to restart and
go again, largely because they disagree with the decision and Pagure is
the choice that they would have made.
Much of the consternation is due to you not having employed an open
pro
On 4/6/20 11:17 AM, Leigh Griffin wrote:
It's a form of engagement among others that we are partaking in day in
day out, week in week out.
Ironically, you have illustrated my point here with your response, which
isn't engagement.
I have answered every question directly, if I missed one in th
On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how
the team historically worked. As a team we are being tasked more and
more with adding what I call real value which is at a new app / service
level that has scale, quality and requiremen
On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote:
> I even go as far as reverting branch-only commits and then doing the
> bidirectional merge trick to restore fast forwardability. That of
> course
> clobbers the branch-only changelog section and replaces it with the
> one from
> master, bu
On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> No. Resolving conflicts implies that you need to do an actual merge,
> NOT a
> fast forward. Fast-forwarding means that I am shipping the SAME
> commit on
> all branches, so the changelog must be identical (unless I play games
> with
> %if
On Fri, 2019-10-11 at 14:34 -0700, Adam Williamson wrote:
> That seems like a personal call, really. I very much like being able
> to
> keep branches in sync without merge commits as it means I can do
> stuff
> like:
>
> for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i;
> git
> pu
On Thu, 2019-10-03 at 19:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> > As pointed out elsewhere, we would have fewer conflicts if we could
> > get
> > the version, release, and changelog out of the spec file, and then
> > I
> > think maintaining different spec in different release branches
> > w
On Thu, 2019-10-17 at 03:53 +0200, Kevin Kofler wrote:
> The user-friendly approach for that is to use a parallel-installable
> compatibility package (with a suffixed Name, such as django1.6)
> instead of a
> module.
I've always liked Gentoo's solution to "too fast too slow" (which has
been arou
On Thu, 2019-10-17 at 08:08 -0400, Stephen Gallagher wrote:
> One of the (often un- or misinformed) major arguments people keep
> using against Modularity is "it makes packaging harder!". This is one
> place where it makes things *much* easier on the packagers. It's a
> clear reduction in complexit
On Thu, 2019-10-17 at 11:19 +0100, Peter Robinson wrote:
> It doesn't obsolete it if it's already transitioning from testing ->
> stable because it's basically not in "testing" state. This happens
> all
> the time even during the usual cycle, it's generally just not seen
> during the usual cycle be
1 - 100 of 422 matches
Mail list logo
