On Wed, 31 Jul 2019 at 13:25, Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Mi, 31.07.19 12:57, Tomasz Kłoczko (kloczko.tom...@gmail.com) wrote: > > > As usually that type of versioning convention is rubbish and it only adds > > more work on packaging layer. > > Why you guys did not released that as v243.99 ? > > I like my bikesheds blue. > Yes. Today is a bit sunny in London. Thanks for asking .. and ignoring that rc<num> versioning convention adds some overhead on packaging layer. Your bikeshed argument is really powerful so I can only give up. > Other thing is that looks like systemd devel cycle elongated and it cased > > that some stabilisation fixes are only committed in master branch with > all > > other changes. > > > > Proposal for next systemd devel cycle: > > - create devel branch and commit all devel changes in that branch only + > > stable fixes > > - commit in master branch only stable fixes and release more ofthen > v244.1, > > v244.2 and so on (one time a month or even more often depends on > importance > > of the fixes) > > - release candidates starting from v244.99 > > - when everything in devel will be ready just merge devel branch to > master > > and tag it as new major release. > > Are you volunteering to do the work for this? Or do you just expect us > upstream to maintain twice the amount of releases? > > We don't want to be consumed in just doing release mangament. It's > hard enough, and we definitely prefer if developers focus on one > master, not many, and stop developing new stuff while we are in release > mode. This means, doing parallel branches for upstream development is > not in the cards, sorry. Either everyone stabilizes or everyone works > on new stuff. > > Note that there's a "stable" backport tree maintained outside of the > main repo: > > https://github.com/systemd/systemd-stable In other words you asking me voluntary do the job which is already done. Nice. OK, I'll take that job. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
