<mithro>
FFY00: The best way to convince people to write tests is to make not having tests affect them :-)
<FFY00>
the things is that most users won't write tests for you
<FFY00>
*thing
<FFY00>
if the tests are missing and you release manually you will still have the same issue
<mithro>
FFY00: That might be true for things like desktop window managers and stuff -- but for developer tools that is a lot more likely
<FFY00>
well, it would still affect them
<mithro>
FFY00: And if releasing manually isn't giving you an advantage, then why do it?
<FFY00>
at least in my projects I usually merge things gradually
<FFY00>
and it doesn't make sense to make a release with an incomplete feature
<FFY00>
don't know if that happens in litex
<FFY00>
the point here is that tests can pass but you still have bugs
<FFY00>
if you let the patches sit in master for a few days they will be tested by actual users
<FFY00>
I don't see how that is a bad thing
<mithro>
FFY00: We only have a small number of users at the moment, the best way to get users to test things in a couple of days is to get them all using head -- splitting the community into people on head and people on a release means a bug is going to take much longer to be found
<FFY00>
right, then use a slower release model
<FFY00>
the users that want the new features will use head
<FFY00>
the users that need reliability will use the release
<FFY00>
you can also do release candidates
<FFY00>
that's a good way to get users to test
<FFY00>
they update to the release candidate to start adapting to the new changes and report bugs if there are any
gregdavill has quit [Ping timeout: 256 seconds]
gregdavill has joined #litex
Degi has quit [Ping timeout: 250 seconds]
Degi has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<zyp>
does litex even do releases?
tcal has quit [Remote host closed the connection]
<zyp>
for my embedded projects I generally keep all dependencies as git submodules from the project repo, at which point it doesn't really matter whether a revision is tagged with a release number or not, I'll grab whatever works and have the features/fixes I need
<zyp>
automated tests are good to determine in advance what might work, version tagging doesn't really add anything for me on top of that
<zyp>
speaking of, does anybody use litex as a git submodule? I get the impression that it's expected to be installed in a virtualenv or something, which is not the way I would like to do it
<zyp>
there doesn't seem to be any problem using it as a submodule though, just pointing PYTHONPATH at it, so that's the approach I'm leaning towards, but it'd be useful to hear if anybody else did something similar
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 272 seconds]
HoloIRCUser1 has quit [Ping timeout: 256 seconds]
CarlFK has quit [Ping timeout: 256 seconds]
CarlFK has joined #litex
rohitksingh has quit [Ping timeout: 256 seconds]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 256 seconds]
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 240 seconds]
HoloIRCUser has joined #litex
gregdavill has quit [Ping timeout: 256 seconds]
_franck_ has quit [Ping timeout: 240 seconds]
spacekookie has quit [Quit: **agressive swooshing**]
spacekookie has joined #litex
_franck_ has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 272 seconds]
<FFY00>
zyp, not yet, that is the reason of the discussion
<FFY00>
I was asking for releases
<FFY00>
zyp, if that works for you, great
lolsborn has joined #litex
<FFY00>
but IMO litex tag commits that should be stable
lolsborn has quit [Client Quit]
<FFY00>
that way instead of pinning to a commit, you pin to a release
<FFY00>
if need newer features you can still pin to a newer commit
<FFY00>
*if you need
CarlFK has quit [Quit: Leaving.]
rohitksingh has joined #litex
tcal has joined #litex
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Read error: Connection reset by peer]