On 22/08/2018 12:17, Carsten Haitzler (The Rasterman) wrote: > On Tue, 21 Aug 2018 10:48:19 -0500 Stephen Houston <[email protected]> > said: > > So have to wait 5 weeks to propose something to know if it will be accepted so > you can do some thing you want to do? this is why i am calling it bureaucracy. > be it a vote for or against - it's the same - an approval process. >
I have been away alot of late and have been rather busy inbetween so I may have missed much of the discussion, i'm probably also not someone who is likely to submit a major set of patches to e (at least currently). I am also intentionally discussing this on the mailing list not in phab, discussions get lost in phab someone can copy this here if they want. I think we could make everyone happier by splitting this into 2 separate sections for the sake of giving them a name i'm going to call them "Pre Approval" and "Merge Approval" these are really bad names because by default you would have approval unless people actively have issues and raise them. Let me explain each further bellow. Pre Approval: This can be done at anytime, ideally before you start work on a feature and having pre approval in no way means your feature will make it into the next or any release (See Merge approval below). The process is as simple as write an email to this list (or I guess someone could come up with some way on phab), It would contain what your going to do and some technical details about how you would do it. Then people would have there chance to give feedback like have you thought about doing it this way instead, or No I don't think astroid's belongs in elm. For larger features it could also outline a plan of I am going to do Part A, then merge that then work on part B etc to try and reduce the number of 100+ commit patch sets landing etc. Given that E is an open source project i'd hope we would welcome pretty much every contribution here but the basic idea is after a few days or a week of this first post the developer can start working on the feature knowing that the fundamental idea and design is fine and won't be blocked later on. Merge Approval: I have no idea how often and when this should happen It could be similar to the currently suggested process, it could just be an email with a link to the review in phab, the reasons for rejecting a merge approval could be to do with code quality, not wanting to accept a 100 commit patch 2 days before a feature freeze etc, it would be nice if at this point jenkins or something could run some basic does it build / break badly tests but until then its the submitters responsibility to ensure that there changes don't break make distcheck or have major bugs, introducing a severe regression or breaking the build would be the only conditions where a merge set could be reverted which would send the branch back to the "Merge Approval" State. Hopefully for 90-95% of features a consensus could be reached during discussion of both approvals but for the occasional cases where it can't then someone would trigger a one off "Accept/Reject" or maybe "Accept/Reject/Defer" poll for the key devs to vote on. Someone could choose to keep a list of features that have had pre approval somewhere if they wanted to keep track of everything people are working on, at the same time if your 99% sure your feature will just be accepted and wont impact other people you could skip the "pre approval" but then you run the risk of people raising issues once you have done the work. -- 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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
