* stable/v2.29.1
@ 2017-01-18 13:12 Karel Zak
2017-01-19 10:32 ` stable/v2.29.1 Bernhard Voelker
0 siblings, 1 reply; 6+ messages in thread
From: Karel Zak @ 2017-01-18 13:12 UTC (permalink / raw)
To: util-linux
The branch stable/v2.29 contains what I want to release as v2.29.1.
Any objections or suggestions? See log below.
Karel
Andreas Henriksson (3):
chrt: default to SCHED_RR policy
sulogin: make getpasswd(...) return NULL on ^D
sulogin: bail out from getpasswd(...) on timeout
Joe Hansen (1):
po: update da.po (from translationproject.org)
Karel Zak (18):
sfdisk: don't be silent when list non-existing device
sfdisk: cleanup --dump error messages
docs: nsenter(1): add missing 'see also' for --user
hwclock: don't check for permissions
build-sys: prefer pkg-config for ncurses
fdisk: don't be silent when list non-existing device
build-sys: cleanup UL_NCURSES_CHECK
more: avoid double free() on exit
findmnt: error on --target /non-exist
lib/linux_version: fix stupid typo
lscpu: add aarch64 specific names
libsmartcols: add scols_cell_get_alignment()
libfdisk: recount size when apply user device properties
libfdisk: (gpt) make calculations more robust
po: merge changes
docs: update AUTHORS file
docs: update v2.29.1-ReleaseNotes
build-sys: release++ (v2.29.1)
Michael Kerrisk (25):
docs: nsenter(1): Describe the 'file' argument used by namespace options
docs: nsenter(1): Formatting fix
docs: various pages: Use "system call" not "syscall"
docs: kill(1): Fix section reference for sigqueue(3) and add to SEE ALSO
docs: kill(1): Add more detail on use of SIGTERM vs SIGKILL
docs: kill(1): Rework notes on thread groups
docs: kill(1): Formatting fixes
docs: kill(1): Wording fix
docs: renice(1): Rework discussion of unprivileged users,
docs: renice(1): Remove obsolete BUGS text
docs: various pages: Format pathnames as italic (.I)
docs: various pages: Use consistent terminology (set-user-ID and set-group-ID)
docs: various pages: Use "ID" not "id" in man pages
docs: various pages: Use "PID" not "pid" in man-pages
docs: various pages: Use 'UID" and "GID", not "uid" and "gid" in man pages
docs: kill(1): Wording fix
docs: namei(1): SEE ALSO: add symlink(7)
docs: taskset(1): Wording fix
docs: last(1): SEE ALSO: add reference to wtmp(5)
docs: last(1): Eliminate oddball formatting
docs: lsns(8): SEE ALSO: add namespaces(7)
docs: ionice(1): SEE ALSO: add ioprio_set(2)
docs: mount(8): Wording fix
docs: renice(1): Add SEE ALSO entry for sched(7)
docs: renice(1): Add credentials(7) to SEE ALSO
Michael Kerrisk (man-pages) (12):
Fix typo in page cross reference (capabilities(7), not, capability(7))
Place SEE ALSO entries in order
Correctly format page cross references
Fix page cross references
Fix section number in lockf() page xref
Fix reference for scheduling discussion
Fix formatting errors in page cross references
Replace reference to sigvec(2) with sigaction(2)
SEE ALSO: add cross reference to namespaces(7)
Provide better cross references for namespace concepts
Provide better cross references for namespace concepts
IPC namespaces also isolate POSIX message queues
Nate Clark (4):
disk-utils/mkfs.minix: Set ninodes after checking max
libblkid/minix: Match minix superblock types
libblkid/minix: Use same checks for version 3
libblkid/minix: Sanity check superblock s_state for v 1 and 2
OGAWA Hirofumi (1):
lsns: Fix parser for /proc/<pid>/stat which is including space in comm
Rafael Fontenelle (1):
po: update pt_BR.po (from translationproject.org)
Ruediger Meier (3):
build-sys: fix empty package release number
build-sys: update package release number during development
build-sys: don't clean *.img files
Stanislav Brabec (1):
If mtab support is disabled, disable ro/rw mtab checks
Stéphane Aulery (1):
po: update fr.po (from translationproject.org)
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stable/v2.29.1
2017-01-18 13:12 stable/v2.29.1 Karel Zak
@ 2017-01-19 10:32 ` Bernhard Voelker
2017-01-19 11:35 ` stable/v2.29.1 Karel Zak
0 siblings, 1 reply; 6+ messages in thread
From: Bernhard Voelker @ 2017-01-19 10:32 UTC (permalink / raw)
To: Karel Zak, util-linux
On 01/18/2017 02:12 PM, Karel Zak wrote:
> The branch stable/v2.29 contains what I want to release as v2.29.1.
General question:
Is it worth dealing with maintenance branches in the upstream repo?
I mean, downstream projects can cherry-pick fixes and improvements
to their own needs anyway. So I think having one upstream mainline
would be sufficient. WDYT?
Have a nice day,
Berny
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stable/v2.29.1
2017-01-19 10:32 ` stable/v2.29.1 Bernhard Voelker
@ 2017-01-19 11:35 ` Karel Zak
2017-01-19 12:15 ` stable/v2.29.1 Bernhard Voelker
2017-01-19 16:09 ` stable/v2.29.1 Bruce Dubbs
0 siblings, 2 replies; 6+ messages in thread
From: Karel Zak @ 2017-01-19 11:35 UTC (permalink / raw)
To: Bernhard Voelker; +Cc: util-linux
On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
> On 01/18/2017 02:12 PM, Karel Zak wrote:
> > The branch stable/v2.29 contains what I want to release as v2.29.1.
>
> General question:
> Is it worth dealing with maintenance branches in the upstream repo?
> I mean, downstream projects can cherry-pick fixes and improvements
> to their own needs anyway. So I think having one upstream mainline
> would be sufficient. WDYT?
I use the branches to create maintenance releases (tarballs), e.g.
v2.29.1.
The goal is to minimize number of patches in downstream packages. So I
guess downstream are happy to have .1 and .2 releases.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stable/v2.29.1
2017-01-19 11:35 ` stable/v2.29.1 Karel Zak
@ 2017-01-19 12:15 ` Bernhard Voelker
2017-01-19 12:46 ` stable/v2.29.1 Karel Zak
2017-01-19 16:09 ` stable/v2.29.1 Bruce Dubbs
1 sibling, 1 reply; 6+ messages in thread
From: Bernhard Voelker @ 2017-01-19 12:15 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
On 01/19/2017 12:35 PM, Karel Zak wrote:
> On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
>> On 01/18/2017 02:12 PM, Karel Zak wrote:
>>> The branch stable/v2.29 contains what I want to release as v2.29.1.
>>
>> General question:
>> Is it worth dealing with maintenance branches in the upstream repo?
>> I mean, downstream projects can cherry-pick fixes and improvements
>> to their own needs anyway. So I think having one upstream mainline
>> would be sufficient. WDYT?
>
> I use the branches to create maintenance releases (tarballs), e.g.
> v2.29.1.
>
> The goal is to minimize number of patches in downstream packages. So I
> guess downstream are happy to have .1 and .2 releases.
I see: as you're also downstream Redhat/Fedora maintainer, you're
effectively doing the downstream work in the upstream repository and
thus share this to other projects. That's nice. ;-)
Thanks & have a nice day,
Berny
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stable/v2.29.1
2017-01-19 12:15 ` stable/v2.29.1 Bernhard Voelker
@ 2017-01-19 12:46 ` Karel Zak
0 siblings, 0 replies; 6+ messages in thread
From: Karel Zak @ 2017-01-19 12:46 UTC (permalink / raw)
To: Bernhard Voelker; +Cc: util-linux
On Thu, Jan 19, 2017 at 01:15:56PM +0100, Bernhard Voelker wrote:
> On 01/19/2017 12:35 PM, Karel Zak wrote:
> > On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
> >> On 01/18/2017 02:12 PM, Karel Zak wrote:
> >>> The branch stable/v2.29 contains what I want to release as v2.29.1.
> >>
> >> General question:
> >> Is it worth dealing with maintenance branches in the upstream repo?
> >> I mean, downstream projects can cherry-pick fixes and improvements
> >> to their own needs anyway. So I think having one upstream mainline
> >> would be sufficient. WDYT?
> >
> > I use the branches to create maintenance releases (tarballs), e.g.
> > v2.29.1.
> >
> > The goal is to minimize number of patches in downstream packages. So I
> > guess downstream are happy to have .1 and .2 releases.
>
> I see: as you're also downstream Redhat/Fedora maintainer, you're
> effectively doing the downstream work in the upstream repository and
> thus share this to other projects. That's nice. ;-)
another downstreams also collaborate on maintenance releases. For
example right now we want to release 2.29.1 before Debian freeze :-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: stable/v2.29.1
2017-01-19 11:35 ` stable/v2.29.1 Karel Zak
2017-01-19 12:15 ` stable/v2.29.1 Bernhard Voelker
@ 2017-01-19 16:09 ` Bruce Dubbs
1 sibling, 0 replies; 6+ messages in thread
From: Bruce Dubbs @ 2017-01-19 16:09 UTC (permalink / raw)
To: Karel Zak, Bernhard Voelker; +Cc: util-linux
Karel Zak wrote:
> On Thu, Jan 19, 2017 at 11:32:20AM +0100, Bernhard Voelker wrote:
>> On 01/18/2017 02:12 PM, Karel Zak wrote:
>>> The branch stable/v2.29 contains what I want to release as v2.29.1.
>>
>> General question:
>> Is it worth dealing with maintenance branches in the upstream repo?
>> I mean, downstream projects can cherry-pick fixes and improvements
>> to their own needs anyway. So I think having one upstream mainline
>> would be sufficient. WDYT?
>
> I use the branches to create maintenance releases (tarballs), e.g.
> v2.29.1.
>
> The goal is to minimize number of patches in downstream packages. So I
> guess downstream are happy to have .1 and .2 releases.
That is certainly true for Linux From Scratch.
-- Bruce
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-19 16:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-18 13:12 stable/v2.29.1 Karel Zak
2017-01-19 10:32 ` stable/v2.29.1 Bernhard Voelker
2017-01-19 11:35 ` stable/v2.29.1 Karel Zak
2017-01-19 12:15 ` stable/v2.29.1 Bernhard Voelker
2017-01-19 12:46 ` stable/v2.29.1 Karel Zak
2017-01-19 16:09 ` stable/v2.29.1 Bruce Dubbs
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.