I'm not worried about time based so much as a general todo, for example: (this is just an example and not an actual opinion on .23) 1. Clean up bugs in new gadgets 2. Make gadget bar/gadget sites more intuitive 3. Remove old gadcon/shelves 4. Make sure supporting documentation is in place for new gadgets (both dev and user docs)
At least then we have a minimum goal to strive for and more devs may get involved if they feel like they know what work is needed currently. If people want to do stuff not in the todo, that's obviously fine, but a lot of devs, including those looking to get involved, are more interested in something/someone else giving them direction rather than just going Leroy Jenkins on development. This is just general good practice/organization/structure. I won't link all of the supporting science/research, but people who are organized and structured including making use of planners, todo lists, and the like are generally more successful, and the same goes for a project/community obviously. Stephen On Jan 10, 2019 10:44 PM, "Simon Lees" <sfl...@suse.de> wrote: Hi On 11/01/2019 05:15, Stephen Houston wrote: > Let me follow that up by saying - That is my opinion on what Enlightenment > needs in a release manager - and of course a release manager can be > different things and done different ways. Further I didn't mean it in any > way to be an indictment of you Simon, you do a good job with the release > procedure. In a project where there doesn't seem to be a clear vision/set > of goals and there are a lot of different philosophies, doing releases > based on a consensus of readiness will be difficult. Mike was successful > in getting releases out because he planned them and determined the work - > and I would like to see someone step up that can be of that mold. > Firstly i'll say if there were multiple devs working on multiple new features i'd probably need to do alot more in this area, for my sanity and tracking as much as anything else. However, currently we have very few developers and with very little work on new features so while I could make a road map that contained "Finish new gadget / shelf system" Then have a release followed by "Re do settings" then have another release. I could look into my crystal ball sprinkle some magic fairy dust and then come up with a time frame for these releases and then we could all get grumpy because the features weren't done when my crystal ball said they would be. So if people are working on new features and can tell me when they think they might be done i'll start on a roadmap, but until then we will have an empty roadmap due to no data. If people just want to work on small things in the meantime thats fine, eventually we will have enough small things and will spin a new release. Raster and I were talking about possibly starting this process for 0.23.0 when I get back from my next travel in a couple of weeks. Partly because bluetooth is now in a good state but mostly because there is a lot of fixes that haven't been backported to 0.22.X and at this point its probably safer and more stable to just create 0.23.0 then start backporting again from there. As an open source release manager I'm never going to say no you can't add that feature if the code is up to scratch and the person is willing to maintain it. At worst I might say a release is coming up real soon I think its best if we wait for the next release which will be likely in X months time. But for now know one has told me they are working on anything and when they think the nothing they are working on will be done so consider us having an empty road map and i'll discuss releases with people and use my discretion to decide when, until such a time as there is enough consistent development going on for me to create a roadmap. > On Thu, Jan 10, 2019 at 8:13 AM Stephen Houston <smhousto...@gmail.com> > wrote: > >> Part of being release manager is that you determine what the schedule >> should be, what needs to be done, what features to focus on, roadmap it, >> etc... Not a sit around until the devs determine in agreement (unlikely) >> that it's time for a release and then just handle the tarballs, upload, and >> news. >> >> On Thu, Jan 10, 2019, 3:41 AM Simon Lees <sfl...@suse.de wrote: >> >>> Hi all, >>> >>> On 10/01/2019 05:45, Mike Blumenkrantz wrote: >>>> Hi all, >>>> >>>> As everyone has likely noticed by now, I haven't been doing much work >>>> lately related to Enlightenment or its releases. There are a number of >>>> factors at play related to this, but the result is that it seems >>> unlikely >>>> I'll be doing anything related to this project for the foreseeable >>> future >>>> and will be focusing more time on various components of EFL. >>>> >>>> If anyone is interested in taking over handling Enlightenment releases, >>>> feel free to get involved. Simon Lees and I have been maintaining a wiki >>>> page (https://phab.enlightenment.org/w/enlightenment_releases/) with >>> the >>>> exact steps needed to handle releases, so at a minimum the mechanics of >>>> releases are already documented. >>>> >>>> >>>> Mike >>>> >>> >>> I'm happy to take this up, given that the rate of new features coming >>> into e is pretty slow I don't have an idea of a timeframe for the next >>> major release when people feel like there is starting to be enough of >>> something start a discussion around the next major release please start >>> it here. >>> >>> In the mean time please backport any fixes and if you think you fix a >>> bug that's either severe or likely to be effecting a lot of people >>> please ping me and i'll put out another point release. But atleast here >>> on X11 the current release seems pretty good. >>> >>> Cheers >>> >>> -- >>> >>> Simon Lees (Simotek) http://simotek.net >>> >>> Emergency Update Team keybase.io/simotek >>> SUSE Linux Adelaide Australia, UTC+10:30 >>> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B >>> >>> >>> _______________________________________________ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >> > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
