Re: [PATCH 1/3] correct typo
On Tue, Aug 30, 2016 at 01:15:20PM +0200, Laurent Bercot wrote: > >I will be happy to send a 0/n introductory message (git send-email > >--compose) for any future proposed series, i was not aware that was the > >custom here. Indeed, i wrote this series because i could find no clear > >instructions for how to propose improvements to runit's codebase. > > I'm not sure. This is more of a discussion/questions list than a > patch-sending list; as far as I'm concerned I don't like to receive > patches without some discussion before or at least a little context, but > for runit you'd have to check with the new runit maintainer, if there's > one - Gerrit, before you leave, please designate one, and if the answer > is "it's maintained by Debian/whateverdistro these days", then we'll know > the right place to send patches is the Debian/whateverdistro ML (but the > actual maintainers should still subscribe to our list and read it). Hi, I'm not leaving, just getting older.. Although runit now has a new Debian maintainer, I intend to keep my hands on the runit original upstream package, most probably not applying many changes to it, if at all. I consider it very stable and usable. There's one itch https://bugs.debian.org/641632 actually reported by Daniel back then. A proposed patch is available in the devground branch in the git repository. But with this bug we're actually living for years already, seems to happen very rarely. > >Alternately, if there's a better way to propose changes than sending > >mail to this list, i'd be happy to rewrite code.html to document it, but > >i don't know what it is. > > I'm sorry I don't have a clearer answer. Until we know more precisely how > the future of runit is organized, it's kinda in a limbo state. I'm not against patches to runit, as long as submitters are not demotivated by the fact that it may take some time for me to respond, and probably most of the patches won't make it into my git repository. As I did contributions to git end of 2005 and the years after that, I'd be fine with submitting patches through the mailing list, as they still do. OTOH there's some discussion about the development workflow through mailboxes on the git list lately https://marc.info/?t=14713666535&r=1&w=2 Regards, Gerrit.
Re: [PATCH 1/3] correct typo
On Mon, Aug 29, 2016 at 09:10:24PM -0400, Daniel Kahn Gillmor wrote: > --- > package/CHANGES | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/CHANGES b/package/CHANGES > index da4ea27..d3c419b 100644 > --- a/package/CHANGES > +++ b/package/CHANGES > @@ -146,7 +146,7 @@ Sun, 16 Apr 2006 12:26:50 + > 1.4.1 > Mon, 20 Mar 2006 18:54:41 + >* doc/faq.html: typos; add usercontrol, userservices; minor. > - * src/uidgid.h: use uid_t, git_t (fix setting of multiple groups with > + * src/uidgid.h: use uid_t, gid_t (fix setting of multiple groups with > dietlibc, thx Tino Keitel, http://bugs.debian.org/356016) Ha! This is a nice one, Freudian slip. I guess now we know approximately when runit version control was migrated from CVS to git ;). Regards, Gerrit.
Re: [PATCH 1/3] correct typo
On Tue 2016-08-30 07:15:20 -0400, Laurent Bercot wrote: > Oh, yes, sorry, you even wrote a message (about a listen(1) command) > not too long ago :) Yes, indeed. That program is now halfway done, and i am hoping to share it with people who might be interested. > (Shameless plug: in the meantime, you could take a look at runit's > cousin, s6. ;)) i assume you mean http://www.skarnet.org/software/s6/ . thanks for the pointer. I'm looking at that, and it looks like s6's preferred form of user contact is via github (i've just submitted a trivial pull request). It doesn't seem to do what i'm proposing with listen(8), though, and listen doesn't quite fit there. For one thing, the socket activation it provides doesn't seem to provide for any shared state between concurrent connections without using the filesystem. Maybe that's a plus, but i don't know of many daemons built to work that way -- they often have shared state directly in RAM, where it's arguably more straightforward to synchronize complex data structures (i'm sure you could do something clever with mmapped files and/or ipc, but i'd have to think about the locking/synchronization stuff there a lot more). Anyway, thanks for the pointers. it looks to me like my proposed listen(8) seems to bridge the gap between the daemontools family and the standard daemons that people will want to deploy (which are being updated for systemd) slightly more closely with runit than with s6, but if you're interested in thinking that kind of gap-bridging through with me, i'm certainly interested. Regards, --dkg signature.asc Description: PGP signature
Re: [PATCH 1/3] correct typo
Oh, yes, sorry, you even wrote a message (about a listen(1) command) not too long ago :) I will be happy to send a 0/n introductory message (git send-email --compose) for any future proposed series, i was not aware that was the custom here. Indeed, i wrote this series because i could find no clear instructions for how to propose improvements to runit's codebase. I'm not sure. This is more of a discussion/questions list than a patch-sending list; as far as I'm concerned I don't like to receive patches without some discussion before or at least a little context, but for runit you'd have to check with the new runit maintainer, if there's one - Gerrit, before you leave, please designate one, and if the answer is "it's maintained by Debian/whateverdistro these days", then we'll know the right place to send patches is the Debian/whateverdistro ML (but the actual maintainers should still subscribe to our list and read it). Alternately, if there's a better way to propose changes than sending mail to this list, i'd be happy to rewrite code.html to document it, but i don't know what it is. I'm sorry I don't have a clearer answer. Until we know more precisely how the future of runit is organized, it's kinda in a limbo state. (Shameless plug: in the meantime, you could take a look at runit's cousin, s6. ;)) -- Laurent
Re: [PATCH 1/3] correct typo
On Tue 2016-08-30 04:55:19 -0400, Laurent Bercot wrote:
> Please avoid sending patches to this list with git-send-email, or at
> least please provide a 0/n introductory message to give context. This
> list is read by humans.
I'm a human, and i read this list :)
I will be happy to send a 0/n introductory message (git send-email
--compose) for any future proposed series, i was not aware that was the
custom here. Indeed, i wrote this series because i could find no clear
instructions for how to propose improvements to runit's codebase.
This series is a set of minor changes to improve the web presence for
runit and to make it clearer how to contribute code.
Alternately, if there's a better way to propose changes than sending
mail to this list, i'd be happy to rewrite code.html to document it, but
i don't know what it is.
Perhaps an additional patch to the proposed doc/code.html to add the
--compose argument to git send-email would make that clearer.
If i were to do that, would you prefer i send a new series of patches
(rebased against master so that they apply directly) or a new follow-on
patch to this series ("4/3", as it were) that just adds the --compose
argument to the example of how to send patches?
regards,
--dkg
signature.asc
Description: PGP signature
Re: [PATCH 1/3] correct typo
Please avoid sending patches to this list with git-send-email, or at least please provide a 0/n introductory message to give context. This list is read by humans. -- Laurent
